Backup Server Otomatis: Strategi 3-2-1 dengan Restic, S3, dan Recovery Testing

Banyak admin server baru sadar pentingnya backup saat data sudah hilang — dan tidak bisa dikembalikan. Ransomware, human error, hardware failure, bencana alam — ancaman terhadap data server sangat nyata. Artikel ini membangun sistem backup yang benar dari awal: strategi, tool, implementasi, dan testing.

Strategi 3-2-1: Standar Emas Backup

3 salinan data — data asli + 2 backup. 2 media berbeda — jangan simpan backup di disk yang sama dengan data asli. 1 salinan offsite — di luar lokasi fisik server utama (bisa cloud, DC berbeda, atau rumah).

Rasional: jika server terbakar, backup di server yang sama ikut terbakar. Jika cloud provider region down, backup di region berbeda tetap aman. Strategi 3-2-1 memastikan satu backup selalu selamat dalam skenario apapun.

Kenapa Restic?

Restic adalah modern backup tool dengan fitur unggulan:

**Deduplication** — Hanya data unik yang disimpan. File yang sama di backup berbeda tidak memakan ruang ganda. Restorasi file lama pun efisien karena blok data sudah ada.

**Encryption** — AES-256-GCM untuk data at-rest. Bahkan penyedia storage S3 pun tidak bisa membaca data Anda. Password encryption disimpan di password manager terpisah.

**Incremental Backup** — Hanya perubahan sejak backup terakhir. Cepat dan hemat bandwidth. Restic secara otomatis mendeteksi blok data yang berubah.

**Multi-Backend** — Local directory, SFTP, S3 (AWS, MinIO, DigitalOcean Spaces, Backblaze B2), REST server, Google Cloud Storage, Azure Blob Storage — pilih sesuai kebutuhan.

**Snapshots** — Setiap backup adalah snapshot yang bisa di-list, di-restore, atau dibandingkan. Lihat daftar snapshot: restic snapshots. Bandingkan dua snapshot: restic diff snapshot1 snapshot2.

Implementasi: Backup ke S3

Setup Repository

install restic. Init repository: restic init --repo s3:https://s3.ap-southeast-1.amazonaws.com/your-bucket. Masukkan encryption password (simpan aman — tanpa password, data tidak bisa direstore).

Backup Data

restic backup /var/www /etc /home --repo s3:... --exclude='*.log' --exclude='*/cache/*'. Gunakan --exclude untuk folder yang tidak perlu di-backup (cache, logs, temporary files).

Backup Database

Database perlu perlakuan khusus — dump dulu, baru backup:

Untuk PostgreSQL: pg_dumpall -U postgres | gzip > /tmp/db-dump.sql.gz; restic backup /tmp/db-dump.sql.gz --repo s3:...; rm /tmp/db-dump.sql.gz

Untuk MySQL: mysqldump --all-databases --single-transaction | gzip > /tmp/mysql-dump.sql.gz; restic backup /tmp/mysql-dump.sql.gz --repo s3:...; rm /tmp/mysql-dump.sql.gz

Automasi dengan Script

Buat script /usr/local/bin/backup.sh yang:1. Dump database ke file temporary

2. Jalankan restic backup untuk direktori data dan file dump

3. Hapus file temporary

4. Jalankan restic forget untuk retensi (keep-daily 7, keep-weekly 4, keep-monthly 6)

5. Prune blok data yang sudah tidak direferensi

Set cron: 0 2 * * * root /usr/local/bin/backup.sh (setiap jam 2 pagi). Kirim notifikasi ke email/Telegram jika backup gagal.

Snapshot Management dan Retensi

Tentukan kebijakan retensi berdasarkan kebutuhan: daily backup — simpan 7 hari (rollback kesalahan kemarin). weekly backup — simpan 4 minggu (recovery dari bug yang terdeteksi seminggu kemudian). monthly backup — simpan 6-12 bulan (audit compliance atau recovery dari insiden besar).

Restic forget command: restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune. Flag --prune akan menghapus blok data yang tidak lagi direferensi oleh snapshot manapun.

Restore Testing: Backup yang Tidak Bisa Direstore = Tidak Punya Backup

Fakta menyedihkan: 50% backup di organisasi tidak bisa direstore. Penyebab: corruption, format tidak kompatibel, encryption key hilang, atau backup tidak lengkap.

Solusi: jadwalkan restore testing otomatis:

1. Restore snapshot terbaru ke direktori test: restic restore latest --target /tmp/restore-test --repo s3:...

2. Verifikasi integritas file: diff antara file asli dan hasil restore

3. Jika database: coba restore dump ke database test dan jalankan query verifikasi

4. Kirim laporan: berapa file di-restore, ada error atau tidak, berapa lama prosesnya

5. Jika gagal: alert immediate ke tim ops

Integrasi dengan Monitoring

Metrics backup yang harus dimonitor: backup duration — apakah makin lama? (indikasi data growth). backup size — ukuran data setelah deduplication. last successful backup — jika >24 jam tanpa backup sukses, alert. restore test result — pass/fail. repository health — restic check secara berkala untuk verifikasi integritas.

Integrasikan dengan Prometheus: buat textfile collector exporter dengan metrics dari script backup. Dashboard Grafana untuk overview status backup seluruh server.

Kesimpulan

Sistem backup yang benar: restic + S3 untuk storage (dedup, encrypted, offsite), automasi dengan cron, retensi policy 7-4-6, restore testing bulanan, dan monitoring integritas. Jangan setengah-setengah — backup yang tidak pernah di-test adalah false sense of security. Mulai hari ini. Besok mungkin sudah terlambat.