{"id":3278,"date":"2015-12-09T08:04:32","date_gmt":"2015-12-09T13:04:32","guid":{"rendered":"https:\/\/academy.sqlbak.com\/?p=3278"},"modified":"2023-10-17T05:19:16","modified_gmt":"2023-10-17T09:19:16","slug":"checksum-and-verifyonly","status":"publish","type":"post","link":"https:\/\/academy.sqlbak.com\/checksum-and-verifyonly\/","title":{"rendered":"CHECKSUM and VERIFYONLY"},"content":{"rendered":"

A database backup process is an integral part of a recovery system. All backups must be operable so that they can be restored at any time. It is recommended to make regular database backups and the majority of SQL Server users actually follow this recommendation. But how can you be sure that you will be able to restore the database from the backups? Sometimes backups can be corrupted. This is why it is useful to test database backups for their integrity. Of course, the best check for any backup is a restore to a server, but there are some other, less radical ways of doing it. Let’s explore CHECKSUM and VERIFYONLY options.<\/p>\n

CHECKSUM<\/h2>\n

The checksum is a value calculated from the data page bytes. Equal data pages have equal checksums. To make the checksum recorded on each page of the backup file the “WITH CHECKSUM” option needs to be added to the “BACKUP DATABASE” command.<\/p>\n

Using a CHECKSUM option makes the database backup process longer, but if the database is really large it is better to use the CHECKSUM option and be confident that all pages are written to the disk and ready for the restore process. To check the checksum value use the following SQL Server option:<\/p>\n

VERIFYONLY<\/h2>\n

The VERIFYONLY \u00a0option does not restore the backup, it only verifies it. The VERIFYONLY performs several checks, such as:<\/p>\n