Banyak tim merasa sudah aman setelah melihat file backup berhasil masuk ke bucket cloud atau server cadangan. Padahal, ukuran backup bukan hanya “data tersimpan”, melainkan “data bisa kembali dipakai saat dibutuhkan”. Perbedaan ini baru terasa ketika database rusak, akun admin diambil alih, atau seseorang tidak sengaja menghapus folder penting.
Backup yang tidak pernah diuji mirip seperti pintu darurat yang belum pernah dibuka. Bentuknya ada, tetapi belum tentu bisa digunakan ketika situasi memburuk.
Backup, versioning, dan replika bukan hal yang sama
Beberapa istilah cloud sering dipakai seolah-olah memiliki fungsi yang sama, padahal perlindungannya berbeda.
- Backup adalah salinan data yang disimpan agar data dapat dipulihkan pada titik waktu tertentu.
- Versioning menyimpan versi lama ketika sebuah objek ditimpa atau dihapus. Ini berguna untuk mengembalikan file ke versi sebelumnya.
- Replikasi menyalin data ke lokasi lain, misalnya region atau bucket berbeda, untuk membantu menghadapi gangguan infrastruktur.
- Immutability berarti data dibuat tidak mudah diubah atau dihapus selama periode tertentu.
Versioning dapat membantu mengembalikan file yang tertimpa, tetapi tidak otomatis melindungi seluruh bucket dari penghapusan. Dokumentasi Google Cloud, misalnya, menjelaskan bahwa Object Versioning tidak melindungi data jika seluruh bucket dihapus. AWS juga membedakan pemulihan versi lama dari perlindungan menggunakan Object Lock. ([docs.cloud.google.com](https://docs.cloud.google.com/storage/docs/object-versioning?utm_source=openai))
Risiko terbesar sering datang dari akses yang terlalu luas
Serangan ransomware bukan satu-satunya ancaman. Kesalahan perintah, kredensial yang bocor, akun admin yang diambil alih, dan aturan lifecycle yang keliru juga dapat menghapus data secara massal.
Masalahnya menjadi lebih serius ketika sistem backup memakai akun dan kredensial yang sama dengan sistem produksi. Jika penyerang mendapatkan akses tersebut, ia mungkin dapat menghapus data utama sekaligus salinannya.
Karena itu, backup sebaiknya diperlakukan sebagai zona terpisah. Gunakan akun atau role khusus, batasi izin tulis dan hapus, aktifkan autentikasi berlapis jika tersedia, serta hindari memberikan hak admin penuh kepada aplikasi yang hanya perlu mengunggah file.
Gunakan perlindungan berlapis, bukan satu fitur
Tidak ada satu tombol yang bisa menyelesaikan semua masalah backup. Pendekatan yang lebih masuk akal adalah menggabungkan beberapa lapisan perlindungan.
- Salinan utama: data yang dipakai aplikasi sehari-hari.
- Salinan pemulihan cepat: backup di storage yang mudah diakses untuk mengatasi kesalahan pengguna atau kerusakan aplikasi.
- Salinan terisolasi: data di akun, bucket, region, atau penyedia berbeda yang tidak dapat dihapus dengan kredensial produksi.
- Retensi dan immutability: aturan yang mencegah data dihapus sebelum masa perlindungan berakhir.
Pada layanan object storage, fitur seperti soft delete, retention policy, bucket lock, atau Object Lock dapat membantu menahan data dari penghapusan langsung. Namun, fitur semacam ini perlu dirancang hati-hati karena retensi yang terlalu lama dapat meningkatkan biaya, sementara retensi yang terlalu pendek mungkin tidak cukup untuk menghadapi insiden yang baru diketahui setelah beberapa hari.
Google Cloud mencatat bahwa Object Versioning dapat meningkatkan biaya penyimpanan dan biasanya perlu dipasangkan dengan lifecycle management. AWS menjelaskan bahwa Object Lock dapat mencegah objek dihapus atau ditimpa selama periode tertentu, tetapi konfigurasi tersebut memiliki konsekuensi yang tidak selalu mudah dibatalkan. ([docs.cloud.google.com](https://docs.cloud.google.com/storage/docs/control-data-lifecycles?hl=en&utm_source=openai))
Uji restore dengan skenario kecil terlebih dahulu
Uji restore tidak harus langsung berupa pemulihan seluruh server. Mulailah dari skenario kecil yang dapat diukur.
- Pilih satu file penting, satu folder, dan satu dump database.
- Pulihkan semuanya ke lingkungan terpisah, bukan langsung menimpa data produksi.
- Periksa apakah file dapat dibuka, checksum sesuai, dan izin aksesnya tidak berubah secara tidak sengaja.
- Untuk database, jalankan aplikasi uji dan pastikan tabel, indeks, relasi, serta data transaksi dapat dibaca.
- Catat waktu mulai, waktu selesai, langkah yang gagal, dan siapa yang bertanggung jawab.
Hasil uji sebaiknya menjawab dua pertanyaan praktis: berapa lama sistem bisa kembali berjalan? dan berapa banyak data yang mungkin hilang? Dalam istilah pemulihan, pertanyaan pertama berkaitan dengan Recovery Time Objective atau RTO, sedangkan pertanyaan kedua berkaitan dengan Recovery Point Objective atau RPO.
Jangan hanya menguji file—uji juga cara menemukannya
Restore dapat gagal bukan karena datanya hilang, tetapi karena tidak ada yang tahu backup mana yang benar. Nama file seperti backup-final-2-benar.sql mungkin terasa cukup saat dibuat, tetapi membingungkan beberapa bulan kemudian.
Gunakan penamaan yang konsisten, timestamp yang jelas, dan catatan singkat tentang isi setiap backup. Simpan juga informasi penting seperti versi aplikasi, versi database, konfigurasi jaringan, variabel lingkungan, serta lokasi secret yang diperlukan untuk menjalankan kembali layanan.
Jika backup terenkripsi, pastikan kunci pemulihannya tidak hanya disimpan di server yang ikut dibackup. Backup tanpa kunci adalah data yang secara teknis ada, tetapi secara praktis tidak dapat digunakan.
Checklist yang bisa dilakukan sekarang
- Pastikan backup memiliki jadwal dan retensi yang jelas.
- Gunakan kredensial khusus backup, bukan akun admin produksi.
- Simpan setidaknya satu salinan yang tidak mudah dihapus dari akun produksi.
- Aktifkan versioning atau soft delete sesuai kebutuhan, lalu hitung dampak biayanya.
- Dokumentasikan cara restore dalam langkah yang bisa diikuti orang lain.
- Lakukan uji restore kecil setiap bulan atau setiap kali arsitektur berubah besar.
- Uji skenario kehilangan kredensial, penghapusan bucket, dan kerusakan database.
Apa artinya bagi kita?
Backup yang baik bukan yang paling mahal atau memiliki fitur paling banyak. Backup yang baik adalah backup yang terpisah dari sistem utama, memiliki masa perlindungan yang masuk akal, dan sudah terbukti bisa dipulihkan.
Mulailah dari satu layanan yang paling penting bagi bisnis. Pulihkan salinan kecilnya, ukur waktunya, dokumentasikan masalahnya, lalu perbaiki. Setelah itu barulah perluas pengujian ke seluruh sistem. Dengan cara ini, backup berubah dari sekadar arsip pasif menjadi bagian nyata dari rencana pemulihan.
Sumber & bacaan lebih lanjut
- Google Cloud Documentation — Object Versioning
- Google Cloud Documentation — Options for controlling data lifecycles
- Amazon S3 Documentation — Restoring previous versions
- Amazon S3 Documentation — Locking objects with Object Lock
– Rio Yotto @rioyotto