Database restore testing is the only reliable way to know a backup will bring your business back. A green "backup succeeded" message tells you a file was written. It does not tell you the data is complete, that your application can read it, or how long recovery will take. We recommend a scheduled restore test into a separate environment, with a written result every time.
Why is a successful backup job not proof you can recover?
Backup tools check that they wrote something. They rarely check that a person can use it. Microsoft's documentation for SQL Server is clear about this. Its RESTORE VERIFYONLY command checks that a backup set is complete and readable, but the same page says it "does not attempt to verify the structure of the data" in the backup.
Recovery also depends on things outside the database file: encryption keys, connection settings, scheduled jobs and the people who know the steps. A backup can be perfect and the business can still be down because one of those pieces is missing.
Ransomware raises the stakes. The CISA #StopRansomware Guide tells organizations to keep offline, encrypted backups of critical data and to regularly test their availability and integrity in a disaster recovery scenario. Testing is part of the advice, not an extra.
What should a database restore test actually prove?
A useful test answers business questions, not only technical ones. We write these down before the first test so everyone agrees on what a pass looks like:
- Recovery point. How much recent data could we lose? Compare the newest record in the restored copy with production at the time of the backup.
- Recovery time. How long from "start restore" to "staff can work"? Time the whole run, including application setup and checks.
- Completeness. Do row counts for key tables match a report taken at backup time? Pick the tables the business depends on, such as customers, orders, invoices and audit logs.
- Usability. Can a real user sign in to a test copy of the application and finish one normal task, such as opening a customer record or running a report?
- Integrity. Run the database's own consistency check on the restored copy. For SQL Server that is DBCC CHECKDB. Other engines have their own equivalent.
If any of these fail, the backup is not yet a recovery plan. Fix the gap and test again.
How often should you run a restore test?
No single schedule fits every system. Our advice is to tie frequency to how much a lost day would hurt. For a core system like a CRM, ERP or customer portal, we suggest a full restore test at least once a quarter, plus a test after any major change: a database version upgrade, a move to a new host, a new encryption setup or a new backup tool.
Also check how long backups are kept. On Amazon RDS, the automated backup retention period for a DB instance can be set from 0 to 35 days, and 0 turns automated backups off. An instance created through the AWS CLI or API defaults to 1 day if no value is set, while the console default is 7 days. If a problem goes unnoticed for longer than your retention window, the clean copy you need may already be gone. For longer needs, plan manual snapshots or a separate backup service.
What breaks when you restore into a new server?
Many restores do not overwrite the old database. They create a new one. AWS documents that a point-in-time restore of an RDS instance creates a new DB instance, which starts with the default security group, the default subnet group and the default DB parameter group. That is a safe design, but it means the restored database will not behave like production until someone reapplies the right network rules and settings.
This is where the application side matters. During a test, check:
- Connection strings and secrets. Does the application know the new host name, and are passwords and keys stored somewhere the team can reach during an outage?
- Network access. Can the application servers reach the new database, and is it closed to everyone else?
- Scheduled jobs and integrations. Do nightly imports, webhooks and sync jobs point at the right database, and will any of them send duplicate messages after recovery?
- Users and permissions. Do service accounts and database roles exist on the restored copy?
Write each step in a short runbook. The goal is that someone other than the original developer can complete the restore.
What should you ask your software vendor or IT partner?
If someone else built or runs your application, ask for evidence, not assurances. Five questions cover most of it:
- When was the last full restore test, and can we see the written result?
- What recovery point and recovery time did that test achieve?
- Where are the backups stored, and is at least one copy offline or isolated from the main account?
- Who holds the encryption keys and admin credentials needed to restore?
- Is there a runbook, and has anyone other than its author used it?
Clear answers show a team that has practiced recovery. Vague answers are a sign to schedule a test together. We include restore tests and runbooks in the custom software and application development work we deliver. We can also add checks with workflow automation so a failed backup raises an alert instead of going unnoticed.
Frequently asked questions
It is restoring a backup into a separate environment and checking that the data is complete, the database is consistent and the application can use it. The test also measures how long recovery takes from start to finish.
No. Commands like SQL Server's RESTORE VERIFYONLY check that a backup set is complete and readable, but Microsoft states the command does not verify the structure of the data inside. A real restore plus a consistency check gives a much stronger answer.
No. Restore into a separate, isolated environment so a failed test cannot damage live data or send messages to customers. Many cloud restores already create a new database instance for this reason.
Base it on how long a problem could go unnoticed and on any record rules your industry follows. Check your platform limits too. Amazon RDS automated backups can be kept for up to 35 days, so longer retention needs manual snapshots or a separate backup service.
Sources
- Microsoft Learn: RESTORE Statements - VERIFYONLY (Transact-SQL)
- CISA: #StopRansomware Guide
- AWS: Amazon RDS backup retention period
- AWS: RestoreDBInstanceToPointInTime API reference
Test your restore before you need it
Tell us which systems hold your business data. We will run a restore test with your team, measure recovery time and data loss, and leave you with a runbook anyone on the team can follow. We can also connect backup alerts through workflow automation.
