Click here to monitor SSC
  • Av rating:
  • Total votes: 41
  • Total comments: 5
Grant Fritchey

Backup Verification: Tips for Database Backup Testing

06 December 2011

A Backup system is merely part of a recovery system. If your backups can't be used to recover the database, then they're useless. Do you regularly make sure that you can restore a database from your backups?

I know that you’re probably running regular database backups. Most people do. Some don’t, but that’s a different discussion. There’s an old saying “Your data is only as good as your last backup.” That’s very true. But, there’s a little known corollary to this: “Your backups are only as good as your last restore.” It’s great that you’re backing up your databases, but you need to do more. You need to test your backups.

The ultimate test for any backup is a restore to a server, but there are a few other things you can do as well. Let’s go over them in the order of their importance in validating that the backups you have are good.


The first thing you can do to ensure you have a good backup is to include CHECKSUM in the WITH clause of your backups, like this:

BACKUP DATABASE AdventureWorks2008R2
TO DISK = 'c:\bu\MovieManagement.bak'

The CHECKSUM is a mathematical construct of a fixed length that gets generated from the page of data. The math will always arrive at the same number for the same page of data. The CHECKSUM value gets written with the page during the backup process and it validates that the page is intact prior to writing it to the backup. This is a good way to validate the media as you do the backup. Then, you can use the CHECKSUMs later during a RESTORE VERIFYONLY operation (see below) to validate the backup media is intact.

This does come with additional cost. It adds overhead, so if you have a very large backup that currently takes a long time, it’ll take longer. But, if you have a very large backup that takes a long time, wouldn’t you want to know that the pages being written to disk are actually intact?


Another way you can ensure that your backups are good is to use RESTORE VERIFYONLY like this:

FROM DISK = 'c:\bu\MovieManagement.bak';

VERIFYONLY will process the backup and perform several checks. First, it can find and read the backup file. Believe it or not, that’s a good first step. Far too many people will assume that they can restore a file that is either incomplete or inaccessible. It also walks through the CHECKSUM information if you used CHECKSUM in the backup (see above). This will validate that the backup media is in place. That can be a costly operation if the backup file is very large, so I don’t know that I’d run this check from my production system if I could help it. Finally, VERIFYONLY checks some of the header information in the backup. It doesn’t check all the header information, so it’s still possible for a backup to pass VERIFYONLY but still not restore successfully to the server. Which brings up the best way to validate your backups, RESTORE.


Like I said at the beginning of this, the best way to know that your backup is intact is to run a RESTORE. It’s very much like taking off and nuking the site from orbit, it’s the only way to be sure. If you successfully run a RESTORE of a backup, then you know that backup is intact. Yes, other things might happen to the file later, but for a moment in time, you’ve validated that your backup and storage mechanisms are working. By the way, notice that all these checks are only concerned with the backup structure and the database structure. What if what you’re backing up is junk?


You might think that running CHECKDB should be done first, prior to running a backup. And, in most circumstances, you’d be right. However, it is possible to find yourself in a situation where DBCC CHECKDB is extremely expensive. You might not have a big enough maintenance window to run the CHECKDB and get a backup completed. In that case, run the backup, it’s the more important operation. But, you can still validate your database. Because the backup is an exact copy of the database, if there are corruption issues (not found by the CHECKSUM) they’ll be backed up as well. Running a RESTORE and then running CHECKDB will enable you to ensure that your backup is intact and that the data in the backup is intact as well.


You know that you need to protect the information for your organization. You’re already running your backups. Now take the next step and ensure that those backups are good. Test them. Just remember, that the very best test is a complete restore.

Easier verification with SQL Backup Pro
Want quick, easy backup verification? Make checking for corruption an easy step in your normal backup and restore routines with SQL Backup Pro's automated integrity checks. Find out more.

Grant Fritchey

Author profile:

Grant Fritchey is a SQL Server MVP with over 20 years’ experience in IT including time spent in support and development. Grant has worked with SQL Server since version 6.0 back in 1995. He has developed in VB, VB.Net, C# and Java. Grant has authored books for Apress and Simple-Talk, and joined Red Gate as a Product Evangelist in January 2011. Find Grant on Twitter @GFritchey or on his blog.

Search for other articles by Grant Fritchey

Rate this article:   Avg rating: from a total of 41 votes.





Must read
Have Your Say
Do you have an opinion on this article? Then add your comment below:
You must be logged in to post to this forum

Click here to log in.

Subject: CHECKSUM and backup compression
Posted by: Skreeby (view profile)
Posted on: Wednesday, January 11, 2012 at 10:09 AM
Message: Thanks for the post. I was looking into adding WITH CHECKSUM to our backup jobs and noticed that WITH CHECKSUM is on by default when using backup compression.

Subject: Compression
Posted by: Grant Fritchey (view profile)
Posted on: Tuesday, January 17, 2012 at 5:10 AM
Message: Yes, if you're using SQL Server compression, it turns it on for you.

Subject: GUI vs coding
Posted by: stevegs (view profile)
Posted on: Thursday, January 26, 2012 at 8:48 AM
Message: Something not touched on in your article is what the 'automatic' process of clicking 'verify database' in a maintenance plan task does - does it create the checksum or 'merely' perform a verify only after backup? Or something else partially or completely different? (Yes, I could look it up, but for those who found your article in a panic g**gle search)

Subject: Re: GUI vs coding
Posted by: Grant Fritchey (view profile)
Posted on: Thursday, January 26, 2012 at 12:16 PM
Message: Yes, it does just run a RESTORE VERIFY_ONLY process. Excellent point. I should have covered that. Thank you for bringing it up.

Subject: Backup Verification: Tips for Database Backup Testing
Posted by: nesliemaratas (view profile)
Posted on: Monday, February 1, 2016 at 1:27 AM
Message: Thanks for this article. I have read one more article on DBCC, WITH CHECKSUM and VERIFY ONLY

Simple-Talk Database Delivery

Patterns & Practices Library

Visit our patterns and practices library to learn more about database lifecycle management.

Find out how to automate the process of building, testing and deploying your database changes to reduce risk and make rapid releases possible.

Get started

Phil Factor
How to Build and Deploy a Database from Object-Level Source in a VCS

It is easy for someone who is developing a database to shrug and say 'if only my budget would extend to buying fancy... Read more...

 View the blog

Top Rated

SQL Server Statistics Basics
 Distribution statistics are used by SQL Server's Query Optimiser to determine a good execution plan for... Read more...

Clone, Sweet Clone: Database Provisioning Made Easy?
 One of the difficulties of designing a completely different type of development tool such as SQL Clone... Read more...

Database Lifecycle Management: Deployment and Release
 So often, the unexpected delays in delivering database code are more likely to happen after the... Read more...

The PoSh DBA: Assigning Data to Variables Via PowerShell Common Parameters
 Sometimes, it is the small improvements in a language that can make a real difference. PowerShell is... Read more...

Issue Tracking for Databases
 Any database development project will be hard to manage without a system for reporting bugs in the... Read more...

Most Viewed

Beginning SQL Server 2005 Reporting Services Part 1
 Steve Joubert begins an in-depth tour of SQL Server 2005 Reporting Services with a step-by-step guide... Read more...

Ten Common Database Design Mistakes
 If database design is done right, then the development, deployment and subsequent performance in... Read more...

Temporary Tables in SQL Server
 Temporary tables are used by every DB developer, but they're not likely to be too adventurous with... Read more...

Concatenating Row Values in Transact-SQL
 It is an interesting problem in Transact SQL, for which there are a number of solutions and... Read more...

SQL Server Index Basics
 Given the fundamental importance of indexes in databases, it always comes as a surprise how often the... Read more...

Why Join

Over 400,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.