Tahun 2021 saya menulis cara dump dan backup MySQL ke DigitalOcean Spaces dengan s3cmd dan cron. Skrip itu masih berjalan, tetapi ada satu kelemahan besar: jika penyerang mendapatkan kredensial yang sama, backup juga bisa dihapus atau dienkripsi. Ransomware modern memang sengaja memburu backup terlebih dahulu.
Prinsip 3-2-1 plus immutability
Simpan 3 salinan data, di 2 media berbeda, 1 di luar lokasi. Tambahkan satu syarat: salah satu salinan harus immutable, yaitu tidak bisa diubah atau dihapus sampai masa retensinya habis.
1. Buat bucket dengan Object Lock
Pilih penyedia object storage yang mendukung Object Lock (misalnya AWS S3 atau penyedia S3-compatible lain yang mendukungnya). Object Lock harus diaktifkan saat bucket dibuat.
aws s3api create-bucket --bucket backup-db-lrsoft --object-lock-enabled-for-bucket
aws s3api put-object-lock-configuration --bucket backup-db-lrsoft --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'
2. Skrip backup yang diperbarui
Kredensial database disimpan di file terpisah, bukan di skrip. Akun object storage yang dipakai cukup punya izin upload, tanpa izin hapus.
#!/bin/bash
set -euo pipefail
TGL=$(date +%F_%H%M)
FILE="/tmp/db_${TGL}.sql.gz"
mysqldump --defaults-extra-file=/root/.backup.cnf --single-transaction --routines nama_db | gzip > "$FILE"
aws s3 cp "$FILE" s3://backup-db-lrsoft/mysql/
rm -f "$FILE"
Jadwalkan seperti sebelumnya dengan cron, misalnya setiap tengah malam.
3. Uji restore
Backup yang tidak pernah diuji belum bisa disebut backup. Minimal sebulan sekali, pulihkan ke database uji:
gunzip < db_2026-09-25_0000.sql.gz | mysql nama_db_uji
Dengan Object Lock, serangan terburuk pun hanya bisa menghapus data di server, bukan jaring pengaman kita.
