Pukul 23:47, notifikasi merah nyala. Migrasi “kecil” bikin data kemarin lenyap. Backup ada—tapi cuma versi terbaru. Yang kesimpen? Versi rusaknya. Kami bengong beberapa detik sebelum sadar: malam itu bukan soal debug, tapi cari cara mundur ke waktu yang masih waras.
Minggu lain, jam makan siang, seseorang menghapus tabel “dummy” di production. Tidak dummy sama sekali. Kami lari ke salinan dekat di server lain, tarik napas, dan balik jalan sebelum kopi dingin. Hari itu kami belajar: kecepatan bukan kemewahan, itu oksigen.
Lalu suatu sore, laptop editor kena ransomware pas promo mau tayang. Panic? Sedikit. Tapi ada salinan jauh di cloud yang nggak bisa dihapus sembarangan. Kerjaan lanjut. Malamnya kami makan gorengan, bukan tebus kunci.
Dari tiga hari sial itu, kami pulang dengan satu aturan tua yang masih relevan: tiga—dua—satu.
Apa itu 3‑2‑1 (singkat dan jelas)
3 salinan: data aktif, satu cadangan dekat untuk balik cepat, satu cadangan jauh untuk bencana lokal.
2 media: teknologi/storage yang beda, biar satu kegagalan nggak ngepel semua.
1 offsite: lokasi/provider lain. Kalau kantor mati listrik dan banjir, salinan ini pura‑pura nggak kenal.
Tujuan yang dipegang bareng
- RPO: berapa menit data maksimal boleh hilang. Target masuk akal 5–15 menit.
- RTO: berapa lama sampai sistem balik jalan. Target masuk akal 30–60 menit.
Tulis angkanya, ukur, lalu beneran kejar.
Contoh arsitektur 3‑2‑1 di production
- Primary: database utama (production).
- Nearline: replika/warm‑standby di region/host berbeda buat insiden cepat.
- Cold backup: full backup harian ke object storage provider lain; aktifkan versioning + object lock (immutability) 7–30 hari.
- Retensi: harian 7–14 hari, mingguan 4 minggu, bulanan 3 bulan (7‑4‑3) — sesuaikan kebutuhan dan biaya.
Tiga kejadian yang bikin 3‑2‑1 masuk akal
- Migration salah: backup cuma versi terbaru, yang kesimpen ya versi rusaknya. Pelajaran: perlu retensi beberapa hari/minggu biar bisa mundur.
- Tabel “dummy” kehapus: ada salinan dekat, balik cepat. Pelajaran: salinan dekat itu nyawa saat butuh cepat.
- Ransomware di laptop: ada salinan jauh yang nggak bisa dihapus sembarangan. Pelajaran: offsite harus tahan dari penghapusan dan bencana lokal.
Jebakan yang bikin kapok
- Backup di server yang sama — mati bareng, nggak ada yang ditolong.
- Semuanya di satu provider — aman rasa ilusi.
- Retensi terlalu pendek — bug lama nggak bisa di‑undo.
- Job backup gagal tanpa alert — ketahuan pas butuh.
- Ngandelin snapshot doang tanpa logical backup — restore nyangkut di versi engine/konfigurasi.
- Satu kredensial buat semua — sekali bocor, habis.
Ritual Jumat: uji restore (10–30 menit)
- Ambil backup terbaru + log (kalau pakai PITR).
- Restore ke instance kosong/staging, jalanin migrasi/seed seperlunya.
- Verifikasi cepat: hitung row tabel inti, login admin, query kritikal.
- Catat total waktu (RTO aktual) dan titik waktu data (RPO aktual).
- Kalau janggal, perbaiki minggu itu juga. Minggu depan, ulang.
Penutup
Orang nitipin kepercayaan di setiap baris data. 3‑2‑1 bikin lo bisa bilang, “Kalau pun salah, kita mundur dikit, terus lanjut jalan.” Sesederhana itu — dan sepenting itu.
Referensi
- CISA — Stop Ransomware Guide (backup offline/immutable, tes rutin)
- Backblaze — The 3‑2‑1 Backup Strategy
- Veeam — 3‑2‑1‑1‑0 (tambah satu copy immutable + target “zero errors”)
- Peter Krogh — The DAM Book (asal‑usul populer)
- Immutability: S3 Object Lock · Azure Immutable Blob · GCS Bucket Lock