Apa itu RTO dan RPO: RTO adalah berapa lama layanan boleh mati sebelum pulih; RPO adalah berapa banyak data yang boleh hilang. Keduanya keputusan bisnis, bukan teknis — dan keduanya menentukan berapa biaya yang harus dikeluarkan.
Dua singkatan ini sering muncul di dokumen penawaran lalu dilewati karena terlihat seperti jargon. Padahal keduanya justru pertanyaan paling sederhana yang bisa diajukan tentang cadangan: seberapa cepat harus pulih, dan seberapa banyak boleh hilang.
Yang membuatnya penting: tanpa dua angka itu, tidak ada cara menilai apakah strategi cadangan Anda memadai atau berlebihan.
Recovery Time Objective: berapa lama boleh mati
Recovery time objective adalah batas waktu dari saat gangguan dimulai sampai layanan berjalan kembali. Kalau RTO Anda empat jam, artinya sistem harus pulih dalam empat jam — dan seluruh rancangan pemulihan harus mendukung itu.
Angka ini menentukan arsitektur, bukan sebaliknya. RTO beberapa menit menuntut sistem siaga yang sudah menyala dan siap mengambil alih. RTO beberapa jam bisa dipenuhi dengan pemulihan dari cadangan ke server baru. RTO satu hari bisa dipenuhi dengan cara yang jauh lebih sederhana dan murah.
Cara mengujinya cuma satu: lakukan pemulihan sungguhan dan catat waktunya. RTO yang ditulis di dokumen tanpa pernah diuji hanyalah harapan, dan angka nyatanya hampir selalu lebih besar dari perkiraan.
Recovery Point Objective: berapa banyak boleh hilang
Recovery point objective adalah jarak waktu antara cadangan terakhir yang bisa dipakai dan saat gangguan terjadi. Cadangan harian pada pukul dua pagi berarti RPO Anda hingga 24 jam — kalau masalahnya terjadi pukul satu siang, sebelas jam transaksi hilang.
Untuk sistem yang datanya bertambah terus — pesanan, transaksi keuangan, rekam medis — RPO 24 jam biasanya tidak dapat diterima. Yang dibutuhkan cadangan log transaksi setiap belasan menit, sehingga pemulihan bisa diarahkan ke titik waktu mana pun.
Untuk situs yang isinya jarang berubah, RPO harian bahkan mingguan mungkin sudah cukup. Menerapkan cadangan tiap lima belas menit untuk situs profil perusahaan hanya menambah biaya penyimpanan tanpa mengurangi risiko yang berarti.
Cara menentukan RPO perusahaan Anda
Pertanyaan menentukan rpo perusahaan sebaiknya tidak diajukan ke tim IT, melainkan ke pemilik proses bisnisnya. Yang tahu berapa nilai data satu jam adalah bagian keuangan dan operasional.
Cara mengajukannya secara konkret: kalau semua data sejak jam sembilan pagi hari ini hilang, apa yang harus dikerjakan ulang, dan berapa lama? Untuk sebagian bisnis jawabannya "masukkan ulang dari berkas fisik, sekitar dua jam". Untuk yang lain, "tidak bisa dipulihkan sama sekali".
Jawaban itu langsung memberi angka yang bisa dipakai. Dan biasanya ia berbeda per sistem — basis data pesanan menuntut RPO ketat, sementara sistem arsip dokumen internal tidak.
Hitung kerugian downtime supaya keputusannya berdasar
Untuk menilai apakah RTO ketat sepadan biayanya, hitung kerugian downtime lebih dulu. Rumusnya kasar tapi cukup: pendapatan per jam pada jam sibuk, ditambah biaya tenaga yang berhenti bekerja, ditambah perkiraan pesanan yang batal dan tidak kembali.
Angka itu lalu dibandingkan dengan biaya menurunkan RTO. Sistem siaga aktif berarti membayar hampir dua kali kapasitas; pemulihan dari cadangan jauh lebih murah tetapi lebih lambat. Perbandingannya jadi keputusan bisnis biasa.
Yang perlu dihindari: menetapkan RTO sangat ketat di dokumen tanpa menyediakan anggarannya. Itu menciptakan janji yang tidak bisa dipenuhi, dan yang paling merugikan bukan biayanya melainkan kepercayaan saat janji itu gagal.
Apa itu disaster recovery plan dan isinya
Pertanyaan apa itu disaster recovery plan sering dijawab dengan dokumen tebal yang tidak pernah dibuka. Yang berguna justru dokumen pendek yang bisa diikuti orang yang panik pada pukul tiga pagi.
Isi minimalnya seperti ini:
- Daftar sistem beserta RTO dan RPO masing-masing, diurut berdasarkan prioritas pemulihan.
- Lokasi cadangan, cara mengaksesnya, dan siapa yang punya kredensialnya.
- Langkah pemulihan per sistem, cukup rinci untuk diikuti orang yang bukan pembuatnya.
- Ketergantungan antar-sistem — apa yang harus hidup lebih dulu sebelum yang lain berguna.
- Nama dan kontak yang harus dihubungi, termasuk vendor dan penyedia.
- Kapan terakhir prosedur ini diuji, beserta waktu yang tercatat.
Kenapa keduanya sering tidak pernah ditetapkan
Dalam praktiknya, banyak perusahaan menjalankan cadangan tanpa pernah menetapkan kedua angka ini. Cadangan berjalan setiap malam karena begitulah kebiasaannya, dan tidak ada yang pernah bertanya apakah itu cukup.
Akibatnya baru terasa saat insiden: ternyata cadangan terakhir dari dua belas jam lalu, dan ternyata pemulihannya butuh delapan jam. Kedua angka itu bisa saja dapat diterima — masalahnya tidak ada yang pernah menyetujuinya.
Menetapkannya tidak menuntut proyek besar. Satu pertemuan satu jam dengan pemilik proses bisnis, satu tabel berisi sistem beserta dua angka, dan satu uji pemulihan untuk memverifikasi bahwa angka itu realistis. Setelah itu keputusan soal cadangan berhenti menjadi perdebatan teknis.
Contoh penerapan pada tiga jenis sistem
Angka menjadi lebih mudah dipahami lewat contoh. Ketiga pola berikut mencakup sebagian besar kebutuhan perusahaan menengah.
Sistem transaksi yang menerima pesanan sepanjang hari biasanya menuntut RPO belasan menit dan RTO beberapa jam. Itu berarti cadangan log transaksi berkala ditambah prosedur pemulihan yang sudah diuji — bukan sistem siaga, karena beberapa jam masih dapat diterima.
Situs profil perusahaan atau portal informasi umumnya cukup dengan RPO harian dan RTO satu hari kerja. Cadangan harian ke penyimpanan luar sudah memadai, dan menambah apa pun di atasnya hanya menambah biaya.
Sistem internal seperti berkas bersama dan aplikasi administrasi berada di antaranya: RPO harian, RTO beberapa jam, karena pekerjaan berhenti bila ia mati tetapi tidak ada pendapatan yang langsung hilang. Menuliskan ketiganya dalam satu tabel membuat pembicaraan anggaran jauh lebih mudah.
Yang perlu diingat: kedua angka ini bukan janji sekali tulis. Sistem berubah, data bertambah, dan waktu pemulihan yang tahun lalu dua jam bisa menjadi lima jam tanpa ada yang menyadarinya. Meninjaunya setahun sekali beserta satu uji pemulihan menjaga angkanya tetap jujur.