Database restore testing checks whether a backup can bring back the data and behavior your application needs. Start by restoring into an isolated destination, then verify representative records, permissions, files and customer actions. A completed restore job is one piece of evidence; the business also needs to know when the product becomes usable and how much recent work is missing.
This guide gives a small SaaS team a recovery-drill plan and a fictional timeline for interpreting the result. It does not report a test of your application or a MUBBITS customer benchmark. Use your provider’s current restore procedure and agree the target environment, access and cleanup responsibilities before running a drill.
Key takeaways
- Set recovery-time and data-loss targets for a named customer workflow.
- Include file storage, configuration and external dependencies in the recovery inventory.
- Restore into an isolated environment with outbound actions controlled.
- Time application validation as well as the database restore.
- Keep evidence, fix the gaps and repeat the affected checks after a meaningful change.
Define what recovered means for your SaaS
Pick an essential workflow and the people who must be able to complete it. In a hypothetical document-review SaaS, a customer signs in, reaches the right workspace, opens an uploaded file and sees its review state. A reviewer can add a comment without exposing the file to another workspace. Those actions describe a useful recovery outcome.
Agree a recovery time objective, or RTO: the intended time to restore the required service after the defined disruption. Agree a recovery point objective, or RPO: the data-loss window the business intends to tolerate. Record the incident and recovery assumptions behind both numbers. Different workflows may justify different targets.
AWS’s reliability guidance recommends periodically recovering backed-up data to verify integrity and the recovery process against RTO and RPO. Translate that principle into acceptance checks for your application. Ask who decides the service is usable and what evidence they need.
Inventory the dependencies that the backup actually covers
For the document-review example, the database contains workspace memberships and references to uploaded files. The files themselves may live in object storage. Identity settings, encryption access, application configuration and a deployed version are also needed to exercise the customer journey.
Check the scope of each recovery mechanism. Supabase documents that its database backups do not include the objects stored through the Storage API. Its restore-to-a-new-project feature creates a database copy and lists settings and services that require separate reconfiguration. Other providers and backup products have their own boundaries; record the ones that apply to your system.
Create a dependency inventory before the drill so that a missing file or configuration value becomes a visible requirement rather than a surprise late in an incident.
| Dependency | Question to answer | Validation to plan |
|---|---|---|
| Database records | Which backup or recovery point can restore the required schema and data? | Find known workspace, document and review records with their relationships intact |
| File bytes | Which process protects the uploaded objects and their versions? | Open representative files and compare them with the agreed source evidence |
| Identity and permissions | Which users, roles and identity settings are restored or reconfigured? | Use authorized test accounts and verify workspace boundaries |
| Application and configuration | Which version and settings work with the recovered schema? | Start the selected app build and exercise its critical routes |
| External connections | Which credentials and destinations must stay isolated during testing? | Use sandbox or blocked destinations for payments, email and webhooks |
| Background work | Which jobs would run automatically after startup? | Keep scheduling controlled until duplicate or unintended actions are excluded |
Prepare an isolated destination and a small validation set
Name the environment and responsible operator in the drill plan. Confirm the restore destination is separate from the live application, and verify the identifiers before any restore command. Follow the provider’s supported process for the database engine, backup type and version in use.
A restored system can contain real addresses, payment references or scheduled tasks. Restrict access and control outbound email, notifications, webhooks and workers before starting the application. Use approved test accounts and sandbox integrations where possible. Production-derived information still needs the same care in a recovery environment.
Choose a compact validation set in advance. For the fictional document service, that could include two workspaces, a reviewer and customer account in each, a recent document, an older archived document and files with known expected contents. Keep the private evidence needed to compare the restored state, and identify the records that should exist at the selected recovery point.
Prepare a record of the steps and their expected outcomes. Write down a stop condition for an unexpected destination, missing authorization or an external action that cannot be safely contained. This makes the exercise reviewable for the owner and repeatable by a different operator.
Measure the whole recovery path
Start the clock at the incident point defined in the plan. Record access preparation, resource restoration, configuration, application startup and validation separately. When the database becomes available, continue the exercise until the agreed customer workflow has been checked.
The following timeline is entirely hypothetical. Assume the team has a 15-minute RPO and a 60-minute RTO for the document workflow. Its chosen recovery point is 09:40 UTC, the simulated incident is 10:00 UTC, and no later point-in-time recovery is available for this exercise. The database is online at 10:32 and the application checks finish at 10:52.
Under those assumptions, the selected recovery point is 20 minutes before the incident, exceeding the intended 15-minute data-loss window. The workflow becomes usable after 52 minutes, within the intended 60-minute recovery time. These are independent conclusions. Completing the restore faster would not recover the missing interval.
| Milestone | Example time or target | What it establishes |
|---|---|---|
| Data-loss target | RPO: 15 minutes | The intended limit for the missing-work window |
| Service-recovery target | RTO: 60 minutes | The intended time to restore the agreed workflow |
| Selected recovery point | 09:40 | The state available to this exercise |
| Simulated incident | 10:00 | The defined start of the recovery clock |
| Database available | 10:32 | 32 minutes elapsed; application acceptance remains incomplete |
| Customer workflow verified | 10:52 | 52 minutes elapsed; the example meets its RTO |
| Data-window assessment | 20 minutes before the incident | The example misses its 15-minute RPO; investigate the protection strategy |
Could your customers use the app after a restore?
Bring your recovery targets and current backup plan. We can help scope an isolated drill that checks data, dependencies and the customer journey.
Validate behavior after the data is restored
Follow the selected customer journey in the recovered environment. Check that the expected account reaches the expected workspace, that a private document belongs to the correct workspace and that the associated file opens. Verify a restricted account cannot access the same private record. Use the test expectations rather than relying only on row totals or a successful health endpoint.
Keep an eye on the surrounding application. A restored database may start while a worker is disabled, file links are invalid or the frontend expects a different schema. Record each issue with its observed effect and the next verification needed. Avoid solving an inconsistency by changing recovered records until the original evidence has been preserved.
Separate missing data from missing configuration. If the record points to an absent file, investigate storage recovery. If sign-in redirects to the wrong environment, investigate identity configuration. If access differs between tenants, inspect the restored authorization rules and application context.
A planned move to a different platform needs additional work around transformations, identifiers and cutover. Use a migration rehearsal for that scenario rather than treating a same-system recovery drill as proof that every destination will work.
Use restore automation with application acceptance checks
AWS Backup offers scheduled restore testing for supported resources and an optional validation step. Its documentation also describes the lifecycle of test resources and the costs associated with testing and the restored resources. Read the current service-specific guidance before deciding what to automate.
Automation can make the infrastructure part repeatable. Your application still needs checks that express its own customer behavior. Retain the restore job result, selected recovery point and application validation together, so a report can distinguish infrastructure restoration from a completed product exercise.
Choose a cadence based on the product’s change rate, operational needs and recovery targets. Repeat affected checks after changes to the schema, file strategy, identity setup or recovery procedure. If the drill cannot meet its targets, describe the gap and the proposed change; a calendar entry alone does not resolve it.
AWS Backup: restore testing, validation and test-resource lifecycle
Close the drill with an evidence record and cleanup owner
Record the environment, operator, selected recovery point, application version, step timings, validation results and unresolved findings. Label the outcome for each target: met, missed or not demonstrated. Include the next action and an owner for each gap. Keep sensitive screenshots and customer-derived data in the agreed private location.
The plan should also identify who removes test resources and access, when that happens and how cleanup is verified. Account for restored storage, temporary application instances, credentials and retained evidence according to the agreed policy. Preserve anything still needed to investigate a finding before removing the environment.
MUBBITS can help review the infrastructure and application dependencies behind a recovery plan. Bring the current backup approach, the customer workflow you need to preserve and the targets the business wants to evaluate. The first useful outcome is a scoped drill and a clear record of what it has demonstrated.
Discuss cloud architecture and operational recovery
Review the resource and ownership decisions behind cloud costs
Frequently asked questions
How often should we test a database restore?
Choose a cadence from the criticality of the workload, the rate of change and the recovery targets. Also repeat affected checks after meaningful changes. Agree who runs the drill, who reviews the result and how a missed target becomes work.
Does a successful restore job prove our SaaS is recovered?
It proves the outcome reported by that restore operation. The application may still depend on files, configuration, identity, workers or integrations. Verify the customer workflow that defines the recovery target.
What is the difference between RTO and RPO?
RTO describes the intended time to restore the agreed service. RPO describes the intended data-loss window. A drill can meet one while missing the other, so record the recovery clock and the selected recovery point separately.
Should we restore over production to test the backup?
Plan an isolated destination and follow the provider’s supported restore procedure. Confirm the destination identifiers, access and outbound controls before running the exercise. A live incident recovery requires its own authorized operational plan.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.