Perbedaan backup dan replikasi terletak pada waktu. Replikasi menyalin perubahan seketika, jadi kesalahan juga tersalin seketika. Backup menyimpan kondisi pada satu titik waktu di masa lalu, sehingga Anda bisa kembali ke sebelum kesalahan terjadi.
Percakapan ini biasanya terjadi setelah insiden. Ada replikasi, ada dua salinan data di dua tempat, dan seseorang menghapus tabel yang salah — lalu ditemukan bahwa kedua salinan sudah kehilangan tabel itu dalam waktu kurang dari satu detik.
Replikasi memang bekerja dengan benar. Ia hanya tidak dirancang untuk melindungi dari hal itu.
Replikasi bukan backup, dan itu bukan soal semantik
Pernyataan replikasi bukan backup sering dianggap perdebatan istilah. Ia bukan — perbedaannya menentukan apakah data Anda bisa dipulihkan atau tidak.
Replikasi menjaga dua salinan tetap identik. Setiap perubahan di sumber diteruskan ke salinan, biasanya dalam hitungan milidetik. Itu tujuannya: kalau satu server mati, yang lain punya data yang sama dan bisa langsung melayani.
Konsekuensinya, replikasi meneruskan segalanya tanpa menilai. Penghapusan, pembaruan yang salah, tabel yang terenkripsi ransomware — semuanya tersalin dengan setia. Yang dilindungi replikasi adalah kegagalan perangkat, bukan kesalahan manusia atau serangan.
Snapshot bukan backup, dengan alasan yang berbeda
Kalimat snapshot bukan backup butuh penjelasan lebih hati-hati, karena snapshot memang menyimpan kondisi masa lalu — jadi ia melindungi dari penghapusan.
Masalahnya letaknya. Snapshot volume cloud tersimpan di infrastruktur penyedia yang sama, terhubung ke akun yang sama. Kalau akun terkompromi, atau ada kesalahan yang menghapus sumber daya berikut snapshotnya, keduanya hilang bersamaan.
Snapshot juga sering punya masa simpan pendek dan bergantung pada volume aslinya untuk sebagian implementasi. Ia sangat berguna sebagai pemulihan cepat dari kesalahan kecil — dan tidak memadai sebagai satu-satunya perlindungan.
Aturan 3-2-1 backup dan versi modernnya
Pedoman yang masih bertahan adalah aturan 3 2 1 backup: tiga salinan data, di dua jenis media berbeda, dengan satu salinan di lokasi terpisah.
Untuk lingkungan sekarang, terjemahannya kira-kira: data aslinya, satu cadangan di lokasi untuk pemulihan cepat, dan satu di penyimpanan objek atau data center lain. Media berbeda bisa berarti disk lokal dan penyimpanan objek — tidak perlu tape.
Ada tambahan yang muncul karena ransomware: satu salinan harus tidak bisa diubah. Penyimpanan dengan proteksi immutable, atau kredensial yang hanya boleh menulis dan tidak boleh menghapus. Tanpa ini, server yang terkompromi bisa menghapus cadangannya sendiri sebelum Anda menyadarinya.
Backup gagal restore: kegagalan yang paling sering
Kasus backup gagal restore lebih sering terjadi daripada cadangan yang tidak pernah berjalan, dan lebih berbahaya karena laporannya terlihat baik selama berbulan-bulan.
Beberapa penyebab yang berulang:
- Basis data dicadangkan dengan menyalin berkasnya saat layanan berjalan, sehingga hasilnya tidak konsisten.
- Cadangan terenkripsi, dan kuncinya hanya tersimpan di server yang hilang.
- Yang dicadangkan hanya sebagian direktori; konfigurasi dan berkas unggahan pengguna tidak termasuk.
- Berkas cadangan rusak sebagian, dan tidak ada verifikasi integritas yang pernah dijalankan.
- Cadangan ada dan utuh, tetapi tidak ada yang tahu prosedur memulihkannya.
Uji pemulihan cadangan: satu-satunya bukti
Satu-satunya cara mengetahui cadangan Anda berfungsi adalah uji pemulihan cadangan yang sungguhan. Laporan sukses dari perangkat cadangan hanya menyatakan proses penulisan selesai, bukan bahwa datanya bisa dipakai.
Yang kami jalankan: pemulihan berkala ke lingkungan terpisah, lalu verifikasi yang bisa diperiksa — jumlah baris pada tabel utama, aplikasi bisa menyala dan login, dan berkas unggahan bisa dibuka. Waktunya dicatat, dan angka itu menjadi RTO nyata Anda.
Frekuensinya tidak perlu tinggi. Sekali per kuartal untuk pemulihan penuh, dan pemulihan satu berkas acak setiap bulan, sudah cukup menangkap hampir semua masalah sebelum ia penting.
Kapan keduanya memang perlu bersamaan
Perlu ditegaskan supaya tidak salah tangkap: bukan berarti replikasi tidak berguna. Keduanya menyelesaikan masalah berbeda dan sistem yang serius biasanya memakai keduanya.
Replikasi memberi pemulihan dalam hitungan detik dari kegagalan perangkat, tanpa kehilangan data. Cadangan memberi kemampuan kembali ke titik waktu sebelum kesalahan atau serangan terjadi, dengan harga waktu pemulihan yang lebih lama.
Yang berbahaya hanya satu: mengira sudah punya keduanya padahal hanya punya satu. Kalau Anda hanya bisa menyebut satu mekanisme, ada satu kategori risiko yang sepenuhnya terbuka — dan biasanya kategori yang justru paling sering terjadi.
Menyusun strategi yang mencakup keduanya
Susunan yang kami pakai untuk lingkungan menengah menggabungkan keduanya tanpa biaya berlebihan, dan urutannya mengikuti risiko yang paling sering terjadi.
Lapisan pertama adalah cadangan harian ke penyimpanan di luar server, dengan retensi bertingkat dan setidaknya satu salinan yang tidak bisa dihapus dari server itu. Ini yang melindungi dari kesalahan manusia dan ransomware — dua penyebab yang paling sering.
Lapisan kedua, untuk basis data yang datanya bertambah terus, cadangan log transaksi berkala. Ini menurunkan jumlah data yang bisa hilang dari sehari menjadi belasan menit, dengan biaya penyimpanan yang kecil.
Lapisan ketiga, replikasi, ditambahkan hanya bila waktu pemulihan yang dituntut memang tidak bisa dicapai lewat pemulihan cadangan. Urutan ini penting: memasang replikasi lebih dulu lalu mengabaikan cadangan adalah pola yang berulang kali berakhir buruk.
Ada satu pertanyaan sederhana yang cukup untuk menguji strategi Anda sekarang: kalau seseorang menghapus data penting pukul sepuluh pagi dan baru diketahui pukul empat sore, apakah data itu bisa dikembalikan?
Kalau jawabannya bergantung pada replika, jawabannya tidak — replika sudah ikut kehilangan data itu sejak pukul sepuluh. Kalau jawabannya cadangan tadi malam, berarti seluruh pekerjaan hari itu hilang. Kalau jawabannya cadangan log transaksi, Anda bisa kembali ke pukul sembilan lima puluh sembilan.
Ketiga jawaban itu bisa saja dapat diterima, tergantung jenis datanya. Yang tidak dapat diterima adalah tidak tahu jawabannya sampai kejadiannya berlangsung.