How do you prove your AWS backups actually restore?
By the Keel team · Last checked · 5 min read
Short answer
You prove an AWS backup works by restoring it to a separate, scratch copy, checking that the data is complete and recent, pointing your application at it, and timing the whole process against your recovery target. Do it on a schedule, at least quarterly, and keep a short written report each time. A backup you have never restored is a hope, not a plan.
90%
of organisations confident they could recover
Source: Veeam, 2026
28%
of ransomware victims fully recovered their data
Source: Veeam, 2026
35 days
Longest RDS automated backup retention
Source: AWS docs
Why is having AWS backups not enough?
Having backups is not enough because many things can stop a backup from becoming a working system: missing tables, a broken encryption key, a restore that takes far longer than anyone expected, or a team that has never done it under pressure.
You only find these out by restoring.
The gap between confidence and reality is large. Veeam's Data Trust and Resilience Report 2026 found that 90% of organisations were confident they could recover from a cyber incident, yet only 28% of those hit by ransomware fully recovered all affected data.
What counts as proof that an AWS backup restores?
Proof that a backup restores comes in levels: the backup exists, the restore completes, the data is right, the app works on it, it is fast enough, and the team can do it without help.
Proof comes in levels. Each level catches problems the one before it misses.
| Level | What you check | What it catches |
|---|---|---|
| 1. Backup exists | Snapshots or recovery points are being created | Backups switched off or failing |
| 2. Restore completes | A restore job finishes without error | Key, permission or configuration problems |
| 3. Data is right | Row counts, latest records, key tables present | Partial or stale backups |
| 4. App works on it | Your application connects and a smoke test passes | Missing extensions, users, settings |
| 5. It is fast enough | Total time measured against your RTO | Restores too slow for your promises |
| 6. People can do it | Someone other than the usual person follows the runbook | Knowledge held by one person |
Most teams stop at level 1. Getting to level 4 on a schedule puts you ahead of most of the market. Level 6 is what a disaster recovery drill is for.
How do you test a restore, not just a backup?
You test a restore by actually creating a new database or volume from the backup, in an isolated place where it cannot be confused with production, then running checks against it.
- Pick a recovery point, ideally the latest one and occasionally an older one.
- Restore it to a new, private resource with a clear name such as
restore-test-2026-10. - Check the data: compare row counts on key tables and confirm the newest records are as recent as expected.
- Point a test copy of your application at it and run a smoke test, such as logging in and loading a dashboard.
- Record how long each step took and anything that went wrong.
- Delete the restored resource so it does not run up a bill.
For Amazon RDS, the step-by-step RDS restore guide has the exact commands. AWS Backup can also run scheduled restore tests for you, with some gaps covered in what AWS Backup restore testing does and misses.
How often should you test database restores?
Test database restores at least once a quarter, and monthly for databases your business cannot run without.
Also test after major changes such as an engine upgrade, a new encryption key or a large schema change, and always within your backup retention window, so you are testing backups you could actually use.
| Data | Suggested frequency | Why |
|---|---|---|
| Main production database | Monthly | Your product does not work without it |
| Secondary databases and caches with state | Quarterly | Needed, but recoverable more slowly |
| S3 buckets with customer files | Quarterly, sample files | Versioning and replication can hide gaps |
| After an engine upgrade or key change | Once, straight away | The most common cause of surprise failures |
What should a backup restore test report include?
A restore test report should record the recovery point tested, the time to a working app, the checks run, anything that failed, who ran it, and the fixes needed.
A restore test report should be short enough that someone actually reads it. One page is plenty.
- Date, database and recovery point tested.
- Time from starting the restore to the application working on it.
- The checks run and their results, such as row counts and the newest record time.
- Anything that failed or needed a manual fix.
- Who ran it, and whether they followed the runbook without help.
- Actions to fix before the next test.
These reports are also useful evidence when an enterprise customer asks how you handle backups, as covered in how to answer a security questionnaire.
What are the common reasons AWS restores fail?
Restores most often fail on networking, default parameter groups, missing encryption key permissions, secrets that still point at production, slow restores of large databases, and knowledge held by one person.
- The restored database lands in the wrong network or security group and nothing can connect.
- Default parameter groups are used, so settings or extensions differ from production.
- Encryption keys or their permissions are missing in the account or region you restore into.
- Secrets and connection strings point at production, not the restored copy.
- Large databases take much longer than expected, breaking the recovery time you promised.
- Only one person knows the steps, and they are on holiday.
None of these show up until you restore. That is the whole argument for testing.
How do RPO and RTO fit into backup testing?
Your recovery point objective (RPO) is how much data you can afford to lose, and your recovery time objective (RTO) is how long you can afford to be down.
A restore test is how you find out whether you meet them. If you have not set them yet, RPO and RTO in plain English shows how to pick sensible numbers for a small team.
Can you prove your AWS backups restore today?
Tick each statement you could back up with a dated report.
- You restored a production backup in the last 90 days.
- You checked the restored data, not just that the job finished.
- Your application ran on the restored copy.
- You timed the restore against your recovery time objective.
- Someone other than the usual person ran it from the runbook.
- The result is written down where an auditor or customer could see it.
Decision point: Fewer than four ticks: you have backups but not proof. Schedule a restore test this month and repeat it at least quarterly.
Sources
- Veeam, Data Trust and Resilience Report 2026 (2026)
- AWS docs, Restoring a DB instance to a specified time for Amazon RDS (checked October 2026)
- AWS docs, AWS Backup restore testing (checked October 2026)
- AWS Well-Architected, Perform data backup validation and recovery testing (checked October 2026)
Keep reading
Keel is an AWS release and recovery operations service for SaaS teams of 3 to 15 developers, provided by Bargainn Services Ltd, a UK company registered at Companies House (16497746). Registered office: 3rd Floor, 86-90 Paul Street, London, EC2A 4NE, United Kingdom.