Backup 3-2-1 Praktis untuk VPS dengan Restic dan Object Storage

Provider VPS itu andal sampai suatu hari tidak. Disk mati, akun tersuspensi gara-gara masalah tagihan, datacenter kebakaran — kebakaran OVH Strasbourg 2021 mengubah banyak strategi backup satu-salinan menjadi postmortem dalam semalam. Pertanyaan tidak nyaman bagi siapa pun yang menjalankan workload production di server sewaan itu sederhana: kalau VPS ini menguap sekarang juga, berapa jam data yang saya hilang, dan berapa lama sampai saya melayani traffic lagi?

Jawaban saya untuk pertanyaan itu adalah aturan 3-2-1 yang diimplementasikan dengan restic dan object storage S3-compatible, dan biayanya hanya beberapa dolar per bulan untuk beberapa server. Artikel ini adalah setup lengkapnya: apa yang sebenarnya dituntut aturan itu, script persis yang saya jalankan tiap malam, kenapa database butuh perlakuan khusus, berapa biayanya, dan latihan restore yang memisahkan sistem backup dari sekadar perasaan aman.

Apa yang Sebenarnya Dituntut 3-2-1

Aturan ini, dipopulerkan Backblaze dan sebelumnya oleh fotografer Peter Krogh, adalah standar minimum, bukan standar emas:

Untuk fleet VPS, terjemahan saya: data live di server, snapshot restic malam hari di object storage pada provider berbeda, dan salinan restic kedua yang disinkronkan ke disk di rumah atau kantor. Penyempurnaan era ransomware seperti 3-2-1-1-0 menambah salinan offline atau immutable dan nol error verifikasi — dan bagian verifikasinya, setidaknya, tidak bisa ditawar di setup saya, seperti akan Anda lihat di script di bawah.

Menentukan Apa yang Di-backup (dan Apa yang Tidak)

Mem-backup seluruh image VPS adalah default pemalas dan kebanyakan mubazir — OS dan paket bisa direproduksi dari playbook Ansible Anda dalam hitungan menit. Saya hanya mem-backup yang tidak bisa dibangun ulang:

• State aplikasi: file upload, dokumen hasil generate, apa pun di bawah /srv yang dibuat user dan akan terasa hilang.
• Dump database — sebagai file dump, jangan pernah sebagai direktori data mentah (lebih lanjut di bawah).
• Konfigurasi yang melenceng dari otomasi: /etc, sertifikat, crontab dan file env yang entah bagaimana tidak pernah masuk git.
• Password restic dan config repository itu sendiri, disimpan terpisah di password manager — backup terenkripsi yang tidak bisa Anda dekripsi adalah generator angka acak yang sangat mahal.

Setup Restic: Terenkripsi, Terdeduplikasi, Murah

Restic adalah pilihan saya karena mencentang semua kotak sekaligus: enkripsi sisi klien secara default, deduplikasi content-defined yang membuat snapshot inkremental tetap mungil, dan dukungan native untuk backend S3-compatible — AWS S3, Google Cloud Storage, Backblaze B2, MinIO, Wasabi — plus SFTP dan rclone untuk sisanya. Setup-nya adalah init sekali jalan:

# one-time setup: encrypted repo on S3-compatible storage
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://storage.googleapis.com/my-backup-bucket
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic init

Job malam harilah tempat strategi sesungguhnya hidup. Punya saya adalah shell script pendek yang digerakkan systemd timer, dan setiap barisnya pantas ada di sana:

#!/usr/bin/env bash
# /usr/local/bin/backup.sh — runs nightly via systemd timer
set -euo pipefail

# 1. dump databases to files restic can snapshot
pg_dumpall -U postgres | gzip > /var/backups/pg/all.sql.gz

# 2. snapshot app data + dumps (deduplicated, encrypted)
restic backup /var/backups/pg /srv/app/uploads /etc \
  --exclude="*.tmp" --tag nightly

# 3. enforce retention, prune unreferenced data
restic forget --keep-daily 7 --keep-weekly 4 \
  --keep-monthly 6 --prune

# 4. verify a sample of the repo actually restores
restic check --read-data-subset=5%

# 5. heartbeat to Uptime Kuma — silence means broken
curl -fsS https://status.example.com/api/push/abc123 > /dev/null

Langkah empat dan lima adalah yang paling sering dilewati. Check dengan read-data-subset mengunduh dan memverifikasi secara kriptografis 5 persen acak data repository tiap malam, jadi korupsi senyap tertangkap dalam hitungan minggu, bukan saat restore. Heartbeat Uptime Kuma di akhir membalik alerting-nya: saya tidak dinotifikasi saat backup sukses, saya di-page saat sinyal sukses berhenti datang — yang juga menangkap mode gagal di mana cron-nya sendiri yang mati.

Memetakan Salinan ke Infrastruktur Nyata

Begini tiga salinan itu mendarat di provider untuk setup klien tipikal, dengan biaya bulanan untuk kira-kira 50 GB data backup terdeduplikasi:

Latihan Restore: Tempat Sistem Backup Menjadi Nyata

Backup yang belum diuji adalah hipotesis. Dua kali setahun, per server, saya menjalankan latihan penuh terhadap VPS sekali pakai dan menghitung waktunya:

1. Provision VPS bersih dari playbook Ansible dasar — ini sekaligus memvalidasi ulang bahwa provisioning masih bekerja dari nol.
2. Install restic, restore snapshot terakhir dengan restic restore latest, dan muat dump database ke PostgreSQL yang segar.
3. Jalankan stack aplikasi terhadap data hasil restore dan jalankan smoke test yang sama dengan yang dipakai pipeline deploy.
4. Catat total wall time dan jarak timestamp snapshot. Dua angka itu adalah recovery time dan recovery point Anda yang sesungguhnya — taruh di runbook, bukan di optimisme Anda.

Empat Kesalahan yang Paling Sering Saya Lihat

• Backup disimpan di provider yang sama dengan production. Satu akun tersuspensi atau outage regional mengambil keduanya. Off-site berarti failure domain berbeda, bukan folder berbeda.
• Tanpa kebijakan retensi. Disk penuh atau tagihan membengkak sampai seseorang menghapus backup secara manual, biasanya yang tertua, biasanya tepat sebelum dibutuhkan. Baris forget/prune adalah kebijakan sebagai kode.
• Kredensial dengan izin delete pada bucket backup tergeletak di server production. VPS yang dibobol lalu bisa menghancurkan backup-nya sendiri — pakai kredensial append-only atau object lock level bucket di provider yang mendukungnya.
• Alerting lewat email kegagalan. Alert kegagalan bergantung pada sistem yang gagal masih cukup sehat untuk mengirimnya. Monitoring heartbeat — alert saat sinyal sukses absen — secara ketat lebih andal dan sepele dibuat dengan push monitor Uptime Kuma.

Intinya

Setup 3-2-1 sungguhan untuk VPS adalah kerja satu malam: restic init ke bucket object storage, script malam dua puluh baris berisi dump, snapshot, retensi, verifikasi, dan heartbeat, plus salinan kedua di tempat yang Anda kontrol secara fisik. Biayanya dibulatkan jadi secangkir kopi per bulan, dan imbalannya adalah hari infrastruktur terburuk dalam setahun Anda — kebakaran provider, ransomware, rm yang salah ketik — menjadi restore dua jam yang terdokumentasi dan terlatih, bukan peristiwa karier. Backup-lah seolah disk itu sudah mulai rusak, karena di suatu tempat di fleet Anda, memang iya.