SQL SERVER – Check Backup Reliability

Backup Reliability needs a successful restore followed by integrity and application validation. Customers ask whether they can skip that exercise.

Preserved fittings are assembled and inspected in a separate test cabinet.

  1. Restore to an isolated test database with distinct file paths, preserving the production database.
  2. Include the required full, differential and log sequence to the intended recovery point.
  3. Supply required encryption certificates or keys and validate server-level dependencies.
  4. Run the appropriate integrity checks and reconcile important application data and behavior.
  5. Record elapsed recovery time and repeat tests as the recovery plan changes.

RESTORE VERIFYONLY checks completeness, readability and available checksums. It does not restore the database. It also does not fully validate database structure or business meaning. Use it as a preliminary check.

I previously mentioned production or development as restore targets. A separate controlled recovery environment avoids overwriting a working production database. Repeatable restore testing provides stronger evidence. Successful backup commands, file existence and file size don’t establish the recovery objective.

Keep test evidence, required media and keys together in the recovery plan. Validate the intended restore sequence. Confidence comes from demonstrated recovery.

Reference: VERIFYONLY capabilities and limits.

Related reading

A readable backup set is not demonstrated recoverability, it is one prerequisite for a tested recovery.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.


Discover more from SQL Authority with Pinal Dave

Subscribe to get the latest posts sent to your email.

SQL Backup and Restore, SQL Scripts, SQL Server
Previous Post
SQL SERVER – Who Dropped Table? Part 2
Next Post
Which Tables Are Huge: Rows Versus Size in SQL Server

Related Posts

1 Comment. Leave new

  • Restoring database just to check if backup is valid may be not enough. DBCC CHECKDB may reveal corruption in database restored from correct backup. Been there, seen that :)
    Also, checking backup: should it be done on licensed instance?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.