Hemat 15% untuk semua layanan hosting

Uji kemampuanmu dan dapatkan Diskon pada paket hosting apa saja

Gunakan kode: Skills Memulai
Bagian FAQ
Cadangan Server Khusus

Backup dan Pemulihan Database PostgreSQL: Panduan Lengkap untuk Pengguna AlexHost

Mengapa Strategi Backup PostgreSQL Lebih Penting Daripada yang Anda Pikirkan

Kehilangan data bukan risiko hipotetis — ini adalah kepastian operasional yang akan dihadapi setiap administrator database di beberapa titik. Kegagalan perangkat keras, penghapusan yang tidak disengaja, transaksi yang rusak, dan serangan ransomware semuanya dapat menghancurkan lingkungan produksi dalam hitungan detik. Bagi pengguna PostgreSQL, memiliki strategi backup yang kuat, teruji, dan otomatis adalah perbedaan antara insiden kecil dan kegagalan bisnis yang bencana.

AlexHost Dedicated Servers menyediakan fondasi ideal untuk hosting dan melindungi database PostgreSQL. Dengan penyimpanan NVMe SSD tingkat enterprise yang memberikan throughput I/O luar biasa, akses root penuh untuk kontrol konfigurasi lengkap, dan perlindungan DDoS bawaan, AlexHost memberi Anda performa infrastruktur dan postur keamanan yang diminta oleh beban kerja database serius.

Baik Anda menjalankan platform e-commerce lalu lintas tinggi, aplikasi SaaS, instalasi WordPress yang didukung oleh database relasional, atau sistem enterprise khusus, panduan ini memandu Anda melalui setiap metode backup dan recovery PostgreSQL utama — dari SQL dumps sederhana hingga Point-in-Time Recovery (PITR) tingkat lanjut — semuanya dioptimalkan untuk lingkungan produksi.

1. Understanding PostgreSQL Backup Options

PostgreSQL ships with several mature, well-documented backup mechanisms. Choosing the right one depends on your database size, recovery time objectives (RTO), recovery point objectives (RPO), and operational complexity tolerance.

MethodBest ForProsCons
SQL Dump (pg_dump)Database kecil hingga menengahSederhana, portabel, mudah dibacaLambat untuk DB yang sangat besar
Custom Format DumpDatabase menengah hingga besarTerkompresi, restore paralelBiner, memerlukan pg_restore
File System SnapshotDatabase yang sangat besarCepat, konsistenMemerlukan keahlian, DB harus dihentikan atau snapshot-aware
PITR (WAL Archiving)Sistem produksi mission-criticalPemulihan point-in-time yang granularSetup dan pemeliharaan kompleks

Memahami trade-off ini sebelum Anda memulai sangat penting. Sebagian besar lingkungan produksi mendapat manfaat dari menggabungkan setidaknya dua pendekatan — misalnya, custom format dumps setiap malam bersama dengan WAL archiving berkelanjutan untuk kemampuan pemulihan yang granular.

2. Prasyarat dan Persyaratan Hak Istimewa

Sebelum menjalankan operasi backup apa pun, konfirmasi prasyarat berikut sudah terpenuhi:

Hak Istimewa Pengguna:

  • Anda harus menjadi superuser PostgreSQL atau pemilik database target untuk melakukan backup penuh.
  • Untuk pg_dumpall, hak istimewa superuser wajib diperlukan.

Verifikasi versi PostgreSQL Anda:

psql --version

Periksa ruang disk yang tersedia sebelum backup:

df -h /var/lib/postgresql/

Pastikan tujuan backup Anda memiliki ruang bebas yang cukup — minimal 1,5× ukuran database yang di-backup untuk memperhitungkan file sementara dan overhead kompresi.

Terhubung ke server Anda melalui SSH:

ssh root@your-server-ip

Jika Anda menggunakan paket VPS Hosting, Anda akan memiliki akses SSH penuh dan kemampuan untuk menginstal, mengonfigurasi, dan mengelola PostgreSQL tanpa batasan.

3. Metode 1 — SQL Dump dengan pg_dump

Utilitas pg_dump adalah alat backup PostgreSQL yang paling umum digunakan. Ini menghasilkan snapshot yang konsisten dari satu database, bahkan saat database sedang digunakan secara aktif. Output adalah skrip SQL teks biasa yang dapat ditinjau, diedit, dan diputar ulang pada instalasi PostgreSQL yang kompatibel.

Langkah 1: Buka Terminal dan Akses Server Anda

ssh root@your-alexhost-server-ip

Langkah 2: Jalankan Perintah pg_dump

pg_dump -U username -W -F p database_name > /backups/backup_file.sql

Penjelasan parameter:

ParameterDeskripsi
-U usernamePengguna PostgreSQL yang melakukan backup
-WMinta password secara interaktif
-F pFormat output: p = teks SQL biasa
database_nameNama database yang akan di-backup
> /backups/backup_file.sqlAlihkan output ke file

Contoh praktis:

pg_dump -U postgres -W -F p my_production_db > /backups/my_production_db_$(date +%Y%m%d_%H%M%S).sql

> Pro Tip: Menambahkan timestamp menggunakan $(date +%Y%m%d_%H%M%S) ke nama file backup Anda memastikan Anda tidak pernah secara tidak sengaja menimpa backup sebelumnya dan membuat arsip kronologis alami.

Langkah 3: Verifikasi File Backup

ls -lh /backups/
head -50 /backups/my_production_db_*.sql

File harus dimulai dengan komentar header PostgreSQL dan pernyataan SET, mengkonfirmasi bahwa dump yang valid telah dibuat.

4. Method 2 — Backing Up All Databases with pg_dumpall

Ketika Anda perlu mem-backup setiap database dalam instance PostgreSQL — termasuk global objects seperti roles dan tablespaces — pg_dumpall adalah tool yang tepat.

pg_dumpall -U postgres -W > /backups/all_databases_$(date +%Y%m%d).sql

Perintah ini mengekspor:

  • Semua database
  • Semua roles (users dan groups)
  • Semua tablespaces
  • Semua global configuration

Penting: File output dari pg_dumpall dapat sangat besar pada server yang sibuk. Pastikan partisi backup Anda memiliki ruang yang cukup dan pertimbangkan untuk mengompresi output segera:

pg_dumpall -U postgres | gzip > /backups/all_databases_$(date +%Y%m%d).sql.gz

5. Method 3 — Custom Format Backups for Large Databases

Untuk database produksi yang melebihi beberapa gigabyte, format custom (-F c) sangat direkomendasikan daripada plain SQL dumps. Custom format backups adalah:

  • Compressed by default — significantly reducing storage requirements
  • Faster to restore — supporting parallel restore operations with -j flag
  • Selectively restorable — allowing you to restore individual tables or schemas

Creating a Custom Format Backup

pg_dump -U postgres -W -F c my_production_db > /backups/my_production_db_$(date +%Y%m%d).dump

Creating a Compressed Directory Format Backup (Supports Parallelism)

pg_dump -U postgres -W -F d -j 4 -f /backups/my_production_db_dir my_production_db
ParameterDescription
-F dDirectory format — one file per table
-j 4Use 4 parallel worker processes
-f /path/to/dirOutput directory (must not exist yet)

Pendekatan ini secara dramatis mengurangi durasi backup pada server multi-core, menjadikannya ideal untuk lingkungan dedicated server berkinerja tinggi yang tersedia di AlexHost.

6. Memulihkan dari SQL Dumps

Memulihkan Database Tunggal dari SQL Dump Biasa

Pertama, pastikan database target ada. Jika tidak, buatnya:

psql -U postgres -c "CREATE DATABASE my_restored_db;"

Kemudian pulihkan:

psql -U postgres -d my_restored_db -f /backups/my_production_db_backup.sql

Penjelasan parameter:

ParameterDeskripsi
-U postgresPostgreSQL superuser
-d my_restored_dbDatabase target untuk pemulihan
-f /path/to/file.sqlJalur ke file SQL dump

Memantau Kemajuan Pemulihan

Untuk file SQL besar, Anda dapat memantau kemajuan menggunakan pv:

pv /backups/my_production_db_backup.sql | psql -U postgres -d my_restored_db

7. Memulihkan dari Custom Format Dumps

Custom format dumps memerlukan utilitas pg_restore daripada psql.

Pemulihan Dasar

pg_restore -U postgres -d my_restored_db /backups/my_production_db.dump

Pemulihan dan Buat Database Secara Otomatis

Gunakan flag -C untuk menginstruksikan pg_restore membuat database sebelum mengisinya:

pg_restore -U postgres -C -d postgres /backups/my_production_db.dump

Pemulihan Paralel untuk Pemulihan yang Lebih Cepat

pg_restore -U postgres -d my_restored_db -j 4 /backups/my_production_db_dir/

Menggunakan -j 4 dengan backup format direktori dapat mengurangi waktu pemulihan hingga 75% pada server quad-core — keuntungan signifikan saat meminimalkan downtime selama pemulihan bencana.

Pulihkan Tabel Tertentu Saja

pg_restore -U postgres -d my_restored_db -t orders /backups/my_production_db.dump

Kemampuan granular ini adalah salah satu keuntungan utama custom format dibandingkan plain SQL dumps.

8. Metode 4 — Continuous Archiving dan Point-in-Time Recovery (PITR)

PITR adalah standar emas untuk deployment PostgreSQL yang mission-critical. Ini memungkinkan Anda untuk memulihkan database Anda ke momen spesifik apa pun — bukan hanya backup terakhir — dengan memutar ulang segmen Write-Ahead Log (WAL) di atas backup dasar. Ini penting untuk skenario di mana Anda perlu memulihkan dari kesalahan logis (seperti DROP TABLE yang tidak disengaja) yang terjadi pada timestamp yang diketahui.

Langkah 1: Aktifkan WAL Archiving di postgresql.conf

Temukan dan edit file konfigurasi PostgreSQL Anda:

nano /etc/postgresql/15/main/postgresql.conf

Tambahkan atau modifikasi direktif berikut:

# Enable WAL archiving
wal_level = replica
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/wal_archive/%f'

Penjelasan parameter:

ParameterNilaiDeskripsi
wal_levelreplicaMengaktifkan detail WAL yang cukup untuk archiving
archive_modeonMengaktifkan proses archiving
archive_command'cp %p /path/%f'Perintah shell untuk menyalin file WAL ke archive

Buat direktori archive dan atur izin yang benar:

mkdir -p /var/lib/postgresql/wal_archive
chown postgres:postgres /var/lib/postgresql/wal_archive
chmod 700 /var/lib/postgresql/wal_archive

Restart PostgreSQL untuk menerapkan perubahan:

systemctl restart postgresql

Langkah 2: Ambil Base Backup dengan pg_basebackup

pg_basebackup -U postgres -D /backups/base_backup -Ft -z -P -Xs
ParameterDeskripsi
-D /backups/base_backupDirektori tujuan untuk base backup
-FtOutput format Tar
-zKompres dengan gzip
-PTampilkan progress
-XsStream WAL selama backup

Langkah 3: Pulihkan ke Titik Waktu Tertentu

Untuk memulihkan dari base backup dan WAL archives:

  1. Hentikan PostgreSQL:
systemctl stop postgresql
  1. Hapus direktori data yang ada:
rm -rf /var/lib/postgresql/15/main/*
  1. Ekstrak base backup:
tar -xzf /backups/base_backup/base.tar.gz -C /var/lib/postgresql/15/main/
  1. Buat recovery.conf (PostgreSQL 11 dan lebih awal) atau konfigurasi postgresql.conf dan buat file recovery.signal (PostgreSQL 12+):
# For PostgreSQL 12+
touch /var/lib/postgresql/15/main/recovery.signal

Tambahkan ke postgresql.conf:

restore_command = 'cp /var/lib/postgresql/wal_archive/%f %p'
recovery_target_time = '2025-01-15 14:30:00'
recovery_target_action = 'promote'
  1. Atur kepemilikan yang benar dan mulai PostgreSQL:
chown -R postgres:postgres /var/lib/postgresql/15/main/
systemctl start postgresql

PostgreSQL akan memutar ulang segmen WAL hingga timestamp yang ditentukan dan kemudian mempromosikan ke status baca-tulis normal.

9. Mengotomatisasi Backup dengan Cron

Backup manual tidak dapat diandalkan. Mengotomatisasi jadwal backup Anda dengan cron memastikan konsistensi dan menghilangkan faktor kesalahan manusia.

Buat Skrip Backup

nano /usr/local/bin/pg_backup.sh
#!/bin/bash

# PostgreSQL Automated Backup Script
BACKUP_DIR="/backups/postgresql"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
DB_USER="postgres"
DB_NAME="my_production_db"
RETENTION_DAYS=14

# Create backup directory if it doesn't exist
mkdir -p "$BACKUP_DIR"

# Perform the backup
pg_dump -U "$DB_USER" -F c "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump"

# Remove backups older than retention period
find "$BACKUP_DIR" -name "*.dump" -mtime +"$RETENTION_DAYS" -delete

# Log completion
echo "[$TIMESTAMP] Backup of $DB_NAME completed successfully." >> /var/log/pg_backup.log

Buat skrip dapat dieksekusi:

chmod +x /usr/local/bin/pg_backup.sh

Jadwalkan dengan Cron

crontab -e

Tambahkan baris berikut untuk menjalankan backup setiap malam pukul 2:00 AM:

0 2 * * * /usr/local/bin/pg_backup.sh

Untuk backup penuh mingguan ditambah pengarsipan WAL inkremental harian, gabungkan ini dengan pengaturan PITR yang dijelaskan di bagian sebelumnya.

10. Mengamankan dan Menyimpan Backup di Lokasi Eksternal

Backup yang disimpan di server yang sama dengan database produksi Anda bukan backup yang sebenarnya — ini adalah titik kegagalan tunggal. Implementasikan praktik keamanan dan penyimpanan offsite berikut:

Enkripsi Backup Sebelum Transfer

gpg --symmetric --cipher-algo AES256 /backups/my_production_db.dump

Transfer Backup ke Lokasi Jarak Jauh dengan rsync

rsync -avz --progress /backups/postgresql/ user@remote-backup-server:/remote/backups/postgresql/

Gunakan pg_dump dengan SSH Pipe untuk Backup Remote Langsung

pg_dump -U postgres my_production_db | gzip | ssh user@remote-server "cat > /backups/my_production_db_$(date +%Y%m%d).sql.gz"

Aturan Firewall untuk PostgreSQL (UFW)

Batasi akses port PostgreSQL hanya ke IP terpercaya:

ufw allow from 192.168.1.0/24 to any port 5432
ufw deny 5432
ufw enable

Untuk tim yang mengelola berbagai proyek di berbagai tingkat hosting, paket AlexHost Shared Web Hosting juga mendukung alat manajemen database yang dapat melengkapi alur kerja backup Anda untuk proyek yang lebih kecil.

11. Ringkasan Praktik Terbaik

Mengimplementasikan backup PostgreSQL dengan benar memerlukan disiplin dan pendekatan berlapis. Ikuti praktik terbaik ini untuk memastikan data Anda selalu terlindungi:

PraktikRekomendasi
Frekuensi backupMinimal harian; setiap jam untuk database dengan transaksi tinggi
Format backupGunakan format custom (-F c) untuk database > 1 GB
Kebijakan retensiSimpan 14 backup harian, 4 mingguan, dan 3 bulanan
VerifikasiRestore ke lingkungan pengujian setiap bulan untuk memvalidasi integritas
EnkripsiSelalu enkripsi backup sebelum transfer offsite
Penyimpanan offsitePertahankan backup di setidaknya satu lokasi yang terpisah secara geografis
PemantauanBeri peringatan pada kegagalan pekerjaan backup melalui email atau sistem pemantauan
PITR untuk produksiAktifkan WAL archiving pada semua database yang penting
DokumentasiPertahankan runbook tertulis untuk prosedur pemulihan

> Pengingat penting: Backup yang tidak pernah diuji bukanlah backup — ini adalah asumsi. Jadwalkan latihan restore reguler dan dokumentasikan hasilnya.

Kesimpulan: Lindungi Data PostgreSQL Anda dengan Percaya Diri di AlexHost

PostgreSQL menawarkan salah satu perangkat backup dan recovery paling komprehensif dari sistem database open-source mana pun. Dari kesederhanaan pg_dump untuk snapshot SQL cepat hingga presisi bedah PITR untuk pemulihan point-in-time yang granular, Anda memiliki semua yang diperlukan untuk membangun strategi perlindungan data yang tahan banting.

Kuncinya adalah eksekusi: otomatisasi backup Anda, verifikasi secara teratur, enkripsi sebelum transfer, dan simpan di lokasi offsite. Dikombinasikan dengan performa dan keandalan AlexHost Dedicated Servers — menampilkan penyimpanan NVMe, akses root penuh, dan perlindungan DDoS tingkat enterprise — database PostgreSQL Anda akan cepat dan tangguh.

Untuk tim yang membutuhkan infrastruktur yang dapat diskalakan tanpa overhead mengelola bare metal, AlexHost VPS Hosting menawarkan alternatif yang fleksibel dan hemat biaya dengan komitmen yang sama terhadap performa dan uptime. Dan jika Anda perlu mengamankan aplikasi web berbasis database Anda dari ujung ke ujung, memasangkan hosting Anda dengan AlexHost SSL Certificates memastikan komunikasi terenkripsi antara lapisan aplikasi Anda dan pengguna Anda.

Mulai terapkan strategi backup ini hari ini. Diri Anda di masa depan — menghadapi insiden jam 3 pagi dengan database produksi yang rusak — akan berterima kasih kepada Anda karena telah melakukannya.