Belajar Cloud Engineer - Backup & Disaster Recovery Cloud

#Pendahuluan

Di episode 17 kita memigrasi aplikasi ke cloud, dan di episode 19 mengamankan aksesnya. Tapi ada satu pertanyaan yang belum terjawab: apa yang terjadi jika region cloud kalian mati? Ini bukan teori — outage region pernah terjadi di semua provider besar, dan perusahaan yang tidak siap kehilangan data serta reputasi dalam hitungan jam.

Episode 20 membahas backup & disaster recovery (DR): dua konsep yang sering dicampur tapi beda. Backup melindungi dari kesalahan manusia dan korupsi data. DR melindungi dari kegagalan infrastruktur skala besar. Kalian akan belajar RPO/RTO, cross-region replication, pola DR yang berbeda, lalu melakukan simulasi DR — latihan membuktikan bahwa infrastruktur bisa bangkit kembali.

#Backup vs Disaster Recovery

Keduanya punya tujuan berbeda, dan mencampurnya adalah kesalahan umum:

Backup tanpa DR = data aman, tapi aplikasi tidak kembali. DR tanpa backup = sistem kembali, tapi datanya sudah lama. Keduanya wajib.

#Bahasa Kesepakatan: RPO dan RTO

Dua angka inilah bahasa yang dipakai seluruh industri untuk menyepakati target:

• RPO (Recovery Point Objective) — seberapa banyak data yang boleh hilang (diukur mundur dari saat bencana). RPO 1 jam = maksimal kehilangan data 1 jam terakhir. Menentukan frekuensi backup/replikasi.
• RTO (Recovery Time Objective) — seberapa cepat sistem harus pulih. RTO 4 jam = sistem harus hidup dalam 4 jam. Menentukan otomasi recovery yang dibutuhkan.

Aturan praktis: semakin kecil RPO/RTO, semakin mahal. RPO 0 (nol detik kehilangan data) butuh sinkronous replication — mahal dan latensinya berpengaruh. RPO 1 hari (backup harian) murah. Cloud engineer tidak menuntut "nol semua", melainkan memilih angka yang sepadan dengan nilai bisnis.

#Cross-Region Replication

Langkah pertama DR: data tidak boleh tinggal di satu lokasi fisik. Cross-region replication menyalin data ke region kedua secara otomatis:

aws s3api put-bucket-replication \
  --bucket lab-static-assets \
  --replication-configuration file://replication.json

replication.json berisi bucket target di region kedua dan role IAM yang boleh menyalin. Setelah aktif, setiap objek baru otomatis disalin — kalian tidak perlu ingat melakukannya manual (episode 8: automasi adalah kebiasaan).

Untuk database, read replica lintas region tidak hanya untuk DR — ia juga melayani trafik baca region lain. Upgrade ke full DR membutuhkan promote replica menjadi primary saat bencana (proses yang harus didokumentasikan dan dilatih).

#Pola Disaster Recovery

Ada beberapa pola DR dengan biaya dan kecepatan berbeda:

Tidak ada pola terbaik — hanya pola yang sesuai RPO/RTO dan budget. Aplikasi lab kalian mungkin cukup backup & restore; aplikasi bank butuh multi-site.

#Backup Berlapis dan Retensi

Backup yang baik memakai prinsip 3-2-1: tiga salinan data, di dua media berbeda, satu di lokasi off-site. Di cloud, pola ini berarti:

1. Snapshot berkala (VM, database) — cadangan konsisten.
2. Replikasi ke region lain — lapisan off-site.
3. Immutability / WORM — backup yang tidak bisa diubah atau dihapus (bahkan oleh admin), untuk melindungi dari ransomware dan kesalahan.

# Snapshot EBS harian, simpan 7 hari, replikasi ke region kedua
# diotomasi lewat lifecycle policy (AWS DLM / GCP snapshots / Azure)
aws dlm create-lifecycle-policy --policy-details file://dlm.json

Retensi juga butuh keputusan: berapa lama backup disimpan? Aturan umum — jangka pendek (hari) murah dan sering; jangka panjang (bulan/tahun) mahal. Backup bulanan yang disimpan 1 tahun cukup untuk audit; backup per-15-menit tidak perlu disimpan setahun.

#Praktik: Simulasi DR Cloud

DR yang tidak pernah diuji adalah DR yang tidak ada. Simulasi DR (DR drill) untuk aplikasi lab-ecommerce:

1. Tetapkan target: RPO 1 jam, RTO 4 jam.
2. Siapkan region kedua: bucket dengan replikasi, snapshot VM yang di-replikasi, dan Terraform (episode 7) untuk environment cadangan.
3. Dokumentasikan runbook — langkah demi langkah: promote database, deploy aplikasi, alihkan DNS.
4. Jalankan simulasi: bayangkan region utama mati, ikuti runbook dari awal, ukur waktunya.
5. Verifikasi hasil: bandingkan data terakhir (RPO), catat waktu pemulihan (RTO), dan temukan langkah yang gagal.
6. Perbaiki dan ulangi — simulasi pertama pasti menemukan kelemahan; itulah gunanya.

dr-runbook:
  target: rpo 1 jam / rto 4 jam
  langkah:
    - promote read replica jadi primary  # RTO: +10 menit
    - terraform apply environment-cadangan # RTO: +40 menit
    - deploy aplikasi lewat pipeline       # RTO: +15 menit
    - switch DNS ke region kedua           # RTO: +5 menit
    - verifikasi healthcheck & data        # RTO: +15 menit
  catatan:
    - semua perintah dijalankan pipeline, bukan manual
    - rollback = kembalikan DNS ke region utama

Aturan emas: DR drill harus sering (minimal kuartalan), dan setiap drill menghasilkan perbaikan runbook. Kalian akan menyadari bahwa kegagalan DR hampir selalu karena hal sepele yang tidak pernah diuji: DNS cache, permission IAM di region kedua, atau endpoint yang hardcode region.

#Kesalahan Umum (Common Pitfalls)

1. Menganggap backup sebagai DR — data aman tapi sistem tidak pernah kembali (RTO tak terdefinisi).
2. RPO/RTO tidak disepakati — target samar = arsitektur DR tidak pernah selesai.
3. Backup satu lokasi — menghapus snapshot lama di region yang sama dengan sumber; off-site replication wajib.
4. DR tanpa IaC — membangun ulang environment manual saat panik = recipe bencana (episode 7, 14).
5. Runbook tidak diuji — pertama kali runbook dijalankan adalah saat bencana nyata; latih dulu.
6. Backup tanpa retensi policy — biaya storage backup membengkak (episode 16); tetapkan retensi sejak awal.

#Penutup

Inti yang harus dibawa pulang:

• Backup melindungi data, DR melindungi sistem berjalan — dua hal berbeda, dua-duanya wajib.
• RPO/RTO adalah bahasa kesepakatan; target menentukan arsitektur dan biaya.
• Cross-region replication membuat data tidak bergantung pada satu lokasi fisik.
• Pola DR: backup-restore → pilot light → warm standby → active-active, pilih sesuai budget.
• DR drill adalah satu-satunya cara membuktikan DR bekerja — dan IaC adalah fondasinya.

Di episode 21 selanjutnya kita akan membuat infrastruktur yang tidak cuma selamat dari bencana, tapi juga menyesuaikan diri: auto-scaling & reliability — auto-scaling groups, target tracking, dan arsitektur multi-AZ high availability, lalu menerapkan auto-scaling untuk produksi. Sampai jumpa di episode 21!