You have a backup. Can you restore the service?
A successful backup job is only the beginning. RPO, RTO and regular restore tests show how much protection your data really has.
The backup script finishes without errors every day. That is good news, but it does not answer the key question: how long would recovery take after losing the database? A backup protects the service only when its data is usable, the credentials are available and the team knows the entire restoration procedure.
Agree on acceptable data loss and recovery time
RPO describes how far back in time you must be able to recover data. RTO sets the target time for restoring operations. Depending on when an incident happens, a daily backup can mean losing almost a day's changes. Whether that is acceptable depends on the product, not on the convenience of a backup script.
Set these objectives with people who understand customer impact. A reporting system and an order database have different needs. Include the time required to obtain access, restore infrastructure and verify the application, not just load database files.
Back up consistently and separately from production
Copying files from a running database without a supported procedure may not produce a consistent backup. Use the tools and mechanisms intended for that database. In PostgreSQL, a logical dump has different properties from a physical backup with WAL archiving and point-in-time recovery.
Keep at least one copy outside the account or environment whose failure you are addressing. Every production process should not automatically be allowed to delete backups. Encryption protects the contents, but an unavailable key can make an otherwise sound backup unusable.
Practise restoration in a separate environment
Regularly restore a selected backup into a test database and run basic checks. Verify record counts, relationships and application functions. Measure the full duration, including transfer and environment preparation. The test must not overwrite production or trigger real emails, payments or integrations.
Monitor freshness, not just file existence
A file named backup can be old, empty or incomplete. Check the last successful run, file size and validation result. A sudden reduction in size warrants investigation; it is not automatic proof of failure. Both the backup result and restore test need an accountable owner.
- Where are the backups and encryption keys?
- Who has access if the production account fails?
- When was the last restore test completed?
- Does the measured duration meet the agreed RTO?
What to take away
Schedule the next restore test as concretely as a deployment. A verified procedure and measured recovery time offer more confidence than a green backup job alone.
