Backup VPS dengan restic: Snapshot Terenkripsi Sebelum Semuanya Hilang

Backup VPS dengan restic adalah salah satu keputusan paling murah yang bisa kita ambil untuk menghindari bencana data. Bayangkan: disk VPS mati besok, atau kita salah menjalankan rm -rf di direktori yang salah — tanpa backup, semua konfigurasi Nginx, database, dan file aplikasi yang susah payah kita bangun hilang dalam hitungan detik. Provider VPS memang menyediakan snapshot, tapi itu terikat pada satu provider, sering berbayar, dan tidak bisa kita pegang sendiri.

Di artikel ini kita akan memasang restic — alat backup open-source yang sudah dipercaya bertahun-tahun — lengkap dengan jadwal otomatis, kebijakan retensi, dan uji restore. Versi stabil saat tulisan ini dibuat adalah 0.19.1 (rilis Juli 2026, sesuai halaman rilis resminya di GitHub). Oke, lanjuutt..

Kenapa restic, Bukan Sekadar `tar` dan Cron?

Sebelum masuk ke perintah, kita pahami dulu kenapa restic layak dipasang di VPS:

Snapshot, bukan salinan file. Setiap backup tercatat sebagai snapshot dengan waktu tertentu. Kita bisa kembali ke kondisi server hari Senin, minggu lalu, atau bulan lalu — tanpa menyimpan banyak salinan penuh.
Deduplikasi otomatis. restic memecah data jadi blok-blok kecil dan hanya menyimpan blok yang belum ada. Backup harian 1 GB data yang berubah sedikit cuma menambah beberapa MB di repositori.
Terenkripsi dari awal. Data dienkripsi sebelum meninggalkan server, jadi repositori backup di tempat lain (termasuk storage pihak ketiga) tetap aman dibaca orang.
Satu binary, tanpa dependensi. Tidak ada daemon yang jalan terus-menerus memakan RAM VPS kecil — restic hanya bekerja saat dipanggil.

Kombinasi ini membuatnya pas untuk backup VPS berkapasitas minim, dan sebagai bonus repositorinya bisa ditaruh di storage S3 self-hosted seperti Garage yang sudah pernah kita bahas.

Langkah 1: Pasang restic di VPS

Untuk Debian/Ubuntu, restic tersedia di repositori distro:


sudo apt update
sudo apt install restic
restic version

Kalau versi di repositori distro terasa jauh tertinggal, unduh binary resmi dari GitHub releases:


sudo bzip2 -d /tmp/restic.bz2
sudo mv /tmp/restic /usr/local/bin/restic
sudo chmod +x /usr/local/bin/restic

Perintah restic version harus menampilkan nomor versi — kalau tidak, binary-nya belum berada di PATH.

Langkah 2: Siapkan Repositori dan Password

Repositori adalah “gudang” tempat semua snapshot disimpan. Untuk pemula, mulai dari disk yang terpasang atau partisi terpisah:


mkdir -p /srv/backup/restic
restic init --repo /srv/backup/restic

restic akan meminta password repositori. Ini kunci enkripsi sekaligus satu-satunya cara membuka data — kalau hilang, backup tidak bisa dipulihkan siapa pun. Simpan password itu di tempat terpisah dari VPS (misalnya password manager), dan simpan salinan file password di server agar cron bisa membacanya:


echo "password-rahasia-anda" | sudo tee /etc/restic-pass
sudo chmod 600 /etc/restic-pass

Untuk mempermudah, set variabel lingkungan di skrip backup nanti:


export RESTIC_REPOSITORY="/srv/backup/restic"
export RESTIC_PASSWORD_FILE="/etc/restic-pass"

Catatan penting: repositori di disk yang sama dengan data asli bukan backup sejati — kalau disk VPS mati, ikut hilang semua. Untuk aman, arahkan repositori ke tempat lain: SFTP ke server kedua (sftp:user@host:/srv/backup), atau backend S3. Ini inti aturan 3-2-1.

Langkah 3: Backup Pertama

Sekarang jalankan backup pertama untuk direktori penting:


restic backup /etc /var/www /home --tag harian

Yang layak dibackup dari VPS: /etc (semua konfigurasi service), /var/www (file aplikasi), /home, plus dump database — PostgreSQL dan MariaDB tidak cukup dibackup dari file datanya yang sedang aktif. Dump dulu, baru masukkan hasilnya ke backup:


sudo -u postgres pg_dumpall > /tmp/pgdump.sql
restic backup /etc /var/www /home /tmp/pgdump.sql --tag harian
rm /tmp/pgdump.sql

Cek daftar snapshot yang sudah tersimpan:


restic snapshots

Langkah 4: Jadwalkan dengan Cron + Atur Retensi

Backup manual pasti dilupakan, jadi otomatisasi kuncinya. Buat skrip sederhana /usr/local/bin/backup-restic.sh:


#!/bin/bash
set -e
export RESTIC_REPOSITORY="/srv/backup/restic"
export RESTIC_PASSWORD_FILE="/etc/restic-pass"

pg_dumpall > /tmp/pgdump.sql

restic backup /etc /var/www /home /tmp/pgdump.sql --tag harian
rm -f /tmp/pgdump.sql

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --prune

Lalu daftarkan di cron:


sudo chmod +x /usr/local/bin/backup-restic.sh
sudo crontab -e
# tambahkan baris ini (jam 03:00 tiap hari):
0 3 * * * /usr/local/bin/backup-restic.sh >> /var/log/restic.log 2>&1

Perintah restic forget --prune inilah yang mengatur retensi: snapshot lama dihapus dan blok data tak terpakai dibersihkan, sehingga repositori tidak membengkak tanpa batas. Kebijakan 7/4/3 adalah titik awal yang wajar untuk VPS pribadi — silakan sesuaikan dengan kebutuhan.

Satu tips tambahan: kalau backup cron gagal diam-diam, kita tidak akan tahu sampai butuh restore. Kombinasikan dengan layanan pemantau cron seperti Healthchecks supaya tiap gagal backup ada notifikasi.

Langkah 5: Uji Restore — Backup yang Belum Diuji Bukan Backup

Ini bagian yang paling sering dilewati, padahal paling penting. Uji restore ke folder sementara:


mkdir /tmp/tes-restore
restic restore latest --target /tmp/tes-restore
ls /tmp/tes-restore/etc/nginx
rm -rf /tmp/tes-restore

Kalau kita hanya butuh satu file, tidak perlu restore semuanya:


restic dump latest /tmp/pgdump.sql > /tmp/cek-db.sql
head -20 /tmp/cek-db.sql

Lakukan uji ini minimal sekali sebulan. restic restore latest mengembalikan snapshot terbaru; ganti latest dengan ID snapshot dari restic snapshots untuk kondisi waktu tertentu.

Masalah yang Sering Muncul dan Cara Mengatasinya

“repository is already locked exclusively by PID…” — ada proses restic lain masih berjalan (biasanya backup sebelumnya yang menempel). Cek dengan ps aux | grep restic; kalau benar-benar macet setelah prosesnya mati, lepas kunci dengan restic unlock. Jangan asal unlock kalau backup masih jalan — dua proses menulis bersamaan bisa merusak repositori.
Prune lambat dan makan CPU. Ini normal: prune memang menulis ulang index. Jalankan saja tidak tiap hari — cukup seminggu sekali di jam sepi, atau pisahkan backup dan forget --prune ke jadwal berbeda.
“wrong password or key” padahal yakin benar. Kemungkinan besar variabel RESTIC_PASSWORD_FILE tidak terbaca di cron (environment cron minim). Selalu export kedua variabel di dalam skrip, bukan mengandalkan profil shell.
Repositori makin besar meski ada retensi. Jalankan restic check berkala untuk memverifikasi integritas; opsi --read-data membaca seluruh data dan lebih teliti tapi berat — cukup sebulan sekali.

Kesimpulan

restic memberi kita tiga hal sekaligus: snapshot berkala, deduplikasi yang hemat ruang, dan enkripsi bawaan — semuanya gratis dan ringan untuk VPS kecil. Alur yang kita bangun di sini (init → backup → cron + retensi → uji restore) bisa diselesaikan dalam satu sore, tapi nilainya terasa bertahun-tahun, yaitu ketika pertama kali kita benar-benar perlu memulihkan sesuatu.

Jangan berhenti di langkah pemasangan — uji restore-nya juga, karena backup yang belum pernah dipulihkan itu cuma harapan. Selamat mencoba, dan semoga VPS-nya awet!