Planning Disaster Recovery
Given a system/service description, produce three deliverables: Recovery Plan, RTO/RPO Strategy, and Restoration Flow.
Minimal input needed: system name, criticality, data types, current backup state (if any). If unclear, make reasonable assumptions and state them explicitly rather than asking clarifying questions.
Progress:
- Step 1: Identify systems/assets in scope and their criticality tier
- Step 2: Determine RTO (Recovery Time Objective) and RPO (Recovery Point Objective) per tier
- Step 3: Define backup strategy (frequency, type, retention, storage location/redundancy)
- Step 4: Design restoration flow (step-by-step, ordered by dependency)
- Step 5: Define continuity measures (failover, manual workaround, communication plan)
- Step 6: Compile into the three-part output
Step 1 — Criticality tiers Classify each asset:
- Tier 1 (Critical): revenue-impacting, customer-facing, legal/compliance data
- Tier 2 (Important): internal operations, degraded-but-tolerable outage
- Tier 3 (Low): non-essential, archival
Step 2 — RTO/RPO defaults by tier (adjust if input specifies otherwise)
| Tier | RTO | RPO |
|---|---|---|
| 1 | ≤ 1 hour | ≤ 15 minutes |
| 2 | ≤ 4 hours | ≤ 1 hour |
| 3 | ≤ 24 hours | ≤ 24 hours |
Step 3 — Backup strategy Specify: full vs incremental vs differential, frequency, retention window (e.g., 30 days rolling), storage (on-site + off-site/cloud, 3-2-1 rule), encryption at rest, access control.
Step 4 — Restoration flow Order steps by dependency (infra → data → services → validation). Always include a validation/verification step before declaring recovery complete.
Step 5 — Continuity Include: failover mechanism (active-passive/active-active), communication plan (who is notified, when), manual fallback procedures, and post-incident review step.
Example 1: Input: "Sistem e-commerce, database transaksi pelanggan, kritikal, belum ada backup formal."
Output:
- Aset: Database transaksi pelanggan (Tier 1 - Critical)
- Risiko saat ini: Tidak ada backup formal → risiko kehilangan data total
- Strategi backup:
- Full backup harian (00:00), incremental setiap 15 menit
- Retensi: 30 hari rolling, arsip bulanan 12 bulan
- Penyimpanan: primary (on-site NAS) + secondary (cloud storage, region berbeda)
- Enkripsi AES-256 saat transit & at rest
- RTO: ≤ 1 jam (Tier 1)
- RPO: ≤ 15 menit (selaras dengan interval incremental backup)
- Justifikasi: sistem revenue-generating, downtime langsung berdampak transaksi
- Deteksi & konfirmasi insiden (monitoring alert / laporan tim)
- Aktifkan tim DR, notifikasi stakeholder (< 5 menit)
- Isolasi sistem terdampak, cegah korupsi data lanjutan
- Provisioning infrastruktur pengganti (jika perlu)
- Restore dari backup terakhir (full + incremental terbaru)
- Validasi integritas data (checksum, row count, sample query)
- Uji fungsional sistem (transaksi test end-to-end)
- Alihkan traffic produksi ke sistem yang sudah pulih
- Monitoring pasca-restore (24 jam pertama)
- Post-incident review & update runbook
**Example 2:**
Input: "Website company profile, statis, non-kritikal."
Output:
- Aset: Website company profile (Tier 3 - Low)
- Strategi backup: snapshot mingguan penuh, retensi 8 minggu, disimpan di 1 lokasi cloud
- RTO: ≤ 24 jam
- RPO: ≤ 24 jam (setara siklus snapshot terakhir + toleransi)
- Deteksi downtime (uptime monitor)
- Restore snapshot terakhir ke hosting
- Verifikasi rendering halaman & link
- Update DNS/CDN cache jika perlu
- Tutup tiket, catat penyebab insiden
- Always state RTO/RPO as explicit numbers, never vague terms like "as fast as possible."
- Apply the 3-2-1 backup rule by default: 3 copies, 2 different media, 1 off-site.
- Restoration flow must end with a validation step — never assume restore succeeded without checking.
- Tie backup frequency directly to RPO target (don't pick arbitrary schedules).
- Flag any single point of failure explicitly (e.g., "backup and primary in same data center").
- Include a communication/notification step — recovery isn't just technical, it's organizational.
- Don't set RTO/RPO without justifying them against business impact/criticality tier.
- Don't recommend backup without specifying retention and storage redundancy.
- Don't skip the post-incident review — recovery plans must feed back into improvement.
- Don't produce a restoration flow that skips dependency order (e.g., restoring services before infrastructure/data is ready).
- Don't treat all systems as equally critical — always tier and prioritize.