Backup di Cloud Bukan Berarti Aman: Cara Menyiapkan Cadangan yang Benar-Benar Bisa Dipulihkan

Banyak tim merasa sudah memiliki backup hanya karena file mereka tersimpan di cloud. Padahal, sinkronisasi folder, snapshot server, dan backup yang bisa dipulihkan adalah tiga hal berbeda. Jika sebuah file terhapus lalu penghapusan itu ikut tersinkronisasi, cloud tidak banyak membantu. Jika akun admin dibajak, penyerang mungkin juga bisa menghapus seluruh cadangan.

Backup yang baik bukan sekadar membuat salinan. Tujuan utamanya adalah memastikan data dapat dikembalikan ke kondisi yang masuk akal, dalam waktu yang masih bisa diterima, dan tanpa bergantung pada satu akun atau satu sistem saja.

Cloud storage bukan selalu backup

Cloud storage dirancang agar file dapat diakses dari banyak perangkat. Fitur sinkronisasi membuat perubahan pada satu perangkat diteruskan ke perangkat lain. Ini praktis untuk kerja sehari-hari, tetapi bukan perlindungan lengkap terhadap kehilangan data.

Contohnya, seorang anggota tim tidak sengaja menghapus folder proyek. Jika sistem melakukan sinkronisasi otomatis, folder tersebut dapat ikut hilang dari perangkat lain. Beberapa layanan menyediakan tempat sampah atau version history, tetapi masa pemulihannya terbatas dan belum tentu mencakup semua jenis data.

Backup memiliki karakter berbeda. Sistem backup biasanya membuat salinan berdasarkan jadwal, menyimpan beberapa versi, dan menyediakan mekanisme pemulihan. Idealnya, salinan tersebut memiliki akses serta kebijakan retensi yang tidak mudah diubah oleh siapa pun yang memiliki akses ke sistem utama.

Mulai dari dua pertanyaan penting

Sebelum memilih layanan atau membeli kapasitas tambahan, tentukan dua ukuran berikut:

• RPO atau Recovery Point Objective: seberapa banyak data yang masih boleh hilang jika terjadi gangguan. RPO satu jam berarti backup perlu dilakukan setidaknya setiap satu jam untuk membatasi potensi kehilangan data.
• RTO atau Recovery Time Objective: berapa lama sistem boleh tidak tersedia sebelum mulai menimbulkan dampak serius. RTO empat jam membutuhkan rencana pemulihan yang jauh lebih siap dibanding target pemulihan dua hari.

Nilainya tidak harus sama untuk semua data. Foto dokumentasi mungkin cukup dicadangkan sekali sehari. Database transaksi, sebaliknya, mungkin membutuhkan backup lebih sering atau replikasi tambahan.

Perbedaan ini membantu menghindari dua kesalahan umum: membayar perlindungan terlalu mahal untuk data yang tidak kritis, atau menghemat terlalu banyak pada sistem yang sebenarnya menjadi pusat operasional.

Gunakan prinsip 3-2-1 sebagai titik awal

Prinsip 3-2-1 masih relevan karena mudah dipahami dan cukup kuat sebagai dasar:

1. Simpan setidaknya tiga salinan data.
2. Gunakan setidaknya dua jenis media atau lokasi penyimpanan.
3. Simpan setidaknya satu salinan di lokasi yang berbeda dari sistem utama.

Dalam praktik cloud, salinan pertama bisa berada di server produksi, salinan kedua di layanan backup utama, dan salinan ketiga di akun atau penyedia berbeda. “Lokasi berbeda” tidak selalu berarti negara berbeda. Yang penting, gangguan pada sistem utama, akun, kredensial, atau jaringan tidak langsung menghapus semua salinan.

Untuk perlindungan yang lebih kuat, sebagian salinan dapat dibuat immutable, yaitu tidak dapat diubah atau dihapus selama periode tertentu. Fitur ini berguna menghadapi ransomware yang mencoba mengenkripsi data sekaligus menghapus backup.

Perhatikan akun dan hak akses

Backup dapat gagal bukan karena proses pencadangannya rusak, melainkan karena semua sistem memakai kredensial yang sama. Jika satu akun admin dibobol, penyerang mungkin dapat mengakses server produksi sekaligus menghapus backup.

Pisahkan akses antara sistem produksi dan sistem backup. Gunakan akun khusus dengan hak minimum yang diperlukan. Jangan menjadikan satu akun sebagai administrator untuk seluruh layanan jika tidak benar-benar dibutuhkan.

Beberapa langkah praktis yang dapat dilakukan:

• Aktifkan autentikasi multifaktor untuk akun administrator.
• Gunakan akun backup khusus, bukan akun pribadi karyawan.
• Batasi siapa yang boleh menghapus atau mengubah kebijakan retensi.
• Simpan log aktivitas dan tinjau perubahan konfigurasi secara berkala.
• Gunakan kredensial yang berbeda antara server produksi dan penyimpanan backup.

Ini bukan sekadar urusan keamanan siber. Pemisahan akses juga mengurangi risiko kesalahan manusia, misalnya seseorang menghapus bucket atau volume karena mengira sudah tidak dipakai.

Uji pemulihan, bukan hanya status “berhasil”

Dashboard backup yang menampilkan status hijau belum membuktikan bahwa data benar-benar bisa dipulihkan. Proses pencadangan dapat selesai tanpa error, tetapi file hasil backup mungkin tidak lengkap, kredensial pemulihan sudah kedaluwarsa, atau konfigurasi aplikasi tidak ikut tersimpan.

Lakukan uji pemulihan secara berkala. Mulailah dari skenario sederhana, seperti mengembalikan satu file yang terhapus. Setelah itu, uji pemulihan database, server aplikasi, atau seluruh lingkungan kerja ke lokasi sementara.

Catat beberapa hal penting:

• Berapa lama proses pemulihan berlangsung?
• Apakah data yang kembali dapat dibuka dan digunakan?
• Apakah izin akses, nama domain, dan konfigurasi aplikasi ikut pulih?
• Siapa yang harus mengambil keputusan saat pemulihan dilakukan?
• Bagian mana yang masih membutuhkan langkah manual?

Jika belum pernah melakukan pemulihan, jangan menunggu sampai insiden terjadi. Backup yang tidak pernah diuji lebih tepat disebut harapan daripada rencana.

Jangan lupa biaya tersembunyi

Biaya cloud backup tidak hanya berasal dari kapasitas penyimpanan. Perhatikan juga biaya transfer data keluar, jumlah permintaan baca-tulis, snapshot, replikasi lintas wilayah, dan pemulihan dalam jumlah besar.

Untuk data yang jarang diakses, kelas penyimpanan arsip mungkin lebih murah. Namun, waktu pengambilan kembali bisa lebih lama dan ada aturan minimum masa penyimpanan. Jika data perlu dipulihkan dengan cepat, pilihan termurah belum tentu paling sesuai.

Buat perkiraan sederhana berdasarkan tiga kondisi: operasi normal, pemulihan sebagian, dan pemulihan total. Dengan begitu, tim tidak hanya mengetahui biaya bulanan, tetapi juga potensi biaya saat rencana pemulihan benar-benar digunakan.

Yang bisa dilakukan sekarang

1. Daftar semua data dan sistem yang dianggap penting.
2. Tentukan RPO dan RTO untuk setiap kelompok data.
3. Pastikan ada lebih dari satu salinan di lokasi atau akun yang terpisah.
4. Aktifkan autentikasi multifaktor dan batasi hak hapus.
5. Periksa masa retensi serta versi file yang tersedia.
6. Lakukan uji pemulihan kecil minggu ini.
7. Dokumentasikan langkah pemulihan dalam bahasa yang bisa diikuti orang lain.

Backup cloud yang baik memang membutuhkan biaya, disiplin, dan pengujian. Namun, pendekatan ini jauh lebih murah dibanding mencoba menebak data mana yang hilang setelah server rusak atau akun diambil alih. Yang perlu dicari bukan layanan dengan janji paling besar, melainkan sistem yang salinannya terpisah, aksesnya terkendali, dan proses pemulihannya sudah terbukti.

– Rio Yotto @rioyotto