We have restored thousands of cloud workloads for customers and watched plenty of green dashboards turn into restores that never finished on the day it counted. This is how to test backups so the next restore you run under pressure is one you’ve already rehearsed in a calm window.
What testing a backup shows that a backup job can’t
A green backup job tells you the copy operation ended without an error. It can't tell you whether the application actually runs on that copy, or how long getting it there takes. Only a restore answers those questions.
Job status wins by default because it’s free. Every dashboard reports it, and it is green most mornings. A restore costs engineer hours and a test window, so it gets deferred, and the RTO in the runbook stays a number nobody has clocked.
According to Eon's 2026 Cloud Data Infrastructure Report, 75% of executives say their recovery time estimates rest on assumptions that have never been tested.
Gartner's 2026 Hype Cycle for Backup and Data Protection Technologies draws the same line. It names limited testing as a cause of RPO and RTO uncertainty, and one that boards now expect to see closed with evidence.
What you need before testing backups
Five things have to exist before the first test, and the recorded baselines are usually the ones missing.
- A current inventory of protected resources: Continuous discovery through Cloud Backup Posture Management (CBPM) keeps the list honest as accounts and regions grow.
- A restore account: A separate cloud account with its own IAM roles, its own KMS key grants, and no network path into production.
- Recorded baselines: Row counts per critical table, a schema dump, checksums for a sample of known files, and object counts per bucket prefix, all captured at backup time.
- Written RTO and RPO per workload tier: The numbers you’ve committed to in a contract, an audit, or a board deck.
- A validation script or health endpoint per application: Something a machine can run after the restore and return a verdict.
Time required: A granular test (one file, one table, one record) takes 15 to 45 minutes including checks. A full environment restore test takes hours and scales with the workload, so schedule it and staff it.
How to test backups in 7 steps
Run the steps in order. Each one depends on the output of the one before it.
1. Tier your workloads and set the pass criteria for each
Split workloads into three tiers by business impact:
- Tier 1 is anything that stops revenue or violates a regulatory commitment when it is down.
- Tier 2 is internal systems with a workaround.
- Tier 3 is everything you could rebuild from source in a day. Attach one RTO and one RPO to each tier.
Then write what "pass" means for each workload type. A test without a written pass criterion has no way to come back negative, and a test that can only pass produces no information.
Pro tip: The application owner writes the pass criterion, not the backup admin. The owner knows which table going empty would cost the business money.
2. Pick recovery points from across the retention window
A test on last night's backup covers only last night's backup. It says nothing about the incremental chain behind it or whether a point from three months ago still restores.
Rotate through three kinds of point:
- The newest point: Confirms the current job and the current configuration.
- A random point inside the retention window: Confirms the chain, the retention policy, and any storage tier transitions.
- The point immediately before a known change: A schema migration, a major deploy, a region move. This is the point you will reach for when the change goes wrong.
An AWS Backup restore testing plan can select either the latest recovery point or a random one from a window of up to 365 days. Use the random option on a schedule and the latest option after every change.
Pro tip: After every schema change, test the pre-change point within the same week, while the people who made the change still remember what it touched.
3. Restore into an isolated account with its own credentials
Target a dedicated restore account. Give it its own IAM roles, its own KMS key grants, and no peering or transit route back into production. The restore should succeed with production entirely unreachable.
A test that borrows a production role or a production key has tested a path that an attacker with those credentials can also close.
CISA's #StopRansomware Guide pairs its testing advice with the instruction to keep backups offline, because ransomware variants hunt for reachable copies first. In a cloud account, "offline" means a copy that production credentials can't touch.
Eon separates the two by design. Backups land in an immutable, logically air-gapped vault in a dedicated vault account, and restores run through restore accounts you register separately from the accounts being protected. A test restore never needs a production credential.
Pro tip: If the test restore needs the production KMS key to decrypt, it has not tested isolation. Re-encrypt to a key the restore account owns.
4. Validate the data inside the restored workload
A VM that boots, or a database whose status reads "available," has passed an infrastructure check. Nothing has read the data yet. Run the check that fits the workload.
VMs and volumes
Mount the restored volume and run a filesystem check. Compare checksums on your sample of known files against the baseline. Start the service and call its health endpoint.
A clean mount with a health check that errors usually means a missing dependency (a secret, a DNS entry, a parameter group). That’s a real finding, so log it.
Managed databases (RDS, Aurora, Cloud SQL, Azure SQL)
Run COUNT(*) on every critical table and compare against the recorded counts. Diff the restored schema against the dump taken at backup time, including indexes, views, and stored procedures. Run one known-answer query whose result you already hold.
Most of this check runs without restoring the database. In Eon, a backed-up database is queryable as a snapshot, so you can inspect the schema, count rows, and sample records before you provision anything. Reserve the full restore for the quarterly proof of the complete path.
NoSQL tables (DynamoDB, MongoDB Atlas)
Compare the item count against the export manifest. Read a fixed sample of partition keys and confirm the attributes match. List the secondary indexes on the restored table and check every source index is present. A table with its data and without its indexes is still down.
Object storage
Count objects per prefix and compare against the baseline. Pull a sample of objects and compare ETags or computed hashes. Read the bucket configuration on the restored target and confirm versioning, Object Lock, and lifecycle rules carried over.
A bucket restored without its lock is a bucket that can be wiped.
Pro tip: Store the validation output alongside the verdict. The log needs the exact numbers ("1,204,311 rows expected, 1,204,311 returned"); a bare "Passed" can't be audited.
5. Time the restore against your RTO
RTO runs from the moment service is interrupted, so the full clock includes detection and decision time a drill rarely sees. A restore test measures the leg it can: start when someone decides to restore, stop when the app answers a real request.
The job's own "completed" timestamp sits in the middle, and the minutes after it, when volumes attach, caches warm, and the app reconnects, are where most of that leg is lost.
Most full restores take far longer than the people approving RTOs believe. 60% of respondents in Eon’s 2026 report need six hours or more to complete a full restore.
Pro tip: Time the granular path separately from the full path. You will use the granular path ten times for every full restore, and it’s the one whose speed shapes daily operations.
6. Confirm the recovery point is clean
A backup that restores perfectly can still carry the encryption, the corruption, or the bad write that caused the incident. Before recording a pass, check that the point you restored predates the damage.
Check the last-clean marker on the resource and compare it against the recovery point you tested. If the point sits after the infection date, the test passed mechanically and missed in substance. Re-run it on the last clean point and record both results.
Eon's ransomware detection marks the last clean and last infected snapshot per resource. For managed databases (RDS, Aurora, Azure SQL, Cloud SQL) where file-level scanners have nothing to scan, Eon uses row-count anomaly, cardinality analysis, and schema-shift detection to reach the same verdict.
The full method for validating a point before restoring it is detailed in our guide to clean recovery points.
Pro tip: A pass on an infected point goes in the log as a miss. The restore ran cleanly, but the point was wrong, so record it as a miss and retest against a clean one.
7. Log the evidence and fix what missed
Every test produces a row in an evidence log. Auditors, insurers, and your own incident reviews will ask for these fields:
When a test misses, the cause falls into one of four groups, and each has a known fix path.
- Permission: The restore role can't assume, or can't reach the KMS key. Fix the trust policy or the key policy, then retest.
- Dependency: The data is fine, and the app will not start. Secrets, DNS, parameter groups, or security groups were never in the backup. Add them to the runbook and to the next test.
- Data: Row counts or checksums diverge. Move to an earlier point and escalate, because this is a corruption or a chain problem.
- Time: Everything passed, and the RTO was missed. Decide whether to change the architecture or change the RTO, and write the decision down.
Pro tip: Every missed test leaves the review meeting with a named owner and a retest date. A miss without a date is a miss you’ve accepted.
How often to test backups
Frequency follows the cost of the test. Checks that run against backup data without provisioning anything can run every day. Full restores can't, so they run on a schedule and against the tiers that matter.
This maps to the exercise types in NIST SP 800-84: tabletop and functional exercises, up to a full-scale reconstitution. AWS's own reliability guidance, REL09-BP04, asks for the same thing: periodic restores to a new location with integrity checks on the data.
Automate the middle rows. An AWS Backup restore testing plan can hold restored resources for up to 168 hours. Its validation hook fires an EventBridge rule on job completion, so a Lambda function can run your checks and post the result.
On Azure, a Recovery Services vault with geo-redundant storage supports Cross Region Restore, which Microsoft positions for compliance drills in the paired region.
Common mistakes to avoid when testing backups
These five patterns let a test come back green without actually proving the restore works.
- Restoring into the production account: It’s faster, and it’s the default, which is why it is the most common. It skips the isolation test entirely. Fix it by making the restore account the only account the test role can assume into.
- Testing only the newest recovery point: It’s the easiest point to find. It says nothing about the chain behind it. Fix it with the random-point rotation from step 2.
- Calling a boot a pass: The instance is running, so the test is marked green. The data inside was never read. Fix it by making the validation script the only source of the verdict.
- Leaving dependencies out of scope: The database restores and the app can't connect, because something it needs was never in the backup policy. Fix it by listing every dependency in the runbook and testing the list.
- Letting the builder run every test: The engineer who set up the backup knows the undocumented steps. Fix it by rotating the tester, so the runbook gets tested along with the data.
How Eon supports backup testing
We built Eon so that the expensive parts of a backup test happen less often and the cheap parts run continuously.
- Query before you restore: With Global Search, backed-up databases, files, and records are queryable as snapshots, so row counts, schema checks, and record samples run without provisioning a database.
- Granular restore into an isolated account: Files, tables, and individual records restore into a registered restore account, so monthly Tier 1 tests don’t require a full environment.
- Clean-point identification: Ransomware detection flags the last clean and last infected snapshot per resource, including managed databases, so step 6 takes one lookup.
SoFi runs this pattern across five AWS regions: cloud-native auto-discovery and policy replaced fragmented native snapshots, and recovery went from a full day to under five minutes.
Where to start with backup testing this quarter
If your program has never run a structured test, do three things in this order. Stand up the restore account and move one Tier 1 workload's test into it. Write the pass criterion and validation script for that workload. Then put a monthly granular test and a quarterly full test on the calendar, each with an owner.
That’s how to test backups in a way that holds up under audit and under an incident.
How many of your Tier 1 restores have you actually timed against a clean point in an isolated account? Book a demo and see how Eon covers all three.
Frequently asked questions
How often should you test backups?
Test backups on a tiered cadence. Run continuous integrity checks and snapshot queries for everything, monthly granular and quarterly full restores for Tier 1 workloads, and an annual full-scale exercise across all tiers. Add an unscheduled test after any schema change, major deploy, or region move.
What's the hardest part of testing backups?
The hardest part of testing backups is keeping the baselines current. Row counts, schema dumps, and file checksums have to be captured at backup time and stored where the test can read them, or step 4 has nothing to compare against.
Do you need a full restore to test a backup?
No, you don’t need a full restore to test a backup. A full restore is one kind of test, reserved for confirming the complete recovery path and its timing. Integrity checks, row counts, schema diffs, and file-level restores validate the data and can run weekly or daily.
Can Eon help test backups without restoring full environments?
Yes. Eon can help you test backups without restoring full environments. You query backed-up databases and browse backed-up files and records directly, so you can inspect schemas, count rows, and sample data before restoring anything. When a restore is needed, it runs at file, table, or record level into a separate restore account.
What if a backup restores but the application won't start?
If a backup restores but the application won't start, the data came back and a dependency did not. The usual culprits are secrets, DNS records, database parameter groups, security groups, or IAM roles that were never in the backup scope. Log it as a miss, add the dependency to the runbook and the backup policy, and retest within the month.
.png)
.jpg)