RPO menggambarkan jendela kehilangan data yang siap Anda terima; RTO menggambarkan gangguan yang ingin Anda jaga dalam batas tertentu. Tentukan keduanya untuk fungsi bisnis yang berguna, lalu buktikan urutan pemulihan dalam latihan. Jadwal pencadangan atau spesifikasi server saja tidak menetapkan salah satu tujuan.
Mulailah dengan layanan yang dapat digunakan orang
Tujuan pemulihan menjadi berguna ketika menggambarkan fungsi bisnis alih-alih mesin yang terisolasi. Server dapat menyala sementara pelanggan masih tidak dapat masuk, mengambil file, atau menyelesaikan permintaan. Tulis kondisi akhir dalam bahasa biasa: pengguna yang diotorisasi dapat mengakses aplikasi dan data yang diperlukan konsisten. Ini membuat target dapat diuji oleh seseorang di luar tim infrastruktur.
Tanyakan kepada pemilik aplikasi apa yang akan dicegah oleh gangguan dan berapa biaya data yang hilang. Publikasi mingguan dan aplikasi pemrosesan transaksi mungkin memiliki jawaban berbeda. Perlakukan tujuan yang dihasilkan sebagai target perencanaan, bukan janji yang diciptakan dari katalog perangkat keras. Catat siapa yang menyetujuinya dan skenario kegagalan mana yang dicakup rencana.
Pisahkan kedua jam
RPO menyangkut seberapa jauh ke belakang data yang dipulihkan relatif terhadap gangguan. RTO menyangkut berapa lama fungsi dapat tetap tidak tersedia. Cadangan terbaru dapat memperbaiki jendela kehilangan data sementara pemulihan yang lambat tetap melewatkan target waktu pemulihan. Sebaliknya, reboot cepat dapat memulihkan akses ke aplikasi yang data terbarunya belum bertahan.
Tentukan titik referensi. Putuskan kapan jam insiden dimulai, apa yang dianggap sebagai operasi yang dipulihkan, dan bagaimana titik data yang dapat digunakan akan diidentifikasi. Jaga target tetap terpisah dari hasil yang diukur: tujuan adalah apa yang Anda cari; latihan menunjukkan apa yang dicapai proses saat ini. Tinjau kembali keduanya ketika aplikasi atau kumpulan data berubah.
Anggarkan setiap langkah pemulihan
Anggaran RTO yang praktis mencakup deteksi, penilaian, otorisasi, akses ke lingkungan pemulihan, pemulihan, validasi aplikasi, dan pembukaan kembali. Waktu penyalinan file hanyalah salah satu komponen. Jika orang yang memegang kunci pemulihan tidak tersedia, cadangan yang secara teoretis cepat tetap dapat tidak dapat digunakan. Daftarkan dependensi dan pastikan tim pemulihan dapat menjangkaunya selama kegagalan yang dipertimbangkan.
Tetapkan waktu sementara untuk setiap langkah, lalu ganti perkiraan dengan pengamatan. Dalam anggaran dua jam ilustratif ini, pemulihan menerima alokasi terbesar tetapi validasi tetap memiliki waktu yang dilindungi. Angka-angka tersebut menggambarkan contoh perencanaan, bukan penyampaian layanan SwissOctet. Jika totalnya tidak memiliki margin, desain perlu ditingkatkan sebelum tujuan menjadi kredibel.
| Langkah pemulihan | Alokasi ilustratif | Bukti yang dikumpulkan |
|---|---|---|
| Deteksi dan nilai | 15 menit | Kedatangan peringatan dan keputusan insiden |
| Siapkan lingkungan pemulihan | 20 menit | Akses dan konfigurasi tersedia |
| Pulihkan data dan layanan | 50 menit | Pemulihan selesai dengan data yang konsisten |
| Validasi dan buka kembali | 25 menit | Perjalanan pengguna berhasil |
| Margin kontingensi | 10 menit | Pekerjaan tak terduga tercatat |
Periksa jendela kehilangan data yang sebenarnya
Pekerjaan yang dijadwalkan setiap jam tidak secara otomatis memberikan RPO satu jam. Pekerjaan yang gagal, unggahan yang tertunda, atau salinan yang tidak dapat digunakan dapat membuat titik pemulihan terbaru jauh lebih lama. Amati penyelesaian yang berhasil dan status yang benar-benar dapat dipulihkan. Untuk aplikasi dengan beberapa penyimpanan data, konfirmasikan bahwa titik pemulihannya kompatibel alih-alih membaca setiap stempel waktu secara terpisah.
Pilih peristiwa referensi selama latihan, seperti catatan uji yang diotorisasi yang dibuat pada waktu yang diketahui. Setelah pemulihan, identifikasi catatan valid terbaru dan ukur selisihnya. Gunakan data uji yang tidak berbahaya. Ini memberikan hasil praktis dan mengungkap asumsi yang mungkin disembunyikan oleh dasbor yang hanya menampilkan keberhasilan pekerjaan.
Pilih strategi dalam anggaran
Pencadangan-dan-pemulihan, lingkungan siaga yang disiapkan, dan desain aplikasi yang direplikasi menukar biaya dan kompleksitas dengan kecepatan pemulihan. Replikasi dapat mengurangi beberapa penundaan tetapi juga dapat mereproduksi penghapusan yang tidak disengaja atau kesalahan aplikasi. Siaga yang menyimpang dari konfigurasi kerja menciptakan risikonya sendiri. Pilih strategi berdasarkan skenario kegagalan dan tujuan yang Anda dokumentasikan.
Pertimbangkan layanan kecil dengan target empat jam dan kumpulan data lebih besar yang pemulihannya saja memakan waktu enam jam dalam latihan. Membeli port jaringan yang lebih cepat hanyalah hipotesis: pembacaan penyimpanan, penulisan penerimaan, dan pemulihan aplikasi mungkin mendominasi. Perbaiki langkah pembatas yang terukur, kurangi kumpulan pemulihan, atau ubah strategi, lalu berlatih lagi.
Berlatih tanpa membahayakan produksi
Gunakan lingkungan pemulihan yang terisolasi dan jendela latihan yang ditentukan. Pastikan pekerjaan yang dipulihkan tidak dapat mengirim notifikasi nyata, menerima pembayaran publik, atau menulis ke integrasi produksi. Uji akses, integritas data, dan perjalanan pengguna yang representatif sebelum menganggap latihan selesai. Sertakan orang yang tidak menulis prosedur asli untuk mengungkap instruksi yang hilang.
Simpan garis waktu latihan, titik pemulihan yang dicapai, dan setiap gangguan yang disebabkan oleh informasi yang tidak tersedia. Laporan yang berguna menyatakan hasil yang diukur, selisih terhadap tujuan, dan tindakan korektif yang spesifik. Ulangi setelah perubahan yang berarti dan pada interval yang sesuai dengan pentingnya proyek.
Jaga rencana tetap dapat digunakan selama kegagalan
Simpan prosedur pemulihan di tempat yang dapat diakses tim tanpa hanya mengandalkan aplikasi yang gagal. Simpan kredensial dan kunci enkripsi di lokasi yang dilindungi dengan proses akses yang teruji. Perbarui kontak, ukuran kumpulan data, dan dependensi seiring perkembangan proyek. Rencana yang usang dapat menghabiskan margin waktu bahkan sebelum pemulihan dimulai.
Saat membandingkan konfigurasi SwissOctet, pisahkan arsitektur pemulihan Anda dari pilihan cadangan opsional katalog. Konfirmasikan apa yang dicakup suatu opsi, di mana data pemulihan disimpan, dan siapa yang melakukan pemulihan. Katalog tidak menetapkan RPO atau RTO aplikasi. Proses terukur Anda dan ketentuan layanan yang sebenarnya memberikan dasar untuk keputusan itu.
Daftar periksa praktis Anda.
- Tentukan fungsi bisnis yang dipulihkan.
- Setujui target RPO dan RTO yang terpisah.
- Anggarkan deteksi, akses, pemulihan, dan validasi.
- Ukur titik data terbaru yang dapat digunakan.
- Berlatih di lingkungan yang terisolasi.
- Catat selisih dan ulangi setelah perubahan yang relevan.
Detail yang penting.
Apakah RTO sama dengan waktu aktif?+
Tidak. RTO adalah target pemulihan untuk skenario gangguan. Waktu aktif mengukur ketersediaan selama suatu periode; yang satu tidak menetapkan yang lain.
Apakah pencadangan setiap jam menjamin RPO satu jam?+
Tidak. Periksa salinan yang selesai dan dapat digunakan serta persyaratan konsistensi aplikasi. Pekerjaan yang gagal dan transfer yang tertunda dapat memperlebar selisih data yang dapat dipulihkan.
Haruskah setiap proyek menggunakan server siaga?+
Pilih strategi berdasarkan tujuan pemulihan proyek dan proses pemulihan yang terukur. Siaga menambah biaya dan kompleksitas operasional dan tidak secara otomatis diperlukan.
Kunjungi sumbernya.
Referensi ini mendukung konsep teknis dalam panduan ini. Ikuti dokumentasi terkini sebelum mengubah sistem produksi.
- NIST SP 800-34 Rev. 1: Panduan Perencanaan Kontingensi nvlpubs.nist.gov
- AWS Well-Architected: Tentukan tujuan pemulihan docs.aws.amazon.com
- Microsoft Learn: Kelangsungan bisnis, ketersediaan tinggi, dan pemulihan bencana learn.microsoft.com
Panduan editorial oleh SwissOctet. Contoh bersifat ilustratif. Spesifikasi layanan, opsi yang tersedia, dan ketentuan kontraktual harus diverifikasi secara terpisah.