arbazkhan971 Backup — Backup & Disaster Recovery
Activate When
- User invokes
/godmode:backup - User says "backup strategy," "disaster recovery," "what happens if we lose the database?"
- User is designing data infrastructure that needs durability guarantees
- After
/godmode:infraprovisions stateful services (databases, storage, queues) - Incident post-mortem reveals backup or recovery gaps
- Compliance requirements mandate backup and recovery documentation
Workflow
Step 1: Inventory Data Assets
Identify all data that needs protection:
DATA ASSET INVENTORY:
| Asset | Type | Size | Growth | Critical |
Step 2: Define RPO/RTO Targets
Set recovery objectives for each data tier:
RECOVERY OBJECTIVES:
| Data Tier | RPO | RTO | Justification |
Step 3: Backup Strategy Design
Design backup approach for each data tier:
Tier 1: Continuous Protection
TIER 1 BACKUP STRATEGY:
Primary database:
Tier 2: Periodic Snapshots
TIER 2 BACKUP STRATEGY:
File uploads (S3/GCS):
Tier 3: Daily Backups
TIER 3 BACKUP STRATEGY:
Application logs:
IF backup age >24h: trigger immediate backup. IF restore test fails: alert and re-run.
Step 4: Backup Verification
Automated checks that backups are actually working:
BACKUP VERIFICATION SCHEDULE:
| Check | Frequency | Method | Alert |
### Step 5: Data Integrity Verification
Verify backed-up data is consistent and usable:
DATA INTEGRITY CHECKS:
| Check | Method | Frequency |
|---|---|---|
| Row count consistency | Compare source vs | After each |
| restored backup | restore test | |
| Checksum verification | SHA-256 of backup | Every backup |
| file | ||
| Foreign key integrity | Run FK constraint | Weekly |
| check on restored DB | restore | |
| Application smoke test | Run app against | Monthly |
| restored DB | restore | |
| Point-in-time accuracy | Restore to specific | Quarterly |
| time, verify records | ||
| Cross-region consistency | Compare checksums | Weekly |
| across regions |
Integrity verification queries:
-- Row count comparison (run against source and restored)
SELECT table_name, n_live_tup
FROM pg_stat_user_tables
Step 6: Recovery Procedures
Document step-by-step recovery for each failure scenario:
RECOVERY: Primary Database Failure
Severity: CRITICAL
RPO: < 1 minute (via streaming replication)
RTO: < 15 minutes (via automated failover)
AUTOMATED RESPONSE:
1. Health check detects primary is unresponsive (30 seconds)
2. Orchestrator promotes synchronous replica to primary (15 seconds)
3. Application connection pool reconnects to new primary (30 seconds)
4. DNS/service discovery updated (60 seconds)
5. Alert sent to on-call engineer
6. Total automated recovery: < 3 minutes
MANUAL RESPONSE (if automated failover fails):
1. Verify primary is truly down (not a network partition)
$ pg_isready -h <primary-host>
2. Check replica lag
$ psql -h <replica-host> -c "SELECT pg_last_wal_replay_lsn();"
3. Promote replica manually
$ pg_ctl promote -D /var/lib/postgresql/data
4. Update connection string in application config
5. Restart application instances
6. Verify application is serving traffic
POST-RECOVERY:
1. Provision new replica from promoted primary
2. Verify replication is streaming
3. Update monitoring and alerting
4. Write incident report
Scenario 2: Data Corruption
RECOVERY: Data Corruption — Severity: HIGH, RTO: 15min-2h
1. STOP: Identify scope, disable source (bad migration, broken code)
2. RECOVER: Point-in-time restore (recent) | Snapshot restore (widespread) | Selective table restore (targeted)
3. VERIFY: Row counts, smoke tests, no orphaned records
4. POST-MORTEM: Root cause, prevention, detection/recovery speed
Scenario 3: Complete Region Failure
RECOVERY: Region Failure — Severity: CRITICAL, RPO: <1min, RTO: <30min
1. Detect failure (monitoring + cloud status page)
2. Activate DR: promote cross-region replica, verify storage, scale instances, update DNS (TTL 60s)
3. Verify DR serving traffic, communicate to stakeholders
RETURN TO PRIMARY: Wait 24h+, reverse replication, verify consistency, canary traffic shift
Step 7: Disaster Recovery Runbook
Generate a comprehensive runbook document:
DISASTER RECOVERY RUNBOOK
Last tested: <date>
Next test scheduled: <date>
Owner: <team/person>
On-call escalation: <contact chain>
Recovery objectives:
| Tier 1 RPO: < 1 min | RTO: < 15 min |
|--|--|
| Tier 2 RPO: < 1 hour | RTO: < 1 hour |
| Tier 3 RPO: < 24 hour | RTO: < 4 hours |
Scenarios covered:
1. Primary database failure → Page 3
2. Data corruption → Page 5
3. Complete region failure → Page 8
4. Ransomware / security breach → Page 11
5. Accidental data deletion → Page 13
6. Cloud provider outage → Page 15
Backup status:
Database: <HEALTHY | DEGRADED | FAILED>
File storage: <HEALTHY | DEGRADED | FAILED>
Configuration: <HEALTHY | DEGRADED | FAILED>
Secrets: <HEALTHY | DEGRADED | FAILED>
Last successful restore test: <date> (<result>)
Last DR failover test: <date> (<result>)
Step 8: Backup & DR Report
BACKUP & DISASTER RECOVERY REPORT
Data assets inventoried: <N>
Backup strategies defined: <N>
Recovery procedures documented: <N> scenarios
Coverage:
Tier 1 (critical): <PROTECTED | GAPS | UNPROTECTED>
Tier 2 (important): <PROTECTED | GAPS | UNPROTECTED>
Tier 3 (operational): <PROTECTED | GAPS | UNPROTECTED>
Verification:
Automated checks: <CONFIGURED | PARTIAL | MISSING>
Last restore test: <date | NEVER>
Last DR test: <date | NEVER>
Gaps identified: <N>
1. <gap description and remediation>
2. <gap description and remediation>
Verdict: <PROTECTED | PARTIAL | AT RISK>
Step 9: Commit and Transition
Save runbook as docs/dr/<date>-disaster-recovery-runbook.md
# Test backup and restore procedures
pg_dump -Fc mydb > backup_test.dump
pg_restore -d mydb_test backup_test.dump
psql mydb_test -c "SELECT count(*) FROM users;"
# Verify backup and test restore
pg_dump --format=custom -f backup.dump $DATABASE_URL
pg_restore --list backup.dump
curl -s http://localhost:8080/health
Auto-Detection
1. Data stores: grep for postgres, mysql, mongodb, redis connection strings
2. Object storage: grep for S3, GCS, Azure Blob configs
3. Existing backups: check crontab, CI jobs, WAL archiving configs
4. No backups → CRITICAL gap. No verification → HIGH gap.
Explicit Loop Protocol
BACKUP VERIFICATION LOOP:
current_iteration = 0
max_iterations = 10
gaps_remaining = total_gaps_found
WHILE gaps_remaining > 0 AND current_iteration < max_iterations:
current_iteration += 1
1. SELECT highest-severity backup gap
2. IMPLEMENT fix:
- Missing backup → create backup job/config
- No verification → add automated integrity check
- No cross-region → configure replication
- No restore test → create and run restore test
3. git commit: "backup: fix <gap> (iter {current_iteration})"
4. VERIFY the fix:
- Backup job runs successfully
- Backup file is valid (checksum, header check)
- Restore test passes (if applicable)
5. IF verification fails:
- Debug configuration
- Retry with adjusted parameters
6. UPDATE gaps_remaining
IF current_iteration % 3 == 0:
PRINT STATUS:
"Iteration {current_iteration}/{max_iterations}"
"Gaps fixed: {total_gaps - gaps_remaining}/{total_gaps}"
"Tier 1 coverage: {tier1_status}"
"Tier 2 coverage: {tier2_status}"
"Last restore test: {last_restore_result}"
Quality Targets
- RPO Tier 1: <1h data loss window
- RTO Tier 1: <15min recovery time
- Restore success: >99% verified
HARD RULES
Never ask to continue. Loop autonomously until all backup gaps are resolved or budget exhausted.
MECHANICAL CONSTRAINTS — NON-NEGOTIABLE:
1. NEVER treat a backup as valid until a restore test has succeeded.
2. NEVER store backups in the same failure domain as production (same region, same account).
3. ENCRYPT EVERY backup at rest — no exceptions for any data tier.
4. EVERY backup job MUST alert on failure — silent backup failures are the worst kind.
5. EVERY backup MUST have a TTL/retention policy — no infinite storage growth.
6. DEFINE RPO and RTO BEFORE designing backup strategy — business drives engineering.
7. git commit backup configurations BEFORE testing — baseline for debugging.
8. Automatic revert on regression: if backup config change causes production issues, revert immediately.
9. NEVER skip quarterly DR tests — schedule them and treat them as P1 obligations.
10. Log all backup operations in TSV:
TIMESTAMP\tASSET\tOPERATION\tSIZE\tDURATION\tSTATUS\tCHECKSUM
Output Format
Print on completion: Backup: {asset_count} assets covered. RPO: {rpo}. RTO: {rto}. Last restore test: {last_test_date}. Encryption: {encryption_status}. Cross-region: {cross_region}. Verdict: {verdict}.
timestamp asset operation size duration_s status checksum
2024-01-15T03:00:00Z postgres-prod backup 12GB 180 success sha256:abc123
2024-01-15T03:05:00Z redis-prod backup 2GB 30 success sha256:def456
2024-01-15T04:00:00Z postgres-prod restore-test 12GB 300 success verified
Columns: timestamp, asset, operation(backup/restore-test/dr-drill), size, duration_s, status(success/failed/partial), checksum.
Success Criteria
## Keep/Discard
KEEP if: improvement verified. DISCARD if: regression or no change. Revert discards immediately.
## Stop Conditions
Stop when: target reached, budget exhausted, or >5 consecutive discards.