Belajar pgBackRest - Restore: Full, Delta & PITR

#Pendahuluan

Semua episode sebelumnya membangun: stanza, backup, WAL, retention. Tetapi seluruh sistem itu baru bermakna saat restore bekerja. Inilah ironi backup: ia paling sering diabaikan justru saat dibutuhkan paling kritis. Di episode 8 kita membalik arah dan menguasai pgbackrest restore — dari memulihkan kondisi terakhir, hingga PITR yang presisi ke waktu, LSN, atau restore point.

Bayangkan pgBackRest sebagai arsip foto: backup adalah kamera yang memotret, WAL adalah film yang merekam setiap momen, dan restore adalah mesin cuci cetak yang menghasilkan foto di momen yang kalian minta. Episode 8 adalah latihan menggunakan mesin itu dengan benar.

#Dasar Restore

#Prasyarat Penting

pgbackrest restore memerlukan direktori PGDATA target dalam kondisi yang benar. Default pgBackRest adalah menyalin ke pg1-path dari config — dan menolak menimpa file yang sudah ada. Untuk target kosong (cluster baru), tidak perlu opsi tambahan:

Restore ke cluster kosong

sudo -u postgres pgbackrest --stanza=main restore

#Memilih Backup yang Dipulihkan

Defaultnya pgBackRest mengambil backup terakhir yang tersedia untuk stanza. Untuk memilih backup spesifik, gunakan --set dengan label dari pgbackrest info:

Restore backup tertentu

sudo -u postgres pgbackrest --stanza=main --set=20260813-090000F restore

#Tipe Restore: Default, Immediate, dan PITR

#--type=immediate: Kondisi Terakhir

Untuk memulihkan ke kondisi paling akhir yang tersedia (memutar ulang semua WAL yang diarsipkan sampai titik terakhir), gunakan --type=immediate:

Restore ke kondisi terakhir

sudo -u postgres pgbackrest --stanza=main --type=immediate restore

Ini pilihan paling umum untuk recovery total dari bencana: kalian ingin kembali ke kondisi "sebelum semuanya hancur", sebaru mungkin.

#--type=time: Point-in-Time Recovery

PITR sejati — pulihkan ke waktu spesifik. Sangat berguna untuk membatalkan kesalahan yang terjadi pada waktu tertentu (misalnya DROP TABLE jam 09:30):

Restore ke waktu tertentu

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

Format waktunya mengikuti konfigurasi timezone cluster. Saat restore tipe ini selesai, PostgreSQL berhenti di titik yang diminta.

#--type=lsn: Presisi ke Log Sequence Number

Untuk presisi maksimal, tentukan titik dalam bentuk LSN (Log Sequence Number). LSN bisa diambil dari log error, output aplikasi, atau pg_current_wal_lsn():

Restore ke LSN tertentu

sudo -u postgres pgbackrest --stanza=main --type=lsn '16/B374D848' restore

LSN memungkinkan pemulihan di antara dua transaksi — presisi yang tidak bisa dijamin waktu karena jam bisa tidak sinkron.

#--type=name: Restore Point

PostgreSQL memungkinkan membuat restore point dengan nama — penanda logis dalam aliran WAL. Buat di database, lalu pulihkan ke nama tersebut:

sql

SELECT pg_create_restore_point('sebelum-migrasi-v2');

Restore ke restore point

sudo -u postgres pgbackrest --stanza=main --type=name 'sebelum-migrasi-v2' restore

Tip

Buat restore point sebelum operasi berisiko (migrasi skema, batch update, drop tabel). Ini memberi kalian penanda bernama yang bisa di-restore kapan pun — jauh lebih mudah diingat daripada LSN atau timestamp.

#Delta Restore: Sinkronkan Cluster yang Ada

#Masalah dengan Cluster yang Masih Ada

Jika PGDATA masih berisi data (misalnya server gagal di tengah jalan, atau kalian ingin "menimpa" cluster yang berjalan), restore default menolak bekerja karena file sudah ada. Menghapus semua lalu restore berarti downtime lebih lama.

#Solusi: --delta

--delta membandingkan file di PGDATA dengan isi backup dan hanya menimpa yang berbeda — file yang sama dibiarkan. Inilah cara tercepat memulihkan cluster yang sebagian besar masih utuh:

Delta restore ke cluster existing

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

--delta juga berguna untuk menurunkan cluster lama ke versi backup tertentu (episode 19), atau sync setelah crash parsial. Tambahkan --force bila ingin memaksa restore ke direktori yang tidak kosong tanpa delta check.

Warning

--delta menghapus file yang ada di PGDATA tapi tidak ada di backup — itu yang membuatnya konsisten dengan isi backup. Pastikan kalian memahami ini: jangan pakai --delta pada PGDATA yang berisi data lebih baru yang ingin dipertahankan. Untuk kasus itu, restore ke direktori terpisah.

#Menangani Recovery: Target Action

Setelah PITR berhenti di titik yang diminta, cluster masuk mode recovery. Untuk kontrol saat drill (episode 16), setel aksi target:

Pause setelah PITR

sudo -u postgres pgbackrest --stanza=main --type=time '2026-08-13 09:30:00+07' --target-action=pause restore

Dengan --target-action=pause, PostgreSQL berhenti di target tanpa membuka write — memungkinkan verifikasi data sebelum membiarkan cluster melayani traffic. Setelah yakin, resume dengan SELECT pg_wal_replay_resume();.

#Verifikasi Hasil Restore

Setelah restore selesai, start cluster dan periksa:

Verifikasi data setelah restore

sudo systemctl start postgresql
psql -U postgres -c "SELECT count(*) FROM aplikasi.pelanggan;"

Jika kalian restore ke waktu sebelum transaksi tertentu, row yang ditambahkan setelah waktu itu harus hilang. Itulah bukti PITR bekerja.

#Penutup

Inti yang harus dibawa pulang:

restore default memakai backup terakhir; --set memilih backup spesifik.
--type=immediate = kondisi terakhir; --type=time = PITR; --type=lsn = presisi log; --type=name = restore point bernama.
--delta menimpa PGDATA existing hanya yang berbeda — recovery tercepat.
--target-action=pause memungkinkan verifikasi sebelum cluster melayani traffic.
Selalu verifikasi data setelah restore — jangan percaya sebelum membuktikan.

Di episode 9 selanjutnya kita akan menguji skenario recovery nyata: cluster korup yang dipulihkan ke backup terakhir + WAL, kehilangan seluruh direktori data yang harus di-rebuild, dan cloning instance standby baru dari backup. Semua diakhiri dengan latihan simulasi crash dan PITR ke waktu spesifik — skill yang membedakan DBA sungguhan!