Belajar pgBackRest - Parallelism & Kompresi

#Pendahuluan

Database kecil, backup berjalan "cukup cepat" apa pun yang dilakukan. Tetapi saat data tumbuh ke ratusan gigabyte atau terabyte, kecepatan backup dan restore menjadi keputusan arsitektur. Di episode 7 kita membuka dua tuas utama performa pgBackRest: parallelism (menggunakan banyak process untuk bekerja bersamaan) dan kompresi (mengecilkan ukuran di repository).

Kedua fitur ini bukan sekadar "opsi yang bagus" — untuk database besar, keduanya adalah pembeda antara backup berjam-jam dan backup beberapa menit. Di episode 19 kita akan mengukurnya dengan benchmark sungguhan.

#Parallelism: Banyak Tangan, Sedikit Waktu

#Konsep Process

pgBackRest secara default bekerja dengan satu process (process-max=1): satu file disalin, dikompresi, dan ditulis ke repository pada satu waktu. Dengan process-max lebih besar, pgBackRest membagi pekerjaan menjadi banyak process worker — masing-masing menangani file yang berbeda secara paralel.

/etc/pgbackrest.conf

[global]
process-max = 4

Nilai ini bisa dioverride per perintah:

Backup dengan 8 process

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

Perhatikan istilahnya: process-max membatasi jumlah process total. Di dalamnya, ada konsep process per file — satu file besar (misalnya relasi 50 GB) tidak bisa dibagi menjadi beberapa process sekaligus pada versi sebelum 2.47; setiap process menangani file utuh. Jadi parallelism paling efektif ketika database terdiri dari banyak file.

#Berapa Nilai yang Tepat?

Tidak ada angka ajaib. Aturan praktis:

Mulai dari 2-4 untuk server kecil, naik bertahap.
Lihat jumlah core CPU: process-max jauh di atas core tidak mempercepat — hanya menambah contention I/O.
Perhatikan bandwidth disk/network: jika menyalin ke NFS atau object storage, network mungkin jadi bottleneck, bukan CPU.

Cek jumlah core sebelum tuning

nproc

Tip

Parallelism mempercepat, tetapi memakai CPU dan I/O — pada server yang melayani beban produksi, naikkan process-max saat jendela backup (malam hari), bukan saat jam sibuk. Nilai yang diulang di konfigurasi vs per-perintah memberi kalian fleksibilitas ini.

#Kompresi: Mengecilkan Ukuran di Repository

#Algoritma dan Default

pgBackRest mendukung beberapa algoritma kompresi: zst (zstd), lz4, gz (gzip), bz2, dan none. Sejak v2.50, default-nya adalah zst (zstd) — keseimbangan rasio kompresi dan kecepatan yang sangat baik.

/etc/pgbackrest.conf

[global]
compress-type = zst
compress-level = 3

compress-type = zst — gunakan zstd (default, tetapi eksplisit tidak pernah salah).
compress-level = 3 — level kompresi; default zstd adalah 3. Semakin tinggi level, semakin kecil ukuran, semakin lambat kompresi.

Perbandingan singkat:

Type	Kecepatan	Rasio	Catatan
`lz4`	Sangat cepat	Rendah	Kompresi ringan, restore cepat
`zst`	Cepat	Bagus	Default, keseimbangan terbaik
`gz`	Sedang	Bagus	Kompatibilitas luas
`bz2`	Lambat	Tertinggi	Hemat ruang, mahal CPU

Note

Restore juga membongkar kompresi. Backup yang sangat kecil (level tinggi) mempercepat transfer network saat restore, tetapi memperlambat dekompresi di sisi CPU. Ukur trade-off ini dengan benchmark (episode 19), bukan perasaan.

#Delta Backup: Hanya Bagian yang Berubah

Fitur penting lain yang bekerja bersama kompresi dan parallelism adalah delta backup (jangan disamakan dengan differential). Saat backup berikutnya dijalankan, pgBackRest membandingkan checksum file dengan backup sebelumnya dan hanya menyimpan blok/file yang berubah — plus memanfaatkan deduplikasi antar backup (fungsionalitas block incremental sejak 2.47).

Praktisnya, ketiga fitur ini saling melengkapi:

Parallelism mempercepat proses.
Kompresi mengecilkan apa yang ditulis.
Delta/dedupe menghindari menulis ulang data yang sudah ada di repository.

Hasilnya untuk database besar: backup kedua dan seterusnya bisa jauh lebih cepat dan kecil dibanding full pertama, karena hanya perubahan yang diproses.

#Latihan: Mengukur Efek

Bandingkan durasi dan ukuran secara langsung:

Bandingkan proses-max 1 vs 4

sudo -u postgres pgbackrest --stanza=main --process-max=1 backup --type=diff
sudo -u postgres pgbackrest --stanza=main --process-max=4 backup --type=diff
sudo -u postgres pgbackrest info

Perhatikan perbedaan backup size di info: dengan dedupe, backup differential kedua harus jauh lebih kecil dari yang pertama. Inilah bukti nyata bahwa pgBackRest tidak menyalin ulang data yang tidak berubah.

Warning

Jangan hanya menaikkan process-max tanpa mengukur. Di mesin dengan sedikit core atau storage lambat, parallelism tinggi justru memperlambat karena CPU/disk berebutan. Selalu verifikasi dengan pgbackrest info dan catat durasi backup (ada di output command) sebelum dan sesudah tuning.

#Penutup

Inti yang harus dibawa pulang:

process-max membagi backup/restore menjadi banyak process paralel; sesuaikan dengan core dan bandwidth.
compress-type = zst adalah default modern (zstd); level bisa dinaikkan untuk rasio lebih tinggi.
lz4 untuk kecepatan ekstrem, bz2 untuk hemat ruang ekstrem — pilih sesuai trade-off.
Delta backup + deduplikasi blok hanya menulis data yang berubah antar backup.
Selalu ukur efeknya dengan pgbackrest info dan durasi aktual.

Di episode 8 selanjutnya kita akan membalik arah: restore — pgbackrest restore, tipe --type=immediate untuk kondisi terakhir, --type=time untuk PITR, --type=lsn, --type=name, serta --delta untuk sinkronisasi cluster yang sudah ada. Inilah momen paling penting dalam seluruh sistem backup: membuktikan bahwa backup kalian benar-benar bisa dipulihkan!