Belajar Infrastructure Engineer - Backup & Disaster Recovery

#Pendahuluan

Setelah di episode 9 kita membangun penglihatan infrastruktur, kini saatnya membangun jaring pengaman: backup & disaster recovery. Semua infrastruktur pasti akan menghadapi bencana suatu saat — disk rusak, data terhapus, ransomware, kebakaran data center. Yang membedakan tim yang profesional bukan kemampuan mencegahnya (tidak mungkin), melainkan kemampuan pulih dengan cepat dan terbukti.

Mengapa topik ini penting? Karena backup yang tidak pernah diuji adalah ilusi keamanan. Banyak perusahaan baru sadar backup-nya rusak justru saat data hilang — saat paling tidak boleh salah. Episode ini membekali kalian kerangka DR lengkap: strategi backup, RPO/RTO, jenis backup, arsitektur DR site, dan DR drill yang sesungguhnya.

#Dua Angka yang Menggerakkan Semua Keputusan

Sebelum membahas tool apa pun, tetapkan dua angka — keduanya adalah kontrak bisnis, bukan keputusan teknis semata:

#RPO (Recovery Point Objective)

Berapa banyak data yang boleh hilang? RPO 24 jam berarti jika bencana terjadi sekarang, data satu hari terakhir hilang — backup harian cukup. RPO 15 menit berarti data maksimal 15 menit terakhir yang hilang — butuh backup jauh lebih sering (log shipping, streaming).

#RTO (Recovery Time Objective)

Berapa lama waktu pulih yang ditoleransi? RTO 4 jam berarti sistem harus kembali berjalan dalam 4 jam sejak bencana. RTO menentukan seberapa siap infrastruktur pemulihan: standby di lokasi lain (cepat) atau restore dari backup (lambat).

Hubungannya: RPO kecil = backup lebih sering = biaya lebih tinggi. RTO kecil = infrastruktur recovery lebih mahal. Tugas infra engineer adalah menemukan keseimbangan yang sesuai dengan nilai bisnis data — bukan memilih yang "paling aman" tanpa anggaran.

#Strategi 3-2-1

Aturan emas backup yang bertahan puluhan tahun:

Aturan 3-2-1

3 → Minimal 3 salinan data
2 → Di 2 media berbeda
1 → 1 di antaranya di lokasi terpisah

Contoh penerapan: data produksi (1) + backup disk lokal (2) + backup ke object storage di region lain (3). Jika data center terbakar, salinan terakhir masih terselamatkan di lokasi lain.

#Jenis Backup

Pola yang umum dipakai: full mingguan + incremental harian. Restore membutuhkan full terakhir + semua incremental setelahnya — karena itu uji restore berkala untuk memastikan rantai tidak putus.

Contoh backup database PostgreSQL:

pg_dump -Fc app > /backup/app-$(date +%F).dump
pg_restore -d app /backup/app-2026-08-16.dump

#Merancang DR Site

Recovery butuh tempat. Tiga level kesiapan:

Pada skala cloud, konsep ini menjadi region aktif-pasif (warm/hot) dan multi-region aktif-aktif (hot). Keputusan level DR selalu turun dari RTO/RPO: butuh pulih dalam menit → hot site; bisa menunggu 2 hari → cold site.

#Backup Server Tujuan

Backup harus pergi ke tempat yang tidak bisa dijangkau oleh penyebab bencana utama. Jika produksi terkena ransomware, backup yang masih terhubung jaringan ikut terenkripsi. Pola yang benar:

1. Backup ke storage terpisah (object storage dengan versioning).
2. Immutable backup: backup yang tidak bisa diubah atau dihapus dalam periode tertentu — pertahanan utama melawan ransomware.
3. Backup offline/air-gapped untuk data paling kritis.

Produksi (lokal)   → Disk backup (lokal terpisah)
Disk backup lokal  → Object storage (region berbeda, versioning ON, immutable)

#Otomasi Backup

Backup manual yang "ingat-ingat" pasti terlewat. Otomasi sejak awal — misal dengan script + cron atau tool seperti restic/borgbackup (bisa dilanjutkan ke series Belajar Borg Backup):

0 2 * * * /usr/local/bin/backup-pg.sh
30 2 * * * /usr/local/bin/backup-files.sh
0 3 * * 0 /usr/local/bin/backup-full.sh

Aturan otomasi backup:

1. Backup yang gagal harus terlihat — integrasikan status backup ke monitoring (episode 9).
2. Setiap backup punya metadata: apa, kapan, berapa besar, berapa lama restore.
3. Retensi yang jelas: berapa lama tiap tier disimpan (misal harian 30 hari, mingguan 12 minggu, bulanan 7 tahun).

#DR Drill: Menguji yang Tidak Boleh Gagal

Backup yang tidak pernah direstore adalah tebakan. DR drill adalah latihan berkala untuk membuktikan prosedur recovery benar-benar bekerja:

1. Tentukan skenario (disk rusak, ransomware, DC terbakar)
2. Restore penuh di lingkungan terpisah (bukan produksi!)
3. Ukur waktu restore aktual vs RTO
4. Bandingkan data ter-restore vs RPO yang dijanjikan
5. Dokumentasikan temuan & perbaiki prosedur
6. Lakukan ulang — DR drill bukan acara sekali jalan

#Common Pitfalls Backup & DR

• Backup tidak pernah diuji: storage penuh, perangkat rusak, atau script salah — semua baru ketahuan saat darurat.
• Backup satu lokasi: data center yang sama terbakar mengambil produksi + backup sekaligus.
• Backup bisa diubah/dihapus penyerang: tanpa immutability, ransomware menyapu semuanya.
• RPO/RTO tidak pernah dihitung: recovery dirapatkan asal-asalan, tidak terukur.
• DR drill "acara seremonial": semua berjalan mulus karena sudah dihafal, tidak menguji skenario sebenarnya.
• Database backup dengan cara salah: mysqldump/pg_dump benar, menyalin file data mentah (file copy) sering tidak konsisten.

#Penutup

Pada episode 10 ini kalian telah membangun fondasi backup & DR:

• RPO (berapa data boleh hilang) dan RTO (berapa lama boleh pulih) adalah kontrak bisnis yang menggerakkan semua keputusan.
• Strategi 3-2-1: 3 salinan, 2 media, 1 di lokasi berbeda.
• Backup full/incremental/differential dengan rantai yang harus diuji.
• DR site: cold → warm → hot, dipilih dari RTO.
• Immutable backup adalah pertahanan utama melawan ransomware.
• DR drill berkala mengubah backup dari tebakan menjadi bukti.

Di episode 11 selanjutnya kita menutup fase operasional dasar dengan security infrastructure — hardening, firewall, dan identity untuk infrastruktur yang dikelola dengan aman sejak awal. Sampai jumpa di episode 11!