Backup Database: Strategi Full vs Incremental

Setiap kali saya masuk ke sistem baru, salah satu pertanyaan pertama yang saya ajukan bukan soal fitur, tapi soal backup: kapan terakhir di-restore, dan berapa lama prosesnya. Di lingkungan klinik atau rumah sakit, data pasien tidak boleh hilang barang semenit pun secara logis — tapi anggaran storage dan waktu maintenance tetap terbatas. Di titik itulah strategi full backup versus incremental backup jadi keputusan yang nyata, bukan sekadar teori.

Banyak tim baru sadar strategi backup-nya salah justru saat butuh restore darurat, bukan saat backup berjalan mulus tiap malam. Artikel ini membahas trade-off utamanya supaya keputusan itu diambil sebelum insiden, bukan sesudahnya.

Full Backup: Sederhana tapi Berat

Full backup menyalin seluruh isi database setiap kali dijalankan. Kelebihannya jelas: proses restore jadi paling sederhana secara konsep — tinggal ambil satu file backup, load, selesai. Tidak ada rantai dependency ke file backup lain.

Konsekuensinya ada di dua sisi. Pertama, ukuran storage membengkak cepat kalau database besar dan retensi backup-nya panjang. Sebagai ilustrasi, kalau database berukuran puluhan gigabyte dan kita simpan full backup harian selama sebulan, kebutuhan storage bisa berkali-kali lipat ukuran database itu sendiri. Kedua, waktu eksekusi backup itu sendiri bisa memakan resource cukup besar — I/O disk dan CPU tertarik selama proses dump berjalan, yang idealnya dijadwalkan di luar jam sibuk.

Contoh perintah dasar untuk MySQL/MariaDB:

mysqldump -u backup_user -p --single-transaction \
  nama_database > backup_full_$(date +%Y%m%d).sql

Flag --single-transaction penting untuk engine InnoDB supaya dump konsisten tanpa mengunci tabel secara penuh — ini prinsip umum yang tetap relevan di berbagai versi MySQL/MariaDB.

Incremental Backup: Hemat Ruang, Rumit di Restore

Incremental backup hanya menyimpan perubahan sejak backup terakhir — baik itu full backup atau incremental sebelumnya. Untuk database relasional, ini biasanya memanfaatkan binary log (MySQL) atau write-ahead log (PostgreSQL) yang mencatat setiap transaksi.

Keuntungannya jelas dari sisi storage dan waktu backup: kalau perubahan harian relatif kecil dibanding ukuran total database, incremental jauh lebih ringan dan cepat dijalankan. Ini juga membuka opsi point-in-time recovery — restore ke kondisi database persis sebelum sebuah kejadian terjadi, bukan hanya ke titik backup terakhir.

Tapi ada harga yang harus dibayar saat restore. Proses restore incremental butuh urutan yang benar: mulai dari full backup terakhir, lalu terapkan setiap incremental secara berurutan sampai titik waktu yang diinginkan. Kalau satu file di rantai itu korup atau hilang, seluruh rantai setelahnya jadi tidak bisa dipakai. Semakin panjang rantainya, semakin lama pula waktu restore total karena setiap log perubahan harus diputar ulang.

Untuk PostgreSQL, pendekatan yang umum dipakai adalah kombinasi base backup plus WAL archiving:

-- konfigurasi dasar di postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'cp %p /path/ke/arsip/wal/%f'

Dari sana, base backup diambil secara berkala dan WAL yang diarsipkan menjadi incremental-nya.

Memilih Strategi yang Realistis

Dalam praktik, saya jarang menemukan sistem yang memakai murni salah satu pendekatan. Pola yang lebih umum dan lebih tahan lama adalah kombinasi: full backup dengan interval tertentu (misalnya mingguan) digabung dengan incremental di antaranya (misalnya harian, atau bahkan mendekati real-time lewat log shipping). Ini menyeimbangkan dua hal sekaligus — restore tidak perlu memutar ulang rantai yang terlalu panjang, sementara storage tetap terkendali.

Beberapa pertimbangan praktis yang saya pakai sebagai checklist:

  • Seberapa besar toleransi kehilangan data (Recovery Point Objective) — makin ketat, makin sering incremental atau log shipping dibutuhkan.
  • Seberapa cepat sistem harus pulih (Recovery Time Objective) — rantai incremental yang panjang memperlambat ini.
  • Backup tidak berarti apa-apa kalau belum pernah dicoba restore. Latihan restore berkala, idealnya ke lingkungan terpisah, adalah bagian yang sering diabaikan padahal paling krusial.
  • Simpan backup di lokasi yang terpisah secara fisik/logis dari server produksi, supaya satu insiden (disk rusak, ransomware) tidak menghapus keduanya sekaligus.

Takeaway

Full backup itu sederhana dan aman secara konsep, tapi mahal di storage dan waktu eksekusi. Incremental hemat resource dan mendukung point-in-time recovery, tapi menambah kompleksitas dan risiko di sisi restore. Strategi yang paling realistis untuk kebanyakan sistem produksi bukan memilih salah satu secara ekstrem, melainkan mengombinasikan keduanya sesuai kebutuhan RPO dan RTO — dan yang tidak kalah penting, memvalidasi bahwa proses restore-nya benar-benar berjalan, bukan cuma berasumsi backup-nya baik-baik saja.