Cadangan terenkripsi yang benar-benar dapat Anda pulihkan.

Pilih batas repositori

Gunakan tujuan dan kredensial terpisah dari server produksi. Enkripsi sisi klien dapat melindungi salinan tersimpan, tetapi kata sandi atau kunci repositori harus dicadangkan secara privat. Kehilangannya dapat membuat setiap snapshot terenkripsi tidak dapat digunakan.

Ambil data secara konsisten

Gunakan dump bawaan basis data atau prosedur snapshot yang didukung aplikasi. Cadangkan konfigurasi, instruksi deployment, dan rahasia terlindungi yang diperlukan untuk pemulihan. Kecualikan cache sementara hanya jika Anda tahu cache tersebut dapat dibangun ulang.

Persulit penghapusan

Pertimbangkan tujuan append-only atau immutable di mana mesin sumber tidak dapat menghapus setiap salinan historis. Pisahkan kredensial retensi dan pemangkasan jika memungkinkan. Enkripsi saja tidak menghentikan server yang disusupi menghapus repositori yang dapat ditulis.

Jadwalkan pemeriksaan dan latihan pemulihan

Pantau status keluar pekerjaan dan usia cadangan baik terakhir. Jalankan pemeriksaan integritas repositori yang didukung oleh alat tersebut. Pulihkan sampel secara rutin dan lakukan gladi pemulihan lengkap setelah perubahan aplikasi besar.

Pisahkan penambahan salinan dari penghapusan riwayat

Tujuan append-only dapat memungkinkan server produksi menambahkan snapshot sambil menyimpan wewenang penghapusan di mesin tepercaya terpisah. Retensi tetap perlu ditinjau dengan cermat: snapshot baru yang dipalsukan dapat melemahkan beberapa kebijakan pemilihan berbasis kalender. Periksa panduan alat, jalankan uji coba retensi, dan pantau kapasitas. Operasi forget Restic memilih snapshot; pruning menghapus data tersimpan yang tidak direferensikan.

• Jauhkan kredensial pemeliharaan repositori dari mesin produksi
• Jalankan uji coba retensi sebelum mengizinkan penghapusan
• Gunakan target kosong baru untuk setiap latihan pemulihan

restic check
restic snapshots
restic restore latest --target /srv/restore-drill

Dokumentasi resmi: Retensi dan pemangkasan Restic

Latihan pemulihan dengan kondisi lulus

Pilih satu kegagalan yang realistis: file terhapus, basis data hilang, atau pembangunan ulang mesin secara menyeluruh. Pulihkan ke direktori terpisah atau host terisolasi. Verifikasi isi file, izin, dan kemampuan aplikasi untuk menggunakannya. Catat waktu yang berlalu dan langkah manual yang hilang dari runbook. Pemeriksaan repositori mengonfirmasi properti yang berbeda dari pemulihan aplikasi yang berfungsi.

• Jangan memulihkan di atas aplikasi yang sedang berjalan sebagai uji pertama
• Pastikan kredensial enkripsi dapat dipulihkan secara independen
• Beri peringatan jika cadangan sukses terbaru melebihi target pemulihan Anda

Buat manifes pemulihan sebelum memilih pengecualian

Daftarkan hal-hal yang tidak dapat dibuat ulang dengan memasang ulang paket: konten basis data, unggahan, konfigurasi aplikasi, kunci penandatanganan atau enkripsi, dan versi deployment. Catat metode konsistensi di samping setiap item. Dump basis data termasuk pada titik waktu tertentu; menyalin direktori basis data yang sibuk dapat menghasilkan hasil berbeda. Simpan akses repositori, passphrase-nya, dan ekspor kunci Borg apa pun di lokasi pemulihan privat yang terpisah. Uji bahwa mesin pengganti dapat membuka repositori sebelum menjadikannya satu-satunya salinan pemulihan.

• Nyatakan tujuan titik pemulihan: berapa banyak pekerjaan terbaru yang boleh hilang. Atur jadwal berdasarkan persyaratan tersebut.
• Nyatakan tujuan waktu pemulihan: berapa lama pembangunan ulang dapat berlangsung. Sertakan impor basis data dan perubahan DNS dalam latihan.
• Pastikan pengecualian yang dimaksudkan untuk cache tidak juga menghapus unggahan, volume kontainer, atau konfigurasi yang dilindungi.
• Gunakan dokumentasi untuk versi mayor Borg yang terpasang; format repositori dan perintah tidak dapat dipertukarkan di semua versi.

Dokumentasi resmi: Borg: enkripsi, konsistensi dan pemulihan

Periksa data tersimpan serta metadata repositori

Pemeriksaan repositori default Restic dan verifikasi baca-tuntas melakukan pekerjaan yang berbeda. Jadwalkan verifikasi data dengan mempertimbangkan biaya bandwidth dan waktu jalannya. Contoh memeriksa seperlima berkas pack yang ditentukan; pemeriksaan terjadwal berikutnya harus menggunakan fraksi lain untuk mencakup repositori. Subset yang dipilih secara acak tidak memberikan jaminan cakupan yang sama. Kedua operasi tersebut tidak membuktikan bahwa aplikasi dapat dimulai dengan data yang dipulihkan.

restic check --read-data-subset=1/5
restic snapshots --host example-host
restic restore latest --host example-host --target /srv/restore-drill

Dokumentasi resmi: restic: pemeriksaan repositori dan verifikasi data

Jauhkan pemeliharaan dari jangkauan klien yang terdampak

Penyimpanan append-only Borg mempertahankan data segmen yang telah di-commit, tetapi klien tetap dapat mengubah daftar arsip yang terlihat; pemulihan dan pemadatan memerlukan prosedur administratif yang terdokumentasi. Batasi kredensial cadangan jarak jauh ke perintah server Borg, bukan shell atau login filesystem tanpa batasan yang dapat melewati perlindungan tersebut. Dengan restic, tinjau panduan keep-within untuk retensi append-only. Sebelum pemeliharaan apa pun yang dapat menghapus riwayat, periksa kesehatan repositori dan pratinjau pilihan dari mesin tepercaya.

• Pantau usia salinan sukses terakhir, pertumbuhan repositori, ruang cache, dan kapasitas kosong di kedua sisi.
• Jika pemulihan gagal, pertahankan repositori asli dan log sebelum mencoba perbaikan atau pembersihan.
• Jika tugas berhasil tetapi file yang diharapkan tidak ada, periksa isi arsip dan pola pengecualian sebelum mengubah retensi.
• Selesaikan latihan dengan membuka file dan menjalankan pemeriksaan aplikasi secara terisolasi; jauhkan tujuan produksi dari perintah pemulihan.

Dokumentasi resmi: Borg: operasi dan pemeliharaan append-only · restic: pertimbangan retensi dan append-only