Pertanyaan dan konteks
Sebuah kluster PostgreSQL besar menginginkan jendela pencadangan penuh (full backup) yang lebih singkat dan biaya penyimpanan yang lebih rendah. Rancang rantai pencadangan basis inkremental menggunakan pg_basebackup, dengan menjelaskan dependensi WAL, manifest pencadangan, pg_combinebackup, verifikasi, retensi, dan simulasi pemulihan.
PostgreSQL menyatakan bahwa pencadangan inkremental tidak dapat dipulihkan secara langsung: pencadangan ini harus digabungkan dengan pencadangan sebelumnya yang menjadi dependensinya menjadi pencadangan penuh sintetis (synthetic full). Alat ini memeriksa relasi tetapi tidak melacak dependensi untuk Anda atau membuktikan bahwa setiap cadangan masih utuh. Wawancara ini menguji bukti keterpulihan (recoverability), bukan sekadar menghafal satu perintah pencadangan.
Hal yang diuji oleh pewawancara
Menjelaskan peran full, inkremental, WAL, dan manifest; pencadangan referensi, rantai dependensi, dan synthetic full; pg_verifybackup, checksum, versi objek yang tidak dapat diubah (immutable), dan pemeriksaan integritas; pemutusan rantai, pencadangan standby, retensi replication-slot/WAL, enkripsi, dan target pemulihan. Membuktikan RPO dan RTO melalui simulasi alih-alih mengandalkan dasbor keberhasilan pencadangan.
Pertanyaan klarifikasi di awal
Target pemulihan
Konfirmasikan RPO, RTO, titik waktu target, pemulihan lintas-wilayah, perubahan versi PostgreSQL yang diizinkan, dan apakah kluster memiliki beberapa tablespace.
Beban kerja pencadangan
Konfirmasikan ukuran penuh, volume perubahan harian, laju WAL, jendela pencadangan, bandwidth jaringan, siklus hidup penyimpanan objek, dan batas konkurensi.
Konsistensi dan kepatuhan
Konfirmasikan enkripsi pencadangan dan rotasi kunci, retensi yang tidak dapat diubah (immutable), izin penghapusan, algoritma checksum manifest, catatan audit, dan frekuensi simulasi.
Jawaban 30 detik
"Saya memulai dengan pencadangan penuh yang dapat diverifikasi, menghasilkan inkremental dari manifest referensi, dan mempertahankan setiap manifest, catatan dependensi, serta segmen WAL yang berkelanjutan. Cadangan inkremental tidak dapat dipulihkan secara langsung: saya menggabungkan rantai secara berurutan dengan pgcombinebackup, lalu menerapkan WAL yang diperlukan. Penyimpanan objek menggunakan versi yang tidak dapat diubah (immutable) dan enkripsi, sementara pgverifybackup dan uji pemulihan sampel memvalidasi kontennya. Jika ada dependensi yang hilang, otomatisasi akan memblokir penghapusan pendahulunya. Simulasi ukuran nyata dan kegagalan membuktikan RPO dan RTO daripada hanya mengandalkan tingkat keberhasilan pencadangan."
Jawaban mendalam langkah demi langkah
Langkah 1: Memodelkan rantai pencadangan
Catat pencadangan penuh, referensi pencadangan setiap inkremental, rentang LSN, manifest, versi kunci, dan URI penyimpanan. Setiap node menunjuk ke prasyaratnya; proses retensi pertama-tama menghitung titik waktu paling awal yang masih dapat dipulihkan.
Langkah 2: Menghasilkan inkremental
pg_basebackup dapat meminta pencadangan inkremental menggunakan manifest referensi; inkremental tersebut berisi blok-blok yang berubah sejak referensi tersebut. Pencadangan tetap mencakup seluruh kluster dan bukan hanya satu objek basis data. Koneksi replikasi memerlukan hak istimewa REPLICATION atau hak superuser dan walsender yang memadai.
full_0 = pg_basebackup(full)
inc_1 = pg_basebackup(incremental, reference=full_0.manifest)
inc_2 = pg_basebackup(incremental, reference=inc_1.manifest)Langkah 3: Mempertahankan WAL berkelanjutan
WAL yang dihasilkan selama pencadangan basis harus tetap tersedia. Metode stream membuka koneksi replikasi kedua secara paralel; metode fetch memerlukan wal_keep_size atau pengarsipan untuk mempertahankan WAL yang dibutuhkan hingga transfer selesai. Replication slot mengurangi risiko penghapusan prematur tetapi dapat meningkatkan penggunaan disk, jadi pantau LSN tertua yang diperlukan.
Langkah 4: Memverifikasi manifest dan relasi
pg_combinebackup memverifikasi hubungan yang sah di antara cadangan input, tetapi tidak memverifikasi integritas dari setiap cadangan. Jalankan pg_verifybackup dan checksum manifest untuk setiap node. Daftarkan node dalam katalog hanya setelah pengunggahan objek dan verifikasinya selesai.
Langkah 5: Membangun input pemulihan
Untuk titik waktu target, panggil pg_combinebackup secara berurutan mulai dari pencadangan penuh hingga inkremental target untuk menghasilkan synthetic full. Ini dapat menjadi dasar untuk operasi penggabungan berikutnya tetapi tidak menggantikan WAL. Tempatkan WAL dari LSN akhir pencadangan hingga waktu target di direktori pemulihan dan konfigurasikan target pemulihan.
Langkah 6: Menangani pemutusan rantai dan retensi
Penjadwal mengelola graf dependensi dan waktu terawal yang dapat dipulihkan. Jika suatu prasyarat hilang, gagal dalam verifikasi checksum, atau kehilangan kuncinya, tandai semua turunannya sebagai tidak dapat dipulihkan dan blokir penghapusan otomatis dari prasyarat tersebut. Buat pencadangan penuh baru atau synthetic full secara berkala untuk membatasi panjang rantai dan RTO.
Langkah 7: Melakukan simulasi RPO dan RTO
Pulihkan titik waktu acak secara terisolasi dan periksa katalog sistem, tablespace, WAL, ekstensi, serta konsistensi aplikasi. Catat byte yang diunduh, durasi penggabungan, laju replay WAL, waktu penyelesaian, dan checksum. Simulasikan error 404 penyimpanan objek, manifest yang rusak, pencabutan kunci, dan kegagalan primary.
Jawaban model
Saya memperlakukan pencadangan sebagai sebuah graf dependensi: full backup adalah root, setiap inkremental merujuk ke suatu referensi, dan WAL mengisi titik waktu target. Setiap node menyimpan manifest, checksum, LSN, versi kunci, dan URI objek yang immutable. Pemulihan menggabungkan rantai secara berurutan menggunakan pgcombinebackup, lalu memutar ulang (replay) WAL berkelanjutan; pemeriksaan relasinya tidak menggantikan pemeriksaan konten pgverifybackup. Retensi mengikuti alur graf, dan simulasi mencakup rantai yang rusak, WAL yang hilang, pencabutan kunci, dan beberapa tablespace sebelum metrik RPO/RTO yang terukur dirilis.
Kesalahan umum
- Kesalahan: Memperlakukan cadangan inkremental sebagai direktori yang dapat langsung di-boot. → Mengapa gagal: Cadangan ini bergantung pada pencadangan referensi. → Perbaikan: Gabungkan menjadi synthetic full, lalu terapkan WAL.
- Kesalahan: Hanya memercayai eksekusi pg_combinebackup yang berhasil. → Mengapa gagal: Ini tidak membuktikan bahwa setiap input dalam kondisi utuh. → Perbaikan: Verifikasi setiap manifest/checksum dan lakukan pemulihan sampel.
- Kesalahan: Mempertahankan atau menghapus pencadangan penuh hanya berdasarkan usia. → Mengapa gagal: Cadangan inkremental berikutnya mungkin masih bergantung padanya. → Perbaikan: Gunakan graf dependensi dan waktu terawal yang dapat dipulihkan.
- Kesalahan: Melaporkan keberhasilan pencadangan tanpa WAL berkelanjutan. → Mengapa gagal: Titik waktu target tidak dapat diputar ulang (replayed). → Perbaikan: Pantau LSN yang diperlukan, lag pengarsipan, dan penggunaan slot.
Pertanyaan lanjutan dan tanggapan
Apa perbedaan antara full, synthetic full, dan inkremental?
Full backup adalah salinan file kluster yang independen. Cadangan inkremental berisi blok-blok yang berubah sejak referensi. Synthetic full direkonstruksi dari rantai cadangan dan dapat menjadi input pemulihan, tetapi tetap memerlukan WAL setelah titik akhir pencadangan untuk mencapai waktu target.
Mengapa tidak memperpanjang rantai inkremental selamanya?
Rantai yang panjang meningkatkan biaya pengunduhan, penggabungan, verifikasi, dan risiko kegagalan, yang pada akhirnya meningkatkan RTO. Sisipkan full backup atau synthetic full baru berdasarkan tingkat perubahan data, biaya penyimpanan, dan data hasil simulasi.
Apa yang Anda lakukan jika sebuah manifest hilang?
Tandai node tersebut sebagai tidak tersedia untuk otomatisasi; jangan pernah menebak dependensi dari nama file. Jika salinan tepercaya berhasil memulihkan manifest, verifikasi checksum file, LSN, dan relasi rantai sebelum mendaftarkannya kembali.
Bagaimana Anda membuktikan bahwa enkripsi tidak akan menghalangi pemulihan?
Pulihkan sampel secara rutin di lingkungan terisolasi menggunakan kunci saat ini dan historis, dengan menguji rotasi, pencabutan, izin, dan akses KMS lintas-wilayah. Berikan peringatan secara eksplisit dan hapus titik waktu tersebut dari klaim keterpulihan jika kunci tidak tersedia.