Saat aplikasi kritis berhenti, pertanyaan tidak berhenti di “backup terakhir kapan?”. Bisnis perlu segera menyepakati dua batas yang menentukan arah pemulihan: berapa banyak data yang masih dapat diterima untuk hilang dan berapa lama layanan boleh tidak tersedia. Dua batas ini dikenal sebagai RPO dan RTO.
Tanpa keputusan yang dibuat sebelum insiden, recovery mudah berubah menjadi perdebatan antara pemilik aplikasi, tim IT, finance, dan direksi. Pada saat itu, setiap menit downtime dan setiap transaksi yang belum tersimpan bisa memiliki dampak yang berbeda. Karena itu, RPO dan RTO sebaiknya diperlakukan sebagai keputusan bisnis yang diterjemahkan ke desain teknologi, bukan sekadar istilah teknis dalam dokumen backup.
RPO dan RTO bukan istilah teknis yang bisa diputuskan IT sendiri
Recovery Point Objective (RPO) adalah batas maksimum kehilangan data yang dapat diterima, diukur dalam waktu. Jika sebuah sistem memiliki RPO empat jam, organisasi menerima bahwa dalam skenario recovery tertentu data hingga empat jam sebelum gangguan mungkin perlu dipulihkan dari salinan yang tersedia. Recovery Time Objective (RTO) adalah batas waktu pemulihan layanan: berapa lama layanan boleh tidak tersedia sebelum dampaknya melewati batas yang disetujui.
Microsoft menempatkan RPO dan RTO sebagai metrik inti dalam perencanaan business continuity dan disaster recovery. Namun angka tersebut tidak bisa disalin begitu saja dari organisasi lain. Sistem payroll, aplikasi transaksi, email, portal pelanggan, database operasional, dan file sharing dapat memiliki toleransi downtime serta kehilangan data yang sangat berbeda.
Mengapa keduanya sering baru diperdebatkan saat insiden
Asumsi yang paling umum adalah bahwa backup yang berhasil berarti kebutuhan bisnis sudah aman. Padahal backup yang dapat dibuat belum tentu dapat dipulihkan pada waktu yang dibutuhkan, dengan urutan yang benar, dan dengan data yang masih konsisten. Sebuah restore mungkin berhasil untuk satu server, tetapi aplikasi masih tidak dapat dipakai karena database, identitas, DNS, konektivitas, lisensi, atau integrasi pihak ketiga belum kembali.
Di sisi lain, pemilik bisnis mungkin menganggap semua aplikasi sama-sama kritis, sementara tim operasi memahami bahwa beberapa layanan bisa dipulihkan lebih bertahap. Finance perlu melihat biaya dari target yang lebih ketat, sedangkan direksi perlu memahami risiko jika target tersebut tidak tercapai. Workshop sebelum insiden adalah tempat yang lebih aman untuk menyelaraskan keputusan ini.
Mulai dari tier aplikasi, bukan dari produk backup
Langkah awal yang lebih praktis adalah membuat tier workload. Mulailah dengan daftar aplikasi, pemilik keputusan bisnis, pengguna utama, dampak jika layanan berhenti, dan data apa yang diproses. Setelah itu, dokumentasikan toleransi kehilangan data dan downtime yang benar-benar dapat diterima.
| Yang perlu diputuskan | Pertanyaan workshop |
|---|---|
| Owner | Siapa yang menerima risiko downtime dan kehilangan data? |
| Dampak | Apa yang berhenti: transaksi, layanan pelanggan, operasi, atau pelaporan? |
| RPO | Berapa lama data yang belum terlindungi masih dapat diterima? |
| RTO | Kapan layanan harus kembali tersedia? |
| Dependensi | Apakah database, identitas, DNS, jaringan, atau vendor lain harus pulih lebih dulu? |
| Bukti | Bagaimana hasil restore atau failover akan diuji dan disimpan? |
Pendekatan ini membantu organisasi menghindari satu angka universal. Tier aplikasi yang berbeda dapat memiliki frekuensi perlindungan, urutan recovery, dan bukti pengujian yang berbeda pula.
Cara menerjemahkan target ke desain recovery
Setelah target disepakati, desain recovery dapat dievaluasi dengan lebih konkret. RPO memengaruhi frekuensi proteksi data, metode replikasi, serta kapasitas storage. RTO memengaruhi pilihan jalur recovery, kesiapan compute, akses administratif terpisah, runbook, dan urutan failover. Backup offline atau terisolasi, enkripsi, pengujian integritas, MFA untuk akses administratif, dan segmentasi jaringan juga dapat menjadi bagian dari kesiapan menghadapi ransomware.
CISA merekomendasikan organisasi memelihara backup kritis yang offline dan terenkripsi, serta menguji ketersediaan dan integritas backup sebagai bagian dari disaster recovery. CISA juga menekankan MFA untuk akun administratif dan sistem kritis, serta segmentasi jaringan untuk membatasi dampak insiden. Kontrol ini tidak menjamin hasil recovery tertentu, tetapi membantu mengurangi titik kegagalan yang perlu dipertimbangkan dalam desain.
Checklist workshop RPO/RTO untuk IT Manager
- Daftarkan aplikasi dan pemilik keputusan bisnisnya.
- Tentukan tier kritikalitas berdasarkan dampak operasional, finansial, dan pelanggan.
- Catat RPO serta RTO yang disepakati, termasuk asumsi dan pengecualian.
- Petakan dependensi database, identitas, DNS, jaringan, dan integrasi vendor.
- Susun urutan restore atau failover, lalu uji dengan skenario yang relevan.
- Simpan bukti hasil uji dan tinjau ulang setelah ada perubahan aplikasi, vendor, atau risiko.
Peran myBATICloud dalam roadmap recovery
myBATICloud dapat membantu memfasilitasi workshop RPO/RTO untuk memetakan workload, dependensi, dan opsi desain recovery. BaaS dapat dipertimbangkan sebagai lapisan proteksi data, sementara DRaaS dapat menjadi opsi jalur failover sesuai target yang disepakati. IaaS dan StaaS dapat mendukung kebutuhan compute dan storage; Managed Service dapat membantu operasi, monitoring, patching, serta dokumentasi pengujian. Kesesuaian desain tetap bergantung pada arsitektur, SLA, anggaran, dan kebutuhan organisasi.
Kesimpulan: keputusan yang perlu disepakati sebelum insiden
RPO dan RTO bukan dua angka untuk disimpan di dokumen. Keduanya adalah keputusan bersama tentang risiko, prioritas aplikasi, dan cara organisasi kembali beroperasi. Dengan menyepakati target sebelum insiden, menguji recovery, dan menyimpan bukti hasilnya, tim dapat membuat keputusan yang lebih cepat ketika tekanan benar-benar terjadi.
Ingin menyelaraskan target recovery aplikasi? Jadwalkan workshop RPO/RTO untuk memetakan workload, dependensi, dan opsi kesiapan recovery yang sesuai dengan kondisi organisasi Anda.
FAQ
Apa perbedaan RPO dan RTO?
RPO mengukur toleransi kehilangan data dalam waktu. RTO mengukur batas waktu pemulihan layanan. Keduanya perlu ditentukan berdasarkan dampak bisnis setiap workload.
Apakah backup otomatis memenuhi RPO dan RTO?
Belum tentu. Backup perlu diuji untuk membuktikan data dapat dipulihkan, dependensi aplikasi terpenuhi, dan layanan kembali dalam urutan serta waktu yang ditargetkan.
Kapan target RPO dan RTO perlu ditinjau ulang?
Tinjau saat ada perubahan aplikasi, arsitektur, vendor, proses bisnis, klasifikasi data, atau risiko yang memengaruhi dampak downtime dan recovery.