Belajar pgBackRest - WAL Archiving & Archive Command

#Pendahuluan

Backup full, differential, dan incremental di episode 5 memberi kalian "snapshot". Tetapi snapshot hanya berguna sampai batas tertentu: apa yang terjadi pada data yang berubah setelah snapshot terakhir? Jawabannya ada di WAL archiving — mekanisme yang membuat pgBackRest mampu memulihkan database ke titik waktu mana pun, bukan sekadar ke titik backup.

Ini bedanya backup "hanya snapshot" dengan backup "point-in-time". Di episode 6 kita membedah cara kerja archive_mode, archive_command, dan pasangannya archive-get — plus opsi async untuk mengurangi dampak latensi pada workload tulis berat.

#WAL: Log yang Menjadi Kunci Recovery

Sebelum membahas archiving, pahami apa yang diarsipkan. PostgreSQL menulis WAL (Write-Ahead Log) untuk setiap transaksi sebelum menulis ke file data. WAL dirotasi dalam segmen-segmen (default 16 MB) — dan segmen-segmen inilah yang diarsipkan. Rangkaian WAL yang lengkap memungkinkan PostgreSQL "memutar ulang" riwayat perubahan untuk mencapai kondisi di titik waktu tertentu.

#Mengaktifkan WAL Archiving

#Parameter di postgresql.conf

Dua parameter wajib diaktifkan agar archiving berjalan:

archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
archive_timeout = 60

• archive_mode = on — mengaktifkan archiving (dibaca saat start; butuh restart).
• archive_command — perintah yang dijalankan setiap kali segmen WAL dirotasi.
• archive_timeout = 60 — memaksa rotasi WAL setiap 60 detik jika server idle, sehingga repository selalu menerima WAL secara berkala (mengurangi data yang hilang saat crash).

Perhatikan %p: ini path lengkap WAL yang sedang diarsipkan. pgBackRest menyalinnya ke repository, mengompresinya, dan mencatat metadata.

#Apa yang Terjadi saat Restart

Setelah mengubah postgresql.conf, restart PostgreSQL:

sudo systemctl restart postgresql

Cek bahwa archiving aktif:

SELECT * FROM pg_stat_archiver;

Kolom archived_count yang bertambah berarti WAL berhasil diarsipkan ke repository. Ini pemeriksaan cepat yang sangat berguna di episode 15 saat WAL stuck.

#archive-push dan archive-get: Dua Arah WAL

#archive-push: WAL Masuk

Saat PostgreSQL memanggil archive-push %p, pgBackRest menyimpan WAL ke repository stanza. Jika gagal (misalnya repository penuh), archive_command mengembalikan status gagal dan PostgreSQL mengulanginya sampai sukses — inilah alasan repository penuh adalah masalah serius yang harus dimonitor (episode 14).

#archive-get: WAL Keluar saat Restore

Saat restore dijalankan, pgBackRest perlu "memutar ulang" WAL. Untuk itu PostgreSQL butuh restore_command — dan di sini ada keuntungan besar: pgBackRest menyuntikkan restore_command secara otomatis saat restore. Kalian tidak perlu menulisnya manual. Arah WAL ini disebut archive-get:

pgbackrest --stanza=main archive-get %f "%p"

%f adalah nama segmen WAL yang diminta, %p adalah tempat ia ditulis saat diputar ulang. Karena diatur otomatis, kalian hanya perlu fokus pada archive-push di sisi primary.

#Memvalidasi dengan pgbackrest check

pgbackrest check menguji kedua arah sekaligus: ia mengarsipkan file uji (archive-push) lalu mengambilnya kembali (archive-get). Jika salah satu arah gagal, output check akan menunjukkan di titik mana rantai putus:

P00   INFO: check command end: completed successfully

Jika archive-push gagal karena WAL belum aktif, check menampilkan error yang jelas — biasanya mengarahkan kalian kembali ke archive_mode atau archive_command di atas.

#Archive-push Async: Mengurangi Latensi

#Masalah dengan Mode Sinkron

Setiap kali segmen WAL dirotasi, PostgreSQL menunggu archive_command selesai sebelum menandai WAL "terarsipkan". Pada workload tulis tinggi, latensi network/kompresi ke repository bisa memperlambat rotasi WAL dan menekan performa.

#Solusi: Async

Mode async memisahkan proses pengarsipan: archive_command hanya menulis WAL ke spool lokal (cepat), sementara process background pgBackRest mengirimkannya ke repository belakangan. Hasilnya: WAL archiving tidak lagi jadi bottleneck.

[global]
repo1-path = /var/lib/pgbackrest
async-archiving = y
spool-path = /var/spool/pgbackrest

Perlu direktori spool yang dimiliki postgres:

sudo mkdir -p /var/spool/pgbackrest
sudo chown -R postgres:postgres /var/spool/pgbackrest

#Memantau WAL di Repository

Cek jumlah WAL yang sudah diarsipkan per stanza:

sudo -u postgres pgbackrest info

Baris wal archive min/max menunjukkan rentang segmen WAL yang tersimpan. Rentang yang terus maju berarti archiving berjalan normal. Jika rentang berhenti, ada yang salah — inilah alarm pertama yang harus kalian pasang di episode 14.

#Penutup

Inti yang harus dibawa pulang:

• archive_mode=on + archive_command='pgbackrest --stanza=main archive-push %p' adalah jembatan WAL ke repository.
• archive-get (restore_command) disuntikkan otomatis saat restore — arah keluar WAL.
• pgbackrest check memvalidasi archive-push dan archive-get sekaligus.
• WAL yang gagal diarsipkan akan diulang PostgreSQL sampai sukses — pantau agar tidak menumpuk.
• Async archiving (spool-path + async-archiving) mengurangi latensi untuk workload tulis tinggi.

Di episode 7 selanjutnya kita akan mempercepat segalanya: parallelism dan kompresi — cara kerja process-max, dampaknya pada backup/restore di CPU banyak, pemilihan compress-type=zst (default zstd) dengan level kompresi, hingga delta backup yang hanya menyalin bagian file yang berubah. Backup pertama kalian akan terasa jauh lebih cepat!