DevOps
Perencanaan Disaster Recovery untuk VPS: Backup, RTO, dan Pemulihan yang Benar-Benar Diuji
Oktober 202512 menit baca
DevOps
Saya mengalami bencana pada pukul 23.47 di hari Selasa. DigitalOcean Droplet yang menjalankan aplikasi web produksi klien tidak merespons — tidak ada SSH, tidak ada ping, tidak ada respons dari dashboard monitoring. Disk Droplet telah penuh 100% karena file log yang tidak dibatasi, yang merusak filesystem ext4. Tidak ada backup otomatis yang dikonfigurasi (kami memiliki snapshot manual tetapi yang terakhir berusia 18 hari). Pemulihan memakan waktu 4 jam dan mengakibatkan hilangnya data pengguna selama 3 hari. Setelah insiden tersebut, saya mengimplementasikan rencana disaster recovery yang tepat di setiap server yang kami kelola. Panduan ini adalah rencana tersebut.
Recovery Time Objective (RTO) adalah waktu maksimum yang dapat diterima dari deklarasi bencana hingga pemulihan layanan. Recovery Point Objective (RPO) adalah kehilangan data maksimum yang dapat diterima yang diukur dalam waktu — seberapa jauh Anda bisa mundur tanpa dampak bisnis yang tidak dapat diterima? Angka-angka ini mendorong setiap keputusan DR lainnya. Untuk API e-commerce yang menghadap pelanggan dengan data transaksi: RTO mungkin 1 jam, RPO 15 menit. Untuk dashboard pelaporan internal: RTO 8 jam, RPO 24 jam. Jangan mengonfigurasi backup dan mengasumsikan Anda sudah terlindungi — secara eksplisit setujui target RTO dan RPO dengan pemangku kepentingan dan rancang infrastruktur DR Anda untuk memenuhinya.
Tidak semua sistem membutuhkan investasi DR yang sama. Sistem Tier 1 (menghadap pelanggan, menghasilkan pendapatan, relevan dengan kepatuhan) membutuhkan target RTO (<1 jam) dan RPO (<1 jam) yang agresif — gunakan backup otomatis per jam dengan runbook pemulihan yang telah diuji dan hot standby. Sistem Tier 2 (alat internal, dashboard, environment dev/staging) dapat mentoleransi RTO 4-8 jam dan RPO 24 jam — backup harian, prosedur pemulihan yang terdokumentasi. Sistem Tier 3 (environment sekali pakai, job batch satu kali) mungkin tidak memerlukan DR sama sekali. Klasifikasikan sistem Anda dengan jujur dan alokasikan anggaran DR secara proporsional.
DigitalOcean menawarkan backup Droplet mingguan otomatis dengan biaya 20% dari biaya Droplet — Droplet $24/bulan menghabiskan $4,80/bulan untuk backup mingguan. Aktifkan ini untuk setiap Droplet Tier 1 dan Tier 2 segera. Backup DigitalOcean menangkap seluruh state Droplet sebagai snapshot. Untuk RPO yang lebih granular, gunakan backup otomatis DigitalOcean Managed Database (backup penuh harian + backup binary log berkelanjutan = pemulihan point-in-time ke detik mana pun dalam periode retensi). Untuk data aplikasi yang tidak ada dalam database terkelola (file yang diunggah, konten yang dibuat pengguna), gunakan restic atau rclone untuk mendorong backup inkremental ke DigitalOcean Spaces atau R2 sesuai jadwal.
Dari pengalaman saya: konfigurasikan alert penggunaan disk pada ambang 80% untuk setiap VPS yang Anda kelola. Penyebab paling umum downtime yang tidak direncanakan yang saya lihat adalah disk penuh — baik dari file log, akumulasi image container, atau log transaksi database. Siapkan cron job yang menjalankan du -sh /var/log/* dan memberi alert melalui Telegram jika direktori log mana pun melebihi ambang. Setup 30 menit ini mencegah 90% insiden 'disk penuh pukul 2 pagi'. Selain itu, atur logrotate untuk semua file log aplikasi dengan ukuran maksimum 100MB dan retensi 7 hari.
restic adalah alat backup cepat, terenkripsi, dan terdeduplikasi yang berjalan di server Linux mana pun dan mendukung backend penyimpanan yang kompatibel dengan S3. Siapkan backup restic harian dari VPS Anda ke DigitalOcean Spaces atau Cloudflare R2 (keduanya kompatibel dengan S3). restic secara otomatis mendeduplikasi di seluruh snapshot backup, sehingga setelah backup penuh pertama, snapshot inkremental hanya mengunggah data yang berubah. Enkripsi backup dengan password restic yang tersimpan dalam secrets manager. Jadwalkan melalui cron atau systemd timer. Kirim status penyelesaian backup ke saluran Telegram sehingga Anda segera tahu jika backup gagal.
#!/bin/bash
# Daily restic backup to Cloudflare R2 (S3-compatible)
export RESTIC_REPOSITORY="s3:https://ACCOUNT_ID.r2.cloudflarestorage.com/backups"
export AWS_ACCESS_KEY_ID="r2_access_key"
export AWS_SECRET_ACCESS_KEY="r2_secret_key"
export RESTIC_PASSWORD_COMMAND="gcloud secrets versions access latest --secret=restic-password"
# Backup application data
restic backup /opt/myapp /etc/nginx /etc/letsencrypt --tag "daily" --tag "$(hostname)" --exclude="/opt/myapp/node_modules"
# Backup PostgreSQL dump
pg_dump -U postgres mydb | restic backup --stdin --stdin-filename mydb.sql
# Prune old snapshots (keep 7 daily, 4 weekly, 3 monthly)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --prune
# Verify backup integrity
restic check
# Alert on failure via Telegram
if [ $? -ne 0 ]; then
curl -s -X POST "https://api.telegram.org/botTOKEN/sendMessage" -d "chat_id=CHAT_ID&text=Backup failed on $(hostname)"
fiUntuk PostgreSQL, gunakan pg_dump untuk backup logis (skema + data dalam format SQL) dan WAL archiving untuk pemulihan point-in-time. pg_dump harian ke S3 menyediakan snapshot bersih yang dapat diimpor yang berfungsi terlepas dari versi PostgreSQL. WAL archiving (archive_command di postgresql.conf) terus mengirimkan log transaksi ke penyimpanan objek — memungkinkan pemulihan ke titik waktu mana pun, bukan hanya snapshot harian. Untuk MySQL, gunakan mysqldump untuk backup logis dan replikasi binary log untuk PITR. Jangan hanya mengandalkan snapshot level filesystem untuk database — mereka dapat menangkap state yang tidak konsisten kecuali database di-quiesce terlebih dahulu.
Setelah bencana yang saya ceritakan di intro, saya mengimplementasikan backup otomatis di setiap server. Tiga bulan kemudian saya menguji salah satu backup tersebut — dan gagal dipulihkan. Repository restic telah dibuat tetapi job backup telah gagal secara diam-diam (output cron menuju ke /dev/null dan saya tidak memeriksa log). Saya memiliki tiga bulan apa yang saya yakini sebagai backup harian yang sebenarnya adalah snapshot kosong. Pelajarannya: jadwalkan tes DR triwulanan. Munculkan Droplet baru, pulihkan dari backup, verifikasi integritas data, uji fungsionalitas aplikasi, dan dokumentasikan waktu pemulihan aktual. Hanya backup yang telah diuji yang merupakan backup nyata.
DR runbook adalah dokumen prosedur langkah demi langkah untuk memulihkan layanan setelah kegagalan. Ini harus cukup sederhana untuk diikuti dalam tekanan pukul 2 pagi. Sertakan: (1) Triase awal — periksa dashboard monitoring, ping server, coba SSH, periksa konsol cloud untuk alert; (2) Decision tree — apakah ini masalah jaringan, masalah disk, crash proses, atau kegagalan hardware?; (3) Prosedur pemulihan untuk setiap jenis kegagalan — untuk proses yang crash, restart melalui systemd; untuk disk penuh, bebaskan ruang dan restart; untuk kegagalan hardware, pulihkan dari snapshot ke Droplet baru. Simpan runbook di lokasi yang dapat diakses tanpa server yang gagal — halaman Notion bersama, repo GitHub, atau bahkan PDF di Google Drive.
┌─────────────────────────────────────────────────────┐
│ VPS Disaster Recovery Layers │
├─────────────────────────────────────────────────────┤
│ │
│ Layer 1: DO Weekly Snapshots (fast VM restore) │
│ RPO: ~7 days | RTO: ~30 min │
│ │
│ Layer 2: Daily restic → Cloudflare R2 │
│ RPO: ~24h | RTO: ~1-2 hours │
│ │
│ Layer 3: pg_dump + WAL archiving │
│ RPO: ~1h | RTO: ~2-4 hours │
│ │
│ Layer 4: Disk monitoring (80% alert) │
│ Prevention > Recovery │
└─────────────────────────────────────────────────────┘Di GCP, disaster recovery memiliki lebih banyak opsi terkelola daripada DigitalOcean. Snapshot instance Compute Engine dapat dijadwalkan melalui Cloud Console (snapshot harian yang disimpan selama 7 hari adalah baseline umum). Cloud SQL mendukung backup harian otomatis dan pemulihan point-in-time hingga 7 hari secara default (dapat dikonfigurasi hingga 365 hari). Untuk setup DR multi-region, read replica lintas region Cloud SQL dapat dipromosikan ke primary dalam pemadaman regional. Objek Cloud Storage mereplikasi di seluruh zone dalam satu region secara default — untuk redundansi lintas region, aktifkan kelas storage multi-region atau replikasi ke bucket terpisah di region berbeda menggunakan Object Lifecycle Management.
Setelah bencana pukul 2 pagi, berikut baseline saya saat ini untuk setiap VPS yang saya kelola: backup restic harian otomatis ke Cloudflare R2 (offsite, provider berbeda), snapshot Droplet mingguan DigitalOcean otomatis (untuk pemulihan VM cepat), monitoring penggunaan disk dengan alert 80%, rotasi log untuk semua log aplikasi, dan tes DR triwulanan yang dijadwalkan dalam kalender. Total biaya untuk Droplet standar $24: $4,80/bulan untuk backup DigitalOcean + $0,50/bulan untuk penyimpanan R2 = $5,30/bulan untuk ketenangan pikiran. Biaya sebenarnya dari tidak memiliki DR yang tepat diukur dalam kepercayaan klien, bukan tagihan server.
Sumber & Bacaan Lanjutan