Belajar pgBackRest - Sejarah, Latar Belakang & Mengapa Membutuhkannya

#Pendahuluan

Setelah environment kita siap di episode 0, sekarang waktunya memahami mengapa pgBackRest ada. Setiap teknologi besar lahir karena masalah nyata, dan pgBackRest tidak terkecuali. Di episode 1 kita menelusuri sejarahnya dari inisiasi Crunchy Data tahun 2014, keterbatasan pendekatan lama yang rapuh, hingga alasan konkret mengapa tool backup berbasis file dan WAL ini menjadi standar de facto di ekosistem PostgreSQL.

Pertanyaan yang akan kita jawab: mengapa pg_basebackup + skrip WAL archiving manual tidak cukup? Mengapa memilih pendekatan physical backup alih-alih logical backup? Dan fitur apa yang membuat pgBackRest layak dipakai untuk database besar di production?

#Sejarah dan Latar Belakang

#Lahir dari Keterbatasan pg_basebackup

Sebelum pgBackRest, backup PostgreSQL umumnya dilakukan dengan pg_basebackup lalu dilengkapi skrip manual untuk WAL archiving. Pola ini bekerja untuk database kecil, tetapi rapuh dalam tiga hal: backup berjalan serial (lambat untuk database besar), tidak ada deduplikasi antar backup (setiap full backup menyimpan semuanya), dan pemulihan point-in-time sangat bergantung pada skrip shell yang ditulis sendiri — rawan salah dan sulit di-debug.

pgBackRest dikembangkan oleh Crunchy Data (2014) untuk menjawab masalah itu: satu tool yang mengelola full/differential/incremental backup, WAL archiving, dan restore secara terpadu — tanpa mengorbankan kecepatan.

#Filosofi: Physical Backup Berbasis File

Perbedaan mendasar dengan pg_dump adalah pendekatannya. pg_dump adalah logical backup — mengekspor data sebagai SQL, tidak bisa melakukan PITR, dan lambat untuk volume besar. pgBackRest memilih physical backup: menyalin file data dan WAL, sehingga bisa memulihkan seluruh cluster (termasuk user, permission, dan data yang tidak tersimpan dalam SQL) ke titik waktu yang presisi.

#Perkembangan dan Status Saat Ini

Sejak lahir, proyek ini terus aktif. Awalnya didanai Crunchy Data, kini di-sponsori komunitas dengan kontributor luas dan kini mencapai v2.59.0 (rilis 20 Juli 2026). Stabilitas dan fokus pada reliability membuatnya dipakai di mana-mana — termasuk sebagai mesin backup bawaan CloudNativePG di Kubernetes (episode 20).

Cek versi terpasang

pgbackrest version

Note

pgBackRest mendukung hingga 10 versi PostgreSQL sekaligus dalam satu instalasi (termasuk versi yang sudah EOL). Ini penting di dunia nyata: tim migrasi sering punya beberapa versi PostgreSQL berjalan bersamaan, dan satu tool yang bisa menangani semuanya menyederhanakan operasional.

#Mengapa Membutuhkan pgBackRest

#Backup Parallel dan Kompresi

Backup database besar bukanlah satu operasi serial. pgBackRest membagi pekerjaan menjadi banyak process yang menyalin dan mengompresi file secara paralel — untuk database terabyte, ini membedakan backup berjam-jam menjadi menit. Detailnya kita bedah di episode 7.

#WAL Archiving Terus-menerus

Ini fitur yang membedakan pgBackRest dari sekadar "snapshot". Setiap kali PostgreSQL menulis WAL, file tersebut diarsipkan ke repository lewat archive_command:

archive_command di postgresql.conf

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

Hasilnya, repository selalu memiliki rangkaian WAL yang kontinu — memungkinkan restore ke titik waktu mana pun, bukan hanya ke titik backup terakhir.

#Restore PITR yang Presisi

Dengan kombinasi physical backup + WAL kontinu, kalian bisa memulihkan database ke kondisi sebelum kejadian buruk (misalnya DROP TABLE yang tidak sengaja) dengan presisi waktu, LSN, atau restore point:

Restore ke waktu tertentu (PITR)

pgbackrest --stanza=main --type=time '2026-08-13 09:30:00+07' restore

Kita akan mempraktikkan semua tipe restore (immediate, time, lsn, name) di episode 8.

#Retention Policy

Tanpa retention, repository akan penuh dalam hitungan minggu. pgBackRest mengelola retention secara otomatis: full backup terbaru dipertahankan, backup lama dan WAL yang tidak lagi dibutuhkan di-expire sesuai aturan yang kalian tetapkan — misalnya repo1-retention-full=2 berarti selalu menyisakan 2 full backup. Kita bahas di episode 5 dan 10.

#Dukungan Repository Beragam

pgBackRest mendukung repository di disk lokal, host remote via SSH, hingga object storage S3-compatible — satu konfigurasi yang sama bisa menargetkan semuanya, sehingga off-site backup (episode 12) bukan proyek besar.

#Posisi di Ekosistem Backup PostgreSQL

Untuk memposisikan pgBackRest, ingatlah empat arus utama:

pg_dump: logical backup, cocok untuk migrasi, bukan untuk recovery cepat.
pg_basebackup: dasar physical backup bawaan, tanpa manajemen WAL dan retention.
Barman: arsitektur server-based dari 2ndQuadrant, solid untuk skenario khusus.
WAL-G / WAL-G2: object storage-first, ringan, tetapi fitur PITR dan reporting lebih sedikit.

Perbandingan menyeluruh kita tutup di episode 22.

#Penutup

Inti yang harus dibawa pulang:

pgBackRest lahir (2014, Crunchy Data) untuk menggantikan pg_basebackup + skrip WAL archiving yang rapuh.
Ia memilih pendekatan physical backup sehingga mampu PITR penuh, bukan sekadar logical dump.
Fitur utamanya: parallel backup, kompresi, WAL archiving kontinu, PITR presisi, retention policy, dan object storage.
Mendukung hingga 10 versi PostgreSQL sekaligus; kini aktif di v2.59.0 (Juli 2026).

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama pgBackRest — apa itu stanza, repository, dan proses backup (full, differential, incremental), serta bagaimana binary pgbackrest, config /etc/pgbackrest.conf, dan archive_command bekerja sama. Inilah anatomi yang akan menjelaskan setiap perintah yang kita jalankan di episode-episode berikutnya.