Belajar Borg Backup - Backup Database Konsisten

#Pendahuluan

Di episode 9 kita mengotomasi backup dengan borgmatic. Sekarang tantangan paling licin: database. Menyalin file data database mentah seperti memotret buku yang sedang dibuka — tulisannya setengah pindah, konsistensinya rusak. Backup database harus dibuat melalui mekanisme yang menjamin konsistensi: dump atau snapshot yang memperhitungkan WAL. Episode ini mengajarkan pola yang benar untuk PostgreSQL, MySQL/MariaDB, dan service file.

#Kenapa Backup Database Berbeda

#Masalah File yang Sedang Ditulis

Database menulis halaman halaman data ke disk secara terus-menerus. Jika backup menyalin file database saat transaksi berlangsung, hasilnya bisa berupa campuran versi halaman yang saling menolak — restore menghasilkan database korup.

#Peran WAL dan Dump

• WAL (Write-Ahead Log): database PostgreSQL mencatat semua perubahan ke WAL sebelum menulis data aktual. Snapshot filesystem + WAL bisa menghasilkan point-in-time recovery — konsisten, tetapi kompleks.
• Logical dump (pg_dump/mysqldump): membaca database melalui API database dengan transaksi baca — menghasilkan file teks/SQL yang konsisten pada satu titik waktu. Ini cara paling sederhana dan paling umum.

Rekomendasi praktis untuk mayoritas workload: dump dulu, lalu backup file dump-nya. Borg tidak perlu tahu bahwa itu database — ia cukup menyimpan file dump yang konsisten.

#Pola Hook: Dump Sebelum, Bersihkan Sesudah

#dengan borgmatic

Langkah 1 — pastikan direktori dump ikut di source_directories:

source_directories:
  - /home
  - /etc
  - /var/backups/db

Langkah 2 — definisikan hook:

hooks:
  before_backup:
    - pg_dump -U backup_user appdb | gzip > /var/backups/db/appdb.sql.gz
    - mysqldump --all-databases --single-transaction | gzip > /var/backups/db/mysql.sql.gz
  after_backup:
    - rm -f /var/backups/db/appdb.sql.gz /var/backups/db/mysql.sql.gz
  on_error:
    - echo "Backup database GAGAL" >&2

Alurnya: dump dibuat → borgmatic membackup direktori /var/backups/db → hook after_backup membersihkan dump agar tidak menggunung.

#Catatan per Mesin Database

• PostgreSQL: pg_dump -U backup_user appdb — konsisten per-database. Untuk seluruh cluster, pg_dumpall. Pastikan user backup_user punya hak baca (SELECT).
• MySQL/MariaDB: mysqldump --all-databases --single-transaction — --single-transaction memberi snapshot konsisten untuk InnoDB tanpa mengunci seluruh tabel.
• Perintah dari borgmatic: pastikan pg_dump/mysqldump ada di PATH user yang menjalankan borgmatic (root biasanya aman).

#dengan borg plain (tanpa borgmatic)

Tanpa borgmatic, pola yang sama dicapai dengan shell script + cron:

#!/usr/bin/env bash
set -euo pipefail
 
pg_dump -U backup_user appdb | gzip > /var/backups/db/appdb.sql.gz
mysqldump --all-databases --single-transaction | gzip > /var/backups/db/mysql.sql.gz
 
export BORG_REPO=/backup/borg
export BORG_PASSCOMMAND='cat /root/.borg-passphrase'
borg create --stats /backup/borg::"{hostname}-{now}" /home /etc /var/backups/db
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6
borg compact
 
rm -f /var/backups/db/appdb.sql.gz /var/backups/db/mysql.sql.gz

#Dukungan Database Native di borgmatic

Borgmatic juga memiliki dukungan bawaan untuk database — ia mengelola dump dan restore sendiri tanpa perlu hook manual:

postgresql_databases:
  - name: appdb
    hostname: localhost
    username: backup_user
 
mysql_databases:
  - name: all

Dengan konfigurasi ini, borgmatic membuat dump database ke lokasi sementara, membackupnya, lalu membersihkannya — plus kemampuan borgmatic restore --database untuk restore terarah. Untuk mulai, pola hook manual lebih eksplisit; native dukungan lebih ringkas dan terdokumentasi.

#Kasus Lain: Service File

Untuk service yang datanya berupa file (Nextcloud, GitLab, aplikasi PHP) ada nuansa yang berbeda:

• Pastikan transaksi berhenti: untuk Nextcloud, matikan mode maintenance atau pakai occ maintenance:mode --on saat backup.
• Gunakan snapshot filesystem (LVM/ZFS) bila memungkinkan: snapshot memberi point-in-time yang konsisten, lalu backup snapshot tersebut.
• Data file vs metadata DB: banyak aplikasi memisahkan file user dan database. Backup keduanya dalam jendela yang berdekatan, atau gunakan fitur built-in (misal GitLab backup rakit) yang menyelaraskan keduanya.

#Pitfall Umum

• Backup file database mentah: hampir pasti korup. Selalu dump atau snapshot.
• Dump di direktori yang tidak dibackup: dump dibuat tapi tidak termasuk source_directories — percuma.
• Dump tidak dibersihkan: dump menumpuk dan menduplikasi data yang sama setiap hari — buang dengan after_backup.
• Mengabaikan user dan privilege: jalankan dump dengan user khusus, bukan root DB.
• Melupakan restore test database: restore dump ke instance kosong setiap bulan untuk memastikan dump masih valid (dan formatnya masih didukung versi DB yang dipakai).

#Penutup

• Database harus dibackup lewat dump/snapshot, bukan salinan file mentah.
• Pola hook: before_backup membuat dump, after_backup membersihkan.
• pg_dump untuk PostgreSQL; mysqldump --single-transaction untuk MySQL/MariaDB.
• borgmatic punya dukungan native postgresql_databases dan mysql_databases.
• Service file butuh maintenance mode atau snapshot agar konsisten.
• Selalu uji restore dump secara berkala.

Di episode 11 kita membawa backup keluar dari server: Borg di Remote Server (SSH) — repository di host lain lewat borg serve, setup SSH key dengan restricted command, dan praktik keamanan seperti dedicated user tanpa password dan seccomp bawaan Borg.