Saat insiden kegagalan data terjadi seperti rilis aplikasi yang menulis record corrupt ke database utama selama empat puluh menit replikasi biasa akan tetap meneruskan data rusak tersebut secara real-time. Tanpa strategi cloud backup yang terisolasi dari lingkungan produksi, data yang rusak akan permanen menggantikan data bersih Anda.
Tidak ada komponen yang gagal. Dari sudut pandang storage layer, write yang corrupt tadi bukan sebuah error. Itu adalah data. Yang akan menolong di situasi ini adalah salinan cloud backup yang diambil sebelum rilis dan disimpan terpisah dari produksi.
Ini celah paling umum dalam desain storage perusahaan, dan jarang berakar pada anggaran. Penyebabnya adalah memperlakukan empat kapabilitas berbeda sebagai satu hal yang sama.
Empat Lapis Storage, Empat Tugas Berbeda
Block storage adalah lapis performa.
Volume persisten dengan performa random read/write hingga 1.000.000 IOPS, throughput sequential hingga 4.000 MB/s, kapasitas 32 TiB per disk, dan reliabilitas data hingga 99,99 persen. Cocok untuk database bertransaksi tinggi, ERP, dan web server berskala besar. Satu catatan penting: replikasinya berjalan di dalam zone yang sama, sehingga menjawab kegagalan perangkat keras. Kegagalan logis berada di luar cakupannya.
Object storage adalah lapis kapasitas dan durabilitas.
Durabilitas data hingga 99,9999999999 persen dengan ketersediaan layanan 99,995 persen, kapasitas praktis tanpa batas, dan akses melalui REST API berbasis HTTP/HTTPS. Lifecycle policy memindahkan data antar storage class secara otomatis, dan fitur inilah yang menentukan berapa biaya sebuah arsip selama satu dekade, bukan sekadar satu kuartal. Cocok untuk arsip surveillance, dataset besar, dan target backup.
Cloud backup adalah lapis kemampuan pulih.
Replikasi berkelanjutan mendekati real time dengan pemulihan dari titik mana pun dalam 24 jam terakhir, enkripsi end-to-end, mencakup server fisik maupun virtual. Salinan direplikasi ke beberapa data center dan disimpan terisolasi, dan properti terakhir inilah yang menentukan ketika lingkungan produksi sendiri sudah terkompromi.
Cloud disaster recovery adalah lapis kontinuitas.
Replikasi infrastruktur dengan orkestrasi failover, RPO 15 menit dan RTO 1 jam, antara fasilitas kembar di Jakarta dan Cibitung. Infrastrukturnya berada di fasilitas bersertifikasi Tier III dan Tier IV di Indonesia dengan sertifikasi BSI ISO/IEC 27001, ISO 9001, dan PCI DSS.
Perbedaan antara replikasi dan backup perlu dinyatakan gamblang, karena percakapan pengadaan rutin mencampuradukkan keduanya. Replikasi menjawab apakah ada salinan di tempat lain saat ini. Cloud backup menjawab apakah versi yang diketahui baik masih bisa diambil setelah kondisi saat ini rusak.
Menetapkan RPO dan RTO
Target pemulihan yang ditetapkan berdasarkan intuisi cenderung mengumpul di angka nol. Semua sistem terasa kritikal ketika ditanya secara abstrak, dan desain yang dihasilkan biasanya terlalu mahal atau diam-diam ditinggalkan.
Metode yang lebih berguna bertolak dari kerugian. Untuk tiap sistem signifikan, hitung biaya satu jam ketidaktersediaan dan biaya satu jam transaksi yang hilang. Keduanya biasanya angka yang berbeda. Hasilnya adalah RTO dan RPO yang bisa dipertahankan dalam rapat anggaran, karena dinyatakan dalam satuan yang sama dengan biaya untuk mencapainya.
Latihan ini umumnya menghasilkan tiga tingkatan. Sekelompok kecil sistem layak mendapat failover terorkestrasi. Kelompok lebih besar cukup dilayani backup terjadwal dengan restore dalam hitungan jam. Sisanya hanya perlu arsip pada storage class yang sesuai.
Tiga Prinsip Cloud Backup Yang Teruji
Dari pengalaman melayani lebih dari 150 klien enterprise di sektor jasa keuangan, logistik, manufaktur, dan ritel, tiga hal ini paling konsisten membedakan desain yang bertahan saat insiden nyata.
Pisahkan redundansi dari kemampuan pulih. Replikasi dalam satu zone melindungi dari kegagalan komponen. Salinan backup terisolasi melindungi dari penghapusan, korupsi data, dan ransomware. Keduanya dibutuhkan.
Sesuaikan tier storage dengan pola akses. Beban kerja transaksional ke block storage, arsip dan target backup ke object storage. Lifecycle policy dikonfigurasi sejak perancangan, bukan setelah tagihan besar pertama.
Uji proses restore, bukan proses backup. Job backup yang sukses hanya memastikan data berhasil ditulis. Hanya restore yang memastikan data dapat dibaca kembali ke dalam sistem yang berfungsi, dalam rentang waktu yang diasumsikan bisnis.
Diskusikan Dengan Spesialis Indonesian Cloud
Ambil tiga sistem yang paling tidak mampu ditanggung bisnis Anda jika hilang. Tuliskan waktu pemulihan yang diasumsikan bisnis, lalu cari tanggal uji restore penuh terakhir yang berhasil beserta durasi aktualnya. Selisih kedua angka itu adalah paparan risiko Anda yang sebenarnya.
Tim engineering kami merancang dan mengoperasikan lingkungan block storage, object storage, cloud backup, dan disaster recovery pada infrastruktur yang berlokasi di Indonesia.