Uji Pemulihan Sebelum Mengandalkan pg_dump

Banyak sistem yang saya audit menjalankan pg_dump setiap malam dan menyimpan berkas bertanggal. Prosedur itu menghasilkan salinan, tetapi kesiapan pemulihannya belum terbukti sebelum salinan diuji.

Berkas yang muncul setiap malam menunjukkan bahwa proses menulis hasil. Tim masih perlu membuktikan bahwa hasil tersebut dapat dipulihkan menjadi basis data yang berfungsi bersama aplikasi.

Membuktikan kesiapan dump melalui uji pemulihan

Uji pemulihan menemukan kegagalan yang tidak terlihat dari nama dan ukuran berkas: dump terpotong, versi pg_restore tidak sesuai, peran atau ekstensi hilang, serta pekerjaan yang menyalin basis data salah. Berkas terbaru saja belum menyingkirkan kemungkinan tersebut.

Jadwalkan pemulihan dump terbaru ke lingkungan uji terpisah. Periksa migrasi aplikasi, jumlah baris tabel penting, serta beberapa kueri dengan hasil yang diketahui. Kegagalan perlu menjadi insiden yang ditindaklanjuti karena kesiapan pemulihan sistem produksi belum terbukti.

Pengujian itu sekaligus melatih prosedur pemulihan. Ketika insiden nyata terjadi, tim menggunakan skrip yang sudah diuji dan memahami langkahnya.

Basis data saja bukan seluruh data

Aplikasi menyimpan baris dan berkas: PDF tagihan, foto tamu, lampiran insiden, serta dokumen pindai. Basis data menyimpan referensinya, sementara penyimpanan objek menyimpan isi berkas.

Rezim pencadangan yang hanya mencakup PostgreSQL menghasilkan pemulihan berupa basis data penuh pointer ke berkas yang sudah tidak ada. Pemulihannya sukses di atas kertas. Kenyataannya, data hilang.

Berkas yang dirujuk baris basis data adalah bagian dari data, titik. Cakupan pencadangan harus memasukkan penyimpanan objek, disalin atau disimpan dalam versi terpisah dengan jadwal dan retensi yang sama dengan basis data, dan uji pemulihan harus memverifikasi kedua sisi bersamaan. Sistem seperti platform manajemen hotel menghasilkan media terus-menerus. Foto status kamar itu bukti, bukan hiasan — kehilangannya masalah bisnis, meski semua baris selamat.

Retensi dan target waktu pemulihan

Dua angka mendefinisikan rezim pencadangan. Keduanya harus keputusan, bukan kebetulan:

• Berapa banyak data yang rela hilang? Jarak antarpencadangan adalah data yang secara implisit disetujui untuk hilang. Dump malam berarti sampai 24 jam raib. Jika itu tidak dapat diterima, bandingkan pencadangan lebih sering dengan pengarsipan WAL, catatan perubahan basis data, dan pemulihan ke titik waktu tertentu. Uji metode yang dipilih terhadap batas kehilangan data.
• Berapa lama rela down? Ukur pemulihan-nya, jangan diperkirakan. Pemulihan logical — menjalankan ulang ekspor isi basis data berbentuk perintah SQL — pada basis data besar makan berjam-jam; pembangunan ulang index yang mendominasi, dan biasanya orang baru tahu ini justru saat outage. Jika waktu terukur melebihi target, evaluasi pencadangan fisik serta alat seperti pgBackRest, lalu ukur kembali waktu pemulihannya.

Retensi menjawab pertanyaan berbeda: seberapa jauh Anda bisa mundur saat korupsi data diketahui terlambat? Deploy buruk yang diam-diam merusak data bisa tak terdeteksi berminggu-minggu. Bentuk praktisnya: rolling window harian plus snapshot mingguan dan bulanan yang hidup lebih lama.

Verifikasi sambungannya terus-menerus

Di antara dua bencana, data bergeser. Baris terhapus tanpa berkasnya, berkas terupload tanpa barisnya, script cleanup kebablasan. Job rekonsiliasi periodik menjaga kedua penyimpanan tetap jujur:

Daftarkan berkas yang dirujuk basis data dan berkas yang tersedia pada penyimpanan, lalu bandingkan keduanya. Jalankan pemeriksaan berkala, misalnya mingguan, dan kirim peringatan ketika jumlah berkas hilang bertambah.

Cadangkan data yang tidak dapat dibuat ulang

Urutan prioritas lahir dari satu pertanyaan: kalau server ini lenyap, apa yang tidak bisa kita buat ulang? Kode ada di git. Kontainer dapat dibangun ulang dari Dockerfile jika sumber dan dependensinya tersedia. Paket dapat dipasang kembali jika versi yang diperlukan masih dapat diperoleh.

Yang tidak bisa diciptakan ulang: basis data, berkas yang diupload, sertifikat TLS dan secret, plus tumpukan keputusan konfigurasi kecil yang menumpuk bertahun-tahun. Himpunan tak tergantikan itulah cakupan pencadangan — dan selalu lebih besar dari sekadar PostgreSQL.

Siapkan lingkungan pemulihan uji, jadwalkan pengujian serta rekonsiliasi, dan tindak lanjuti kegagalannya. Dengan langkah ini, kesiapan pemulihan dapat dinilai dari hasil yang terukur.

Pemulihan ke lingkungan baru juga perlu memeriksa konfigurasi aplikasi. Zona waktu, misalnya, dapat mengubah hasil laporan. Karena itu, saya memasukkan pengelompokan data lintas zona waktu ke daftar kueri uji pemulihan.