RPO dan RTO: Menyusun Rencana Pemulihan Bencana untuk Aplikasi Bisnis
Penjelasan RPO dan RTO dengan contoh, cara menentukan target yang realistis bersama klien, strategi backup dan server cadangan yang sesuai, serta langkah menguji rencana pemulihan secara berkala.
Server rusak, database terhapus tidak sengaja, ransomware, atau ruang server kebanjiran. Pertanyaannya bukan apakah hal itu akan terjadi, melainkan seberapa siap Anda ketika terjadi. Dua angka membantu menjawabnya secara terukur: RPO dan RTO.
Apa itu RPO dan RTO?
| Istilah | Pertanyaan yang dijawab | Contoh |
|---|---|---|
| RPO (Recovery Point Objective) | Berapa banyak data yang boleh hilang, diukur dalam waktu? | RPO 1 jam: paling banyak data 1 jam terakhir yang hilang |
| RTO (Recovery Time Objective) | Berapa lama sistem boleh mati sampai kembali berjalan? | RTO 4 jam: sistem harus pulih paling lambat 4 jam setelah gangguan |
RPO ditentukan terutama oleh seberapa sering data dicadangkan atau direplikasi. RTO ditentukan oleh seberapa cepat Anda bisa menyiapkan server dan memulihkan data.
Contoh: backup harian saja
Sebuah klinik memakai backup database otomatis setiap pukul 01.00. Server rusak pada pukul 16.00.
- Data terakhir yang aman adalah dari pukul 01.00, sehingga transaksi dari pagi sampai sore, sekitar 15 jam, hilang. RPO nyata sistem ini adalah sampai 24 jam.
- Bila menyiapkan server baru, memasang aplikasi, dan me-restore database memakan waktu 6 jam, RTO-nya sekitar 6 jam, belum termasuk waktu mendeteksi masalah.
Untuk klinik yang melayani puluhan pasien per hari, kehilangan data satu hari pelayanan berarti harus memasukkan ulang rekam medis dan transaksi dari catatan kertas, bila catatan itu ada.
Strategi dan dampaknya
| Strategi | Perkiraan RPO | Perkiraan RTO | Biaya relatif |
|---|---|---|---|
| Backup harian ke lokasi lain | Sampai 24 jam | Beberapa jam hingga 1 hari | Rendah |
| Backup harian + backup log transaksi berkala (misalnya tiap 15 menit) | ± 15 menit | Beberapa jam | Rendah – sedang |
| Replikasi database ke server cadangan yang siap | Detik – menit | Menit – 1 jam | Sedang – tinggi |
| Dua lokasi aktif dengan failover otomatis | Mendekati nol | Mendekati nol | Tinggi |
Replikasi tidak menggantikan backup. Bila data terhapus atau terenkripsi ransomware, kerusakan itu ikut tereplikasi ke server cadangan dalam hitungan detik. Tetap simpan backup berkala yang terpisah dan tidak bisa diubah dari server utama.
Menentukan target bersama klien
RPO dan RTO adalah keputusan bisnis, bukan hanya keputusan teknis. Ajukan pertanyaan seperti:
- Bila sistem mati 4 jam, apa yang terjadi pada pelayanan? Apakah ada prosedur manual cadangan?
- Bila data 1 hari hilang, berapa biaya dan tenaga untuk memasukkannya kembali?
- Berapa anggaran yang tersedia untuk infrastruktur cadangan?
Sajikan beberapa pilihan beserta biayanya, lalu biarkan klien memutuskan. Cara menyajikannya dibahas di artikel menjelaskan keputusan teknis kepada klien. Target ini sebaiknya tertulis di kontrak atau SLA, bersama target ketersediaan yang bisa dihitung dengan kalkulator SLA dan uptime.
Isi dokumen rencana pemulihan
- Daftar sistem dan prioritasnya: mana yang harus pulih lebih dulu, misalnya pendaftaran dan rekam medis sebelum laporan manajemen.
- Lokasi backup dan cara mengaksesnya, termasuk kredensial yang disimpan aman di luar server utama.
- Langkah pemulihan yang rinci: menyiapkan server, memasang aplikasi, me-restore database, mengarahkan domain.
- Kontak penting: tim teknis, penanggung jawab klien, penyedia hosting, dan penyedia internet.
- Prosedur manual sementara bagi pengguna selama sistem belum pulih.
Uji secara berkala
Rencana yang tidak pernah diuji hanyalah harapan. Jadwalkan uji pemulihan, misalnya setiap tiga atau enam bulan:
- Restore backup terbaru ke server terpisah, lalu periksa apakah aplikasi berjalan dan data lengkap.
- Catat waktu yang benar-benar dibutuhkan. Bandingkan dengan target RTO.
- Perbarui dokumen berdasarkan kendala yang ditemukan.
Hitung juga ruang penyimpanan yang dibutuhkan untuk menyimpan beberapa generasi backup dengan kalkulator storage dan backup. Dasar-dasar backup 3-2-1 dibahas di artikel DevOps untuk tim kecil.
Pertanyaan yang sering diajukan
Apakah layanan cloud otomatis aman dari bencana? Penyedia cloud menjaga perangkat kerasnya, tetapi kesalahan konfigurasi, data yang terhapus, dan akun yang diretas tetap menjadi tanggung jawab Anda. Backup tetap diperlukan.
Berapa RPO dan RTO yang wajar untuk klinik kecil? Tidak ada angka baku. Banyak klinik kecil memulai dengan backup harian ditambah backup berkala di jam pelayanan dan prosedur manual cadangan, lalu meningkatkannya seiring pertumbuhan.