Belajar pgBackRest - Backup dari Standby & HA

#Pendahuluan

Sampai episode 17, semua backup kita diambil dari primary — server yang melayani traffic. Untuk database besar, backup memakan CPU, I/O, dan bandwidth — persis sumber daya yang dibutuhkan transaksi produksi. Di episode 18 kita menyelesaikan masalah ini dengan cara yang elegan: mengambil backup dari standby (replica) — server yang tidak melayani traffic tulis.

Ini juga episode tempat pgBackRest dan high availability (HA) bertemu: backup tidak lagi menjadi beban primary, dan restore menjadi cara menumbuhkan node baru di cluster HA. Dua sistem yang biasanya diurus terpisah, kini berjalan dalam satu kesatuan.

#Backup dari Standby

#Mengapa Backup dari Standby

Primary melayani semua tulis dan baca kritikal. Menjalankan backup di sana berarti:

• I/O menyalin file data bersaing dengan I/O transaksi.
• Kompresi (episode 7) memakai CPU yang seharusnya untuk query.
• Traffic keluar memakai bandwidth.

Standby tidak punya masalah ini — ia hanya menerapkan WAL dari primary. Backup di standby = beban nol di primary.

#Prasyarat

Standby harus streaming replication aktif dari primary, dan backup (full/diff/incr) tetap konsisten karena diambil dari file data + WAL yang sama. pgBackRest memastikan konsistensi dengan memeriksa posisi WAL saat backup — konsep yang sama seperti backup dari primary.

#Konfigurasi

Pada host standby, konfigurasi stanza menunjuk ke cluster standby:

[global]
repo1-path = /var/lib/pgbackrest
 
[main]
pg1-path = /var/lib/postgresql/16/standby
pg1-standby = y

• pg1-standby = y — memberitahu pgBackRest bahwa cluster ini adalah standby, sehingga memperlakukan backup dengan cara yang sesuai.
• Untuk memicu backup dari primary lewat standby (sehingga WAL dikumpulkan dan backup diambil di standby), gunakan opsi backup-standby = y pada perintah backup:

sudo -u postgres pgbackrest --stanza=main --backup-standby backup --type=full

#Konsistensi WAL

Pertanyaan yang sering muncul: bagaimana backup standby konsisten jika file data standby selalu berubah (menerapkan WAL)?

Jawabannya: pgBackRest mencatat posisi WAL (replay location) saat backup dimulai dan selesai, lalu melengkapi backup dengan WAL yang diarsipkan hingga posisi tersebut. Hasilnya backup standby identik konsisten dengan backup primary — sama-sama mewakili kondisi database pada titik waktu tertentu. Ini yang membuat restore dari backup standby sama validnya.

#Integrasi dengan Patroni/repMgr

#Bagaimana pgBackRest Berperan

Patroni dan repMgr mengelola siapa yang jadi primary dan kapan failover terjadi. pgBackRest mengelola bagaimana data dipulihkan dan node baru dilahirkan. Keduanya saling melengkapi: Patroni memutuskan, pgBackRest menyediakan data.

#Pola Integrasi

Pola yang paling umum di cluster yang dikelola Patroni:

1. Backup terjadwal diambil dari standby (backup-standby) — beban nol di primary.
2. Restore untuk node baru: saat cluster kehilangan node atau menambah node, bootstrap dilakukan dari backup:

sudo -u postgres pgbackrest --stanza=main --delta restore
sudo -u postgres pg_ctl -D /var/lib/postgresql/16/main start
# Patroni mendeteksi node baru dan menghubungkannya ke primary

3. Daftarkan node baru agar Patroni mengenalinya (via REST API atau config), lalu biarkan ia melakukan streaming catch-up dari WAL.

Karena Patroni mengelola identitas cluster, pastikan stanza pgBackRest konsisten dengan identitas yang diharapkan Patroni — restore dari backup yang sama lalu sinkron via WAL adalah pola yang sangat umum di produksi.

#Failover: Backup Tidak Berubah Tujuan

Saat failover, standby naik menjadi primary. Konsekuensi bagi pgBackRest:

• WAL archiving kini berjalan dari node baru — pastikan archive_command benar di semua node, bukan hanya node lama.
• Backup berikutnya diambil dari node yang sekarang menjadi standby baru.

Praktik baik: stanza-create dan check di setiap node setelah failover, sehingga identitas cluster tetap sinkron:

sudo -u postgres pgbackrest --stanza=main check
sudo -u postgres pgbackrest --stanza=main info

#Restore ke Node Baru di Cluster HA

#Skenario: Menambah Kapasitas

Ketika cluster HA butuh node tambahan (atau node rusak), jangan menyalin PGDATA dari primary (mahal dan mengganggu). Gunakan backup:

# 1. buat direktori dan restore dari backup terakhir
sudo mkdir -p /var/lib/postgresql/16/main
sudo chown postgres:postgres /var/lib/postgresql/16/main
sudo -u postgres pgbackrest --stanza=main --delta restore
 
# 2. konfigurasi replica (primary_conninfo) lalu start
# 3. Patroni/repMgr mengelola pengenalan dan streaming

Node baru start sebagai standby, menerapkan WAL dari primary, dan mengejar ketertinggalan dengan cepat. Backup yang pernah diuji (episode 16) membuat proses ini bisa diprediksi.

#Latihan Mini: Konfirmasi Kesiapan

Simulasikan penambahan node di lab:

sudo -u postgres pgbackrest --stanza=main --delta \
  --pg1-path=/var/lib/postgresql/16/nodebaru restore
sudo -u postgres /usr/lib/postgresql/16/bin/pg_ctl \
  -D /var/lib/postgresql/16/nodebaru start
# verifikasi streaming: SELECT * FROM pg_stat_replication;

#Penutup

Inti yang harus dibawa pulang:

• Backup dari standby (backup-standby) memindahkan beban backup dari primary ke replica.
• pg1-standby = y memberi tahu pgBackRest bahwa cluster adalah standby.
• Konsistensi dijamin posisi WAL — backup standby valid seperti backup primary.
• Patroni/repMgr memutuskan; pgBackRest menyediakan data — bootstrap node baru dari restore.
• Setelah failover: check dan stanza-upgrade di semua node, dan pastikan archive_command benar.

Di episode 19 selanjutnya kita akan mengukur dan mengoptimalkan untuk skala: database besar & delta optimization — parallel backup untuk data terabyte, tuning process-max sesuai resource, --delta restore, dan benchmark yang membandingkan durasi backup/restore terhadap ukuran database. Optimasi dimulai dari data, bukan tebakan!