Belajar System Administrator - Disaster Recovery Planning
Bersiap menghadapi yang terburuk: memahami RPO dan RTO, merancang DR site, menyusun runbook, dan menjalankan simulasi DR yang membuktikan rencana kalian benar-benar berfungsi.
#Pendahuluan
Episode 22 membuat layanan tahan terhadap kegagalan komponen — server mati, aplikasi tetap jalan. Episode 23 membahas skala yang lebih besar: bencana. Kebakaran gedung, ransomware yang mengenkripsi semuanya, atau kesalahan yang menghapus data produksi. HA tidak bisa menyelamatkan dari itu semua — tetapi Disaster Recovery (DR) bisa.
DR bukan dokumen yang disimpan di laci. Ia adalah rencana yang terbukti — diuji lewat simulasi, diperbaiki dari setiap pelajaran, dan benar-benar dipakai saat bencana datang. Episode ini membangun rencana itu dari nol.
#RPO dan RTO: Dua Angka yang Menentukan Segalanya
Semua perencanaan DR berpusat pada dua metrik:
| Metrik | Pertanyaan | Analogi |
|---|---|---|
| RPO (Recovery Point Objective) | Berapa banyak data yang boleh hilang? | Jarak antara backup terakhir dan bencana |
| RTO (Recovery Time Objective) | Seberapa cepat harus pulih? | Waktu sampai layanan kembali |
Contoh nyata: RPO 1 jam = kalian siap kehilangan maksimal 1 jam data; RTO 4 jam = layanan harus kembali dalam 4 jam. Semakin ketat, semakin mahal. Seperti HA, RPO/RTO adalah keputusan bisnis — dirundingkan, bukan diimpor dari template.
| Jenis Aplikasi | RPO yang Wajar | RTO yang Wajar |
|---|---|---|
| Email / dokumen | 24 jam | 24 jam |
| Aplikasi bisnis | 4 jam | 8 jam |
| Sistem transaksi | Menit | Jam |
#Arsitektur DR: Situs dan Situs
DR memerlukan tempat pemulihan — DR site:
| Model | Deskripsi | RTO Realistis |
|---|---|---|
| Hot site | Penuh, replikasi nyata, siap pakai | Menit-jam |
| Warm site | Infrastruktur siap, data di-restore saat bencana | Jam-hari |
| Cold site | Gedung & listrik saja, sisanya dibangun ulang | Hari-minggu |
Di 2026, cloud sebagai DR site sangat populer: on-prem + backup ke object storage cloud (dari episode 14-15), dan saat bencana, bangun ulang VM di cloud dari image + Ansible (episode 13). Warm site di cloud adalah titik manis biaya vs kesiapan.
#Runbook: Resep untuk Masa Panik
Saat bencana terjadi, otak manusia berhenti bekerja jernih. Runbook adalah resep tertulis yang bisa diikuti langkah demi langkah — tanpa berpikir, tanpa tebak-tebakan. Satu runbook DR yang baik berisi:
- Trigger — apa yang menandakan ini bencana (bukan sekadar insiden biasa)?
- Kontak — siapa yang dihubungi, dalam urutan apa?
- Langkah recovery — nomor, berurutan, bisa dieksekusi orang lain.
- Verifikasi — bagaimana tahu recovery sukses?
- Rollback / komunikasi — kapan memberi tahu user, kapan "kembali normal".
# DR: Database Server
Trigger : database down > 1 jam, data korup (lihat monitoring)
Kontak : 1) Sysadmin on-call 2) IT Lead 3) Vendor
Langkah :
1. Verifikasi sumber data terakhir (S3: backup-tahunan-latest)
2. Provision VM baru di cloud (template db-image, Ansible)
3. Restore base backup + replay WAL (PITR)
4. Verifikasi: SELECT count(*) ... ; /health app
5. Arahkan DNS app ke IP baru (TTL pendek)
Komunikasi: update status di channel #incident tiap 30 menitCatat: runbook ditulis untuk orang panik — kalimat pendek, perintah jelas, tanpa asumsi.
#Simulasi DR: Satu-Satunya Cara Tahu
Rencana yang tidak pernah diuji adalah rencana yang belum ada. Simulasi DR (DR drill) adalah latihan kebakaran: semua orang menjalankan runbook dalam kondisi terkendali, sebelum kebakaran sungguhan.
Frekuensi: minimal tahunan untuk organisasi normal; kuartalan untuk sistem kritis. Setiap drill menghasilkan lessons learned — perbaikan runbook, temuan bottleneck, perubahan yang dibutuhkan.
Important
Jika DR plan belum pernah diuji, asumsikan ia gagal. "Kami punya backup" tanpa pernah membuktikan restore-nya (episode 9), "kami punya runbook" tanpa pernah menjalankannya — keduanya adalah kepercayaan yang belum terbukti. Uji, lalu uji lagi. Itu satu-satunya jalan.
#Praktik: Simulasi DR di Lab
Latihan terpadu — jalankan seluruh siklus DR untuk database lab:
# 1. Baseline: backup + WAL archiving aktif (episode 17 & 20)
# 2. Skenario: "data produksi hilang" - hapus database
sudo -u postgres psql -c "DROP DATABASE appdb;"
# 3. Ikuti runbook: provision ulang & restore
sudo -u postgres createdb -O app_user appdb
sudo -u postgres psql appdb < /srv/backup/appdb.sql
# 4. Replay WAL sampai titik waktu sebelum bencana (PITR)
# 5. Verifikasi: tabel & data terakhir ada kembali
sudo -u postgres psql appdb -c "\dt"
# 6. Catat lessons learned di runbookJika data kembali sesuai RPO yang ditetapkan — simulasi lulus, dan kalian membawa pulang pengalaman yang tidak bisa dibeli: kepercayaan bahwa rencana kalian benar-benar bekerja.
Tip
Setiap drill harus menghasilkan minimal satu perbaikan. Mungkin runbook-nya kurang jelas, mungkin backup-nya ternyata tidak lengkap, mungkin verifikasinya butuh langkah tambahan. DR yang sehat adalah DR yang terus diperbaiki setelah setiap simulasi — bukan dokumen yang membeku di folder.
#Penutup
Inti yang harus dibawa pulang dari episode 23:
- RPO (berapa data yang boleh hilang) dan RTO (seberapa cepat pulih) adalah keputusan bisnis.
- DR site: hot/warm/cold — cloud sebagai warm site adalah pilihan 2026 yang seimbang.
- Runbook ditulis untuk orang panik: trigger, kontak, langkah, verifikasi, komunikasi.
- Simulasi DR berkala adalah satu-satunya cara membuktikan rencana — dan setiap drill wajib menghasilkan perbaikan.
Di episode 24 selanjutnya kita akan membahas sesuatu yang mengubah cara sysadmin bekerja di 2026: AI for Sysadmin — AI-assisted troubleshooting, summarization log, dan auto-remediation, dengan praktik memakai AI untuk menganalisis log. Teknologi berubah, tetapi keterampilan berpikir kalian tetap kuncinya!