Apa Itu RPO dan RTO dalam Rencana Pemulihan Server?

Bayangkan server toko online mati pukul dua siang karena disk rusak. Backup terakhir dibuat pukul satu dini hari. Artinya, semua pesanan dari pagi sampai siang tidak ada di backup. Lalu proses menyiapkan server baru dan memulihkan data ternyata butuh enam jam. Dua kerugian itu punya nama: data yang hilang terkait RPO, dan waktu henti terkait RTO.

RPO (Recovery Point Objective) adalah batas maksimal data yang boleh hilang, diukur mundur dari saat bencana. RTO (Recovery Time Objective) adalah batas maksimal waktu sistem boleh tidak berjalan, dihitung dari saat bencana sampai layanan pulih. Keduanya adalah target yang kamu tetapkan sendiri sebelum bencana terjadi, bukan angka yang muncul belakangan.

Apa bedanya RPO dan RTO?

Cara mudah mengingatnya: RPO melihat ke belakang, RTO melihat ke depan.

RPO menjawab "sampai titik waktu mana data kita bisa dikembalikan?". Kalau RPO-mu 1 jam, kamu harus punya salinan data yang usianya tidak lebih dari 1 jam kapan pun bencana datang. Jadi RPO langsung menentukan frekuensi backup atau replikasi.

RTO menjawab "berapa lama pelanggan harus menunggu?". Kalau RTO-mu 2 jam, seluruh proses, mulai dari menyadari ada masalah, menyiapkan server, memulihkan data, sampai mengarahkan domain, harus selesai dalam 2 jam. RTO menentukan metode pemulihan: cukup dari backup, atau perlu server cadangan yang sudah menyala.

Ada dua istilah pasangannya yang kadang muncul di laporan. RPA dan RTA (A untuk actual) adalah angka yang benar-benar terjadi saat uji atau insiden. Selisih antara target dan kenyataan inilah yang perlu diperbaiki.

Contoh target untuk usaha kecil

Target tidak harus sama untuk semua sistem. Justru lebih hemat bila dibedakan menurut dampaknya.

Angka di tabel hanyalah ilustrasi titik awal, bukan standar. Usaha yang hampir semua pesanannya masuk lewat website tentu butuh target lebih ketat dibanding usaha yang website-nya hanya brosur.

Bagaimana menentukan angkanya?

Mulailah dari pertanyaan bisnis, bukan teknis. Kalau sistem ini mati sehari penuh, apa yang terjadi? Pesanan tertunda, pelanggan pindah ke toko lain, atau staf tidak bisa bekerja? Kalau data setengah hari hilang, apakah bisa disusun ulang dari chat, email, atau nota kertas, atau benar-benar lenyap?

Dari jawaban itu muncul angka yang masuk akal. Lalu cocokkan dengan biaya. Makin kecil RPO dan RTO, makin mahal infrastrukturnya. Backup harian ke penyimpanan lain itu murah. Replikasi database ke server kedua yang selalu menyala, ditambah pemantauan dan penanganan otomatis, jelas lebih mahal dan lebih rumit dirawat.

Hindari jebakan menetapkan "RPO nol dan RTO nol" untuk semuanya. Target seperti itu menuntut beberapa server aktif sekaligus di lokasi berbeda, dan untuk kebanyakan usaha kecil biayanya tidak sebanding dengan risikonya.

Dari target ke teknis

Setelah angkanya disepakati, terjemahkan ke pilihan teknis.

Untuk RPO, aturannya sederhana: jarak antar backup tidak boleh lebih panjang dari RPO. RPO 24 jam cukup dengan backup harian. RPO 1 jam butuh backup per jam atau cara yang lebih halus, misalnya binary log MySQL yang ikut disalin sehingga database bisa dipulihkan sampai menit tertentu. Untuk RPO di bawah beberapa menit, biasanya dipakai replikasi database ke server lain. Perlu diingat, replikasi saja bukan backup: perintah hapus yang salah ikut tereplikasi dalam hitungan detik.

Untuk RTO, hitung semua tahap, bukan hanya waktu restore. Waktu sampai ada yang sadar server mati (tanpa pemantauan, ini bisa berjam-jam), waktu menyiapkan server pengganti, waktu mengunduh backup yang besarnya puluhan gigabyte, waktu memulihkan database, dan waktu perubahan DNS menyebar. Kalau total tahap itu melebihi target, pilihannya adalah mempercepat salah satu tahap, misalnya menyiapkan server cadangan lebih dulu, atau menyesuaikan target.

Backup harus mencakup semua yang dibutuhkan untuk pulih: database, file, dan konfigurasi. Cara menjadwalkannya untuk MySQL dan PostgreSQL dibahas di backup database otomatis, sedangkan susunan rencana lengkapnya ada di strategi disaster recovery untuk bisnis kecil.

Kesalahan umum saat menetapkan target

Kesalahan pertama adalah menetapkan target tanpa melibatkan pemilik usaha atau orang yang paling tahu dampaknya. Tim teknis cenderung memilih angka yang mudah dicapai, sementara pemilik usaha cenderung meminta angka yang terlalu ketat. Angka yang sehat lahir dari obrolan kedua pihak, lengkap dengan perkiraan biayanya.

Kesalahan kedua adalah menganggap RTO hanya urusan server. Kalau yang bisa memulihkan cuma satu orang dan ia sedang cuti, waktu pulih otomatis molor. Langkah pemulihan yang tertulis dan akses darurat yang bisa dipakai orang lain sama pentingnya dengan backup itu sendiri.

Kesalahan ketiga adalah lupa bahwa satu sistem bergantung pada sistem lain. Website toko yang pulih dalam satu jam tidak banyak berguna bila database atau layanan pembayarannya baru pulih sehari kemudian. Target untuk sistem yang saling bergantung perlu diselaraskan.

Uji, lalu ukur ulang

Target di atas kertas baru berarti setelah dibuktikan. Lakukan uji pemulihan di server terpisah dan catat dua hal: usia data terbaru yang berhasil dipulihkan (RPA) dan total waktu sampai aplikasi bisa dipakai (RTA). Banyak tim baru menyadari saat uji bahwa mengunduh backup saja sudah memakan sebagian besar target RTO, atau bahwa ada file konfigurasi yang tidak pernah ikut dibackup.

Ulangi uji secara berkala dan setiap kali ada perubahan besar pada server. Data yang terus bertambah membuat waktu restore ikut bertambah, jadi angka yang lolos tahun lalu belum tentu lolos sekarang.

Singkatnya, RPO menjawab berapa banyak data yang rela kamu hilangkan dan RTO menjawab berapa lama bisnismu sanggup berhenti. Tetapkan keduanya per sistem sesuai dampak bisnis, pilih frekuensi backup dan metode pemulihan yang memenuhi angka itu, lalu buktikan lewat uji restore yang rutin.