Apa perbedaan antara pg_dump dan pg_basebackup, dan kapan harus menggunakan masing-masing?

pg_dump membuat backup logis dengan mengekspor pernyataan SQL yang membuat ulang skema dan data — portabel lintas versi PostgreSQL dan cocok untuk database di bawah 10GB dengan RPO beberapa jam. pg_basebackup membuat salinan biner fisik dari direktori data, yang lebih cepat dipulihkan untuk database besar dan diperlukan untuk point-in-time recovery (PITR), namun spesifik versi dan tidak bisa memulihkan tabel tertentu saja. Untuk produksi, keduanya diperlukan: backup fisik untuk disaster recovery dan backup logis untuk pemulihan tabel spesifik serta migrasi lintas versi.

Mengapa pengujian proses pemulihan sangat penting, dan seberapa sering harus dilakukan?

Backup yang berjalan diam-diam dan gagal diam-diam lebih buruk daripada tidak ada backup, karena menciptakan kepercayaan diri yang palsu. Postingan ini menceritakan kejadian nyata di mana pg_dump gagal secara diam-diam akibat masalah ruang disk di VPS backup — cron job melaporkan sukses karena pg_dump keluar dengan kode 0 pada penulisan parsial, sehingga terdapat 3 minggu file backup yang kosong. Menguji pemulihan setiap bulan dengan menyiapkan VPS sementara, memulihkan backup terbaru, dan menjalankan query sanity check adalah satu-satunya cara untuk memastikan backup benar-benar berfungsi.

Apa itu WAL archiving dan mengapa penting untuk database ERP atau keuangan?

WAL (Write-Ahead Log) adalah log transaksi yang ditulis PostgreSQL sebelum menerapkan perubahan ke file data. Dengan mengarsipkan segmen WAL secara terus-menerus bersama backup dasar, Anda dapat memulihkan database ke titik waktu mana pun — bukan hanya cap waktu backup terakhir. Untuk database yang datanya sering berubah seperti sistem ERP atau keuangan, ini berarti Anda bisa memulihkan ke tepat sesaat sebelum perintah DELETE yang tidak disengaja atau kejadian korupsi data terjadi.

Apa aturan backup 3-2-1 dan bagaimana penerapannya untuk PostgreSQL yang di-hosting di VPS?

Aturan 3-2-1 mengharuskan 3 salinan data, disimpan di 2 jenis media berbeda, dengan 1 salinan offsite. Postingan ini mengilustrasikan pentingnya aturan ini dengan kejadian nyata di mana kegagalan DigitalOcean Droplet merusak filesystem server sekaligus volume backup yang dipasang di server yang sama — backup lokal di server atau datacenter yang sama bukan backup nyata, melainkan hanya salinan kenyamanan. Setup minimal yang sesuai aturan mencakup pg_dump harian yang dikirim ke penyimpanan objek offsite (Spaces, GCS, atau B2), backup fisik malam hari di Droplet terpisah dalam region yang sama, dan backup bulanan ke region cloud yang berbeda.

Strategi Backup PostgreSQL untuk VPS: pg

Q: Mengapa pgBackRest direkomendasikan dibanding WAL archiving manual untuk PostgreSQL produksi?

pgBackRest adalah alat backup produksi yang direkomendasikan karena menangani kompleksitas koordinasi antara backup dasar dan segmen WAL yang rentan error jika dilakukan secara manual. Alat ini mendukung backup penuh, inkremental, dan diferensial; backup dan pemulihan paralel; kompresi dan enkripsi; beberapa backend penyimpanan termasuk S3, Azure, dan GCS; serta PITR yang disederhanakan. Backup penuh setiap malam dikombinasikan dengan WAL archiving terus-menerus via pgBackRest memberikan recovery point dalam hitungan detik dari transaksi mana pun.

Strategi Backup PostgreSQL untuk VPS: Dari pg_dump hingga WAL Archiving

Strategi backup PostgreSQL praktis untuk deployment VPS — mencakup pg_dump, pg_basebackup, WAL archiving, dan backup offsite otomatis dengan contoh konfigurasi nyata.

Matthews Wong

Software Engineer

Juni 202512 menit baca

DevOps

Kehilangan data bisa mengakhiri karier. Database PostgreSQL tanpa strategi backup yang teruji dan otomatis adalah kewajiban yang menunggu untuk terwujud. Data ERP adalah jenis data di mana satu hari transaksi yang hilang dapat berarti konsekuensi finansial dan hukum yang serius.

Memahami Jenis Backup PostgreSQL

PostgreSQL memiliki dua pendekatan backup fundamental: backup logis (pg_dump) dan backup fisik (pg_basebackup, pgBackRest). Backup logis mengekspor pernyataan SQL yang membuat ulang skema dan data Anda — portabel, dapat dibaca manusia, dan bekerja di seluruh versi PostgreSQL. Backup fisik menyalin file data mentah — lebih cepat untuk database besar, diperlukan untuk point-in-time recovery (PITR), namun spesifik versi.

pg_dump: Titik Awal

pg_dump adalah alat backup paling sederhana dan cukup untuk database di bawah 10GB dengan RPO (recovery point objective) beberapa jam. Perintah pg_dump -Fc -f backup.dump dbname membuat dump format custom terkompresi yang dipulihkan dengan pg_restore. Jadwalkan pg_dump melalui cron pada frekuensi yang diinginkan, dan segera kirim dump ke penyimpanan offsite.

pg_basebackup untuk Backup Fisik

pg_basebackup membuat salinan biner direktori data PostgreSQL saat server sedang berjalan. Ini adalah dasar untuk replikasi streaming dan PITR. Gunakan pg_basebackup -D /path/to/backup -Ft -z -P untuk backup tarball dengan output progres. Backup fisik lebih cepat untuk dipulihkan untuk database besar.

┌─────────────────────────────────────────────────────┐
│          POSTGRESQL BACKUP STRATEGY LAYERS          │
└─────────────────────────────────────────────────────┘

  PostgreSQL DB
       │
       ├── [1] pg_dump (daily) ──────► Offsite Object Storage
       │         (logical backup)       (Spaces / GCS / B2)
       │
       ├── [2] pg_basebackup (weekly) ► Backup VPS
       │         (physical backup)       (same region)
       │
       ├── [3] WAL Archiving ──────────► Object Storage
       │         (continuous)            (PITR to any timestamp)
       │
       └── [4] pgBackRest (full+incr) ► Encrypted S3-compat
                 (production-grade)

  3-2-1 Rule: 3 copies | 2 media types | 1 offsite

Dari pengalaman dengan backup PostgreSQL, selalu uji proses pemulihan Anda setiap bulan. Atur pengingat kalender, sediakan VPS sementara, pulihkan backup terbaru Anda, dan jalankan query sanity check terhadap data yang dipulihkan. Job pg_dump bisa gagal secara diam-diam, misalnya saat VPS backup kehabisan ruang disk, sementara cron job tetap melaporkan berhasil. Anda lalu bisa memiliki file backup yang kosong atau parsial selama berminggu-minggu.

WAL Archiving dan Point-in-Time Recovery

WAL (Write-Ahead Log) adalah log transaksi yang ditulis PostgreSQL sebelum menerapkan perubahan ke file data. Dengan mengarsipkan segmen WAL secara terus-menerus, Anda dapat memulihkan ke titik waktu mana pun antara backup dasar — bukan hanya cap waktu backup. Untuk database di mana data sering berubah (ERP, sistem keuangan), PITR memungkinkan Anda berkata: pulihkan ke 10:47:23 kemarin, sebelum DELETE yang tidak sengaja dijalankan.

pgBackRest: Solusi Tingkat Produksi

pgBackRest adalah alat backup yang direkomendasikan untuk PostgreSQL produksi. Ia mendukung backup penuh, inkremental, dan diferensial; backup dan pemulihan paralel; kompresi dan enkripsi; beberapa backend penyimpanan (lokal, S3, Azure, GCS); dan PITR yang disederhanakan.

# Daily pg_dump backup script
#!/bin/bash
DB_NAME="production_db"
BACKUP_DIR="/backups/postgres"
DATE=$(date +%Y%m%d_%H%M%S)
DUMP_FILE="$BACKUP_DIR/${DB_NAME}_$DATE.dump"

pg_dump -Fc -f "$DUMP_FILE" "$DB_NAME"

# Upload to DigitalOcean Spaces
s3cmd put "$DUMP_FILE" s3://my-backups/postgres/

# Delete local files older than 3 days
find "$BACKUP_DIR" -name "*.dump" -mtime +3 -delete

# Send success signal (dead man's switch)
curl -s "https://hc-ping.com/YOUR-UUID"

# WAL archiving in postgresql.conf
# archive_mode = on
# archive_command = 'aws s3 cp %p s3://my-backups/wal/%f'
# wal_level = replica

Mengotomatiskan Pipeline Backup

Pipeline backup produksi untuk instance DigitalOcean Managed PostgreSQL: gunakan backup otomatis bawaan (disertakan dengan layanan terkelola, retensi 7 hari), tambahkan backup pg_dump harian Anda sendiri ke DigitalOcean Spaces untuk retensi 30 hari dan perlindungan lintas region, dan uji pemulihan bulanan.

Saya pernah memiliki DigitalOcean Droplet gagal dengan filesystem yang rusak yang juga merusak volume backup yang dipasang di server yang sama. Backup lokal di server yang sama atau bahkan datacenter yang sama bukan backup nyata — itu adalah salinan kenyamanan. Ikuti aturan 3-2-1: 3 salinan data, 2 jenis media berbeda, 1 offsite.

Kebijakan Retensi dan Biaya Penyimpanan

Kebijakan retensi menyeimbangkan RPO, biaya penyimpanan, dan persyaratan kepatuhan. Untuk sebagian besar data ERP bisnis kecil, kebijakan yang wajar adalah: backup harian 7 hari (mencakup penghapusan yang tidak disengaja), backup mingguan 4 minggu (mencakup penemuan korupsi yang tertunda), backup bulanan 12 bulan (mencakup persyaratan kepatuhan dan audit).

Memantau Kesehatan Backup Anda

Backup yang berjalan diam-diam dan gagal diam-diam lebih buruk daripada tidak ada backup, karena menciptakan kepercayaan diri yang palsu. Pantau kesehatan backup: kirim alert Telegram saat pekerjaan backup berhasil (sehingga Anda menyadari ketika notifikasi berhenti), kirim alert segera saat kegagalan backup, lacak ukuran file backup dan alert jika turun secara signifikan.