Backup di Produksi

Database produksi tidak boleh dimatikan hanya demi keperluan administrasi — pengguna tidak akan menunggu jendela backup kita. Karena database SQLite adalah berkas biasa, godaan cp selalu mengintai, padahal kita sudah membuktikan pada Chapter Backup dan Restore bahwa salinan yang dibuat sembari database ditulis bisa kehilangan data. Chapter ini menyusun strategi backup produksi yang utuh pada tiga hal: terjadwal tanpa menghentikan aplikasi, diverifikasi secara otomatis, dan — untuk kebutuhan yang lebih ketat — berkelanjutan.

Titik Awal: .backup yang Aman #

Seluruh strategi di chapter ini berdiri di atas .backup, perintah yang bekerja lewat Online Backup API: engine menyalin halaman demi halaman, dan bila sumber berubah di tengah proses, penyalinan diulang hingga didapat salinan konsisten. Chapter Backup dan Restore sudah membuktikannya berjalan aman ketika penulis lain sedang menahan transaksi — hasilnya snapshot keadaan terakhir yang ter-commit. Alternatif VACUUM INTO yang sekaligus memadatkan berkas juga tersedia di chapter yang sama.

Terjadwal dengan cron dan Rotasi #

Pada server Linux, cron adalah penjadwal bawaan yang paling bisa diandalkan. Satu baris crontab berikut menjalankan backup setiap hari pukul 02:15:

15 2 * * * sqlite3 /var/lib/toko/toko.db ".backup /backup/toko-$(date +\%F).db"

Backup harian yang tidak dibersihkan lama-lama memenuhi disk, jadi pasangkan dengan rotasi. Simpan sebagai rotasi-backup.sh:

#!/bin/sh
# rotasi-backup.sh — hapus backup tertua di luar jumlah retensi
# pemakaian: ./rotasi-backup.sh 'backup/toko-*.db' 3
pola="$1"
simpan="$2"

ls -1 $pola 2>/dev/null | sort -r | tail -n +"$((simpan + 1))" | while read -r berkas; do
  rm -f "$berkas"
  echo "hapus: $berkas"
done

Kita uji dengan lima tanggal tetap, seolah lima hari backup sudah terkumpul:

rm -f toko.db
sqlite3 toko.db "CREATE TABLE pelanggan (id INTEGER PRIMARY KEY, nama TEXT NOT NULL, email TEXT NOT NULL);
INSERT INTO pelanggan VALUES (1,'Budi','[email protected]'),(2,'Siti','[email protected]'),(3,'Ani','[email protected]'),(4,'Rina','[email protected]');"
sqlite3 toko.db "SELECT count(*) FROM pelanggan;"

mkdir -p backup
for tgl in 2025-06-13 2025-06-14 2025-06-15 2025-06-16 2025-06-17; do
  sqlite3 toko.db ".backup backup/toko-$tgl.db"
done
ls -1 backup
./rotasi-backup.sh 'backup/toko-*.db' 3
ls -1 backup

Output yang Dihasilkan:

4
toko-2025-06-13.db
toko-2025-06-14.db
toko-2025-06-15.db
toko-2025-06-16.db
toko-2025-06-17.db
hapus: backup/toko-2025-06-14.db
hapus: backup/toko-2025-06-13.db
toko-2025-06-15.db
toko-2025-06-16.db
toko-2025-06-17.db

Mari kita bedah skrip rotasinya:

1. ls -1 $pola | sort -r: mendaftar semua backup dari yang terbaru — nama bertanggal ISO membuat urutan alfabetis sama dengan urutan waktu.
2. tail -n +4 (untuk simpan=3): membuang tiga baris pertama yang akan dipertahankan; sisanya adalah kandidat penghapusan.
3. while read -r berkas: menghapus satu per satu sambil mencetak nama berkasnya, sehingga log rotasi bisa diperiksa dari output cron.

Memverifikasi Backup Secara Otomatis #

Backup yang tidak pernah diuji hanyalah harapan sampai terbukti sebaliknya. Verifikasi minimal dua lapis: integritas berkas dan isi yang masuk akal. Simpan sebagai verifikasi-backup.sh:

#!/bin/sh
# verifikasi-backup.sh — buktikan backup bisa dibuka dan isinya utuh
berkas="$1"
sqlite3 "$berkas" "PRAGMA integrity_check;"
sqlite3 "$berkas" "SELECT 'pelanggan=' || count(*) FROM pelanggan;"

Jalankan pada backup terbaru hasil rotasi di atas:

./verifikasi-backup.sh backup/toko-2025-06-17.db

Output yang Dihasilkan:

ok
pelanggan=4

Baris ok membuktikan struktur berkas utuh secara menyeluruh — mekanisme integrity_check dibahas pada Chapter Integrity Check dan Perbaikan. Baris pelanggan=4 adalah pemeriksaan isi: jumlah baris yang diketahui tidak pernah mengecil memberi sinyal dini bila backup dibuat di saat yang salah. Jadwalkan verifikasi ini di cron juga, dan perlakukan output selain ok sebagai alarm — bukan catatan biasa.

Replikasi Berkelanjutan dengan Litestream #

Litestream adalah alat pihak ketiga (satu biner terpisah, bukan bagian dari SQLite) yang mengubah pola cadangan dari “sekali sehari” menjadi “hampir seketika”. Cara kerjanya bersandar pada mekanisme WAL yang sudah kita kenal: transaksi yang sudah di-commit menunggu di berkas -wal sebelum dipindahkan ke berkas utama pada checkpoint.

Litestream berjalan sebagai proses pendamping di mesin yang sama — aplikasi tidak diubah sama sekali. Prosesnya mengambil alih pengaturan checkpoint, memantau frame baru di WAL, dan mengirimkannya secara terus-menerus ke penyimpanan objek yang kompatibel dengan S3, dengan jeda hanya hitungan detik. Saat pemulihan, perintah litestream restore membangun ulang berkas database dari snapshot dasar plus seluruh frame WAL yang tersimpan — bahkan sampai titik waktu tertentu.

Posisinya harus dipahami jujur: ini adalah disaster recovery, bukan ketersediaan tinggi. Bila host mati, aplikasi tetap harus dipindahkan dan dijalankan ulang di mesin baru sebelum database bisa melayani lagi; yang terselamatkan adalah data hingga detik-detik terakhir, bukan nol gangguan. Tidak perlu memasangnya untuk memahami mekanismenya — yang penting adalah melihat bahwa WAL mengubah backup dari salinan berkas menjadi aliran transaksi.

Memilih Metode: RPO dan RTO #

Dua istilah ini membantu membandingkan pilihan di atas. RPO (Recovery Point Objective) adalah umur data maksimum yang boleh hilang; RTO (Recovery Time Objective) adalah lama maksimum pemulihan sebelum aplikasi hidup lagi.

Terakhir, ikuti prinsip 3-2-1: sediakan tiga salinan data, pada dua media berbeda, dengan satu salinan di lokasi terpisah. Contoh pemetaannya pada SQLite: berkas aktif toko.db di server, backup harian di disk cadangan mesin yang sama, dan aliran Litestream ke penyimpanan objek di region lain. Kebijakan backup yang seperti inilah yang membuat “satu berkas” menjadi kekuatan, bukan titik lemah — sampai suatu hari data atau bebannya menuntut lebih dari yang bisa diberikan SQLite.