Keluarga backup logis yang kita jalani sepanjang empat chapter terakhir membangun kembali database dengan memutar ulang SQL — teliti, portabel, tetapi lambat untuk data besar. Keluarga kedua mengambil jalan yang sama sekali berbeda: menyalin file data server apa adanya, byte demi byte, sehingga pemulihannya cukup mengembalikan file itu ke tempatnya — tidak ada tabel yang dibuat ulang, tidak ada index yang disusun ulang, tidak ada constraint yang diperiksa ulang. Untuk cluster berukuran ratusan gigabyte, selisih waktunya bukan menit melainkan jam. Chapter ini membahas konsepnya: mengapa penyalinan naif tidak bisa dilakukan sembarangan, dua syarat konsistensi yang wajib dipenuhi, dan perkenalan dengan pg_basebackup — alat resmi yang menuntaskan semuanya dalam satu perintah.

Menyalin File, Bukan Menyalin Makna #

PostgreSQL menyimpan seluruh datanya sebagai file biasa di satu direktori — yang biasa disebut data directory atau PGDATA: tabel dan index di base/, katalog cluster di global/, dan jurnal transaksi (WAL) di pg_wal/. Backup fisik menduplikasi direktori ini beserta isinya. Hasilnya bukan “resep membangun database” seperti dump SQL, melainkan database itu sendiri dalam bentuk yang sama persis dengan aslinya.

Konsekuensinya menentukan karakter keluarga ini. Ukuran backup selalu seluruh cluster — tidak ada pilihan per database atau per tabel, jadi cluster berisi lima database kecil tetap menghasilkan backup sebesar kelimanya dijumlahkan. Sebaliknya, pemulihan menjadi urusan menyalin file kembali dan memutar sedikit jurnal: database raksasa kembali siap kerja dalam waktu yang ditentukan kecepatan disk, bukan kompleksitas skemanya. Granularitas kasar, RTO pendek — kebalikan persis dari backup logis di tabel strategi chapter Konsep Backup .

Kenapa cp -r Sambil Server Berjalan Itu Jebakan #

Ide pertama setiap pendatang baru sama: cp -r /var/lib/postgresql/17/main /backup & sambil server terus melayani. Hasilnya tampak berhasil — file tersalin semua — dan diam-diam rusak. Tiga alasan membuatnya begitu:

  • Halaman robek (torn pages): satu halaman 8 kB sedang ditulis server saat Anda menyalinnya; hasil salinan bisa berisi separuh tulisan lama dan separuh tulisan baru. Server asli tidak pernah menyimpan halaman seperti itu — salinan Anda iya.
  • Keadaan yang tidak pernah ada: cp menyalin file A pada detik ke-1 dan file B pada detik ke-7. Server yang sedang sibuk bertransaksi tidak pernah berada persis di keadaan “A versi detik-1 + B versi detik-7” pada satu titik waktu pun. Salinan itu merekam keadaan yang mustahil.
  • WAL yang tidak cocok: file data hanyalah bagian dari cerita — perubahan yang belum dipermanenkan ke tabel masih hidup di WAL. Salinan data tanpa WAL yang pas bahannya adalah teka-teki yang tidak bisa dirakit ulang.

Satu lapis pertahanan yang menyembunyikan masalah ini lebih cepat adalah checksum data: hash tiap halaman yang diverifikasi saat dibaca. PostgreSQL bisa mengaktifkannya hanya saat cluster dibuat (initdb --data-checksums) — bukan setelahnya. Query berikut memeriksa tiga pengaturan yang menentukan kelayakan backup fisik di server kita:

sql cek-konfigurasi.sql 
-- Tiga pengaturan yang menentukan kelayakan backup fisik di server ini.
-- wal_level=replica dan max_wal_senders>=1 dibutuhkan pg_basebackup;
-- data_checksums hanya bisa diaktifkan saat cluster dibuat (initdb).
SELECT name, setting
FROM pg_settings
WHERE name IN ('wal_level', 'max_wal_senders', 'data_checksums')
ORDER BY name;

Output yang Dihasilkan:

text 
      name       | setting 
-----------------+---------
 data_checksums  | off
 max_wal_senders | 10
 wal_level       | replica
(3 rows)

Dua baris pertama adalah kabar baik: wal_level = replica (bawaan) dan max_wal_senders = 10 berarti server siap mengirim WAL dan menerima koneksi pg_basebackup tanpa konfigurasi tambahan. Baris data_checksums = off adalah keadaan bawaan yang patut Anda ketahui: checksum tidak aktif, jadi halaman rusak di backup atau disk tidak akan terdeteksi otomatis saat dibaca. Cluster produksi yang serius umumnya memilih mengaktifkannya sejak awal.

Dua Syarat Konsistensi: Checkpoint dan WAL #

Backup fisik yang sah menjawab ketiga jebakan di atas dengan dua mekanisme. Pertama, checkpoint: server diminta memaksa seluruh keadaan memori ke file data pada satu titik yang tercatat, sehingga ada momen ketika file di disk benar-benar menggambarkan keadaan database. Kedua, WAL: segmen jurnal yang dibuat selama proses penyalinan ikut dikumpulkan, sehingga perubahan yang terjadi di tengah-tengah penyalinan bisa diputar ulang di atas salinan.

pg_basebackup mengerjakan keduanya secara otomatis: program ini membuka koneksi khusus (jalur yang sama dengan replikasi), memicu checkpoint, menyalin file per data directory melalui protokol yang memahami struktur server, dan mengalirkan WAL yang dibutuhkan selama proses berlangsung. Karena berjalan lewat protokol resmi, backup bisa diambil dari jauh lewat jaringan — mesin backup tidak perlu berada di server yang sama.

pg_basebackup dalam Praktik #

Satu perintah menjalankan seluruh konsep di atas. Skrip berikut mengambil base backup format plain (-Fp) dengan WAL dialirkan (-Xs) ke sebuah direktori, lalu menelusuri hasilnya:

bash basisdata-fisik.sh 
#!/bin/bash
# pg_basebackup menyalin seluruh isi cluster ke sebuah direktori.
# Buang sisa percobaan lama, lalu buat base backup format plain (-Fp)
# dengan WAL yang diperlukan ikut dialirkan selama proses (-Xs).
rm -rf basisdata_cadangan
pg_basebackup -D basisdata_cadangan -Fp -Xs
echo "exit code: $?"

# Struktur hasilnya meniru data directory server.
ls -1 basisdata_cadangan

# Label backup mencatat asal dan cara backup dibuat.
grep -E '^(BACKUP METHOD|BACKUP FROM|LABEL|START TIMELINE)' basisdata_cadangan/backup_label

# Hapus hasil demo agar bundel contoh tetap ringkas;
# di lingkungan nyata folder inilah yang disimpan di lokasi aman.
rm -rf basisdata_cadangan

Output yang Dihasilkan:

text 
exit code: 0
PG_VERSION
backup_label
backup_manifest
base
global
pg_commit_ts
pg_dynshmem
pg_hba.conf
pg_ident.conf
pg_logical
pg_multixact
pg_notify
pg_replslot
pg_serial
pg_snapshots
pg_stat
pg_stat_tmp
pg_subtrans
pg_tblspc
pg_twophase
pg_wal
pg_xact
postgresql.auto.conf
postgresql.conf
BACKUP METHOD: streamed
BACKUP FROM: primary
LABEL: pg_basebackup base backup
START TIMELINE: 1

Bedah perintah dan keluarannya:

  1. rm -rf basisdata_cadangan: pg_basebackup menuntut direktori tujuan kosong atau belum ada — sisa percobaan lama dibuang lebih dulu agar skrip aman diulang.
  2. pg_basebackup -D basisdata_cadangan -Fp -Xs: -D menunjuk direktori tujuan; -Fp memilih format plain (struktur direktori asli — format alternatif -Ft mengemas hasil sebagai file tar); -Xs (stream) mengalirkan WAL yang dibutuhkan selama backup berjalan sehingga hasilnya lengkap berdiri sendiri. Program ini selesai dengan senyap dan exit code 0 — deretan progres hanya muncul bila opsi -P ditambahkan.
  3. ls -1: isi hasilnya meniru data directory server — base/ tempat tabel, global/ katalog cluster, pg_wal/ jurnal, plus file konfigurasi postgresql.conf dan pg_hba.conf yang memang hidup di dalam PGDATA. Dua file khusus ikut ditambahkan: backup_label (kartu identitas backup) dan backup_manifest (daftar file terpisah lengkap dengan checksum untuk verifikasi).
  4. grep ... backup_label: empat baris yang stabil menegaskan identitas hasil — BACKUP METHOD: streamed (WAL dialirkan), BACKUP FROM: primary (diambil dari server utama, bukan standby), label default, dan timeline. Dua baris lain di file ini sengaja tidak ditampilkan: lokasi WAL awal dan waktu pembuatan, yang nilainya berbeda pada setiap backup.
  5. rm -rf terakhir: hasil backup dihapus agar contoh bisa diulang dan bundel materi tetap ringkas — di produksi justru folder inilah yang dikompres, dienkripsi, dan dikirim ke lokasi terpisah.

Untuk server dengan tablespace di luar PGDATA, pg_basebackup menawarkan pemetaan lokasi lewat -T path_lama=path_baru agar hasil backup tidak menimpa tablespace produksi saat dipulihkan. Opsi lain yang sering dipakai di lapangan: --checkpoint=spread (checkpoint tersebar agar tidak mengguncang server sibuk), --wal-method=fetch bila arsip WAL sudah dikelola terpisah, dan --compress untuk kompresi di tingkat alat.

Base Backup + WAL: Pintu ke Point-in-Time Recovery #

Satu base backup saja belum menyelesaikan cerita — ia hanyalah titik awal. Karena WAL terus terarsip setelah backup selesai, database bisa “dijalankan maju” dari base backup ke titik waktu mana pun di antaranya. Inilah fondasi point-in-time recovery:

Diagram ini membaca alur waktunya dari kiri ke kanan: base backup menjadi fondasi, segmen-segmen WAL yang terkumpul setelahnya menjadi bahan pemutar ulang, dan pemulihan berhenti tepat pada titik yang ditunjuk. Bila administrator menemukan DROP TABLE terjadi Selasa pukul 09:48, pemulihan dihentikan di 09:47 — seluruh data sebelum musibah kembali, tanpa satu baris pun dari sesudahnya. RPO dari strategi ini ditentukan seberapa rajin WAL diarsipkan — biasanya hitungan menit, jauh dari 24 jam backup malam hari.

Portabilitas dan Batasannya #

Kekuatan backup fisik dibayar dengan kekakuan. File data hanya bisa dibaca oleh PostgreSQL versi major yang sama — backup dari server 17 hanya bisa dibangunkan oleh server 17, karena format internal file berubah di tiap major version. Arsitektur mesin juga harus serumpun (little-endian ke little-endian). Pindah dari 17 ke 18, atau ke arsitektur berbeda? Jalannya kembali ke keluarga logis: pg_dump/pg_restore yang kita kuasai di chapter-chapter sebelumnya — atau pg_upgrade untuk migrasi versi di tempat. Kedua keluarga backup ini bukan pesaing: produksi yang sehat menjalankan keduanya sekaligus, logical untuk portabilitas dan selektivitas, physical untuk RTO yang pendek dan pintu ke pemulihan titik waktu.

Dengan konsep kedua keluarga kini lengkap di tangan Anda, sisa section ini bergerak mendalam ke mesinnya: mulai dari cara mengambil base backup yang benar di berbagai skenario — server sibuk, tablespace, kompresi — di chapter Base Backup .

Referensi #

Berkas Sumber

Berkas pendukung halaman ini dapat diunduh dan dijalankan langsung sesuai penjelasan di atas.

basisdata-fisik.sh

Unduh berkas
bash 
#!/bin/bash
# pg_basebackup menyalin seluruh isi cluster ke sebuah direktori.
# Buang sisa percobaan lama, lalu buat base backup format plain (-Fp)
# dengan WAL yang diperlukan ikut dialirkan selama proses (-Xs).
rm -rf basisdata_cadangan
pg_basebackup -D basisdata_cadangan -Fp -Xs
echo "exit code: $?"

# Struktur hasilnya meniru data directory server.
ls -1 basisdata_cadangan

# Label backup mencatat asal dan cara backup dibuat.
grep -E '^(BACKUP METHOD|BACKUP FROM|LABEL|START TIMELINE)' basisdata_cadangan/backup_label

# Hapus hasil demo agar bundel contoh tetap ringkas;
# di lingkungan nyata folder inilah yang disimpan di lokasi aman.
rm -rf basisdata_cadangan

cek-konfigurasi.sql

Unduh berkas
sql 
-- Tiga pengaturan yang menentukan kelayakan backup fisik di server ini.
-- wal_level=replica dan max_wal_senders>=1 dibutuhkan pg_basebackup;
-- data_checksums hanya bisa diaktifkan saat cluster dibuat (initdb).
SELECT name, setting
FROM pg_settings
WHERE name IN ('wal_level', 'max_wal_senders', 'data_checksums')
ORDER BY name;