Use backup checksums and RESTORE VERIFYONLY as early integrity checks, but do not treat either as proof that every database object is logically consistent or that the recovery procedure works. The strongest test is restoring the backup on another instance and checking the restored database.
Last updated: October 3, 2026.
BACKUP DATABASE Sales
TO DISK = 'E:\SqlBackups\Sales-full.bak'
WITH CHECKSUM, COMPRESSION, STATS = 10;
RESTORE VERIFYONLY
FROM DISK = 'E:\SqlBackups\Sales-full.bak'
WITH CHECKSUM;
DBCC CHECKDB ('Sales') WITH NO_INFOMSGS;BACKUP ... WITH CHECKSUM validates available page checksums while reading pages and writes a checksum for the backup stream. RESTORE VERIFYONLY checks that the backup set is complete and readable without restoring it.
Know what each check proves
Microsoft’s backup-checksum guidance explains how CHECKSUM is enabled for backup and restore. Its RESTORE VERIFYONLY reference lists checks such as readable volumes, backup completeness, page header fields, and stored media checksums.
Neither command runs the full set of logical and physical consistency checks performed by DBCC CHECKDB. A successful verification also does not test file relocation, permissions, encryption certificates, log-chain recovery, application startup, or the time required to restore.
Add scheduled test restores
Regularly restore representative backups to a separate instance, run DBCC CHECKDB, and exercise the recovery steps your runbook requires. Microsoft’s DBCC CHECKDB documentation describes the object, allocation, catalog, and indexed-view checks it performs.
Continue with restoring a backup to another server, restoring under a different name, and resolving backup permission errors.
