Tidak ada yang naik jabatan karena sistem backup dan disaster recovery yang rapi. Tidak ada yang merayakan saat script restore berjalan mulus. Justru karena itulah urusan ini selalu dilewatkan, ditunda, dan akhirnya baru ketahuan rusak di hari ketika hal itu benar-benar penting, biasanya di Senin pagi setelah muncul catatan ransomware di komputer bagian akuntansi.
Saya pernah duduk berhadapan dengan pemilik bisnis di tiga puluh menit terburuk dalam setahun mereka, menatap folder "backup" yang ternyata kosong, atau cloud sync yang berhenti diam-diam sejak empat bulan lalu. Polanya selalu sama: mereka punya sesuatu yang terlihat seperti backup. Mereka tidak pernah mencoba me-restore-nya. Backup yang belum pernah di-restore adalah harapan, bukan backup, dan harapan bukan rencana disaster recovery.
Apa yang sebenarnya perlu di-backup
Kebanyakan bisnis melakukan backup pada hal yang salah, atau membackup semuanya tanpa pilah-pilih dan menyebutnya strategi. Mulailah dari apa yang benar-benar akan menghentikan bisnis jika hilang besok.
- Database transaksional, pesanan, invoice, inventori, data pelanggan. Ini kategori paling berharga.
- Konfigurasi dan kredensial, konfigurasi server, API key, pengaturan DNS, setup payment gateway. Kehilangan ini memakan waktu berhari-hari untuk membangun ulang, bahkan jika datanya sendiri selamat.
- Penyimpanan dokumen, kontrak, perjanjian yang sudah ditandatangani, dokumen kepatuhan.
- Kode aplikasi, jika Anda menjalankan software custom, repository itu sendiri butuh salinan di luar single point of failure dari git host utama Anda.
Aset marketing, draf dokumen lama, dan file pribadi di shared drive prioritasnya lebih rendah. Jangan biarkan proses backup tersendat oleh gigabyte data yang tidak penting, sementara backup database justru diam-diam gagal karena timeout.
Aturan 3-2-1, diterapkan secara praktis
Aturan klasiknya: tiga salinan data, di dua jenis media berbeda, dengan satu salinan di luar lokasi (off-site). Untuk bisnis kecil-menengah yang berjalan di infrastruktur cloud, ini diterjemahkan menjadi sesuatu yang konkret, bukan abstrak.
- Salinan produksi, database atau file store yang aktif digunakan.
- Snapshot harian otomatis, disimpan di region cloud yang sama tapi di service atau bucket terpisah, terenkripsi.
- Salinan off-site atau off-provider, provider atau region cloud yang benar-benar berbeda, diperbarui minimal seminggu sekali.
Alasan di balik diversifikasi provider bukan soal paranoid, melainkan karena outage provider cloud memang terjadi, dan ransomware yang berhasil membobol kredensial admin Anda bisa menjangkau apa pun yang bisa dijangkau kredensial itu, termasuk "backup" Anda kalau itu berada di akun yang sama dengan akses yang sama.
Otomatiskan jadwalnya, lalu lupakan keberadaannya
Backup manual gagal karena bergantung pada ada tidaknya orang yang ingat. Solusinya membosankan: sebuah scheduled job yang berjalan tanpa campur tangan manusia, dengan alert yang menyala saat proses TIDAK berjalan dengan sukses, bukan sekadar entri log yang tak pernah dibaca siapa pun.
Kadensi yang wajar untuk kebanyakan UKM:
| Jenis data | Frekuensi | Retensi |
|---|---|---|
| Database transaksional | Setiap 6 jam | Rolling 30 hari |
| Snapshot sistem penuh | Harian | Rolling 14 hari |
| Salinan off-site | Harian | Rolling 90 hari |
| Vault konfigurasi/kredensial | Setiap ada perubahan | Selamanya, dengan versioning |
Retensi sama pentingnya dengan frekuensi. Ransomware sering kali bersembunyi diam-diam selama berhari-hari atau berminggu-minggu sebelum aktif, ikut mengenkripsi backup harian Anda tepat bersamaan dengan sistem produksi jika jendela retensi Anda terlalu pendek untuk menjangkau ke belakang sebelum infeksi terjadi.
Uji coba restore: satu-satunya tes yang benar-benar berarti
Ini langkah yang hampir selalu dilewatkan semua orang, padahal ini inti dari seluruh perencanaan backup dan disaster recovery. Backup yang belum pernah di-restore statusnya belum terverifikasi. Anda tidak tahu apakah file backup-nya korup, apakah script restore-nya merujuk ke server yang sudah tidak ada, atau apakah prosesnya memakan waktu enam jam padahal bisnis hanya sanggup menoleransi downtime satu jam.
Jalankan uji coba restore setiap kuartal:
- Pilih satu backup secara acak, bukan yang paling baru, ambil yang lebih lama dari dalam jendela retensi.
- Restore ke lingkungan terisolasi, bukan ke produksi.
- Verifikasi datanya lengkap dan aplikasinya benar-benar bisa berjalan dengan data tersebut.
- Ukur waktu keseluruhan prosesnya, dari awal sampai akhir.
- Catat apa yang bermasalah, karena biasanya selalu ada sesuatu yang bermasalah.
Saya pernah menjalankan uji coba ini untuk klien perusahaan multifinance dan menemukan, pada percobaan pertama, bahwa script restore-nya memiliki hardcoded path ke server yang sudah dinonaktifkan delapan bulan sebelumnya. Tidak ada yang tahu sampai kami mencobanya. Itulah nilai dari uji coba ini: ia mengubah asumsi menjadi fakta, sebelum fakta itu benar-benar dibutuhkan.
Ransomware sebagai skenario pemicu di era sekarang
Kebakaran, banjir, dan kerusakan hardware dulu menjadi skenario baku dalam disaster recovery. Sekarang pemicu paling umum adalah ransomware, dan ini mengubah satu syarat penting: backup Anda harus immutable atau air-gapped dari kredensial yang berpotensi dibobol. Jika penyerang dengan akses admin bisa menghapus atau mengenkripsi backup Anda juga, maka yang Anda punya bukan backup, melainkan target kedua.
Langkah praktisnya:
- Gunakan penyimpanan backup dengan object-lock atau retensi write-once, sehingga bahkan akun admin pun tidak bisa menghapus backup dalam jendela retensi.
- Simpan minimal satu set kredensial untuk sistem backup yang terpisah dari akses admin umum.
- Asumsikan penyerang sudah punya akses selama berminggu-minggu sebelum ketahuan; simpan histori yang cukup panjang untuk bisa restore dari sebelum kompromi terjadi, bukan sekadar sebelum catatan tebusan muncul.
Rencana darurat satu halaman
Saat sistem down, tidak ada yang mau membaca dokumen 40 halaman. Tulis satu halaman saja: siapa yang menyatakan status insiden, siapa yang punya akses ke proses restore backup, apa rencana komunikasi untuk pelanggan dan staf, dan berapa downtime yang bisa ditoleransi untuk tiap sistem. Cetak. Simpan satu salinan di tempat yang tidak bergantung pada sistem yang baru saja down.
Jika Anda sedang membangun atau membenahi ketahanan semacam ini sebagai bagian dari dorongan transformasi digital yang lebih luas, disaster recovery seharusnya menjadi item yang masuk hitungan sejak hari pertama, bukan tambalan yang baru dipasang setelah insiden pertama membuat kaget.
Kesimpulan praktis
Backup dan disaster recovery bukan soal membeli teknologi, melainkan disiplin menggabungkan otomasi dengan verifikasi. Terapkan struktur 3-2-1, otomatiskan jadwalnya agar tidak bergantung pada ingatan seseorang, dan jadwalkan uji coba restore setiap kuartal, dengan keseriusan yang sama seperti fire drill. Bisnis yang selamat dari hari yang buruk bukanlah yang punya tool backup paling canggih, melainkan yang sudah tahu, karena sudah pernah mengujinya, bahwa proses restore-nya benar-benar berfungsi. Jika Anda ingin sudut pandang kedua untuk mengevaluasi setup Anda saat ini sebelum diuji oleh insiden sungguhan, itu percakapan yang layak dilakukan lebih awal daripada terlambat, lewat partner.