Data Backup and Recovery Plan Template

What This Template Is For

Every SaaS product will eventually face a data loss event. A database corruption, a bad migration, a ransomware attack, or even a well-intentioned engineer running a DELETE without a WHERE clause. The question is not whether it will happen, but whether you can recover. And how fast.

This template provides a structured approach to planning your backup and disaster recovery (DR) procedures. It covers four areas: defining recovery objectives (RTO and RPO), designing backup schedules and storage, writing recovery runbooks, and testing your ability to actually restore from backups.

Most teams have backups. Few teams have tested their backups. An untested backup is not a backup. It is a hope. This template forces you to define what "recovered" actually means, document step-by-step restoration procedures, and schedule regular recovery drills.

For PMs who need to understand infrastructure reliability decisions, the Technical PM Handbook covers how these trade-offs affect product roadmaps. If your product has SLA commitments, the SLA glossary entry explains how RTO and RPO map to customer expectations. For incident handling when recovery is triggered, see the incident response template.

How to Use This Template

1. Classify your data. Not all data has the same recovery priority. Separate critical data (user accounts, billing, core product data) from non-critical data (analytics, logs, caches).
2. Set RTO and RPO targets. Define how fast you need to recover (RTO) and how much data loss you can tolerate (RPO) for each data class.
3. Design backup schedules. Map each data class to a backup frequency and storage strategy that meets your RPO.
4. Write recovery runbooks. Document step-by-step procedures for every recovery scenario.
5. Schedule and run recovery drills. Test your runbooks quarterly. Fix anything that fails.

The Template

Part 1: Data Classification

Classify every data store in your product by criticality and recovery priority.

Data classification checklist:

• ☐ Every data store in production is listed (no "shadow" databases or local file stores)
• ☐ Criticality is based on business impact, not technical convenience
• ☐ "Rebuildable" data stores are verified: confirm the rebuild procedure exists and is documented
• ☐ Compliance requirements (GDPR, SOC 2, HIPAA) are reflected in retention and recovery targets
• ☐ Third-party managed data (Stripe, Auth0, Salesforce) has its own backup/export strategy

Part 2: Recovery Objectives

Define RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for each criticality tier.

RTO/RPO decision factors:

• ☐ RTO targets account for: detection time + decision time + restoration time + validation time
• ☐ RPO targets are achievable with the selected backup frequency (5-min RPO requires continuous replication, not hourly snapshots)
• ☐ Cost of achieving each target is documented and approved by engineering leadership
• ☐ Targets are aligned with customer SLA commitments (your RTO cannot exceed your SLA uptime guarantee)
• ☐ Targets are realistic: they have been validated through at least one recovery drill

Part 3: Backup Schedule and Storage

Backup storage rules:

• ☐ Critical backups are stored in a different region than production (survive regional outage)
• ☐ At least one backup copy is in a different cloud account (survive account compromise)
• ☐ All backups are encrypted at rest with keys managed separately from the data
• ☐ Backup access requires separate credentials from production access
• ☐ Backup retention meets compliance requirements (SOC 2: 90 days minimum, GDPR: aligned with data retention policy)
• ☐ Old backups are automatically purged per retention schedule (no indefinite retention of PII)
• ☐ Backup monitoring alerts if a scheduled backup fails or is delayed

Part 4: Recovery Runbooks

Document a step-by-step procedure for each recovery scenario. Each runbook should be executable by any on-call engineer, not just the person who wrote it.

Scenario A: Primary Database Corruption

Trigger: Data integrity check fails, or application reports unexpected data states.

Recovery procedure:

1. Assess scope. Determine which tables/rows are affected and the time range of corruption.
2. Stop writes. Enable read-only mode on the application to prevent further corruption.
3. Identify the safe restore point. Find the latest WAL position before the corruption event using database logs.
4. Perform point-in-time recovery. Restore to the identified position using PITR on the cross-region replica.
5. Validate restored data. Run integrity checks on the restored database. Compare row counts and checksums against the last known-good backup.
6. Switch traffic. Update the application to point to the restored database. Disable read-only mode.
7. Communicate. Post status update per the incident response template.
8. Postmortem. Document root cause, timeline, and prevention measures within 48 hours.

Estimated recovery time: 30-60 minutes.

Scenario B: Complete Regional Outage

Trigger: Cloud provider reports a regional service disruption affecting compute, database, or networking.

Recovery procedure:

1. Confirm the outage. Verify via cloud provider status page and independent monitoring.
2. Activate DR region. Switch DNS to the DR region using pre-configured failover records (TTL: 60 seconds).
3. Promote read replica. Promote the cross-region database replica to primary.
4. Scale DR compute. Auto-scaling should handle this, but verify instance counts match production baseline.
5. Validate functionality. Run smoke tests against the DR deployment.
6. Communicate. Update status page and notify customers.
7. Plan failback. Once the primary region recovers, plan a controlled migration back during a maintenance window.

Estimated recovery time: 15-30 minutes (automated failover) to 2-4 hours (manual).

Scenario C: Accidental Data Deletion

Trigger: Engineer or customer accidentally deletes critical data (project, account, etc.).

Recovery procedure:

1. Identify the deletion. Use audit logs to find the exact time, user, and scope of deletion.
2. Check soft-delete. If soft-delete is implemented, recover via undelete API.
3. If hard-deleted: Restore the affected table/rows from PITR to a temporary database.
4. Extract and merge. Export the deleted rows from the temporary database and insert them into production.
5. Validate. Confirm the restored data is complete and consistent with related tables.
6. Notify the user. Confirm recovery and provide the restored data.

Estimated recovery time: 15 minutes (soft-delete) to 2 hours (PITR extraction).

Scenario D: Ransomware or Malicious Access

Trigger: Security team detects unauthorized encryption of data or ransom demand.

Recovery procedure:

1. Isolate affected systems. Revoke all access keys, rotate credentials, disable network access.
2. Assess scope. Determine which systems and data stores are compromised.
3. Verify backup integrity. Confirm that backups in the separate account are uncompromised.
4. Reprovision infrastructure. Build new infrastructure from infrastructure-as-code. Do not attempt to clean compromised systems.
5. Restore data. Restore from the latest verified-clean backup.
6. Harden access. Implement fixes for the attack vector before restoring service.
7. Engage legal and compliance. Determine notification obligations (see GDPR compliance template for breach notification requirements).

Estimated recovery time: 4-24 hours depending on scope.

Part 5: Recovery Testing Schedule

Testing checklist:

• ☐ Every recovery runbook has been executed at least once in a non-production environment
• ☐ Recovery times from drills are within RTO targets (if not, update targets or improve procedures)
• ☐ Drill results are documented with actual times, issues found, and fixes applied
• ☐ Drills are announced in advance to prevent confusion with real incidents
• ☐ Failed drills generate action items with owners and deadlines

Filled Example: DataVault Analytics Platform

Product: DataVault, a SaaS analytics platform processing 2B events/day for 500 enterprise customers.

Recovery objectives (implemented):

Last recovery drill (January 2026):

• Simulated PostgreSQL corruption in staging environment
• Restored from PITR in 22 minutes (within 30-min RTO)
• Found issue: restore script assumed a specific PostgreSQL version. Updated to auto-detect version.
• Simulated full regional failover to us-west-2 in 18 minutes (DNS propagation was the bottleneck)

Key lesson learned: Their ClickHouse backup restore took 6 hours on the first drill, exceeding the 4-hour RTO. Root cause: the restore process was downloading 2TB from S3 sequentially. They parallelized the restore across 8 nodes and reduced it to 90 minutes.

Common Mistakes

1. Backing up but never testing restores. A backup you have never restored from is just a file. It might be corrupted, encrypted with a lost key, or missing critical tables. Test quarterly.
2. Same-region backups only. If your backups are in the same region as your production systems, a regional outage takes out both. Cross-region replication is not optional for Critical-tier data.
3. Backing up the database but not the schema. You restored the data, but the migrations are out of sync and the application cannot connect. Back up schema definitions, migration history, and application configuration alongside data.
4. No backup monitoring. A nightly backup job failed silently for 3 weeks. When you need it, your newest backup is 3 weeks old. Monitor backup jobs and alert on failure.
5. Treating all data as equally critical. Not everything needs 5-minute RPO. Over-engineering backup for analytics data wastes money. Under-engineering it for billing data risks compliance violations. Classify first, then design.

The vulnerability management template covers how to track and remediate the security gaps that could lead to the ransomware and breach scenarios described above.