What this prompt does
This prompt designs a full backup and disaster recovery strategy for your [database_type], sized to your current [db_size] and [growth_rate]. It defines which [backup_types] to run with retention policies, an automated [backup_schedule], point-in-time recovery configuration, and cross-region replication to your [dr_region]. It anchors the whole plan to explicit [rto] and [rpo] targets so recovery expectations are measurable, not aspirational.
The structure works because it treats an untested backup as no backup at all. Alongside the backup mechanics, it asks for verification and integrity testing, a step-by-step restoration runbook, a failover procedure, and a DR drill schedule. By forcing real [rto] and [rpo] numbers and a rehearsal checklist, it turns vague "we have backups" confidence into a recovery plan you can actually execute under pressure. It also covers backup encryption and access control, monitoring alerts for backup failures, and a storage cost estimate sized to your [db_size] and [growth_rate], so the plan is not only technically sound but accounts for who can touch the backups and what they cost as your data grows. An automated DR-testing pipeline keeps the rehearsal honest instead of a once-a-year ritual.
When to use it
- You run a production
[database_type]and have never formally tested a restore. - You need to document
[rto]and[rpo]targets for stakeholders or compliance. - Your data is growing at
[growth_rate]and you need a retention and storage-cost plan. - You want cross-region replication to
[dr_region]configured deliberately, not as an afterthought. - You need a restoration runbook with concrete commands before an outage forces improvisation.
- You want a recurring DR drill schedule so recovery skills stay sharp.
Example output
Expect a structured DR plan: a backup strategy section mapping [backup_types] to retention windows, a scheduling section for the [backup_schedule], PITR and replication configuration toward [dr_region], and an explicit RTO/RPO section. The most valuable parts are usually the step-by-step restoration runbook, the failover procedure, a storage cost estimate, and a DR drill checklist you can run on a cadence.
Pro tips
- Provide accurate
[db_size]and[growth_rate]; retention and storage-cost estimates are only useful when the numbers reflect reality. - Set honest
[rto]and[rpo]targets based on what the business can tolerate, not what sounds impressive, because they drive the entire design. - Choose
[backup_types]that match your engine; WAL archiving and PITR pair naturally with PostgreSQL, while other databases have their own mechanisms. - Treat the restoration runbook as something to rehearse, not file away; the first real restore should not be your first attempt.
- Confirm
[dr_region]is genuinely independent of your primary so a regional outage cannot take both down. - Iterate by running the generated DR drill checklist, noting where it breaks, and feeding those gaps back for a tighter runbook.
