Tentukan kehilangan dan pemadaman yang dapat diterima
Catat titik pemulihan terbaru yang dapat diterima dan waktu target untuk memulihkan layanan yang berguna. Ini adalah tujuan aplikasi, bukan SLA PrivacyNodes. Jika kehilangan data satu jam tidak dapat diterima, salinan harian saja tidak dapat memenuhi tujuan itu. Pilih metode cadangan basis data yang konsisten dengan beban kerja dan versi Anda.
Dapatkan target sekali pakai, artefak aplikasi dan kredensial pemulihan yang berwenang melalui penyimpanan terlindungi. Konfirmasi siapa yang menyetujui pemulihan data pelanggan dan bagaimana lingkungan uji mencegah lalu lintas luar. Jangan pulihkan ke basis data produksi yang berjalan atau direktori yang ada.
Inventarisasi seluruh status aplikasi
Untuk API pelaporan, daftarkan PostgreSQL, unggahan, ekspor yang tidak dapat direproduksi, konfigurasi, referensi kunci enkripsi, DNS dan dependensi eksternal. Bedakan cache sekali pakai dari antrean yang menyimpan pekerjaan pelanggan yang memerlukan rekonsiliasi. Image container mendeskripsikan perangkat lunak, bukan semua status persisten.
| Catatan | Nilai Anda |
|---|---|
| Versi artefak dan konfigurasi | Pengenal tepat |
| Cadangan basis data dan titik pemulihan | Arsip dan timestamp yang dipilih |
| Snapshot unggahan dan batas konsistensi | Snapshot, jalur dan rencana pencocokan |
| Target sekali pakai | Lingkungan terverifikasi dan tujuan kosong |
| Kredensial dan penyetuju | Hanya referensi terlindungi |
| Mulai, selesai, langkah yang hilang | Hasil yang diamati, bukan perkiraan |
Pahami apa yang disertakan cadangan
PostgreSQL mendokumentasikan dump logis, cadangan sistem berkas dan pengarsipan berkelanjutan sebagai strategi yang berbeda. Sebuah pg_dump arsip mencakup satu basis data; peran dan tablespace seluruh kluster memerlukan pertimbangan terpisah. Kliennya tidak dapat membuang server versi mayor yang lebih baru. Cocokkan versi alat dan strategi dengan tujuan; menyalin direktori data yang aktif tidak otomatis konsisten.
Periksa arsip sebelum memulihkan. Memilih tabel dengan pg_restore tidak otomatis menyertakan semua dependensinya. Opsi --clean menghapus objek yang ada; pemulihan transaksi tunggal tidak dapat digabungkan dengan pekerjaan paralel. Tinjau opsi untuk basis data uji kosong yang diidentifikasi secara spesifik.
Referensi teknis: Cadangan dan pemulihan PostgreSQL · PostgreSQL pg_dump · PostgreSQL pg_restore.
Periksa integritas dan pulihkan secara independen
Pemeriksaan repositori dan pemulihan fungsional menjawab pertanyaan yang berbeda. Perintah biasa restic check tidak membaca setiap paket data yang tersimpan; check --read-data menambahkan pembacaan tersebut dan dapat menghabiskan bandwidth yang substansial. Keduanya tidak membuktikan snapshot berisi semua yang dibutuhkan API.
Pilih snapshot tertentu dan direktori target baru. Perintah latest tanpa kualifikasi di repositori bersama dapat memilih beban kerja lain. Pemulihan dapat menimpa berkas dan gangguan dapat meninggalkan hasil parsial. Verifikasi tujuan terlebih dahulu, pertahankan berkas produksi dan repositori asli.
Referensi teknis: pemeriksaan repositori restic · target pemulihan restic.
Uji perilaku yang dipulihkan dalam urutan dependensi
Buat ulang lingkungan, pulihkan basis data dan unggahan yang cocok, lalu jalankan API dengan kredensial staging. Tahan worker sampai backlog dan efek sampingnya dipahami. Nonaktifkan email produksi, panggilan pembayaran dan webhook; gunakan tujuan ekspor uji dan jangan pernah mengonsumsi antrean produksi.
Gunakan akun uji yang diketahui untuk membaca catatan, membuka unggahannya, memeriksa pembatasan akses dan menjalankan ekspor baru kecil. Verifikasi bahwa akun uji lain tidak dapat membaca datanya. Bandingkan titik pemulihan yang dipilih dengan catatan terbaru yang diharapkan. Catat waktu pemulihan aktual setelah gladi; jangan menulis hasil sukses yang dibuat-buat sebelumnya.
Selesaikan kepemilikan tulis sebelum cutover nyata
Selama insiden, tentukan sistem mana yang boleh menerima tulisan dan bagaimana perubahan selanjutnya direkonsiliasi. Dua salinan yang dapat ditulis dapat menyimpang. Gladi mendokumentasikan keputusan ini tanpa mengalihkan lalu lintas nyata. Hapus data sekali pakai sesuai aturan retensi Anda saat latihan berakhir.
Perbaiki kredensial, dependensi dan langkah validasi yang hilang setelah setiap gladi. Simpan runbook di luar host asli dan pastikan pemelihara berwenang lain dapat menemukannya. Opsi cadangan yang dapat dipilih terpisah dari proses aplikasi ini; konfirmasi cakupan dan prosedur pemulihan di fakta layanan. Gunakan catatan rilis untuk penerapan berikutnya.
Referensi resmi
Dokumentasi telah ditinjau untuk artikel ini. Contoh adalah latihan perencanaan, bukan perintah yang diuji pada server PrivacyNodes. Periksa dokumentasi untuk versi yang terpasang.