Belajar Data Center Engineer - Backup & DR Data Center

#Pendahuluan

Setelah di episode 12 kita mengelola kapasitas, sekarang kita siapkan skenario terburuknya: fasilitas utama hilang. Kebakaran hall, banjir regional, atau gangguan listrik total berhari-hari — pertanyaannya bukan "bisa terjadi?", melainkan "kalau terjadi, aplikasi apa yang harus hidup duluan, dalam berapa menit, dengan kehilangan data berapa detik?".

Backup dan disaster recovery (DR) sering dicampur. Backup menyelamatkan data dari kesalahan (terhapus, terenkripsi ransomware); DR menyelamatkan layanan dari bencana (site mati). DC engineer butuh keduanya — dan hari ini kita susun keduanya secara sistematis.

#RTO dan RPO: Bahasa Kontrak

Dua angka ini adalah seluruh dasar desain DR:

Istilah	Arti	Pertanyaan
RPO (Recovery Point Objective)	Berapa banyak data boleh hilang	"Kapan backup/replica terakhir?"
RTO (Recovery Time Objective)	Berapa cepat layanan harus kembali	"Berapa lama sampai jalan lagi?"

RPO 15 menit = maksimal kehilangan 15 menit data; RTO 4 jam = layanan wajib hidup dalam 4 jam. Angka-angka ini ditentukan bisnis, bukan IT sendirian — tugas engineer menerjemahkannya menjadi arsitektur dan biaya:

text

RTO 72 jam + RPO 24 jam  → backup offsite sederhana (murah)
RTO 4 jam  + RPO 1 jam   → warm site + async replication
RTO 0      + RPO ~0      → active-active + sync replication (mahal)

Setiap pengetatan angka = lonjakan biaya. Dokumen yang menjembatani keduanya disebut business impact analysis hasilnya masuk ke matriks tier aplikasi.

#Matriks Tier Aplikasi

Tidak semua sistem layak diperlakukan sama. Susun inventaris aplikasi ke dalam tier:

Tier	Contoh	RTO/RPO Tipikal	Strategi
0/Kritis	Core banking, payment gateway	RTO ~menit, RPO ~detik	Active-active / hot standby
1/Penting	ERP transaksi, e-commerce	RTO 2-8 jam, RPO 15-60 menit	Warm standby, async replica
2/Umum	Intranet, reporting	RTO 1-3 hari, RPO 24 jam	Restore di DR dari backup
3/Arsip	Data historis	RTO mingguan	Backup saja

Matriks inilah yang membuat rapat budget DR berubah dari perdebatan emosional menjadi tabel harga pilihan.

#Redundansi vs DR: Jangan Tertukar

Episode 3 membahas redundansi (2N power, dual feed). Penting dipisahkan:

text

Redundansi  : bertahan dari KEgagalan KOMPONEN di dalam satu site
              (UPS mati, PSU mati, link putus)
DR          : bertahan dari KEHILANGAN SITE UTAMA
              (kebakaran, banjir, bencana regional)

Fasilitas Tier IV sekalipun tidak menyelamatkan kalian dari kebakaran gedung — hanya DR site yang bisa. Sebaliknya, DR tanpa redundansi internal membuat failover sering dipicu oleh hal sepele.

#Pola DR Site

Tiga pola klasik, naik biaya seiring RTO mengecil:

Cold site: ruangan + rak kosong; restore dari backup saat bencana. Murah, RTO hari-an.
Warm site: hardware standby + data ter-replikasi async; aktifkan saat perlu. RTO jam-an.
Hot site / active-active: dua site melayani trafik bersamaan; RTO mendekati nol.

#Sync vs Async Replication

Pilihan replikasi dibatasi fisika cahaya:

text

Sync  : commit menunggu konfirmasi site kedua → RPO ≈ 0
        batas praktis jarak ±100 km (latensi membatasi throughput DB)
Async : commit lokal, replika menyusul → RPO = lag replikasi
        jarak bebas; risiko kehilangan data sebesar lag

Aturan jarak sync lahir dari latensi fiber ±5 µs/km satu arah: pada 100 km, round-trip ±1 ms — cukup untuk database tertentu, terlalu mahal untuk yang lain. Ini fondasi pemilihan lokasi DR site: cukup jauh agar tak kena bencana yang sama, cukup dekat jika sync diperlukan.

#Praktik: Replikasi ZFS Antar-Site

Untuk merasakan mekanik replikasi block-level, lab ZFS memberi eksperimen terbaik. Di site utama buat dataset dan snapshot:

Snapshot dataset sumber

sudo zfs create tank/appdata
zfs set compression=on tank/appdata
sudo zfs snapshot tank/appdata@base

Kirim snapshot pertama ke DR host (full):

Replikasi awal ke DR

sudo zfs send tank/appdata@base | \
  ssh dr@10.30.30.5 sudo zfs receive -duF pool/dr-appdata

Setelah ada perubahan data, kirim inkremental saja:

Replikasi inkremental berkala

sudo zfs snapshot tank/appdata@snap1
sudo zfs send -i tank/appdata@base tank/appdata@snap1 | \
  ssh dr@10.30.30.5 sudo zfs receive -duF pool/dr-appdata

Di dunia nyata loop ini dijalankan otomatis (cron/systemd timer atau tool seperti sanoid+syncoid), dan RPO kalian = interval loop minus durasi transfer. Pantau lag-nya sebagai metrik monitoring (episode 10): alert jika lag melewati target RPO.

#Praktik: DR Plan yang Layak Dipercaya

Dokumen DR plan minimalis namun jujur:

dc-docs/dr/dr-plan.md

# DR Plan - DC-JKT01 -> DC-BDG01 (warm)
 
## Asumsi
Site utama hilang total; personel dapat mengakses DR.
 
## Urutan Bangkit (recovery order)
1. Network edge & VPN (RTO 30 m)
2. Database cluster (RTO 2 j, via promote replica)
3. App servers (RTO 4 j, boot dari template)
4. Reporting/analytics (RTO 24 j)
 
## Prosedur Failover (ringkas, detail di runbook per-layanan)
1. Deklarasi bencana (siapa yang berwenang!)
2. Freeze perubahan DNS/konfigurasi
3. Promote replica DB, verifikasi konsistensi
4. Nyalakan app tier, arahkan ke DB DR
5. Ubah DNS/lb ke DR, uji smoke test
6. Komunikasi status ke stakeholder tiap 60 m
 
## Rollback (failback)
Direncanakan TERBALIK setelah site utama pulih;
resync arah balik dulu, baru cut-over kembali.
 
## Uji
Tabletop drill kuartalan; full failover test tahunan.
Hasil uji: tanggal, temuan, perbaikan.

Dua kalimat paling penting di dokumen itu: siapa yang berwenang mendeklarasikan bencana, dan jadwal pengujian. DR plan yang belum pernah diuji hanyalah fiksi korporat — rata-rata tim baru menemukan lubangnya (DNS lama, lisensi DR kedaluwarsa, akun vendor tak ada) saat mencoba sungguhan.

Important

Jadwalkan game day: satu setengah hari per kuartal, jalankan failover satu layanan tier-1 ke DR secara sungguhan. Temuan pertama game day selalu bernilai lebih mahal daripada satu tahun rapat.

#Common Pitfalls Backup & DR

Backup di storage yang sama dengan produksi — ransomware mengenkripsi keduanya sekali jalan; ikuti aturan 3-2-1 (3 salinan, 2 media, 1 offsite) plus salinan immutable.
Restore tidak pernah diuji — backup yang belum direstore adalah hipotesis; uji restore acak bulanan.
DR site ikut kena domain masalah yang sama — DNS tunggal, IdP tunggal, atau lisensi yang terikat site utama membuat DR lumpuh bersama.
Failback tidak direncanakan — semua siap failover, tidak siap pulang; data baru di DR vs data lama di utama = konflik replikasi.

#Penutup

Inti yang harus dibawa pulang:

RPO/RTO adalah angka dari bisnis; tugas engineer menerjemahkannya menjadi arsitektur dan biaya lewat matriks tier aplikasi.
Redundansi menyelamatkan dari kegagalan komponen; DR menyelamatkan dari kehilangan site — butuh keduanya.
Sync replication (jarak pendek, RPO≈0) vs async (jarak bebas, RPO=lag); pilih lokasi DR dengan logika itu.
Backup 3-2-1 + immutable untuk data; DR plan tertulis dengan recovery order, otoritas deklarasi, dan pengujian berkala.

Di episode 14 selanjutnya kita keluar dari dinding fasilitas: cloud & hybrid integration — kapan on-prem, colocation, atau cloud yang tepat, cara kerja interconnect privat lewat MMR, pola hybrid design, dan jebakan biaya egress yang mengubah keputusan arsitektur banyak organisasi. Sampai jumpa di episode 14!