Nobody can tell you from the backup size alone. Time a real restore into a clean environment, step by step, and add the waiting around it: finding the backup, getting access, validating data and switching traffic. The total from that drill is your honest recovery time.
Why estimates miss
A common estimate is size divided by transfer speed. It leaves out most of what takes time:
- Decision time before anyone starts
- Getting credentials and decrypting
- Provisioning a place to restore to
- Replaying logs after the base restore
- Rebuilding indexes or caches
- Data checks before users return
- Deploying the application and pointing it at the new database
The PostgreSQL manual illustrates one piece of this. A consistent snapshot restore is treated like a crash, so the server replays write ahead log on startup, and running a checkpoint before the snapshot reduces that time. Dump restores need all owning roles to exist first, and the manual advises running ANALYZE after restoring so the planner has statistics.
The drill
- Choose one system and one recent backup.
- Write the steps in advance as a numbered runbook. Someone who did not write it should run it.
- Start a timer when the exercise starts, not when the restore command starts.
- Record a timestamp at each step: backup located, access granted, restore started, restore finished, data checks passed, application working.
- Note every question asked in chat. Each one is a missing line in the runbook.
- Compare the total with your RTO target.
Reading the result
| Result | What to do |
|---|---|
| Under target | Repeat in six months, and after major changes |
| Over target by a little | Automate the slowest manual step |
| Over target by a lot | Change the design: more frequent backups, warm standby, or smaller blast radius |
| Could not complete | Treat it as an incident, fix, and repeat soon |
Make the drill realistic
- Restore into an isolated environment that matches production size.
- Use the real encryption keys and access path, not a shortcut for the test.
- Include the dependencies, such as the identity provider and deployment tooling.
- Run it on a normal working day with the people who would be on call.
AWS's disaster recovery guidance says a scheduled periodic restore is a good idea, partly because restoring from backup can be a control plane operation that may be unavailable during a disaster, whereas a recently restored copy is already usable.
Keep the evidence
Save the timestamps, the runbook version and who ran it. Auditors and customers often ask for restore test evidence, and it also shows trends in how recovery time changes.
Safeguard offers compliance and evidence automation that helps collect dated records, and asset discovery to list the systems to drill. There is a free scan for repositories.
Quick check
How often should I time a restore?
At least twice a year for critical systems, and after any big change in data size or tooling.
Can I test restores in production?
Avoid it. Restore into a separate environment so you cannot overwrite live data.
Sources
- PostgreSQL docs: File System Level Backup
- PostgreSQL docs: SQL Dump
- AWS: Disaster recovery options in the cloud
Last reviewed: 19 October 2026.
