Disaster Recovery: Strategi Backup dan Failover untuk Aplikasi Kritikal

Pada Februari 2017, sebuah kesalahan perintah operasional di Amazon S3 region US-EAST-1 memicu gangguan besar yang melumpuhkan ribuan layanan online selama berjam-jam, termasuk aplikasi-aplikasi besar yang mengandalkan S3 sebagai penyimpanan utama tanpa strategi redundansi memadai. Kejadian semacam ini — baik disebabkan kesalahan manusia, bencana alam, serangan siber, maupun kegagalan hardware — adalah pengingat bahwa pertanyaan bukan lagi "apakah sistem kita akan pernah down total", melainkan "seberapa siap kita ketika itu terjadi". Disaster recovery (DR) adalah disiplin yang menjawab pertanyaan itu: bagaimana organisasi memulihkan sistem, data, dan operasional bisnis secepat dan seminim kerugian mungkin setelah insiden besar. Artikel ini membahas DR secara menyeluruh, dari konsep dasar RTO/RPO, strategi backup, arsitektur failover, hingga cara menguji rencana DR agar benar-benar bisa diandalkan saat dibutuhkan.

Apa Itu Disaster Recovery, dan Kenapa Berbeda dari Backup Biasa

Disaster recovery sering disalahpahami sebagai sekadar "punya backup data". Padahal backup hanyalah salah satu komponen dari DR. Disaster recovery adalah keseluruhan strategi, proses, dan infrastruktur yang memungkinkan organisasi memulihkan seluruh kemampuan operasional sistem — bukan cuma datanya, tapi juga aplikasi yang berjalan, konfigurasi jaringan, kredensial akses, hingga proses bisnis yang bergantung padanya — setelah insiden besar seperti kegagalan data center, serangan ransomware, kesalahan konfigurasi fatal, atau bencana alam.

Disaster recovery adalah bagian dari payung yang lebih besar bernama Business Continuity Planning (BCP), yang juga mencakup aspek non-teknis seperti komunikasi krisis ke pelanggan, rantai komando darurat, dan kelangsungan operasional tim non-engineering.

Dua Metrik Fundamental: RTO dan RPO

Dua istilah ini adalah bahasa universal dalam perencanaan disaster recovery, dan menentukan seberapa besar investasi infrastruktur yang dibutuhkan.

• RTO (Recovery Time Objective) — target maksimum waktu yang dibutuhkan sistem untuk kembali beroperasi normal setelah insiden terjadi. Jika RTO ditetapkan 1 jam, artinya sistem harus sudah pulih dan bisa diakses kembali dalam waktu 1 jam sejak insiden dimulai.
• RPO (Recovery Point Objective) — target maksimum data yang boleh hilang, diukur dalam satuan waktu mundur dari titik insiden. Jika RPO ditetapkan 15 menit, artinya sistem backup harus mampu memulihkan data hingga maksimal 15 menit sebelum insiden terjadi — data yang masuk dalam 15 menit terakhir sebelum insiden boleh hilang, tapi tidak lebih dari itu.

Semakin kecil nilai RTO dan RPO yang ditargetkan, semakin mahal dan kompleks infrastruktur yang dibutuhkan untuk mencapainya. RTO mendekati nol butuh sistem failover otomatis yang selalu siaga (hot standby); RPO mendekati nol butuh replikasi data sinkron secara real-time. Organisasi perlu menetapkan RTO/RPO berbeda untuk sistem berbeda sesuai kekritisannya — sistem pembayaran mungkin butuh RTO/RPO dalam hitungan detik, sementara sistem laporan internal mungkin cukup toleran dengan RTO 24 jam.

Jenis-jenis Bencana yang Perlu Diantisipasi

DR plan yang baik mempertimbangkan berbagai skenario, bukan hanya "server mati":

• Kegagalan infrastruktur fisik — data center kebakaran, banjir, gangguan listrik massal, atau kerusakan hardware storage.
• Gangguan penyedia cloud — outage region tertentu dari AWS/GCP/Azure, seperti insiden S3 tahun 2017 yang disebutkan di awal.
• Kesalahan manusia (human error) — perintah DROP TABLE yang tidak sengaja dijalankan di produksi, deployment yang salah konfigurasi, atau penghapusan resource cloud secara tidak sengaja. Ini justru penyebab insiden paling umum dibanding bencana alam.
• Serangan siber — ransomware yang mengenkripsi data produksi dan backup sekaligus jika keduanya berada di jaringan yang sama, atau serangan DDoS yang melumpuhkan akses.
• Kegagalan software/bug kritis — bug pada proses migrasi data yang merusak integritas database, atau memory leak yang menyebabkan seluruh cluster crash serentak.
• Kegagalan dependency pihak ketiga — API payment gateway atau layanan SMS OTP yang down, melumpuhkan fungsi bisnis kritikal meski infrastruktur milik sendiri baik-baik saja.

Strategi Backup: Aturan 3-2-1 dan Variannya

Aturan backup klasik yang masih relevan hingga sekarang adalah aturan 3-2-1:

• 3 — simpan setidaknya tiga salinan data (data asli plus dua backup).
• 2 — simpan di dua jenis media/lokasi penyimpanan berbeda (misalnya disk lokal dan object storage cloud).
• 1 — simpan setidaknya satu salinan di lokasi terpisah secara geografis (off-site), agar bencana lokal (kebakaran, banjir) tidak menghapus semua salinan sekaligus.

Di era cloud modern, aturan ini sering diperluas menjadi 3-2-1-1-0: tambahan "1" untuk salinan yang immutable atau air-gapped (tidak bisa diubah/dihapus bahkan oleh akun yang sudah disusupi, penting sebagai pertahanan terhadap ransomware), dan "0" untuk memastikan proses restore diverifikasi tanpa error setiap kali diuji.

Berikut contoh script backup PostgreSQL sederhana yang mengimplementasikan sebagian prinsip ini — backup terjadwal, terkompresi, diunggah ke object storage terpisah region, dengan retensi otomatis:

#!/bin/bash
set -euo pipefail

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="/tmp/backup_${TIMESTAMP}.sql.gz"
RETENTION_DAYS=30

# Dump database dan kompresi langsung
pg_dump -h "$DB_HOST" -U "$DB_USER" -d "$DB_NAME" \
  --format=custom --compress=9 \
  | gzip > "$BACKUP_FILE"

# Upload ke object storage region utama
aws s3 cp "$BACKUP_FILE" \
  "s3://backup-primary-ap-southeast-3/db/${TIMESTAMP}.sql.gz" \
  --storage-class STANDARD_IA

# Replikasi ke region terpisah (cross-region)
aws s3 cp "$BACKUP_FILE" \
  "s3://backup-dr-us-west-2/db/${TIMESTAMP}.sql.gz" \
  --storage-class STANDARD_IA

# Hapus backup lokal setelah upload sukses
rm -f "$BACKUP_FILE"

# Terapkan object lock (immutability) selama masa retensi
aws s3api put-object-legal-hold \
  --bucket backup-dr-us-west-2 \
  --key "db/${TIMESTAMP}.sql.gz" \
  --legal-hold Status=ON

echo "Backup ${TIMESTAMP} selesai dan direplikasi ke dua region."

Perhatikan penggunaan put-object-legal-hold di akhir script — ini adalah implementasi konsep "immutable backup" yang mencegah backup dihapus atau ditimpa, bahkan oleh kredensial yang sudah disusupi penyerang ransomware, selama periode legal hold aktif.

Arsitektur Failover

Backup saja tidak cukup untuk mencapai RTO yang rendah — memulihkan sistem dari backup dingin (cold backup) bisa memakan waktu berjam-jam. Untuk sistem kritikal, dibutuhkan arsitektur failover yang memungkinkan sistem cadangan mengambil alih secara cepat, bahkan otomatis.

Active-Passive (Hot Standby)

Sistem cadangan berjalan penuh secara paralel dengan sistem utama, menerima replikasi data secara real-time, tapi tidak melayani traffic produksi sampai terjadi failover. Ketika sistem utama gagal, traffic dialihkan (biasanya lewat DNS failover atau load balancer) ke sistem cadangan. RTO bisa dicapai dalam hitungan menit, tapi ada biaya menjalankan infrastruktur cadangan yang sebagian besar waktu menganggur (idle).

Active-Active

Kedua (atau lebih) sistem berjalan secara bersamaan dan sama-sama melayani traffic produksi, biasanya di region berbeda, dengan load balancer global mendistribusikan traffic di antara keduanya. Jika satu region gagal, traffic otomatis dialihkan sepenuhnya ke region lain tanpa downtime yang terasa pengguna. Ini memberikan RTO mendekati nol, tapi jauh lebih kompleks secara arsitektur — terutama untuk data konsisten (butuh strategi replikasi database multi-master atau conflict resolution yang matang) dan biayanya juga lebih tinggi karena kedua sisi harus mampu menangani traffic penuh sendirian.

Pilot Light

Pendekatan hemat biaya di mana hanya komponen inti (biasanya database dengan replikasi berjalan) yang selalu aktif di region DR, sementara komponen compute (server aplikasi) baru di-provision saat failover benar-benar dibutuhkan. RTO lebih lambat dibanding hot standby (butuh waktu provisioning), tapi jauh lebih murah untuk dijalankan sehari-hari.

Backup and Restore

Pendekatan paling murah tapi RTO paling lambat: tidak ada infrastruktur cadangan yang berjalan sama sekali, semua di-provision dari nol menggunakan Infrastructure as Code (Terraform/CloudFormation) dan data dipulihkan dari backup saat insiden terjadi. Cocok untuk sistem non-kritikal dengan toleransi downtime tinggi.

Replikasi Database untuk Disaster Recovery

Strategi replikasi database menentukan langsung RPO yang bisa dicapai:

• Replikasi sinkron — setiap transaksi dikonfirmasi sukses hanya setelah tertulis di primary dan replica DR. Memberikan RPO mendekati nol (zero data loss), tapi menambah latensi setiap transaksi, terutama jika replica berada di region yang jauh secara geografis.
• Replikasi asinkron — transaksi dikonfirmasi sukses segera setelah tertulis di primary, replikasi ke DR terjadi belakangan dengan sedikit lag. Latensi transaksi lebih rendah, tapi ada risiko kehilangan data yang belum sempat direplikasi jika primary gagal mendadak (RPO tidak nol, tergantung besar lag replikasi).
• Replikasi semi-sinkron — kompromi di antara keduanya, biasanya memastikan minimal satu replica menerima data sebelum transaksi dikonfirmasi, tanpa harus menunggu replica DR yang jauh.

Contoh konfigurasi PostgreSQL untuk replikasi streaming asinkron ke instance DR di region berbeda menggunakan postgresql.conf:

# Primary: ap-southeast-3
wal_level = replica
max_wal_senders = 5
wal_keep_size = 1GB
archive_mode = on
archive_command = 'aws s3 cp %p s3://wal-archive-dr/%f'

# Replica DR: us-west-2 (recovery.conf / standby.signal di PG 12+)
primary_conninfo = 'host=primary-db.internal port=5432 user=replicator'
restore_command = 'aws s3 cp s3://wal-archive-dr/%f %p'

Menyusun Disaster Recovery Plan

DR plan yang efektif adalah dokumen hidup, bukan sekadar arsip yang dibuat sekali lalu dilupakan. Struktur umum yang perlu ada:

1. Inventarisasi sistem dan klasifikasi kekritisan. Daftar semua sistem, data yang mereka simpan, dan tier RTO/RPO masing-masing.
2. Peran dan tanggung jawab (RACI). Siapa yang berwenang mendeklarasikan status "disaster", siapa yang mengeksekusi failover, siapa yang berkomunikasi ke pelanggan dan manajemen.
3. Runbook teknis langkah demi langkah untuk setiap skenario — bukan cuma "restore dari backup", tapi urutan perintah konkret, kredensial mana yang dipakai, dan siapa yang dihubungi jika langkah tertentu gagal.
4. Rencana komunikasi krisis — template pengumuman ke pelanggan, status page yang diperbarui, dan eskalasi internal.
5. Kontak darurat — nomor telepon vendor cloud, tim keamanan, dan pihak ketiga kritikal, disimpan di tempat yang tetap bisa diakses meski sistem utama down (misalnya bukan cuma di wiki internal yang hosting-nya ikut down).

Menguji DR Plan: Jangan Cuma Ditulis, Dijalankan

DR plan yang tidak pernah diuji hampir pasti akan gagal saat benar-benar dibutuhkan — backup yang ternyata corrupt, kredensial yang sudah kedaluwarsa, atau runbook yang mengasumsikan langkah yang sudah tidak relevan dengan arsitektur terkini. Beberapa metode pengujian yang direkomendasikan:

• Tabletop exercise — simulasi diskusi (tanpa eksekusi teknis nyata) di mana tim membahas langkah-langkah respons terhadap skenario bencana hipotetis, biasanya dilakukan kuartalan.
• Simulasi failover terjadwal — benar-benar mengalihkan traffic ke sistem DR pada jam dengan traffic rendah, untuk memverifikasi seluruh rantai proses bekerja end-to-end, bukan cuma di atas kertas.
• Uji restore backup secara rutin — banyak insiden nyata terjadi bukan karena tidak ada backup, tapi karena backup yang ada ternyata tidak bisa di-restore (corrupt, format berubah, atau kredensial akses sudah tidak valid). Restore test bulanan ke lingkungan staging adalah praktik minimum yang wajib ada.
• Chaos engineering — pendekatan yang dipopulerkan Netflix lewat tool seperti Chaos Monkey, yang secara sengaja mematikan instance produksi secara acak (dalam batas terkendali) untuk memvalidasi bahwa sistem benar-benar tangguh terhadap kegagalan, bukan cuma diasumsikan tangguh di atas kertas arsitektur.

Layanan Cloud untuk Disaster Recovery

Kesalahan Umum dalam Perencanaan Disaster Recovery

• Menyimpan backup di lokasi/akun cloud yang sama dengan sistem produksi. Jika akun cloud disusupi atau region utama mengalami outage total, backup yang berada di tempat sama ikut terdampak.
• Tidak pernah menguji proses restore. Backup yang "ada" tapi tidak pernah diverifikasi bisa di-restore sama saja dengan tidak punya backup sama sekali.
• RTO/RPO ditetapkan tanpa mempertimbangkan biaya realistis. Menargetkan RTO 1 menit untuk semua sistem tanpa membedakan tier kritikalitas hanya akan membuat biaya infrastruktur membengkak tanpa manfaat proporsional.
• DR plan hanya menyimpan aspek teknis, lupa aspek manusia. Siapa yang berwenang mengambil keputusan pukul 2 dini hari saat insiden terjadi? Tanpa kejelasan ini, waktu berharga terbuang untuk eskalasi internal yang membingungkan.
• Mengabaikan dependency pihak ketiga dalam DR plan. Sistem sendiri sudah punya failover matang, tapi lupa bahwa payment gateway atau layanan SMS OTP pihak ketiga juga bisa jadi single point of failure.
• Dokumentasi DR plan tidak diperbarui seiring perubahan arsitektur, sehingga runbook yang ditulis dua tahun lalu sudah tidak relevan dengan infrastruktur saat ini.

Kesimpulan

Disaster recovery bukan sekadar checklist "sudah punya backup", melainkan strategi menyeluruh yang menggabungkan target bisnis (RTO/RPO), arsitektur teknis (replikasi, failover), proses operasional (runbook, RACI), dan yang paling sering diabaikan: disiplin pengujian berkala. Organisasi yang serius soal ketahanan sistem memperlakukan DR plan sebagai dokumen hidup yang terus diuji dan diperbarui, bukan arsip yang ditulis sekali untuk memenuhi syarat audit lalu dilupakan. Investasi pada disaster recovery memang terasa seperti "biaya tanpa manfaat langsung" — sampai hari ketika insiden besar benar-benar terjadi, dan perbedaan antara organisasi yang pulih dalam hitungan menit versus yang kehilangan data selamanya ditentukan sepenuhnya oleh seberapa matang persiapan yang sudah dibangun jauh sebelum bencana itu datang.