Belajar Cloud Computing - Disaster Recovery (DR) & Business Continuity

#Pendahuluan

Pada episode 18 kemarin kita membangun jembatan konektivitas antara data center on-premise dan cloud, dari IPsec Site-to-Site VPN hingga dedicated private connection. Namun konektivitas hanyalah sebagian cerita. Ada pertanyaan yang wajib dijawab setiap organisasi yang menjalankan sistem di production: apa yang terjadi ketika sesuatu yang jauh lebih besar rusak?

Bukan sekadar satu server yang mati — melainkan gempa bumi, kebakaran data center, kesalahan manusia yang menghapus database produksi, atau serangan ransomware yang mengenkripsi seluruh sistem. Insiden sebesar ini terjadi lebih sering daripada yang kalian kira, dan di sinilah Disaster Recovery (DR) dan Business Continuity (BC) menentukan apakah sebuah perusahaan bertahan atau runtuh.

Business Continuity adalah kemampuan organisasi tetap beroperasi saat gangguan besar. Disaster Recovery adalah bagian teknis dari itu: bagaimana memulihkan sistem, data, dan infrastruktur dari bencana. Di cloud, DR menjadi jauh lebih terjangkau daripada di on-premise, karena penyedia menyediakan region, object storage, dan layanan manajemen yang bisa dipakai sebagai target pemulihan. Pada episode ini kita akan membahas dua metrik yang menjadi dasar semua keputusan DR — RPO dan RTO — lalu empat strategi pemulihan dari yang termurah hingga yang paling tangguh.

#RPO dan RTO: Dua Angka yang Menentukan Segalanya

Semua keputusan DR berakar pada dua angka yang harus ditetapkan lebih dulu. Keduanya ditentukan oleh bisnis, bukan oleh engineer.

#RPO (Recovery Point Objective)

RPO adalah batas maksimum kehilangan data yang boleh terjadi saat bencana, diukur dalam waktu. Jika RPO kalian adalah 1 jam, artinya kalian rela kehilangan maksimal 1 jam data terakhir. Semakin kecil RPO, semakin sering backup atau replikasi harus dilakukan.

Analogi paling jelas: kalian menulis dokumen panjang dan menekan Ctrl+S setiap 30 menit. Jika laptop mati mendadak, kalian hanya kehilangan maksimal 30 menit pekerjaan — RPO kalian adalah 30 menit. Titik pemulihan adalah kondisi data pada saat terakhir tersimpan; semakin sering menyimpan, semakin kecil kehilangan data yang harus diterima.

RPO = selisih waktu antara data terakhir yang tersimpan dan saat bencana terjadi
RPO kecil = backup/replikasi sering dilakukan
RPO besar = backup/replikasi jarang, risiko kehilangan data meningkat

#RTO (Recovery Time Objective)

RTO adalah batas maksimum durasi downtime yang boleh terjadi, diukur dari bencana sampai sistem pulih kembali beroperasi normal. Jika RTO kalian 4 jam, sistem harus kembali melayani pengguna dalam 4 jam.

Analogi untuk RTO: sebuah toko mati listrik di jam buka. Selama lampu padam, tidak ada transaksi dan tidak ada pemasukan. Pemilik toko harus memutuskan berapa lama ia sanggup kehilangan pendapatan sebelum kerugiannya tidak tertahankan — itulah RTO. Panjang RTO ditentukan oleh seberapa cepat proses pemulihan berjalan: menyalakan server, me-restore data, dan memverifikasi semuanya.

Kedua angka ini saling berkaitan, dan pola yang tidak bisa dihindari: semakin kecil RPO dan RTO, semakin mahal biayanya. Strategi DR apapun yang kalian pilih hanyalah cara mencapai target RPO/RTO dengan biaya yang masih bisa diterima organisasi.

#Empat Strategi Disaster Recovery di Cloud

#1. Backup & Restore

Strategi paling sederhana dan paling murah. Seluruh data di-backup secara berkala ke object storage atau snapshot, dan saat bencana terjadi semuanya di-restore dari nol. Tidak ada resource DR yang berjalan di sisi pemulihan — biaya hanya muncul saat backup dijalankan dan saat bencana benar-benar terjadi.

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier app-prod-restored \
  --db-snapshot-identifier rds:app-prod-2026-08-03-01-00

RPO-nya sama dengan interval backup — bisa 24 jam atau lebih jika hanya backup harian. Perhatikan --db-snapshot-identifier pada perintah di atas: itulah penentu titik pemulihan, dan semakin jauh snapshot itu dari waktu bencana, semakin banyak data yang hilang. RTO-nya yang terpanjang dari semua strategi: restore snapshot, provisioning ulang infrastruktur, konfigurasi ulang aplikasi, hingga verifikasi data. Cocok untuk data yang tidak kritis, atau workload dengan target RPO/RTO dalam hitungan jam hingga hari.

#2. Pilot Light

Konsepnya seperti lampu pilot pada kompor gas, atau mesin pesawat yang menyala saat parkir di apron: hanya komponen inti yang tetap hidup, sisanya dinyalakan penuh saat dibutuhkan. Di cloud, komponen inti itu biasanya database yang terus-menerus mereplikasi data ke region pemulihan, sementara server aplikasi dan load balancer tidak berjalan sama sekali.

aws rds promote-read-replica \
  --db-instance-identifier app-prod-replica

Saat bencana terjadi, kalian cukup menyalakan server aplikasi, menautkannya ke database yang dipromosikan lewat aws rds promote-read-replica, dan mengarahkan DNS ke infrastruktur baru. Karena database selalu sinkron, RPO mendekati nol, dan RTO lebih pendek daripada backup-and-restore karena tidak ada proses restore data — hanya provisioning compute. Biayanya murah karena yang berjalan terus hanyalah database berkapasitas kecil.

#3. Warm Standby

Versi "setengah nyala" dari environment production: environment minimal yang berjalan terus-menerus — server aplikasi aktif dengan kapasitas kecil, database mereplikasi data, dan otomatisasi sudah siap untuk menaikkan skala saat dibutuhkan.

Resources:
  StandbyASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: 2
      MaxSize: 20
      DesiredCapacity: 2
      LaunchConfigurationName: app-standby-launch-config

Pada konfigurasi di atas, MinSize: 2 memastikan minimal dua instance selalu hidup meski dalam keadaan normal. Karena sistem sudah hidup, failover tinggal mengarahkan traffic dan menaikkan kapasitas. RPO biasanya dalam hitungan detik hingga menit, RTO dalam hitungan menit. Biayanya lebih tinggi daripada pilot light karena ada resource yang berjalan terus, tetapi masih jauh di bawah biaya menjalankan production ganda penuh.

#4. Multi-Region Active-Active

Strategi paling mahal sekaligus paling tangguh: dua atau lebih region yang sama-sama aktif melayani traffic sejak awal. DNS dengan routing berbasis latency dan health check (misalnya Route 53 di AWS atau global load balancing) mendistribusikan request ke semua region; ketika satu region mati, traffic otomatis berpindah ke region yang tersisa.

Region A ──┐                     ┌── Region B
  ALB ─────┼── Global DNS ───────┼── ALB
  App ─────┘   (health check)    └── App
  DB (replikasi multi-region)

Karena kedua region selalu aktif dan data direplikasi terus-menerus, RPO dan RTO mendekati nol — pengguna nyaris tidak merasakan gangguan. Namun konsekuensinya paling berat: setiap region menjalankan production penuh, data harus direplikasi lintas region dengan menangani masalah konsistensi dan konflik tulis, dan biaya transfer data antar region ikut membengkak.

#Perbandingan Empat Strategi

Perhatikan pola yang konsisten: semakin kecil RPO dan RTO, semakin mahal biaya dan semakin kompleks operasinya. Tidak ada strategi yang "paling benar" — yang paling benar adalah strategi yang mampu memenuhi target bisnis dengan biaya yang bisa diterima.

#Memilih Strategi: Urutan Kerjanya

1. Tetapkan target dari bisnis, bukan dari teknologi. Tanyakan: berapa banyak data yang boleh hilang (RPO) dan berapa lama sistem boleh mati (RTO) agar bisnis tetap bertahan? Angka ini harus disetujui pemilik bisnis, bukan ditentukan engineer sendirian.
2. Pilih strategi termurah yang mampu memenuhi target. Mulai dari yang paling murah, lalu naikkan level hanya jika strategi tersebut gagal mencapai target.
3. Otomatiskan pemulihan. DR yang bergantung pada runbook manual yang dijalankan manusia di tengah kepanikan adalah DR yang rentan gagal. Codify prosedur pemulihan dengan Infrastructure as Code (kembali ke episode 16).
4. Uji secara berkala. Jadwalkan game day minimal setahun sekali, ukur RPO/RTO aktual, dan perbaiki jika hasilnya melewati target.

#Penutup

Pada episode 19 ini kalian memahami dua metrik yang menentukan semua keputusan disaster recovery: RPO — batas kehilangan data — dan RTO — batas durasi downtime — serta empat strategi yang memenuhi keduanya: backup and restore yang murah tapi lambat, pilot light yang hanya menghidupkan database inti, warm standby yang menjaga environment minimal tetap berjalan, dan multi-region active-active dengan RPO/RTO mendekati nol dengan biaya tertinggi.

Poin kunci yang perlu kalian bawa:

• RPO dan RTO adalah keputusan bisnis yang ditetapkan sebelum memilih teknologi.
• RPO menentukan frekuensi backup; RTO menentukan kecepatan pemulihan.
• Empat strategi DR membentuk spektrum biaya vs kecepatan: Backup & Restore, Pilot Light, Warm Standby, Active-Active.
• Strategi termurah selalu diuji dulu; naikkan level hanya jika target tidak tercapai.
• DR yang tidak pernah diuji hanyalah dokumen; latihan kegagalan adalah bagian dari strategi itu sendiri.

Kalian kini memiliki seluruh puzzle arsitektur cloud: fondasi, jaringan, komputasi, storage, database, keamanan, observability, konektivitas, hingga pemulihan bencana. Di episode 20, episode terakhir seri ini, kita akan merangkai semuanya menjadi studi kasus arsitektur production-grade yang lengkap, memeriksa checklist kesiapan produksi, dan menutup perjalanan dengan panduan jalur sertifikasi cloud. Sampai jumpa di episode final!