Belajar pgBackRest - Testing Restore (Drill)

#Pendahuluan

Di episode 9 kita melatih recovery manual — sekarang kita naik level: menjadikan pengujian restore sebagai rutinitas terjadwal. Ini perbedaan antara tim yang "punya backup" dan tim yang "tahu backup-nya bekerja". Banyak organisasi baru menyadari backup mereka rusak justru saat membutuhkannya — dan saat itulah segalanya sudah terlambat.

Filosofi episode ini sederhana dan tanpa kompromi: backup yang tidak pernah di-restore bukanlah backup. Ia adalah harapan yang disamarkan sebagai rencana.

#Mengapa Restore Test Itu Penting

#Kegagalan yang Tidak Terlihat oleh Backup

Backup bisa sukses selama bertahun-tahun — log bersih, info tampak sehat — tetapi restore tetap gagal. Penyebabnya beragam: file backup terkorupsi diam-diam, WAL yang terlewat, kompresi yang rusak, atau konfigurasi yang berubah setelah backup dibuat. Hanya membongkar dan menjalankan yang membuktikan semuanya utuh.

#Konsep "Believe Nothing, Verify Everything"

Setiap drill adalah bukti: backup yang diambil hari ini, benar-benar bisa menghidupkan database besok. Ini bukan latihan yang menyenangkan — ini audit kejujuran terhadap sistem yang kalian bangun di 15 episode sebelumnya.

#Melakukan Restore Test ke Instance Terpisah

#Prinsip: Jangan Sentuh Production

Drill dilakukan ke instance terpisah — direktori PGDATA yang berbeda, port berbeda, dan bukan host yang sama dengan production. Tujuannya menguji backup, bukan merusak environment yang sehat.

#Prosedur Drill Dasar

sudo mkdir -p /var/lib/postgresql/drill
sudo chown postgres:postgres /var/lib/postgresql/drill
sudo -u postgres pgbackrest --stanza=main --delta \
  --pg1-path=/var/lib/postgresql/drill restore

Sesuaikan port di postgresql.conf hasil restore agar tidak bentrok dengan production:

sudo -u postgres sed -i "s/^port = .*/port = 5433/" /var/lib/postgresql/drill/postgresql.conf

Lalu start instance drill:

sudo -u postgres /usr/lib/postgresql/16/bin/pg_ctl -D /var/lib/postgresql/drill -l /tmp/drill.log start

#Validasi Data: Checksum dan Row Count

Restore yang "berhasil start" belum cukup. Validasi data dengan tiga lapis:

#1. Row Count

SELECT count(*) FROM aplikasi.pelanggan;
SELECT count(*) FROM aplikasi.pesanan;

Bandingkan dengan angka yang dicatat saat produksi (bisa dari query harian atau dari backup sebelumnya).

#2. Checksum Data

Jalankan validasi blok di level PostgreSQL:

SET default_table_access_method = heap;
SELECT sum(hashtextextended(row_to_json(t)::text, 0))
FROM aplikasi.pelanggan t;

Atau gunakan pg_checksums untuk memvalidasi integritas file data:

sudo -u postgres /usr/lib/postgresql/16/bin/pg_checksums -c -D /var/lib/postgresql/drill

#3. Query Bisnis Sampel

Jalankan beberapa query yang merepresentasikan workload nyata — transaksi terbaru, laporan harian, pencarian. Jika hasilnya masuk akal, data pulih dengan benar.

#Mengotomatiskan Drill

#Skrip Drill + Report

Drill bulanan harus bisa dijalankan satu perintah dan menghasilkan laporan. Skrip inti:

#!/usr/bin/env bash
set -euo pipefail
 
stanza="main"
drill_dir="/var/lib/postgresql/drill"
report="/var/log/pgbackrest/drill-report.txt"
 
rm -rf "$drill_dir"
mkdir -p "$drill_dir"
chown postgres:postgres "$drill_dir"
 
sudo -u postgres pgbackrest --stanza="$stanza" --delta \
  --pg1-path="$drill_dir" restore
 
sudo -u postgres /usr/lib/postgresql/16/bin/pg_ctl \
  -D "$drill_dir" -l /tmp/drill.log start
 
result=$(sudo -u postgres psql -p 5433 -d aplikasi -tAc \
  "SELECT 'row_count=' || count(*) FROM pelanggan;")
 
echo "=== PGBACKREST DRILL REPORT ===" > "$report"
echo "tanggal: $(date -Is)" >> "$report"
echo "stanza: $stanza" >> "$report"
echo "hasil: $result" >> "$report"
echo "=== SELESAI ===" >> "$report"
 
sudo -u postgres /usr/lib/postgresql/16/bin/pg_ctl -D "$drill_dir" stop -m fast

Jadwalkan bulanan via systemd timer, dan buat alert (episode 14) yang terpicu jika script gagal atau report tidak mengandung row_count=.

#Report sebagai Bukti Audit

Simpan report dalam direktori yang di-archive (misal S3, episode 12). Report ini menjadi bukti audit bahwa recovery memang diuji — penting untuk tim yang tunduk pada kepatuhan (SLA, ISO, HIPAA, dsb.).

#Dokumentasi Runbook

Runbook adalah dokumen yang menyelamatkan malam saat on-call. Struktur yang wajib ada:

1. Gejala — daftar skenario: cluster korup, disk mati, kehilangan PGDATA, PITR meleset.
2. Langkah recovery langkah demi langkah — perintah persis, bukan arahan samar.
3. Verifikasi — cara membuktikan recovery sukses (row count, checksum, query sampel).
4. Rollback — apa yang dilakukan jika langkah ternyata salah (misal restore ke waktu yang keliru).
5. Kontak & eskalasi — siapa yang dihubungi dan kapan.

## Skenario: Kehilangan PGDATA
 
1. Stop service: systemctl stop postgresql
2. Hapus PGDATA: rm -rf /var/lib/postgresql/16/main
3. Restore: sudo -u postgres pgbackrest --stanza=main --type=immediate restore
4. Start: systemctl start postgresql
5. Verifikasi: psql -c "SELECT count(*) FROM aplikasi.pelanggan;" (harus = 10420)
6. Jika tidak cocok: hubungi DBA senior sebelum melanjutkan

#Penutup

Inti yang harus dibawa pulang:

• Restore test berkala ke instance terpisah adalah satu-satunya cara membuktikan backup bekerja.
• Validasi tiga lapis: row count, checksum, dan query bisnis — jangan hanya "server bisa start".
• Otomasi drill dengan skrip + report; archive report sebagai bukti audit.
• Alert ketika drill gagal — kegagalan drill adalah kegagalan sistem backup.
• Runbook yang jelas, lengkap, dan sudah diuji oleh orang lain.

Di episode 17 selanjutnya kita akan mengikuti perkembangan versi: v2.59.0 & fitur terbaru — rilis 20 Juli 2026 dengan dukungan PostgreSQL 17/18, perbaikan-perbaikan pentingnya, serta jejak rilis 2.56 (perbaikan S3) dan 2.54 (backup dari standby). Menjaga pgBackRest tetap ter-update adalah bagian dari menjaga backup kalian tetap andal!