Backup VPS Otomatis: rsync, cron, dan Aturan 3-2-1

Kebanyakan pemilik VPS baru menyadari pentingnya backup tepat satu kali: setelah datanya hilang. Artikel ini memberi resep backup yang bisa dijalankan di server mana pun dengan biaya hampir nol: rsync inkremental, penjadwalan cron, rotasi retensi, uji restore, dan aturan 3-2-1.

1. Backup Bukan Salinan, Backup Adalah Kemampuan Memulihkan

Definisi kerja yang kami pakai: sebuah backup hanya sah bila Anda bisa menyebutkan perintah yang mengembalikannya dan pernah menjalankannya dengan sukses. Arsip .tar.gz berumur setahun di sudut disk yang tidak pernah dibuka punya nilai yang sama dengan tidak ada backup.

Tiga angka yang menentukan desain Anda:

• RPO (Recovery Point Objective) — toleransi kehilangan data. RPO 24 jam berarti backup harian cukup; RPO 15 menit berarti Anda butuh replikasi atau salinan sering.
• RTO (Recovery Time Objective) — toleransi lama pemulihan. Mengunduh 50 GB dari storage murah bisa memakan setengah hari; ini yang sering membuat RTO meledak.
• Jumlah salinan dan lokasinya — penentu ketahanan terhadap bencana satu gedung.

2. Aturan 3-2-1 untuk VPS Tunggal

Versi praktis yang terjangkau untuk server produksi kecil:

• 3 salinan data: satu produksi, dua arsip.
• 2 media berbeda: disk VPS itu sendiri dan storage kedua (bucket, NFS, server lain).
• 1 salinan off-site — wajib, karena VPS dan file backup di disk yang sama akan hilang bersamaan saat panel provider di-suspend, akun dibajak, atau disk fisik mati.

Tambahan yang bikin perbedaan saat insiden ransomware: minimal satu salinan bersifat immutable atau append-only, misalnya bucket dengan object lock, atau user rsync yang hanya boleh menulis tanpa boleh menghapus.

3. Backup Filesystem dengan rsync Inkremental

rsync hanya mengirim blok yang berubah, jadi backup ke-50 tidak lebih mahal dari backup pertama. Pola hard-link memberi Anda banyak snapshot "penuh" dengan kapasitas satu snapshot:

DEST=/mnt/backup/vps
PREV=$DEST/latest
DATE=$(date +%F_%H%M)

rsync -aHAX --numeric-ids --delete \
  --exclude '/proc' --exclude '/sys' --exclude '/dev' \
  --exclude '/run'  --exclude '/mnt' --exclude '/tmp' \
  --link-dest="$PREV" \
  / "$DEST/$DATE"

ln -sfn "$DEST/$DATE" "$DEST/latest"

Flag yang menentukan kualitas hasil:

• -a menyederhanakan -rlptgoD: symlink, permission, waktu, pemilik.
• -H mempertahankan hard link, penting untuk beberapa aplikasi mail dan repositori.
• -AX membawa ACL dan extended attribute.
• --numeric-ids mencegah UID terpetakan ke pengguna yang salah di sistem tujuan.
• --link-dest membuat snapshot hemat ruang; tanpa ini tiap run menyalin ulang semuanya.

--delete membuat salinan identik dengan sumber, tapi juga merambat ke bencana bila sumber sudah terlanjur terenkripsi ransomware. Karena itu kunci salinan off-site Anda ke mode append-only.

4. Backup Database dengan Konsisten

Mencopy file /var/lib/mysql saat server berjalan menghasilkan arsip rusak. Gunakan dump logis:

mariadb-dump --single-transaction --routines --triggers \
  --events --all-databases \
  | gzip -9 > /backup/db/mysql-$(date +%F).sql.gz

pg_dumpall -U postgres | gzip -9 > /backup/db/pg-$(date +%F).sql.gz

Untuk basis data besar, dump logis tidak cukup; kombinasikan dengan backup fisik:

• MySQL/MariaDB: xtrabackup atau mariabackup untuk salinan panas.
• PostgreSQL: pg_basebackup plus arsip WAL ke storage kedua.
• MongoDB: mongodump --oplog agar titik pemulihan konsisten.

Simpan dump database berdampingan dengan salinan file aplikasi. Memulihkan kode tanpa data, atau sebaliknya, akan membuat Anda bolak-balik selama berjam-jam.

5. Backup Konfigurasi dan Infrastruktur sebagai Kode

Bagian yang paling mahal untuk dibangun ulang bukan data, melainkan konfigurasi: sshd, nginx, firewall, unit systemd, crontab. Arsipkan semuanya ke repositori privat:

tar czf /backup/conf/etc-important.tgz \
  /etc/nginx /etc/ssh/sshd_config /etc/ssh/sshd_config.d \
  /etc/fail2ban /etc/ufw /etc/systemd/system /etc/cron.d /etc/cron.daily \
  /var/spool/cron/crontabs

rsync -a /backup/conf/ git@repo-lokal:server-config.git/ && \
  (cd /backup/conf && git add -A && git commit -m "conf $(date +%F)" -q)

Keuntungan tambahan: git log memberi riwayat perubahan konfigurasi, sehingga saat terjadi masalah Anda bisa menjawab "siapa yang mengubah ini, dan kapan".

6. Penjadwalan cron yang Tidak Saling Tabrakan

Contoh crontab yang rapi dan saling terkunci:

CRONLOG=/var/log/backup-cron.log

# 01:30 WITA: snapshot filesystem rsync (harian)
30 1 * * *  flock -n /run/backup-fs.lock /usr/local/bin/backup-fs.sh  >> $CRONLOG 2>&1
# 02:15 WITA: dump database, setelah snapshot file agar tidak berebut I/O
15 2 * * *  flock -n /run/backup-db.lock /usr/local/bin/backup-db.sh  >> $CRONLOG 2>&1
# 03:40 WITA: sinkronkan salinan ke storage off-site
40 3 * * *  flock -n /run/backup-sync.lock /usr/local/bin/backup-sync.sh >> $CRONLOG 2>&1
# 05:00 WITA: hapus snapshot lebih tua dari 14 hari, bulanan dipertahankan 12 bulan
0  5 * * *  /usr/local/bin/backup-prune.sh             >> $CRONLOG 2>&1

flock mencegah dua job berjalan bertumpuk saat sebuah backup melar melewati jatah waktunya. Jangan lupa chmod +x pada skrip dan gunakan path absolut, karena cron berjalan dengan environment minimal.

Untuk job yang mungkin memakan waktu lebih lama daripada intervalnya, systemd timer memberi keuntungan: RandomizedDelaySec untuk meratakan beban, dan Persistent=true yang tetap menjalankan job meski server sempat mati.

7. Rotasi dan Retensi

Simpan harian untuk memulihkan kesalahan terbaru, mingguan untuk memulihkan insiden yang baru ketahuan, bulanan untuk audit:

find /mnt/backup/vps -maxdepth 1 -name '20*' -mtime +14  -exec rm -rf {} +
find /mnt/backup/db  -name '*.sql.gz' -mtime +30 -delete

Skema granular (mis. rclone ke bucket dengan lifecycle) memberi pilihan retensi yang lebih murah daripada menyimpan semuanya di blok cepat. RPO menentukan frekuensi, harga menentukan lama penyimpanan; tetapkan keduanya sebelum skrip ditulis.

8. Enkripsi dan Verifikasi Integritas

Backup hampir selalu berisi data yang lebih sensitif daripada aplikasi itu sendiri. Enkripsi sebelum meninggalkan server:

tar czf - /var/www | age -r age1xxxx... -o /backup/www-$(date +%F).tar.gz.age
gpg --symmetric --cipher-algo AES256 -o /backup/db.tar.gz.gpg /backup/db.tar.gz

Simpan kunci recovery terpisah dari backup, idealnya di password manager organisasi. Lalu hitung sidik jari agar kerusakan senyap terdeteksi:

sha256sum /backup/db-$(date +%F).sql.gz >> /backup/checksums.txt

9. Uji Restore: Bagian yang Sering Dilompati

Minimal sebulan sekali, pulihkan ke lingkungan staging. Prosedur yang bisa diotomasi:

1. Buat VPS staging murah atau container kosong.
2. Tarik salinan tertentu secara acak, bukan backup terbaru.
3. Restore database dan file aplikasi, jalankan migrasi bila perlu.
4. Jalankan cek fungsional: login, satu transaksi, satu laporan.
5. Catat durasi pemulihan sebenarnya dan bandingkan dengan RTO Anda.

# contoh restore cepat di staging
rsync -aHAX --info=progress2 backup@storage:/mnt/backup/vps/2026-11-01_0130/ /restore/
gunzip -c /backup/db/mysql-2026-11-01.sql.gz | mariadb

Tempel hasilnya di dokumen kecil yang diperbarui tiap kuartal. Uji restore yang tidak tercatat sama dengan tidak pernah diuji.

10. Backup Image Panel dan Snapshot Provider

Snapshot level hypervisor dari provider sering dianggap cukup. Tidak selalu: snapshot biasanya berada di storage yang sama, bisa ikut terhapus lewat API yang sama dengan akun Anda, dan sering tidak bisa dipindah ke provider lain. Jadikan snapshot sebagai lapisan kenyamanan, bukan satu-satunya salinan. Bandingkan pilihan layanan di Shared Hosting vs VPS vs Dedicated Server sebelum memilih paket yang termasuk backup dikelola.

Kesimpulan

Backup yang baik itu membosankan dan berulang: rsync snapshot harian, dump database yang konsisten, konfigurasi di git, salinan off-site yang tidak bisa dihapus, cron yang dikunci flock, dan uji restore terjadwal. Bangun sekali, lalu lupakan perasaan bersalah. Karena saat krisis terjadi, yang membedakan pemulihan 30 menit dan kehilangan total bukan kecanggihan tools Anda, melainkan kapan terakhir kali Anda benar-benar mengujinya.

Artikel terkait: 10 Langkah Hardening VPS | Membaca Log Server dan Deteksi Intrusi