Data Backup and Recovery Plan Template

RTO (Recovery Time Objective) is how fast you need to be back online after an outage. RPO (Recovery Point Objective) is how much data loss you can tolerate. A 1-hour RTO means the service must be restored within 1 hour. A 5-minute RPO means you can lose at most 5 minutes of data. The two are independent: you might need fast recovery (low RTO) but tolerate some data loss (higher RPO), or vice versa.

Test backup integrity weekly (automated). Test single-resource restores monthly. Test full database restores quarterly. Test regional failover semi-annually. After any significant infrastructure change (new database, new cloud provider, major schema migration), run an unscheduled drill.

Use managed backups (RDS automated backups, Cloud SQL backups, Atlas backups) as your foundation. They handle the common cases reliably. Build custom backup procedures for scenarios the managed service does not cover: cross-account isolation, custom retention policies, multi-database consistency, or compliance-specific requirements.

Store backup encryption keys in a separate key management service (AWS KMS, GCP Cloud KMS, HashiCorp Vault) from the data itself. Use separate keys for each data classification tier. Rotate keys annually. Ensure at least two team members have key recovery access. Document the key recovery procedure and test it during drills.

Lower RTO and RPO targets cost more. Continuous replication for 5-minute RPO costs 3-5x more than daily snapshots for 24-hour RPO. Sub-hour RTO requires active-active or hot standby infrastructure, which doubles your compute costs. The right target depends on the business impact of downtime versus the cost of the infrastructure to prevent it.