A green backup job is useful evidence. It tells you the job reported success. Your next question is whether the selected backups can be restored on a suitable target—and whether that test answers the recovery question your business is asking.
Backup status, verification, a database restore and application recovery are different stages. Keeping them separate helps your team decide what is already known and what still needs testing.
Begin with the recovery your business needs
Before discussing the backup schedule, agree the business question. Which database or application matters? How much recent data could the business afford to lose? How long could it work without that system? Who makes the recovery decision?
These questions are often described as a recovery point objective (the acceptable data-loss window) and a recovery time objective (the time within which service needs to be restored). Microsoft explains how recovery requirements inform the backup strategy in its SQL Server backup and restore overview.
A schedule is easier to assess once the objective is clear. “We take a backup every night” does not, on its own, answer what happens to changes made during the following day or how long the whole recovery process would take.
Find out what the successful job covered
Ask for the database names, backup types, completion times and storage locations behind the status. Check whether the report covers every database you care about or only the jobs that happened to run.
Useful questions for your team include:
- Which databases are covered, and are failures or missed runs visible?
- Where are the backup files, and can the authorised recovery team reach them?
- What retention period applies, and what happens if a required file has already been removed?
- Which files form the selected restore sequence?
- If encryption is used, are the required keys or certificates available through an approved recovery process?
Depending on the recovery model and target recovery point, a restore may require a sequence of full, differential and transaction-log backups rather than one recent file. Ask the administrator to identify the required sequence and any gaps. Microsoft’s restore and recovery overview describes the relationships.
You are asking for a review of the evidence and plan. You are not asking someone to overwrite a production database to see what happens.
Understand what backup verification tells you
SQL Server’s RESTORE VERIFYONLY can check that a backup set is complete and readable without restoring it. Microsoft explicitly states that it does not verify the structure of the data in the backup. It is a useful check with a defined limit, rather than a substitute for an actual restore. Read the RESTORE VERIFYONLY documentation.
Ask which verification was performed, when it ran, which backup set it covered and what result was recorded. A generic “verified” label is not enough to tell you the method or its limits.
Agree an isolated restore test
A planned test needs an appropriate target, access, storage capacity, a compatible restore path and a clear boundary around the source and target environments. The team should agree the selected backup sequence, test goal, validation steps and cleanup before starting.
Ask for a written record that identifies:
- The source database, selected backup sequence and target.
- The test’s start, finish and relevant stage timings.
- What was attempted, what succeeded and what failed.
- Which validation checks ran, and their results or limitations.
- What was excluded, such as application connectivity or a production cutover.
- The follow-up needed before repeating or expanding the test.
A failed test can still provide valuable information. It can expose a missing file, access problem or target limitation while there is time to plan a response. The report should say what happened without turning a limited attempt into proof that every backup is usable.
Keep integrity checks and application recovery separate
An integrity check adds evidence about the restored database, but its scope matters. DBCC CHECKDB checks database integrity; its PHYSICAL_ONLY option performs narrower checks and skips some checks a full run would perform. Ask which options were used and what was covered. See Microsoft’s DBCC CHECKDB reference.
Database checks do not demonstrate that your users can sign in, the application can reach the new location or every business workflow works. Those are additional recovery questions for the teams responsible for the application and its dependencies.
Likewise, a recorded restore duration is not automatically the time needed to restore business service. Retrieving files, arranging infrastructure, approvals, reconnecting applications and validation may also be part of your recovery plan. Treat the test result as evidence about the agreed scenario and date, with those limits recorded.
Decide whether you need a review or a test
Backup & Recovery Assessment compares backup metadata and practices with your stated recovery objectives. It can identify gaps and help plan restore testing; it does not execute a restore test.
Recovery Proof is a Managed service that attempts one agreed backup chain on an isolated target in your environment and records what happens. Its prerequisites are checked before quoting or payment. A documented failure or timeout can complete an executed test; unmet prerequisites do not count as an executed test. It does not certify all backups or establish end-to-end application recovery.
If you are unsure which evidence is missing, use the service finder or tell us about your recovery question. Keep backups, credentials and sensitive records out of the enquiry form. We can agree how to handle evidence after the scope is clear.
This guide is published by BriteThought. Technical references are linked where relevant. Service details and terms govern any engagement; this guide does not change them.
