Backup dan Disaster Recovery Cheat Sheet

#Filosofi Dasar

Backup tanpa rencana pemulihan cuma bikin kamu merasa aman, bukan benar-benar aman. Pertanyaan yang harus bisa kamu jawab bukan "apakah aku punya backup", tapi "berapa lama sampai layanan jalan lagi kalau database utama hilang besok pagi". Disaster recovery (DR) adalah disiplin menjawab pertanyaan itu dengan angka, prosedur, dan bukti bahwa prosedurnya pernah dicoba.

Dua angka kunci yang membingkai semuanya:

Contoh: RPO 15 menit dan RTO 2 jam artinya kamu siap kehilangan maksimal 15 menit data dan layanan harus hidup lagi dalam 2 jam. Angka ini menentukan arsitektur backup kamu, bukan sebaliknya. RPO 0 butuh streaming replication, bukan sekadar pg_dump malam-malam.

#Aturan 3-2-1

Aturan klasik dari fotografer Peter Krogh ini tetap jadi fondasi semua strategi backup:

Varian modern yang makin relevan zaman ransomware:

• 3-2-1-1-0: tambah satu salinan immutable (tidak bisa dihapus atau diubah, misal S3 Object Lock) dan angka nol artinya nol error verifikasi. Backup yang belum pernah diverifikasi dianggap gagal.
• 4-3-2: empat salinan untuk organisasi yang sangat konservatif.

Contoh susunan nyata untuk satu database PostgreSQL produksi:

Salinan 1 (primer)  : PostgreSQL di VPS utama, dengan streaming replica
Salinan 2 (on-site) : pg_dump malaman ke disk terpisah, retensi 7 hari
Salinan 3 (offsite) : dump terenkripsi di S3 (versioning on), retensi 30 hari
Salinan immutable   : WAL archive ke bucket terpisah dengan Object Lock 30 hari

Musuh utama 3-2-1 bukan teknis, tapi proses: backup lokal di server yang sama dengan disk primer, kredensial S3 yang sama dipakai aplikasi dan skrip backup (kalau aplikasi kena kompromi, attacker bisa hapus bucket juga), dan backup yang tidak pernah diuji restore.

#Backup PostgreSQL: Logical vs Physical

PostgreSQL menyediakan dua keluarga metode backup, dan keduanya menyelesaikan masalah berbeda.

Kesimpulan praktis: pakai keduanya. Logical dump untuk migrasi, audit, dan restore granular. Physical + WAL untuk skenario bencana yang butuh PITR.

#pg_dump dan pg_restore

# Dump format custom (compressed, bisa parallel restore)
pg_dump -Fc -d produk -f produk_$(date +%F).dump
 
# Dump format directory, parallel saat dump (hanya format ini yang dukung -j)
pg_dump -Fd -j 4 -d produk -f dumpdir/
 
# Dump plain SQL (bisa dibaca manusia, restore pakai psql)
pg_dump -d produk -f produk.sql
 
# Hanya schema / hanya data
pg_dump --schema-only -d produk -f schema.sql
pg_dump --data-only -d produk -f data.sql
 
# Satu tabel saja
pg_dump -t transaksi -d produk -f transaksi.sql
 
# Jangan lupa globals (roles, tablespace): pg_dump tidak menyimpannya
pg_dumpall --globals-only > globals_$(date +%F).sql

Restore dari format custom:

# Restore parallel
pg_restore -d produk -j 4 --clean --if-exists produk_2026-09-19.dump
 
# Buat index setelah data masuk, lebih cepat untuk DB besar
pg_restore -d produk --section=data dump.fc
pg_restore -d produk --section=index dump.fc
 
# Lihat isi dump tanpa restore
pg_restore --list produk_2026-09-19.dump

Catatan penting dari dokumentasi resmi PostgreSQL:

• pg_dump membuat snapshot konsisten dalam satu transaksi, jadi tidak perlu menghentikan aplikasi.
• pg_dump -j (parallel) hanya berlaku untuk format directory -Fd, dan hanya meng-copy data paralel; schema tetap serial.
• --clean --if-exists membuat restore idempotent: objek lama di-drop dulu, error drop diabaikan.
• pg_dumpall satu-satunya cara membackup roles dan tablespace untuk seluruh cluster.

#Cron backup malaman dengan retensi

# /etc/cron.d/pg-backup, jalan tiap jam 2 pagi
0 2 * * * postgres /usr/local/bin/pg-nightly-backup.sh
 
# pg-nightly-backup.sh
#!/bin/bash
set -euo pipefail
BACKUP_DIR=/var/backups/postgres
STAMP=$(date +%F)
mkdir -p "$BACKUP_DIR"
 
pg_dump -Fc -d produk -f "$BACKUP_DIR/produk_$STAMP.dump"
pg_dumpall --globals-only > "$BACKUP_DIR/globals_$STAMP.sql"
 
# Enkripsi sebelum kirim (kunci age publik penerima)
sops --encrypt --age age1qyqsz... \
  "$BACKUP_DIR/produk_$STAMP.dump" > "$BACKUP_DIR/produk_$STAMP.dump.enc"
 
# Upload offsite
aws s3 cp "$BACKUP_DIR/produk_$STAMP.dump.enc" \
  s3://perusahaan-backup/postgres/produk/$STAMP.dump.enc
 
# Hapus lokal lebih dari 7 hari
find "$BACKUP_DIR" -name '*.dump' -mtime +7 -delete
find "$BACKUP_DIR" -name '*.dump.enc' -mtime +2 -delete
 
# Catat hasil agar bisa dimonitor
echo "$(date -Is) dump produk $STAMP OK" >> "$BACKUP_DIR/backup.log"

#Continuous Archiving: WAL + Base Backup untuk PITR

WAL (Write-Ahead Log) adalah catatan semua perubahan data di PostgreSQL. Kalau kamu punya base backup (foto lengkap data directory di titik waktu tertentu) plus semua WAL setelahnya, kamu bisa memutar ulang ke titik waktu berapa pun di antara keduanya. Inilah yang disebut Point-In-Time Recovery (PITR).

#Konfigurasi WAL archiving

Di postgresql.conf:

wal_level = replica          # minimal replica untuk archiving
archive_mode = on
archive_command = 'test ! -f /var/lib/postgresql/archive/%f && cp %p /var/lib/postgresql/archive/%f'
archive_timeout = 300        # paksa switch WAL tiap 5 menit walau belum penuh

• %p adalah path file WAL yang mau diarsip, %f nama filenya.
• archive_command harus mengembalikan exit code 0 hanya jika arsip benar-benar tersimpan. Kalau gagal, PostgreSQL akan mencoba lagi dan menumpuk WAL: waspadai disk penuh.
• archive_timeout menjaga RPO: tanpa ini, WAL hanya di-flush saat 16 MB penuh, dan database sepi bisa meninggalkan data segar hanya di memori.

WAL archive harus punya retensi lebih panjang dari base backup terbaru plus margin, kalau tidak PITR tidak bisa jalan. Contoh pola mingguan: base backup tiap Minggu, semua WAL disimpan 10 hari.

Pindahkan arsip ke object storage bisa langsung dari archive_command:

archive_command = 'aws s3 cp %p s3://perusahaan-backup/wal/%f'

Untuk produksi serius, pgBackRest atau WAL-G lebih cocok: mereka menangani kompresi, paralel, enkripsi, retensi otomatis, dan verifikasi checksum.

#Membuat base backup

# pg_basebackup: butuh user dengan permission REPLICATION
pg_basebackup -D /var/backups/postgres/base -X stream -P --checkpoint=fast
 
# Kirim langsung terkompresi ke arsip
pg_basebackup -D - -Ft -X stream | zstd | \
  aws s3 cp - s3://perusahaan-backup/base/base_$(date +%F).tar.zst

• -X stream memastikan WAL selama backup ikut terkumpul, backup jadi konsisten sendiri.
• Sejak PostgreSQL 13 ada manifest yang bisa diverifikasi dengan pg_verifybackup /var/backups/postgres/base.
• pgBackRest: pgbackrest --stanza=produk backup --type=full untuk full, --type=diff atau --type=incr untuk inkremental.

#Prosedur PITR

Skenario: sore tadi jam 14.30 ada DROP TABLE transaksi yang tidak disengaja. Kamu ingin pulih ke kondisi tepat sebelum perintah itu jalan.

# 1. Matikan PostgreSQL yang rusak, simpan datanya untuk forensik
sudo systemctl stop postgresql
 
# 2. Siapkan cluster baru dari base backup terakhir SEBELUM 14.30
rm -rf /var/lib/postgresql/16/main
pg_basebackup -D /var/lib/postgresql/16/main \
  --pgdata=- ... # atau: tarik dari arsip pgBackRest / bucket
 
# 3. Pastikan WAL archive lengkap tersedia lokal
#    (misal rsync dari S3 ke /var/lib/postgresql/archive)
 
# 4. Bersihkan konfigurasi yang bisa mengganggu
rm /var/lib/postgresql/16/main/standby.signal   # kalau ada

Di postgresql.auto.conf (atau recovery.conf di versi 11 ke bawah):

restore_command = 'cp /var/lib/postgresql/archive/%f %p'
recovery_target_time = '2026-09-19 14:29:00+07'
recovery_target_action = 'promote'

# 5. Signal bahwa ini recovery
touch /var/lib/postgresql/16/main/recovery.signal
 
# 6. Start, PostgreSQL akan memutar WAL sampai target lalu promote
sudo systemctl start postgresql
 
# 7. Cek log: "recovery stopping before commit of transaction..."
#    Verifikasi tabel transaksi masih ada datanya

Kalau recovery_target_time meleset, kamu bisa mengulang dari base backup dengan target waktu berbeda. Karena itu penting menandai waktu kejadian dengan presisi sejak insiden dilapor.

#Object Storage sebagai Tujuan Backup

Object storage (S3, Cloudflare R2, Backblaze B2, Google Cloud Storage) adalah pilihan paling umum untuk salinan offsite: awet, murah di cold tier, dan API-nya terstandar.

#Fitur yang wajib kamu nyalakan

#Contoh lifecycle policy

# Aktifkan versioning
aws s3api put-bucket-versioning --bucket perusahaan-backup \
  --versioning-configuration Status=Enabled
 
# Retensi Object Lock mode governance 30 hari (compliance kalau mau lebih keras)
aws s3api put-object-retention --bucket perusahaan-backup \
  --key postgres/produk/2026-09-19.dump.enc \
  --retention '{"Mode":"GOVERNANCE","RetainUntilDate":"2026-10-19T00:00:00Z"}'
 
# Lifecycle: backup 30 hari lalu pindah ke Glacier
aws s3api put-bucket-lifecycle-configuration \
  --bucket perusahaan-backup \
  --lifecycle-configuration file://lifecycle.json

{
  "Rules": [
    {
      "ID": "archive-old-backups",
      "Status": "Enabled",
      "Filter": { "Prefix": "postgres/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    }
  ]
}

#Prinsip isolation kredensial

Skrip backup sebaiknya pakai IAM user atau role terpisah yang hanya bisa s3:PutObject ke bucket backup, tidak bisa DeleteObject atau DeleteObjectVersion. Kalau server aplikasi kena kompromi, attacker tidak bisa membersihkan jejak dengan menghapus backup. Ini bagian dari least privilege di cheat sheet /cheat-sheets/secrets-management-devops.

#RTO dan RPO per Skenario Bencana

Bukan semua bencana sama. Memetakan skenario membuat angka RTO/RPO kamu realistis, bukan angan-angan.

Perhatikan baris terakhir: tidak semua insiden diselesaikan dengan restore. Kebocoran kredensial butuh rotasi, dan itu dibahas di cheat sheet secrets management.

#Restore Testing: Backup yang Belum Diuji Belum Ada

Aturan paling keras di dunia backup: backup yang tidak pernah di-restore ke mesin lain itu belum terbukti. Skrip backup bisa sukses tiap malam sementara dump-nya korup semua.

#Test restore otomatis mingguan

#!/bin/bash
# restore-drill.sh: restore dump terbaru ke container sekali pakai, verifikasi, laporkan
set -euo pipefail
 
STAMP=$(date +%F-%H%M)
CONTAINER=drill-$STAMP
 
# Tarik dump terbaru dari bucket
LATEST=$(aws s3 ls s3://perusahaan-backup/postgres/produk/ --recursive \
  | sort | tail -1 | awk '{print $4}')
aws s3 cp "s3://perusahaan-backup/$LATEST" /tmp/drill.dump
 
# Dekripsi
sops --decrypt /tmp/drill.dump > /tmp/drill.dump.plain
 
# Jalankan Postgres sekali pakai dan restore
docker run -d --name "$CONTAINER" -e POSTGRES_PASSWORD=drill \
  -p 55432:5432 postgres:16
sleep 8
until docker exec "$CONTAINER" pg_isready -U postgres; do sleep 2; done
 
pg_restore -h localhost -p 55432 -U postgres -d postgres \
  --clean --if-exists -j 4 /tmp/drill.dump.plain
 
# Verifikasi: hitung baris tabel kunci, cocokkan dengan angka harapan
ROW_COUNT=$(docker exec "$CONTAINER" psql -U postgres -d postgres -tAc \
  "SELECT count(*) FROM transaksi")
if [ "$ROW_COUNT" -lt 1000000 ]; then
  echo "FAIL: transaksi cuma $ROW_COUNT baris, mestinya jutaan"
  exit 1
fi
 
echo "$(date -Is) DRILL PASS: $LATEST restore OK, transaksi=$ROW_COUNT"
docker rm -f "$CONTAINER"
rm /tmp/drill.dump*

Jalankan via cron mingguan dan kirim notifikasi kalau gagal. Yang kamu ukur dari tiap drill:

1. Berapa menit dari nol sampai data bisa dibaca? Itu RTO riil kamu.
2. Data sampai kapan yang ada? Itu RPO riil kamu.
3. Apakah ada yang menghalangi (kredensial hilang, langkah tidak terdokumentasi, kapasitas kurang)?

Catat hasil drill. Kalau target RTO 2 jam tapi drill selalu 4 jam, kamu punya dua pilihan: perbaiki prosesnya atau jujur revisi targetnya.

#Menulis Runbook DR

Runbook adalah resep langkah demi langkah yang bisa dijalankan orang yang panik jam 3 pagi. Cirinya: konkret, bernomor, tanpa keputusan yang harus dipikirkan saat itu.

#Struktur runbook yang baik

1. Trigger        : gejala apa yang memanggil runbook ini
2. Impact         : apa yang terkena, estimasi user affected
3. Pre-checks     : cara konfirmasi diagnosis (perintah + output yang diharapkan)
4. Keputusan      : siapa berwenang mendeklarasikan disaster
5. Langkah restore: perintah konkret, urut, dengan estimasi waktu tiap langkah
6. Verifikasi     : query/endpoint apa yang harus hijau sebelum dinyatakan pulih
7. Komunikasi     : siapa yang mengabarkan user, status page, channel mana
8. Post-mortem    : kapan, siapa, apa template laporannya

#Contoh runbook: restore PostgreSQL dari arsip WAL

RUNBOOK: PITR PostgreSQL Produksi (RB-DR-001)
Terakhir direvisi: 2026-09-19 | Owner: tim infra | Terakhir drill: 2026-09-05 (PASS, 47 menit)
 
TRIGGER
- Data hilang setelah migrasi/deploy (tabel kosong, row count anjlok)
- DBA melaporkan transaksi rusak yang tidak bisa diperbaiki aplikasi
 
PRE-CHECKS (5 menit)
1. catatan waktu kejadian: kapan persisnya perintah buruk jalan?
   grep "DROP TABLE" /var/log/postgresql/*.log
2. Konfirmasi arsip WAL lengkap:
   aws s3 ls s3://perusahaan-backup/wal/ | tail -20
3. Konfirmasi base backup terakhir SEBELUM kejadian ada:
   aws s3 ls s3://perusahaan-backup/base/
 
LANGKAH (estimasi total 45-60 menit)
1. Deklarasikan incident, matikan write di aplikasi (mode maintenance)
2. stop postgresql, arsipkan data directory lama untuk forensik
3. Tarik base backup + WAL sesuai periode
4. Konfigurasikan recovery_target_time = 1 menit sebelum kejadian
5. touch recovery.signal, start postgresql
6. Pantau log sampai "database system is ready to accept connections"
 
VERIFIKASI
- psql: SELECT count(*) FROM transaksi; cocok dengan snapshot harian
- Aplikasi: smoke test transaksi kecil end-to-end
- Monitor error rate 30 menit pertama
 
ESKALASI
- Kalau WAL gap (arsip kurang): fallback ke dump malaman terakhir,
  laporkan RPO riil ke incident commander

Runbook yang tidak pernah dijalankan di drill akan berhenti jadi benar dalam hitungan bulan: path berubah, kredensial kedaluwarsa, ukuran data membuat estimasi meleset. Jadwalkan drill tiap kuartal dan update tanggal "terakhir drill" di header runbook.

#Monitoring Backup

Backup adalah sistem produksi juga. Yang perlu kamu pantau:

• Exit code job backup harian (bukan hanya file ada, tapi job sukses).
• Umur backup terbaru yang sukses: alert kalau lebih dari 25 jam.
• Ukuran dump: dump yang tiba-tiba mengecil drastis sering tanda data hilang, bukan kompresi bagus.
• Kelengkapan WAL: selisih antara arsip terbaru dan sekarang (RPO riil kamu).
• Hasil restore drill mingguan.
• Kapasitas disk arsip lokal: WAL yang menumpuk karena archive_command gagal bisa memenuhi disk dan menjatuhkan database utama.

Pola sederhana yang bisa dipakai: job backup menulis metrik ke file atau push gateway, dan alerting (misal cron check atau Prometheus) menyala kalau metrik berhenti update. Backup yang gagal diam-diam adalah mode kegagalan terburuk di area ini.

#Perbandingan Tools Backup PostgreSQL

Untuk database kecil sampai menengah (puluhan GB), pg_dump malaman ke S3 plus WAL archiving sederhana sering sudah cukup dan paling gampang dipahami. Di atas itu, atau begitu PITR jadi kebutuhan riil, pgBackRest layak dipelajari sejak awal.

#Checklist Kematangan DR

• Semua data produksi punya minimal 3 salinan di 2 media, 1 offsite
• Satu salinan immutable yang tidak bisa dihapus kredensial biasa
• Target RTO/RPO tertulis per layanan dan disepakati bisnis
• PITR dikonfigurasi dan terbukti jalan untuk database utama
• Restore drill terjadwal otomatis, hasilnya dicatat
• RTO/RPO hasil drill dibandingkan dengan target tiap kuartal
• Runbook tertulis untuk tiap skenario bencana utama
• Kredensial backup terisolasi dari kredensial aplikasi
• Backup terenkripsi at rest dan saat transit
• Alert menyala kalau backup gagal atau berhenti update

#Glosarium