Belajar pgBackRest - Scale: Database Besar & Delta Optimization

#Pendahuluan

Semua yang kita pelajari bekerja indah untuk database kecil-menengah. Tetapi saat data menembus ratusan gigabyte hingga terabyte, aturan main berubah: satu file besar, banyak file kecil, bandwidth terbatas, dan jendela backup yang sempit. Di episode 19 kita membawa pgBackRest ke skala itu — dengan parallelism yang diukur, delta optimization, dan benchmark yang mengubah intuisi menjadi angka.

Filosofi episode ini: optimasi tanpa pengukuran adalah opini. Setiap keputusan — berapa process-max, apakah perlu level kompresi lebih tinggi, kapan pakai --delta — harus didukung data dari benchmark kalian sendiri.

#Parallel Backup untuk Data Terabyte

#Mengapa Data Besar Berbeda

Pada database terabyte, waktu backup ditentukan oleh:

• Jumlah file: ribuan relasi → parallelism banyak membantu.
• Ukuran file terbesar: satu relasi 200 GB hanya bisa diproses satu process (satu file = satu process).
• I/O dan network: lebih cepat jenuh daripada CPU.

#Menemukan Titik Manis process-max

Uji bertahap pada database yang sama di window yang sama:

sudo -u postgres pgbackrest --stanza=main --process-max=2 backup --type=diff
sudo -u postgres pgbackrest --stanza=main --process-max=4 backup --type=diff
sudo -u postgres pgbackrest --stanza=main --process-max=8 backup --type=diff

Catat durasi setiap percobaan (ada di output command). Kurva khasnya: durasi turun lalu mendatar — di titik mendatar itulah bottleneck pindah dari CPU ke I/O/network, dan menambah process-max tidak lagi membantu.

#Menyelaraskan dengan Resource Server

process-max yang terlalu tinggi mengganggu workload produksi. Dua strategi:

• Jadwal off-peak: jalankan backup dengan process-max besar saat traffic rendah (episode 10).
• Per-perintah: --process-max yang lebih rendah di jam sibuk, lebih tinggi di window backup — tanpa mengubah config:

sudo -u postgres pgbackrest --stanza=main --process-max=16 backup --type=full

#Delta Optimization: Restore yang Cepat

#Kembali ke --delta

Untuk database besar, full restore (menyalin semua file dari repository) bisa memakan waktu berjam-jam. --delta (episode 8) mengubah permainan: ia membandingkan file lokal dengan backup dan hanya menimpa yang berbeda. Untuk cluster yang sebagian besar masih utuh, ini bisa memangkas RTO secara dramatis.

sudo -u postgres pgbackrest --stanza=main --delta restore

#Memaksimalkan Efek Delta

Agar --delta bekerja optimal:

• Jangan hapus PGDATA dulu — file yang masih bagus dipertahankan dan diverifikasi.
• Pastikan checksum aktif (data_checksums=on) sehingga delta membandingkan dengan percaya diri.
• Untuk PITR ke titik jauh, --delta tetap dipakai — ia hanya mempercepat penyalinan file, bukan mengubah logika recovery.

#Kombinasi dengan Backup Standby

Di cluster HA (episode 18), delta restore menjadi senjata andalan bootstrap node baru: restore ke PGDATA existing, lalu streaming catch-up dari primary. Waktu untuk menumbuhkan node turun dari "jam" ke "menit".

#Benchmark: Duration vs Ukuran Database

#Membuat Benchmark yang Valid

Benchmark yang baik punya tiga ciri: variabel tunggal, data nyata, dan diulang. Rancang tabel pencatatan:

CREATE TABLE bench_backup (
  dt timestamptz default now(),
  db_size_gb numeric,
  type text,
  process_max int,
  duration_sec numeric
);

Lalu catat setiap backup dengan query ke pg_database_size:

psql -U postgres -tAc \
  "INSERT INTO bench_backup (db_size_gb, type, process_max, duration_sec)
   VALUES (round(pg_database_size('aplikasi')/1e9,2), 'full', 8, $DURATION);"

#Membaca Hasil

Plot durasi terhadap ukuran untuk tiap tipe. Pola yang harus kalian pahami:

• Full: linear terhadap ukuran — setiap terabyte menambah durasi hampir konstan.
• Differential/Incremental: durasi ditentukan perubahan, bukan total ukuran — itulah mengapa jadwal full+diff (episode 10) memakai bandwidth jauh lebih hemat.
• Restore: linear terhadap ukuran + waktu replay WAL; PITR jauh menambah waktu.

Ukuran (GB)  Full (mnt)  Diff (mnt)  Restore (mnt)
  250          18          4            21
  500          36          5            42
 1000          72          6            85

Dari data ini, perkiraan RTO di episode 10 bisa dihitung bukan dengan tebakan: jika restore 1 TB butuh 85 menit, RTO kalian minimal di angka itu.

#Optimasi Berurutan yang Terbukti

Untuk database besar, urutan optimasi yang paling efektif:

1. Delta backup: kurangi data yang ditulis (episode 7) — efek terbesar.
2. Parallelism: percepat proses (episode 7 + episode ini).
3. Kompresi: kecilkan ukuran di repository (level menengah, bukan ekstrem).
4. Jadwal cerdas: full+diff, off-peak (episode 10).
5. Restore delta: perkecil RTO (episode 8 + episode ini).

#Penutup

Inti yang harus dibawa pulang:

• Parallel backup memakai banyak process; temukan titik mendatar dengan uji bertahap, bukan tebakan.
• process-max tinggi di window off-peak; lebih rendah saat produksi ramai.
• --delta restore memangkas RTO untuk cluster yang sebagian besar utuh.
• Benchmark: ukur durasi vs ukuran untuk full, diff, dan restore — simpan historinya.
• Optimasi berurutan: delta backup → parallelism → kompresi → jadwal → delta restore.

Di episode 20 selanjutnya kita akan membawa pgBackRest ke dunia container dan cloud: integrasi Docker, K8s & cloud — pola sidecar pgBackRest dengan operator CloudNativePG di Kubernetes, Docker image dengan config mount, serta backup ke S3/GCS/Azure Blob dengan IAM role versus static key. Backup kini bagian dari platform, bukan lagi server terpencil!