Belajar Restic - Backup Database & Aplikasi Konsisten

#Pendahuluan

Di episode 9 script backup kalian sudah berjalan otomatis. Tapi ada satu kelas data yang membuat backup naif berbahaya: database. Menyalin file .frm, .ibd, atau base/... selagi database menulis adalah resep korupsi — file yang setengah tertulis menghasilkan restore yang tak bisa dibuka.

Episode ini membedah mengapa konsistensi itu penting, dan bagaimana mengombinasikan tool resmi database (pg_dump/mysqldump) dengan restic.

#Filesystem Snapshot ≠ Logical DB Backup

Mengapa kita tidak bisa sekadar restic backup /var/lib/postgresql? Karena database menggunakan buffer pool dan WAL: data di file bisa saja dalam keadaan mid-write, dan file yang dikopi tanpa pemahaman urutan WAL tidak dijamin konsisten. Restore-nya bisa sukses, tapi database menolak start.

Prinsipnya: backup logical (dump SQL) untuk konsistensi, backup filesystem untuk kecepatan — dan keduanya tidak bisa saling menggantikan.

#Peran WAL dalam Konsistensi

PostgreSQL menulis perubahan ke WAL (Write-Ahead Log) sebelum ke data file. Backup filesystem yang konsisten harus mencakup data + WAL yang cukup, atau memakai mekanisme seperti pg_basebackup dengan --wal-method=stream.

Untuk MySQL/MariaDB, analoginya redo/undo log. Karena menangani ini benar-benar rumit, praktik yang disarankan untuk kebanyakan tim adalah dump logical — cara paling mudah diverifikasi dan di-restore.

#Pre/Post Hooks dengan Staging Directory

Pola yang bersih: pg_dump/mysqldump menulis ke staging directory, lalu restic membackup staging itu — bukan file data database langsung:

pg_dump -Fc -f /var/backup/staging/appdb.dump appdb
mysqldump --single-transaction --routines --triggers \
  -u backup -p"$MYSQL_PW" appdb > /var/backup/staging/appdb.sql

Lalu backup staging:

restic backup /var/backup/staging --tag db-daily

Karena dump adalah file teks/biner yang tervalidasi, restore-nya deterministik: pg_restore atau mysql < file.sql selalu bisa berhasil selama dump-nya utuh.

#--single-transaction untuk MySQL

Flag --single-transaction membuat dump membaca snapshot InnoDB yang konsisten tanpa mengunci tabel — tanpa ini, dump bisa mencampur data dari titik waktu berbeda.

#Backup PostgreSQL

Untuk PostgreSQL, dua pendekatan layak dipakai:

pg_dump -Fc -f /var/backup/staging/appdb.dump appdb
restic backup /var/backup/staging --tag db-daily

Format -Fc (custom) mendukung selective restore dan kompresi — cocok untuk repository besar. Restore:

restic dump latest /var/backup/staging/appdb.dump | pg_restore -d appdb

restic dump ke stdout lalu pipe ke pg_restore — tidak perlu menginstal dump ke disk. Untuk skala besar, pertimbangkan pg_basebackup + WAL archive; itu topik tersendiri di series lain.

#Backup MySQL/MariaDB

mysqldump --single-transaction --routines --triggers \
  -u backup -p"$MYSQL_PW" appdb > /var/backup/staging/appdb.sql
restic backup /var/backup/staging --tag db-daily

Restore:

restic dump latest /var/backup/staging/appdb.sql | mysql -u root appdb

#Backup File Aplikasi

Selain database, jangan lupa file aplikasi: kode, upload, config. Back up bersama snapshot biasa:

restic backup /var/www /etc/nginx --tag app-daily

Perhatikan pembedaan: --tag db-daily untuk dump, --tag app-daily untuk file. Tag memungkinkan retention berbeda (episode 8) — database mungkin butuh riwayat lebih panjang daripada file build yang bisa diunduh ulang.

#Penutup

• Filesystem snapshot database tanpa memahami WAL berisiko restore korup.
• Backup logical (pg_dump/mysqldump) = konsistensi yang bisa diverifikasi.
• Pola staging dir: dump → staging → restic backup staging — bukan file data DB.
• --single-transaction membuat dump MySQL konsisten tanpa lock.
• Restore lewat pipe: restic dump ... | pg_restore/mysql.
• Pisahkan tag DB vs aplikasi agar retention bisa diatur terpisah.

Di episode 11 selanjutnya kita menguji kepercayaan: check & integrity verification — restic check untuk konsistensi repo, --read-data untuk verifikasi seluruh blob, penjadwalan berkala, audit dengan restic cat config, serta restore drill ke host lain.