Status backup semalam sukses. Semua job berwarna hijau. Bagi tim IT, itu tentu kabar baik—tetapi belum cukup untuk memastikan data bisa dipulihkan saat terjadi serangan.
Bayangkan akun administrator diretas dan penyerang berhasil masuk ke sistem backup. Salinan data yang selama ini diandalkan bisa menjadi target berikutnya: restore point dihapus, repository dirusak, atau kebijakan retensi diubah. Ketika server produksi ikut terkena ransomware, perusahaan mungkin baru menyadari bahwa jalur pemulihannya sudah terganggu.
Di sinilah immutable backup perlu diperhatikan. Bukan untuk menggantikan software backup atau sistem keamanan yang sudah ada, melainkan untuk membantu menjaga salinan data agar tidak bisa diubah atau dihapus sebelum masa perlindungannya berakhir.
Ransomware tidak selalu berhenti di server produksi
Di sejumlah lingkungan IT, server produksi, server backup, dan repository masih berbagi jaringan atau akun dengan hak akses yang luas. Pengelolaannya memang lebih praktis. Namun, jika satu akun penting disalahgunakan, dampaknya bisa menjalar ke sistem pencadangan.
Memindahkan backup ke lokasi lain adalah langkah yang baik. Meski begitu, offsite saja belum menyelesaikan persoalan apabila kredensial yang sama masih bisa menghapus seluruh salinan. Karena itu, tim IT perlu memikirkan pemisahan akses, lokasi penyimpanan, kebijakan retensi, dan perlindungan terhadap penghapusan.
Apa itu immutable backup?
Secara sederhana, immutable backup adalah salinan cadangan yang dilindungi dari perubahan atau penghapusan selama periode tertentu. Prinsipnya berkaitan dengan Write Once, Read Many (WORM): data disimpan, dapat dibaca kembali, tetapi versi yang sudah dikunci tidak boleh ditimpa atau dihapus selama masa perlindungan.
Contohnya, perusahaan menetapkan retensi 30 hari untuk sebuah backup. Selama periode itu, upaya menghapus versi objek yang dilindungi seharusnya ditolak oleh mekanisme storage sesuai konfigurasi yang berlaku. Setelah masa retensi berakhir, objek dapat mengikuti kebijakan penyimpanan berikutnya. Angka 30 hari ini hanya contoh, bukan rekomendasi untuk semua perusahaan.
Bagaimana S3 Object Lock bekerja?
Pada penyimpanan objek yang mendukung mekanisme S3 Object Lock, perlindungan retensi diterapkan pada versi objek. Dengan versioning, versi lama yang terkunci tetap dapat dipertahankan meskipun muncul versi baru atau delete marker. Ini berbeda dengan sekadar menyembunyikan file dari daftar tampilan.
Di ekosistem Amazon S3 dikenal governance mode dan compliance mode. Governance memiliki mekanisme izin khusus untuk melewati perlindungan tertentu; compliance menerapkan pembatasan lebih ketat selama masa retensi. Namun, tidak semua layanan yang kompatibel dengan S3 menyediakan mode dan perilaku yang identik. Untuk penggunaan AOS, kemampuan, mode, dan kompatibilitasnya harus diperiksa saat desain dan pengujian.
Satu hal yang sering luput: immutable tidak berarti backup pasti bersih. Bila data sudah terinfeksi sebelum dicadangkan, versi yang terkunci pun dapat menyimpan data bermasalah. Karena itu, perusahaan tetap memerlukan sejumlah restore point, pemantauan, dan proses verifikasi pemulihan.
Ilustrasi: alur backup dari sistem produksi menuju repository object storage offsite dengan retensi immutable.
Menentukan retensi: jangan hanya memilih angka yang paling panjang
Masa retensi yang terlalu singkat dapat membuat restore point yang dibutuhkan sudah kedaluwarsa ketika insiden baru diketahui. Sebaliknya, retensi terlalu panjang membuat kapasitas yang terkunci terus bertambah dan tidak bisa segera dibersihkan.
Mulailah dari pertanyaan praktis: berapa sering backup dijalankan, berapa lama insiden biasanya baru terdeteksi, berapa lama data wajib disimpan, dan restore point mana yang dibutuhkan untuk pemulihan? Perhatikan juga RPO, yaitu batas kehilangan data yang dapat ditoleransi berdasarkan waktu, serta RTO, yaitu target waktu pemulihan layanan. Immutability membantu menjaga salinan; fitur ini sendiri tidak menjamin target RPO atau RTO tercapai.
Gunakan perlindungan berlapis, bukan satu repository saja
Prinsip 3-2-1-1-0 bisa menjadi titik awal: tiga salinan data, dua media atau pendekatan penyimpanan, satu salinan offsite, satu salinan offline atau immutable, serta nol error yang belum ditangani setelah pemeriksaan backup. Ini bukan rumus yang otomatis membuat sistem aman, tetapi membantu tim mengurangi ketergantungan pada satu lokasi.
Dalam praktiknya, perusahaan dapat menyimpan backup lokal untuk pemulihan cepat dan menempatkan salinan lain pada object storage offsite yang mendukung immutability. Keduanya sebaiknya menggunakan kontrol akses terpisah, izin minimum, dan prosedur recovery yang sudah diuji.
Integrasi dengan Veeam dan software backup lainnya
Sebagian skenario Veeam Backup & Replication mendukung object storage S3-compatible sebagai target penyimpanan. Pengaturan umumnya meliputi bucket, endpoint, kredensial, kebijakan retensi, dan pilihan repository yang sesuai dengan versi perangkat lunak.
Namun, koneksi S3 yang berhasil bukan bukti bahwa immutable backup sudah aktif. Tim IT tetap perlu memastikan dukungan Object Lock atau metode immutability yang dibutuhkan oleh software backup, termasuk perilaku retensi dan izin aksesnya.
Arupa Object Storage (AOS) menawarkan object storage berbasis cloud dengan infrastruktur di Indonesia dan dukungan S3-compatible API. AOS juga diposisikan untuk kebutuhan backup yang memerlukan immutability. Sebelum implementasi, lakukan pemeriksaan kesesuaian fitur, versi aplikasi, serta uji restore dan uji penghapusan berdasarkan rancangan yang disepakati.
Empat pengujian sebelum mengandalkan backup saat insiden
1. Penghapusan
Coba hapus objek yang masih dalam masa perlindungan menggunakan akun operasional biasa. Pastikan storage menolak tindakan yang seharusnya tidak diizinkan.
2. Pemulihan
Restore file, VM, atau database ke lingkungan terisolasi. Periksa apakah data utuh dan bisa digunakan, bukan hanya apakah job berstatus sukses.
3. Skenario gangguan
Simulasikan kondisi saat repository utama atau akun backup tidak tersedia. Catat tahapan recovery dan waktu yang benar-benar dibutuhkan.
4. Review retensi dan akses
Tinjau siapa yang bisa mengubah konfigurasi, lama retensi, kapasitas yang dibutuhkan, dan cara memisahkan kredensial antarlingkungan.
Immutable backup bukan pengganti antivirus, deteksi ransomware, atau disaster recovery plan. Fungsinya adalah menambah lapisan perlindungan terhadap perubahan dan penghapusan salinan yang sudah dikunci.
Kapan Arupa Object Storage relevan untuk perusahaan?
AOS dapat dipertimbangkan saat tim IT perlu menempatkan salinan backup di luar infrastruktur produksi, mengurangi ketergantungan pada perangkat penyimpanan lokal, atau merancang retensi untuk backup berbasis object storage. Dukungan S3 API memberi jalur integrasi untuk aplikasi yang kompatibel, dengan pengujian tetap diperlukan sebelum dipakai di lingkungan produksi.
Memilih repository backup bukan semata persoalan kapasitas atau biaya per gigabyte. Yang lebih menentukan adalah apakah data cadangan tetap bisa diakses saat dibutuhkan, apakah hak aksesnya dibatasi dengan benar, dan apakah proses restore berjalan sesuai target bisnis.
Pertanyaan yang sering ditanyakan
Apakah immutable backup benar-benar tidak dapat dihapus?
Selama masa retensi, perlindungannya bergantung pada mekanisme, mode, dan izin yang digunakan. Karena itu, penting untuk membuktikannya lewat pengujian, bukan hanya melihat bahwa opsi immutability sudah dicentang.
Apakah object storage menggantikan software backup?
Tidak. Object storage menyimpan data, sementara software backup mengelola proses pencadangan, konsistensi data aplikasi, katalog, kebijakan retensi, serta restore.
Apakah backup offsite otomatis sudah immutable?
Belum tentu. Offsite menjelaskan pemisahan lokasi, sedangkan immutability adalah perlindungan terhadap perubahan atau penghapusan selama periode retensi tertentu.
Berapa lama retensi immutable yang tepat?
Tidak ada satu angka yang cocok untuk semua organisasi. Tentukan berdasarkan kebutuhan recovery, perkiraan waktu deteksi insiden, kebijakan perusahaan, kewajiban retensi, dan kapasitas yang tersedia.
Kesimpulan: jangan hanya memastikan backup berhasil
Backup yang baik harus bisa dipakai saat perusahaan benar-benar membutuhkannya. Status sukses adalah awalnya; perlindungan terhadap penghapusan, pemisahan repository, dan pengujian restore yang konsisten menentukan kesiapan tim ketika terjadi insiden.
Jika Anda sedang mengevaluasi repository offsite atau immutable backup, pelajari Arupa Object Storage dan diskusikan kebutuhan retensi, integrasi, serta skenario pemulihan dengan tim Arupa.