Snapshot adalah representasi pada titik waktu dengan perlindungan yang ditentukan oleh implementasinya. Strategi backup menambahkan retensi yang disengaja, pemisahan akses, dan pemulihan yang teruji. Beberapa snapshot adalah backup; yang lain bergantung pada penyimpanan asli. Tanyakan apa yang bertahan dari penghapusan, kompromi, atau kehilangan lingkungan utama.
Jelaskan salinannya sebelum menamainya
Kata snapshot memberi tahu Anda bahwa suatu titik waktu telah direpresentasikan, tetapi tidak di mana data yang dapat dipulihkan disimpan atau siapa yang dapat menghapusnya. Snapshot filesystem pada penyimpanan asli dan snapshot blok yang dikelola penyedia dapat memiliki batas kegagalan yang berbeda. Mulailah dengan implementasinya alih-alih memperlakukan label sebagai janji universal.
AWS mendokumentasikan snapshot EBS sebagai backup titik waktu inkremental dari volumenya. Itu adalah implementasi tertentu, bukan bukti bahwa setiap opsi snapshot berperilaku sama. Untuk layanan apa pun, tanyakan apakah pemulihan bergantung pada volume asli, apakah salinan meninggalkan domain kegagalan utama, dan apa yang terjadi ketika sumber dihapus.
Bandingkan kegagalan yang Anda perkirakan dapat diatasi
Rollback cepat setelah pembaruan dan pemulihan setelah kehilangan akun adalah masalah yang berbeda. Snapshot lokal mungkin nyaman untuk yang pertama sementara menawarkan sedikit pemisahan untuk yang kedua. Salinan independen dapat menambah perlindungan, tetapi hanya jika jalur penyimpanan, akses, dan penghapusannya cukup terpisah dari insiden yang Anda persiapkan.
Tuliskan kegagalan dan hasil yang diperlukan. Perbandingan ilustratif ini adalah alat bantu keputusan, bukan daftar fitur untuk SwissOctet. Ini mendorong pertanyaan tentang salinan dan kendali alih-alih klaim bahwa satu teknologi selalu lebih unggul. Hasil sebenarnya bergantung pada konfigurasi dan proses pemulihan yang didokumentasikan operator.
| Skenario | Pertanyaan untuk snapshot | Pertanyaan untuk backup |
|---|---|---|
| Pembaruan aplikasi yang buruk | Dapatkah saya kembali ke titik yang dimaksud? | Berapa lama pemulihan yang dapat digunakan? |
| Disk utama hilang | Apakah salinan bergantung pada disk itu? | Dapatkah saya memulihkan ke penyimpanan baru? |
| Akun administratif dikompromikan | Dapatkah akun ini menghapus setiap salinan? | Apakah hak penghapusan dipisahkan? |
| Kesalahan ditemukan berminggu-minggu kemudian | Apakah titik itu masih disimpan? | Apakah retensi mencakup keterlambatan penemuan? |
Periksa konsistensi aplikasi
Disk dapat menangkap file saat aplikasi masih mengubahnya. Bergantung pada perangkat lunak dan proses snapshot, hasilnya mungkin merepresentasikan keadaan yang konsisten dengan crash alih-alih keadaan aplikasi yang terkoordinasi. Jangan mengasumsikan bahwa file yang dapat dibaca berarti database dan unggahan terkaitnya sesuai. Gunakan metode backup yang didokumentasikan oleh aplikasi atau database.
Desain pengarsipan berkelanjutan PostgreSQL menggambarkan perbedaannya: pemulihan memerlukan base backup yang sesuai dan urutan berkelanjutan dari file write-ahead log yang diperlukan. Direktori yang disalin secara sembarangan saat database berjalan bukan prosedur yang setara. Jika aplikasi juga menyimpan file di luar database, rencanakan bagaimana kedua kumpulan data tersebut dipulihkan bersama.
Perlakukan retensi sebagai jendela pemulihan
Retensi harus memperhitungkan berapa lama kesalahan dapat tidak disadari. Jendela sepuluh hari tidak membantu penghapusan tidak sengaja yang ditemukan setelah sebulan. Menyimpan setiap salinan tanpa batas waktu menciptakan masalah lain: biaya, paparan data sensitif yang terus bertambah, dan kebijakan penghapusan yang tidak jelas. Pilih retensi dari persyaratan operasional dan penanganan data yang konkret.
Beri label titik pemulihan dengan konteks yang berguna, seperti versi aplikasi dan waktu pekerjaan yang selesai, tanpa menyematkan rahasia. Simpan riwayat yang cukup untuk membedakan keadaan yang baik dari yang rusak. Sebelum pemangkasan, konfirmasi bagaimana sistem yang dipilih menangani data bersama atau inkremental; menghapus titik berlabel mungkin tidak sama dengan menghapus file mandiri yang sederhana.
Pisahkan pekerjaan yang berhasil dari data yang terverifikasi
Alat backup yang melaporkan keberhasilan menetapkan bahwa prosesnya selesai sesuai aturannya. Ini tidak secara otomatis membuktikan bahwa semua data aplikasi penting telah dipilih, setiap byte yang disimpan tetap utuh, atau server baru dapat menggunakan hasilnya. Itu adalah pemeriksaan yang berbeda. Sertakan kesehatan repositori, tinjauan pemilihan, dan pemulihan representatif dalam rencana operasional.
Restic mendokumentasikan perbedaan antara pemeriksaan repositori defaultnya dan verifikasi yang membaca data pack yang disimpan. Pemeriksaan pembacaan data penuh dapat menghabiskan lebih banyak waktu dan bandwidth. Contoh itu membuat poin perencanaannya konkret: tentukan apa yang sebenarnya dibaca verifikasi dan anggarkan pekerjaannya. Gunakan dokumentasi alat alih-alih mengasumsikan setiap perintah bernama check memiliki cakupan yang sama.
Uji pemulihan kecil yang lengkap
Bayangkan sebuah publikasi dengan database, gambar yang diunggah, dan konfigurasi. Pulihkan ketiganya ke lingkungan pengujian privat, lalu buka artikel dan verifikasi lampirannya. Nonaktifkan integrasi email terjadwal, pembayaran, dan penerbitan selama latihan. Menguji hanya file teks acak akan melewatkan hubungan yang membuat aplikasi berguna.
Ukur waktu yang diperlukan dan catat kredensial, versi paket, atau dependensi eksternal mana yang hilang. Tinjau izin pada file yang dipulihkan, bukan hanya isinya. Latihan pemulihan sering menemukan bahwa data ada tetapi instruksi atau akses yang diperlukan untuk menggunakannya belum pernah disimpan bersama rencana operasional.
Baca backup opsional sebagai layanan tertentu
Saat mengonfigurasi SwissOctet, lihat opsi backup yang tepat dan periode retensi untuk keluarga tersebut. Tanyakan volume dan data aplikasi mana yang dicakupnya, apakah pemulihan bersifat swalayan, dan apa yang terjadi ketika konfigurasi utama berubah. Label opsi saja tidak menetapkan salinan independen, repositori yang tidak dapat diubah, atau titik pemulihan yang konsisten dengan database.
Gunakan snapshot jika sesuai dengan beban kerja dan pertahankan strategi backup yang lebih luas untuk kegagalan yang tidak dicakupnya. Catat jalur pemulihan independen untuk data penting, lindungi kredensial yang dapat menghapus salinan, dan uji prosedurnya. Pilihan terkuat adalah yang bertahan dari skenario yang Anda tentukan, bukan yang namanya paling meyakinkan.
Daftar periksa praktis Anda.
- Identifikasi di mana data yang dapat dipulihkan berada.
- Daftarkan kegagalan yang harus diatasi salinan.
- Gunakan metode konsistensi yang didukung aplikasi.
- Pilih retensi untuk jendela penemuan.
- Lindungi hak penghapusan secara terpisah.
- Pulihkan aplikasi lengkap secara terisolasi.
Detail yang penting.
Apakah snapshot tidak pernah menjadi backup?+
Beberapa implementasi snapshot adalah backup. Perbedaan yang berguna adalah ketergantungan penyimpanan, retensi, model akses, dan pemulihan yang teruji, bukan labelnya saja.
Apakah pemeriksaan integritas yang berhasil membuktikan aplikasi akan berfungsi?+
Itu hanya membuktikan apa yang dicakup pemeriksaan tersebut. Uji pemulihan aplikasi, konfigurasi, izin, dan hubungan data secara terpisah.
Haruskah saya menyimpan backup di server yang sama?+
Salinan di server yang sama dapat membantu untuk kesalahan terbatas tetapi berbagi kegagalan penting. Data penting memerlukan jalur pemulihan di luar batas kegagalan yang ingin Anda atasi.
Kunjungi sumbernya.
Referensi ini mendukung konsep teknis dalam panduan ini. Ikuti dokumentasi terkini sebelum mengubah sistem produksi.
- Amazon EBS: Snapshot docs.aws.amazon.com
- PostgreSQL: Pengarsipan berkelanjutan dan pemulihan titik waktu www.postgresql.org
- Restic: Bekerja dengan repositori dan pemeriksaan integritas restic.readthedocs.io
Panduan editorial oleh SwissOctet. Contoh bersifat ilustratif. Spesifikasi layanan, opsi yang tersedia, dan ketentuan kontraktual harus diverifikasi secara terpisah.