Backups Are Not a Disaster Recovery Strategy
The false comfort of the green backup indicator
Most database dashboards show a green checkmark next to "Backups: enabled." Engineers see this and feel safe. They shouldn't — or at least, not as safe as they think.
Having backups is the beginning of data protection, not the end. The questions that matter are different:
- How long does restoration actually take? (Recovery Time Objective)
- How much data would you lose if a failure happened right now? (Recovery Point Objective)
- When did you last verify that a backup actually restores correctly?
- Does anyone on your team know how to run the restoration process?
Most teams can answer the first question vaguely ("hours, probably") and the rest not at all.
RTO and RPO are not abstract
Recovery Time Objective (RTO) is how long your application is offline while you recover. Recovery Point Objective (RPO) is how much data you lose — measured in time.
For a SaaS with a daily backup taken at midnight, the RPO is up to 24 hours. If a failure occurs at 11:55pm, you lose an entire day of user data. For most B2B applications, that's catastrophic. For a payments platform, it may be unrecoverable.
Continuous WAL archiving — which we run for all Aureus clusters — brings RPO down to typically under 5 minutes. Point-in-time recovery lets you restore to any moment in the past, not just the most recent backup.
The backup that doesn't restore
Backups can silently fail in ways that don't trigger alerts. We've seen:
- Backup jobs completing "successfully" but producing corrupted archives due to a disk filling up mid-write
- Encryption keys for backup archives stored in the same system that failed — making restoration impossible
- Backup processes that ran against a replica but forgot to include sequences, causing key collisions on restore
- pg_dump backups of a 500GB database that "completed" but excluded a schema due to a permission change six months earlier
None of these are caught by a green checkmark. They're caught by restoration tests.
What a real DR posture looks like
At minimum:
- Automated restoration tests — weekly, against a restored copy of production, with schema and row-count validation
- Documented RTO — someone has timed an actual restoration recently and written down how long it takes
- Offsite storage — backup archives stored in a different geographic region from the primary database
- Runbook — a written procedure for restoration that someone other than the original author has successfully followed
- RPO appropriate to the data — understand what data loss is actually acceptable for each system and verify that your backup strategy meets it
What we do on every Aureus cluster
All Aureus clusters include continuous WAL archiving to object storage in a separate region, daily base backups with 30-day retention, and weekly automated restoration tests that verify backup integrity and report on restoration time. Customers get a restoration time report in their dashboard so they know exactly what their RTO is — not in theory, but measured against their actual data.
If you're on a self-managed database and have never run a restoration drill, this weekend would be a good time to do it. Better to discover problems in a planned exercise than during an incident at 3am.