Status backup “sukses” belum menjawab apakah layanan dapat digunakan kembali setelah gangguan. File mungkin sudah tersalin, tetapi pemulihan masih membutuhkan data yang tepat, akses yang tersedia, dan prosedur yang benar-benar bekerja.
Saya melihat backup sebagai bagian dari kemampuan memulihkan sistem. Pertanyaan akhirnya sederhana: jika lingkungan utama tidak bisa dipakai, apa yang dapat kita pulihkan, seberapa banyak data yang hilang, dan berapa lama layanan berhenti?
Peta singkat
Bagian | Pertanyaan yang perlu dijawab |
Cakupan | Data dan komponen apa yang diperlukan agar layanan kembali berfungsi? |
RPO dan RTO | Berapa banyak perubahan data yang boleh hilang, dan berapa lama layanan boleh terhenti? |
Perlindungan | Apakah salinan tetap tersedia ketika lingkungan utama bermasalah? |
Uji pemulihan | Apakah data dapat dipakai kembali dan fungsi aplikasi berjalan? |
Prosedur | Siapa yang memulihkan, dengan akses apa, dan dalam urutan bagaimana? |
1. Tentukan hasil pemulihan sebelum memilih alat
Dua istilah membantu menyatakan kebutuhan: Recovery Point Objective (RPO) menentukan titik waktu data yang harus dapat dipulihkan, berkaitan dengan kehilangan data yang dapat diterima. Recovery Time Objective (RTO) menentukan batas waktu ketidaktersediaan sumber daya sistem. Keduanya dibahas dalam NIST SP 800-34 Rev. 1, bagian 3.2.
Misalnya, sebuah aplikasi menetapkan RPO satu jam dan RTO empat jam. Jika gangguan terjadi pukul 10.00, targetnya adalah mengembalikan data setidaknya sampai pukul 09.00 dan memulihkan layanan dalam empat jam sejak gangguan. Salinan terakhir yang hanya mencakup data sampai pukul 02.00 tidak memenuhi target kehilangan data itu.
RPO dan RTO adalah kebutuhan yang harus dibuktikan. Jadwal backup setiap jam saja belum membuktikan RPO terpenuhi apabila prosesnya gagal atau salinannya tidak dapat digunakan.
2. Pulihkan layanan, bukan hanya file
Untuk latihan, bayangkan aplikasi pengarsipan dokumen dengan database dan direktori unggahan. Mengembalikan database saja belum membuktikan bahwa dokumen yang dirujuknya bisa dibuka.
Kebutuhan pemulihannya mencakup database, berkas dokumen, versi aplikasi yang sesuai, konfigurasi, serta akses ke layanan pendukung. Komponen-komponen ini tidak harus disalin dengan alat yang sama; yang penting, semuanya ikut diuji saat restore.
Panduan NIST NCCoE untuk perlindungan data menyarankan identifikasi berkas penting, ketergantungan sistem, dan urutan pemulihan. Panduan itu juga memasukkan kredensial serta kunci enkripsi sebagai kebutuhan yang harus tetap tersedia saat pemulihan.
Cara memeriksanya sederhana: pilih satu dokumen uji, catat identitas serta isinya, lalu pastikan dokumen yang sama bisa dibuka setelah restore. Hasilnya lebih konkret daripada melihat direktori sudah terisi.
3. Pisahkan salinan dari sumber gangguan
Salinan perlu dilindungi dari kejadian yang merusak lingkungan utama. Dalam konteks ransomware, advisory bersama CISA, FBI, dan HHS menganjurkan backup offline yang terenkripsi serta pengujian berkala.
Artinya, lokasi penyimpanan dan kemampuan mengaksesnya perlu dinilai bersama. Skenario yang layak diuji: server utama tidak tersedia, akun operasionalnya tidak bisa dipakai, dan salinan harus diambil lewat akses pemulihan yang sudah disiapkan.
Enkripsi membutuhkan pengelolaan kunci. Salinan yang tersimpan aman tetapi kuncinya ikut hilang tidak membantu proses restore. NCCoE membahas ketergantungan ini dalam bagian pengelolaan kunci; rencana pemulihan perlu mencakup akses yang sah ke kunci tanpa membukanya kepada pihak yang tidak berwenang.
4. Uji pemulihan sampai fungsi aplikasi
NIST SP 800-34 Rev. 1 membedakan validasi data dan pengujian fungsi sistem dalam tahap pemulihan. Berhasil membaca media backup belum sama dengan membuktikan layanan siap digunakan kembali.
Untuk aplikasi pengarsipan tadi, urutan latihan yang saya sarankan adalah:
- Siapkan lingkungan uji terpisah dengan akses terbatas. Pastikan konfigurasi pengujian tidak mengirim email, menjalankan integrasi produksi, atau menulis ke data asli.
- Ambil salinan melalui jalur yang akan digunakan saat insiden, lalu catat waktu pengambilannya.
- Jalankan restore dan catat kesalahan maupun langkah manual yang dibutuhkan.
- Jalankan versi aplikasi yang sesuai. Uji login, pencarian dokumen, dan pembukaan dokumen contoh.
- Periksa batas waktu data yang berhasil dipulihkan. Bandingkan dengan target RPO.
- Hitung waktu dari awal simulasi gangguan sampai fungsi yang disepakati tersedia. Bandingkan dengan RTO.
- Catat hasil, perbaiki hambatan, dan hapus data uji sesuai aturan penanganan datanya.
Misalnya, dalam latihan diperoleh waktu pengambilan salinan 50 menit, restore 70 menit, dan pemeriksaan aplikasi 40 menit. Total tiga tahap itu adalah 160 menit. Angka ini masih perlu ditambah waktu deteksi, pengambilan keputusan, serta persiapan lingkungan jika belum termasuk pengukuran.
Contoh tersebut menunjukkan mengapa saya memilih mengukur satu alur lengkap. Durasi restore yang singkat tidak otomatis berarti target pemulihan layanan tercapai.
5. Tulis prosedur yang dapat dijalankan ulang
Hasil latihan sebaiknya menjadi prosedur operasional: siapa yang berwenang memulai pemulihan, lokasi salinan, cara mendapatkan akses, urutan langkah, pemeriksaan hasil, dan pihak yang menyatakan layanan siap dipakai.
Untuk aplikasi pengarsipan, tiga skenario latihan sudah cukup sebagai awal: pemulihan satu dokumen, pemulihan seluruh aplikasi, dan pemulihan ketika akses utama tidak tersedia. Setiap skenario mempunyai kriteria lulus sendiri.
Catat juga tanggal uji terakhir, salinan yang digunakan, titik waktu data yang berhasil dikembalikan, durasi total, serta masalah yang belum selesai. Setelah perubahan penting pada penyimpanan, akses, atau aplikasi, prosedurnya perlu diperiksa kembali. Pemeliharaan rencana dan latihan merupakan bagian dari proses contingency planning dalam NIST SP 800-34 Rev. 1.
Penutup
Mulailah dari satu layanan: tentukan kebutuhan pemulihannya, petakan komponen yang diperlukan, lalu lakukan restore di lingkungan terpisah. Gunakan hasilnya untuk memperbaiki prosedur dan mengukur apakah target benar-benar tercapai.
Jumlah file backup tidak membuktikan apa-apa. Yang membuktikan adalah layanan yang kembali berfungsi dengan data yang bisa diperiksa.