What’s the issue?
SQL Server supports an option called WITH CHECKSUM on backup and restore commands, which causes SQL Server to verify page checksums as the database is read during a backup, calculate a checksum across the backup stream itself, and verify all of these checksums during a restore or RESTORE VERIFYONLY operation. This protects against corruption introduced during backup, transit, or storage of the backup file.
The server level configuration option backup checksum default controls whether WITH CHECKSUM is applied automatically to every backup and restore that does not explicitly specify a checksum option. The default value is 0, meaning checksums are not used unless explicitly requested in each backup command.
This finding identifies instances where backup checksum default is set to 0, leaving the protection off by default for any backup that does not specifically include it.
Why is this a problem?
Without backup checksums, corruption that occurs during the backup process or while the backup file is at rest can go undetected. SQL Server reads pages from the database, writes them to the backup, and stores the backup, all without verifying that the data on the way through is consistent with what was originally written. Corruption introduced by faulty memory, storage, network paths, or backup software can quietly produce a backup that cannot be restored successfully when needed.
The WITH CHECKSUM option also catches corruption that already exists in the source database, since SQL Server verifies page checksums as it reads. This provides an additional layer of corruption detection that complements DBCC CHECKDB, often surfacing issues earlier and during routine activity rather than only during scheduled integrity checks.
The default off behavior means that organizations must remember to specify WITH CHECKSUM in every backup script, maintenance plan, and third-party backup tool configuration. In practice, some backups are taken with the option and others are not, producing an inconsistent protection profile that depends on which mechanism took the backup. Administrators reviewing backup history may not realize that some backups offer the protection while others do not.
Setting the default to enabled removes the dependency on every individual script and tool remembering to include the option. Every backup, including those taken by ad hoc commands, vendor software, and maintenance plans, is automatically protected, and the protection is consistent across the environment.
What should you do about this?
Enable CHECKSUM as a backup defualt with EXEC sp_configure ‘backup checksum default’, 1; RECONFIGURE;. The change takes effect immediately for all subsequent backups and restores.
The performance impact of backup checksums is small for most workloads, typically a few percent of additional CPU during the backup operation. The protection benefit is substantial, so the tradeoff strongly favors enabling the setting in nearly all environments. Test in a non production environment first if you have unusually constrained CPU on the SQL Server host or if backup duration is already at the limit of available windows.
Confirm that existing backup scripts and maintenance plans are compatible with the change. Most are unaffected, since the setting only changes the default behavior when no checksum option is explicitly specified. Backup scripts that already include WITH CHECKSUM continue to work as before, and scripts that previously included WITH NO_CHECKSUM still override the new default.