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

> Setup backup 3-2-1 yang bekerja untuk VPS: restic ke object storage S3-compatible, dump database yang benar, retensi, dan latihan restore yang membuktikannya.

URL: https://www.matthewswong.com/id/blog/backup-3-2-1-strategy-vps/

- Author: Matthews Wong (https://www.matthewswong.com/id/about/)
- Published: 2026-05-16
- Updated: 2026-05-16
- Category: DevOps

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:

Tiga salinan data Anda — data production yang live plus dua backup.

Dua media atau sistem penyimpanan berbeda, supaya satu kelas kegagalan tidak bisa mengambil kedua backup sekaligus.

Satu salinan off-site — gedung, provider, atau region yang berbeda dari production.

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.

Jangan pernah men-snapshot direktori data database yang sedang berjalan dengan tool level file. File PostgreSQL yang disalin di tengah penulisan itu inkonsisten dan bisa gagal start, dan kegagalannya senyap sampai hari restore. Dump dulu — pg_dump atau pg_dumpall untuk Postgres, mysqldump atau mariadb-dump untuk MySQL — lalu biarkan restic mem-backup dump-nya. Dump itulah backup-nya; restic adalah transport dan arsipnya.

## 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:

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

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:

Salinan

Tempat tinggalnya

Biaya bulanan (perkiraan)

Salinan 1 — live

VPS production itu sendiri: PostgreSQL, upload, config.

Sudah termasuk di server yang memang Anda bayar.

Salinan 2 — off-site, media berbeda

Repository restic di object storage pada provider dan region berbeda dari VPS.

Beberapa dolar dengan harga object storage tipikal sekitar setengah sen AS per GB.

Salinan 3 — media kedua, lokasi kedua

restic copy dari repo yang sama ke disk di kantor, disinkronkan mingguan.

Hardware milik sendiri; praktis gratis setelah dibeli.

> Deduplikasi mengubah ekonominya lebih dari yang orang duga: repository saya menampung berbulan-bulan snapshot malam dari dataset 40 GB dalam kira-kira 55 GB storage, karena blok yang tidak berubah disimpan sekali. Biaya marginal menyimpan enam bulan riwayat dibanding satu bulan nyaris nol — jadi simpan riwayatnya.

## 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.

> Tulis perintah restore ke repo yang sama dengan script backup, sebagai restore.sh yang bisa langsung dijalankan. Saat insiden sungguhan Anda akan stres dan mungkin bukan Anda yang melakukan restore. Script yang bekerja di latihan terakhir mengalahkan dokumentasi, setiap saat.

## 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.

## Sumber dan bacaan lanjutan

- Restic Docs: Preparing a new repository
- Backblaze: The 3-2-1 Backup Strategy

## Source links

- https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
- https://www.backblaze.com/blog/the-3-2-1-backup-strategy/

## FAQ

### Kenapa saya tidak bisa langsung men-snapshot direktori data database dengan restic?

Database seperti PostgreSQL menulis file secara non-atomik, sehingga snapshot level file yang diambil di tengah penulisan menghasilkan state yang inkonsisten dan bisa gagal start saat restore. Cara yang benar adalah dump dulu — menggunakan pg_dump atau pg_dumpall untuk PostgreSQL, atau mysqldump untuk MySQL — baru biarkan restic mem-backup file dump yang dihasilkan. Dump itulah backup sesungguhnya; restic adalah transport dan arsipnya.

### Apa yang dituntut aturan 3-2-1, dan bagaimana pemetaannya ke setup VPS tipikal?

Aturan 3-2-1 menuntut tiga salinan data, disimpan di dua media atau sistem berbeda, dengan satu salinan disimpan off-site di gedung, provider, atau region yang berbeda. Untuk fleet VPS, ini berarti data production yang live di server adalah salinan pertama, snapshot restic malam hari di object storage pada provider berbeda adalah salinan kedua, dan salinan restic kedua yang disinkronkan ke disk di rumah atau kantor adalah salinan ketiga. Off-site artinya failure domain berbeda — bukan sekadar folder berbeda di akun yang sama.

### Bagaimana setup ini memverifikasi bahwa backup benar-benar utuh, bukan sekadar ada?

Script malam menjalankan restic check dengan flag read-data-subset, yang mengunduh dan memverifikasi secara kriptografis 5 persen acak data repository setiap malam. Ini memastikan korupsi senyap tertangkap dalam hitungan minggu, bukan baru ditemukan saat restore. Heartbeat Uptime Kuma di akhir script membalik model alerting: alih-alih dinotifikasi saat gagal, Anda di-page saat sinyal sukses berhenti datang — yang juga menangkap kasus di mana cron-nya sendiri yang mati.

### Bagaimana deduplikasi memengaruhi biaya storage untuk menyimpan banyak bulan snapshot?

Deduplikasi content-defined berarti blok data yang tidak berubah hanya disimpan sekali di semua snapshot, sehingga biaya marginal menambah retensi lebih lama nyaris nol. Artikel ini mencatat bahwa berbulan-bulan snapshot malam dari dataset 40 GB muat dalam kira-kira 55 GB storage. Ini membuat menyimpan enam bulan riwayat dibanding satu bulan praktis gratis, dan menjadi salah satu alasan sarannya adalah tetap simpan riwayatnya daripada memangkas terlalu agresif.

### Kenapa monitoring heartbeat direkomendasikan daripada email alert kegagalan untuk job backup?

Email alert kegagalan bergantung pada sistem yang gagal masih cukup sehat untuk mengirimnya — kalau cron mati, script crash sebelum alert terpicu, atau server down, tidak ada alert yang terkirim. Monitoring heartbeat membalik ini: job backup mengirim sinyal sukses setiap selesai, dan Anda di-page hanya saat sinyal itu berhenti datang. Pendekatan ini secara ketat lebih andal dan mudah diimplementasikan dengan push monitor Uptime Kuma.

---

- HTML version: https://www.matthewswong.com/id/blog/backup-3-2-1-strategy-vps/
- English: https://www.matthewswong.com/en/blog/backup-3-2-1-strategy-vps/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json