Backup VPS terenkripsi.
Tersimpan offsite, terdeduplikasi, dan di luar jangkauan.

Hampir setiap perdebatan soal backup sudah salah arah sejak menit pertama, karena kedua pihak yang bicara membayangkan kegagalan yang berbeda. Yang satu membayangkan drive yang mati. Yang lain membayangkan suatu Selasa pagi di mana akunnya lenyap. Keduanya butuh jawaban yang berbeda, dan setup yang hanya bertahan dari yang pertama terasa aman — sampai diuji oleh yang kedua.

Ada empat mode kegagalan yang layak diantisipasi sejak desain, dan semuanya bukan sekadar variasi dari satu tema — masing-masing mengalahkan pertahanan yang berbeda.

Perangkat keras. NVMe gagal, host node mati, array kehilangan dua anggota sekaligus. Ini kegagalan yang selalu direncanakan semua orang, dan justru yang paling jarang terjadi pada infrastruktur virtualisasi modern. Penyimpanan redundan mengatasinya. Penyimpanan redundan tidak mengatasi hal lain, itulah sebabnya RAID bukan backup dan tidak pernah menjadi backup: ia menyalin setiap penulisan dengan setia, termasuk penulisan yang berbunyi "hapus semuanya".

Manusia. Skrip migrasi yang dijalankan terhadap sistem produksi. DROP TABLE di terminal yang salah. rsync dengan argumen yang terbalik. Ini, dengan selisih jauh, adalah penyebab paling umum dari kehilangan data yang sesungguhnya, dan satu-satunya pertahanan terhadapnya adalah riwayat — salinan dari sebelum kesalahan terjadi, disimpan di tempat yang tidak terjangkau oleh kesalahan itu. Waktu adalah bahan utamanya: jika satu-satunya salinan adalah mirror yang tertinggal tiga puluh detik, salinan itu sudah memuat kesalahan tersebut.

Jahat. Seseorang mendapatkan akses root, atau ransomware masuk lewat aplikasi yang belum ditambal. Hal pertama yang dilakukan ransomware modern adalah mencari konfigurasi backup — kredensial, shares yang ter-mount, kunci cloud — lalu menghancurkan apa pun yang ditemukannya, justru karena pemulihan yang berhasil mengubah bencana menjadi urusan satu sore saja. Kredensial backup yang bisa menghapus adalah kredensial backup yang diwarisi penyerang. Inilah kegagalan yang membuat bab append-only pada panduan ini ada.

Kustodial. Tidak ada yang rusak dan tidak ada yang diserang; Anda hanya kehilangan akses. Akun yang ditangguhkan karena sinyal penipuan otomatis, kartu yang gagal saat Anda sedang bepergian, sengketa, tinjauan kepatuhan, perintah hukum yang dilayangkan ke penyedia. Mesinnya utuh tapi tidak terjangkau, dan setiap snapshot di dalam akun itu ikut tidak terjangkau. Inilah kegagalan yang tidak bisa dijawab oleh redundansi sebanyak apa pun selama masih berada dalam satu penyedia, dan inilah alasan mengapa backup yang serius harus berada di bawah atap yang berbeda.

Baris terakhir adalah yang dibangun oleh sisa panduan ini. Baris ini tidak lebih mahal dari baris di atasnya — pengaturan append-only gratis dan yurisdiksi kedua berbiaya sama, $3.90, seperti yang pertama.

Aturan 3-2-1, dirumuskan ulang untuk satu VPS. Tiga salinan data, pada dua jenis penyimpanan yang berbeda, salah satunya offsite. Rumusan klasik ini berasal dari era tape dan server kantor, dan semangatnya bertahan lebih baik daripada bunyi literalnya. Untuk satu mesin self-hosted, bunyinya jadi: data live di VPS, satu repository di mesin kedua di tempat lain, dan — untuk apa pun yang benar-benar tidak tergantikan — satu salinan ketiga yang bisa kamu pegang sendiri, di disk di rumah atau di dalam laci. Angka yang sebenarnya penting bukanlah tiga. Yang penting adalah berapa banyak hal independen yang harus sama-sama gagal sebelum data itu benar-benar hilang. Dua adalah jumlah minimum yang layak dimiliki.

Membackup seluruh filesystem adalah pilihan yang bisa dipertahankan sekaligus pilihan yang boros. Sebagian besar isi server hanya berjarak satu package manager dari bisa dibuat ulang, dan setiap gigabyte yang Anda bawa membuat repositori makin lambat untuk di-prune, makin mahal untuk disimpan, dan makin lambat untuk dicari saat Anda sedang terburu-buru. Latihan yang lebih berguna justru sebaliknya: daftar apa saja yang tidak akan dikembalikan oleh instalasi baru.

Untuk VPS self-hosted yang umum, daftar itu pendek, dan selalu berisi lima hal berikut:

• 01Isi database. Bukan direktori data — melainkan dump-nya. Langkah 05 menjelaskan alasannya.
• 02File yang diunggah pengguna. Volume Docker, direktori uploads atau media, mail store. Biasanya inilah yang memakan sebagian besar byte.
• 03Konfigurasi dan data rahasia. File Compose, file .env, kunci enkripsi, token API. Kecil, tapi menjadi pembeda antara pemulihan dua jam dan pemulihan dua hari.
• 04Status sistem yang sudah kamu ubah. /etc secara keseluruhan cukup kecil untuk diambil sepenuhnya — konfigurasi sshd, aturan firewall, unit systemd, entri cron, routing email yang Anda habiskan satu malam untuk menyiapkannya.
• 05Apa pun yang memiliki identitas yang melekat. Kunci hidden-service Tor, kunci penandatanganan Matrix, kunci privat WireGuard, dompet node. Kehilangan salah satu dari kunci ini dan layanan tidak akan kembali — yang kembali adalah layanan berbeda dengan nama yang sama.

Ubah daftar itu menjadi dua file di server sumber. Daftar include membuat maksudnya tetap terlihat jelas; daftar exclude menjaga agar noise tidak ikut masuk. Keduanya dibaca oleh perintah backup, dan keduanya sendiri juga harus ikut dibackup.

/etc/backup/include.txt

/etc
/opt
/root
/var/backups
/var/lib/docker/volumes
/home

/etc/backup/exclude.txt

# Caches and rebuildable artefacts
**/node_modules
**/.cache
**/*.tmp
/var/lib/docker/volumes/*/_data/cache
# Log noise — keep the config, drop the volume
/var/log/journal
# Never back up the mount point you restore into
/mnt/restore

Dua catatan soal baris Docker itu, karena sering membuat orang keliru. Named volume berada di bawah /var/lib/docker/volumes dan itulah yang kamu inginkan; bind mount berada di mana pun kamu menaruhnya, biasanya di sebelah file Compose, dan sudah tercakup oleh /opt. Image container bukan data — ia bisa kembali hanya dengan pull, dan backup yang ikut membawanya hanya membawa gigabyte yang tidak dibutuhkan.

Terakhir, ukur dulu hasilnya sebelum Anda membangun apa pun di sekitarnya. Angka itu memberi tahu tier repositori mana yang perlu dipesan dan apakah proses pertama akan memakan waktu empat menit atau empat puluh menit:

du -sh --exclude=/var/lib/docker/overlay2 /etc /opt /root /home /var/lib/docker/volumes

Host repository punya satu tugas dan nyaris tanpa persyaratan. Ia tidak butuh core CPU, karena tidak pernah membaca datamu — ia hanya menyimpan blob terenkripsi yang tidak bisa dibukanya. Ia tidak butuh memori, karena kerja deduplikasi terjadi di sisi sumber. Yang ia butuhkan hanyalah disk, alamat yang stabil, dan berada di suatu tempat yang tidak ikut terseret masalah mesin sumber.

Di panel: Order → VPS → Sentinel, image Debian 12, dan — inilah inti persoalannya — bastion yang berbeda dari tempat sumber berjalan. Helsinki untuk kerja, Reykjavík untuk menyimpan. Tidak perlu alamat email untuk membuka akun dan tagihannya bisa dilunasi dengan Monero, Bitcoin, Lightning, atau aset lain yang didukung, yang berarti mesin kedua ini tidak memunculkan kembali identitas yang sudah dijaga hati-hati oleh mesin pertama.

Kolom working set mengasumsikan snapshot harian yang disimpan selama satu tahun dengan tingkat perubahan normal; repository yang sebagian besar berisi file yang jarang berubah bisa bertahan jauh lebih lama, sedangkan yang penuh binary besar yang sering ditulis ulang bertahan lebih singkat. Baris terakhir ada untuk skala, dan untuk detail yang sering dilupakan orang sampai hari buruk itu tiba: object storage juga membebankan biaya untuk download, dan download adalah hal yang kamu lakukan saat keadaan darurat.

Di sisi tujuan — user tanpa privilese dan sebuah direktori.

adduser --disabled-password --gecos "" backup
install -d -m 0700 -o backup -g backup /srv/restic/web01

Pengguna backup ini tidak punya password, tidak punya akses sudo, dan tidak ada apa pun untuk di-login. Ia ada hanya untuk memiliki satu direktori. Beri direktori tersendiri untuk setiap mesin sumber jika kamu membackup beberapa mesin — satu repository per sumber menjaga agar penyusupan di satu mesin tidak menyentuh riwayat mesin lain.

Di sisi sumber — kunci yang tidak dipakai untuk hal lain apa pun.

ssh-keygen -t ed25519 -f /root/.ssh/id_backup -N "" -C "backup:web01"
cat /root/.ssh/id_backup.pub

Jangan pakai ulang kunci login Anda. Kunci ini disimpan tidak terenkripsi di disk karena timer tanpa pengawasan harus memakainya pukul tiga pagi, dan itu justru jenis kunci yang seharusnya Anda batasi ruang lingkupnya hanya untuk satu tujuan dan satu keperluan.

Kembali ke tujuan — batasi apa yang boleh dilakukan kunci itu. Tempelkan kunci publik ke /home/backup/.ssh/authorized_keys dengan prefix di depannya. Untuk restic lewat SFTP:

restrict,from="198.51.100.7" ssh-ed25519 AAAAC3NzaC1lZDI1... backup:web01

Opsi restrict mematikan port forwarding, agent forwarding, X11, dan alokasi PTY hanya dengan satu kata, hanya menyisakan transfer file dan tidak ada yang lain. Klausa from= mengunci kunci itu ke alamat sumber, sehingga salinannya yang dicuri dari server tidak berguna di tempat lain mana pun. Untuk Borg, maju satu langkah lagi dan paksa perintahnya (force command), di sanalah mode append-only-nya berada:

command="borg serve --append-only --restrict-to-path /srv/borg/web01",restrict ssh-ed25519 AAAAC3NzaC1lZDI1... borg:web01

Baris itu adalah keseluruhan pertahanan ransomware dalam satu tempat: apa pun yang dikirim sumber, tujuan hanya akan pernah menjalankan borg serve, hanya di dalam path itu, dan hanya dalam mode yang menambahkan (append). Root shell di sisi sumber tidak bisa memakai kunci ini untuk menghapus data bulan lalu.

Beri nama tujuan sekali saja, di sisi sumber. Taruh di /root/.ssh/config agar setiap perintah berikutnya singkat dan alamatnya hanya hidup di satu file:

Host rkv-repo
    HostName 198.51.100.42
    User backup
    IdentityFile /root/.ssh/id_backup
    IdentitiesOnly yes

Lalu sambungkan sekali secara manual — ssh rkv-repo — untuk menerima kunci host. Timer yang berjalan tanpa pengawasan tidak akan menjawab prompt fingerprint, dan backup pertama yang menggantung diam-diam selama seminggu adalah kejadian klasik. Selagi kamu berada di sisi tujuan, perlakukan ia sama seperti mesin lain yang kamu miliki: jalankan juga checklist pengerasan jam pertama di sana. Mesin ini menyimpan salinan segalanya, dan pantas mendapatkan satu jam penuh itu.

Aturan database, dinyatakan sekali. Mesin database yang sedang berjalan menyimpan state di memori dan menuliskannya ke disk sesuai waktunya sendiri. Baca filenya saat proses itu berlangsung dan Anda mendapatkan sekumpulan halaman dari beberapa momen yang berbeda — file yang mungkin bisa dipulihkan, mungkin pulih dalam keadaan rusak, atau mungkin pulih menjadi sesuatu yang terbuka dengan baik namun diam-diam kehilangan data satu jam terakhir. Tidak ada cara untuk mengetahui yang mana dari luar. Karena itu backup tidak pernah menyentuh file live: dump ditulis ke disk terlebih dahulu, dan backup mengambil dump tersebut.

Semuanya masuk ke dalam satu skrip. Letakkan di /usr/local/sbin/nb-backup.sh, jadikan executable, dan simpan skrip itu di dalam backup itu sendiri:

#!/bin/sh
set -eu

# ---- 1. Consistent dumps, written where the include list will find them.
install -d -m 0700 /var/backups/db

# PostgreSQL in a container:
docker exec -t app-db pg_dumpall -U postgres | gzip -9 > /var/backups/db/postgres.sql.gz

# MariaDB / MySQL, InnoDB tables:
# docker exec -t mail-db mariadb-dump --single-transaction --all-databases \
#   | gzip -9 > /var/backups/db/mariadb.sql.gz

# SQLite — never a plain file copy:
# sqlite3 /opt/app/data/app.db ".backup '/var/backups/db/app.db'"

# ---- 2. The snapshot.
restic backup \
  --files-from /etc/backup/include.txt \
  --exclude-file /etc/backup/exclude.txt \
  --tag nightly --one-file-system

# ---- 3. Retention, then reclaim the space it freed.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

# ---- 4. Structural check every night; read 5% of the data on Sundays.
restic check
[ "$(date +%u)" = "7" ] && restic check --read-data-subset=5%

echo "backup ok: $(date -u +%FT%TZ)"

Tiga detail dalam script itu bekerja lebih keras daripada yang terlihat. Set -eu di bagian atas berarti dump yang gagal akan membatalkan run, alih-alih diam-diam menyimpan snapshot dari dump kemarin selama enam bulan ke depan. Forget dan prune dijadikan satu perintah, karena kebijakan retensi yang tidak pernah membebaskan ruang sama saja dengan disk yang terus penuh. Dan pemeriksaan hari Minggu membaca sebagian data yang sebenarnya, bukan hanya indeksnya — korupsi repository itu jarang terjadi, dan diam-diam, dan satu-satunya cara menemukannya adalah dengan membaca.

Timer-nya. Dua file unit kecil. systemd adalah scheduler yang tepat di sini, bukan cron, karena timer memberimu Persistent — run yang terlewat saat mesin mati akan dijalankan pada boot berikutnya, bukannya dilewatkan begitu saja tanpa suara — dan karena journalctl kemudian menyimpan riwayat setiap run.

/etc/systemd/system/nb-backup.service

[Unit]
Description=Nightly encrypted offsite backup
Wants=network-online.target
After=network-online.target docker.service

[Service]
Type=oneshot
EnvironmentFile=/etc/backup/restic.env
ExecStart=/usr/local/sbin/nb-backup.sh
Nice=10
IOSchedulingClass=idle

/etc/systemd/system/nb-backup.timer

[Unit]
Description=Nightly encrypted offsite backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=45m
Persistent=true

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now nb-backup.timer
systemctl list-timers nb-backup.timer
systemctl start nb-backup.service && journalctl -u nb-backup.service -n 40 --no-pager

Jeda acak itu bukan hiasan. Setiap server self-hosted di internet menjalankan maintenance-nya tepat pukul 03:00, dan backup yang mulai di detik yang sama dengan rotasi log, perpanjangan sertifikat, dan update container akan menghabiskan malamnya berebut I/O dengan mereka. Menyebarkan waktu mulai dalam rentang empat puluh lima menit tidak memakan biaya apa pun dan menghilangkan seluruh kategori malam-malam lambat yang misterius.

Lalu buat kegagalan itu bersuara keras. Ini langkah yang selalu dilewatkan semua orang, padahal langkah inilah yang menentukan apakah semua yang di atas tadi ada gunanya. Backup yang berhenti bekerja tidak memberi tahu apa pun: timer tetap menyala, layanan tetap gagal, dan snapshot baik terakhir semakin mundur ke masa lalu sementara dashboard tetap hijau. Tambahkan unit OnFailure= ke layanan itu yang mengirimimu sesuatu yang benar-benar akan kamu lihat, dan sebulan sekali lirik bagian atas daftar snapshot. Satu baris, satu kebiasaan.

restic snapshots --latest 3        # is the newest one from last night?
systemctl list-timers nb-backup.timer   # is the timer still armed?

Semua yang dibahas sampai di sini melindungi dari kecelakaan. Bab ini melindungi dari pihak yang mengancam, dan masalah desainnya terasa tidak nyaman begitu Anda menyadarinya: mesin sumber harus menjangkau repositori setiap malam, yang berarti mesin sumber menyimpan kredensial aktif untuk repositori itu. Siapa pun yang menguasai sumber, menguasai kredensial itu. Jika kredensial itu bisa menghapus, penyerang akan menghapus — dan ransomware modern justru melakukan ini dengan sengaja, sebelum mengenkripsi apa pun, karena korban yang masih bisa dipulihkan tidak akan membayar.

Solusinya bukan password yang lebih baik. Solusinya adalah izin asimetris: sumber boleh menambahkan data dan tidak boleh menghapus apa pun. Tiga cara untuk membangunnya, diurutkan dari yang paling mudah dilakukan dengan benar.

Satu — append-only paksa lewat SSH. Ini wilayah utama Borg dan jawaban paling bersih yang tersedia di mesin milikmu sendiri. Entri authorized_keys dari langkah 03 memaksa borg serve --append-only, sehingga sisi jauh menolak penghapusan apa pun yang diminta sisi dekat. Pruning tetap harus dilakukan, tapi terjadi dari sisi tujuan, dengan jadwal yang tidak bisa dipengaruhi sumber, dijalankan oleh akun yang tidak bisa dijangkau sumber. Penyerang dengan akses root di sisi sumber bisa memenuhi repository dengan sampah; ia tidak bisa menghapus arsip dari malam sebelum ia datang.

Dua — REST endpoint append-only. rest-server, pendamping restic, memiliki mode --append-only dengan sifat yang sama: blob baru diterima, yang sudah ada tidak bisa dihapus. Jalankan di sisi tujuan di balik TLS, arahkan RESTIC_REPOSITORY ke URL https:// alih-alih sftp:, dan bentuk pertahanannya identik. Ini hanya menambah satu layanan lagi di sisi tujuan dan memberikan jaminan yang sama.

Tiga — object lock. Pada storage yang kompatibel S3, versioning ditambah periode retensi object-lock membuat penghapusan mustahil dilakukan sampai periode itu berakhir, dan ini dipaksakan oleh lapisan storage itu sendiri, bukan oleh sebuah program. Ini yang paling kuat di antara ketiganya dan juga paling mahal, dan ini memunculkan lagi akun penyedia — yang membawa kembali risiko custodial yang justru coba disebar oleh seluruh panduan ini. Masuk akal sebagai salinan ketiga, tapi janggal kalau dijadikan satu-satunya.

Jika tidak ada satu pun dari itu yang cocok — SFTP biasa, kunci yang bisa menulis dan karenanya bisa menghapus — jangan berpura-pura sebaliknya; tambahkan salinan kedua yang independen dan sama sekali tidak bisa disentuh oleh sumber. Gunakan pull, bukan push: biarkan tujuan yang login ke sumber, membaca apa yang dibutuhkan, lalu menyimpannya. Kredensialnya pun kini berada di mesin yang tidak terekspos, dan penyerang di sisi sumber tidak akan menemukan apa pun yang mengarah ke backup. Ini memang sedikit lebih merepotkan untuk disiapkan, tapi membalik risiko ke arah yang justru tepat.

Apa pun yang kamu pilih, verifikasi dengan cara yang sama seperti memverifikasi kontrol keamanan lainnya — dengan mencoba mematahkannya. Dari sisi sumber, dengan kunci backup, coba lakukan penghapusan. Hasil yang benar adalah penolakan.

borg delete ::name-of-an-old-archive
# → Remote: Repository is in append-only mode. Refusing to delete.

Tanyakan pada kebanyakan orang mengapa backup harus berada di tempat lain, dan jawabannya adalah kebakaran, banjir, atau datacenter yang kehilangan daya. Semuanya benar, semuanya makin jarang terjadi, dan semuanya bisa dijawab dengan jarak seratus kilometer. Kegagalan yang benar-benar meruntuhkan bisnis pada 2026 bersifat administratif, dan jarak semata tidak berbuat apa-apa terhadapnya.

Satu akun adalah satu titik kegagalan. Penangguhan akibat sinyal penipuan otomatis, chargeback saat Anda sedang di pesawat, tinjauan kepatuhan, takedown yang ditujukan ke perusahaan dan bukan ke satu mesin — semua ini menjangkau setiap server di bawah akun tersebut pada saat yang sama, termasuk server yang menyimpan snapshot. Redundansi teknis yang sempurna pun jadi tidak relevan. Dua penyedia, atau minimal dua akun di bawah dua payung hukum yang berbeda, adalah satu-satunya struktur yang menjawab masalah ini.

Satu yurisdiksi adalah satu kerangka hukum. Keempat bastion Nordik ini tidak bisa saling dipertukarkan begitu saja — Swedia, Finlandia, Norwegia, dan Islandia masing-masing melindungi hal yang sedikit berbeda, dan Norwegia serta Islandia sepenuhnya berada di luar Uni Eropa. Memisahkan mesin kerja dan repository-nya ke dua negara berbeda berarti salinannya bukan sekadar berada di tempat lain; ia berada di bawah seperangkat aturan kedua yang independen. Referensi yurisdiksi Nordik membahas undang-undangnya satu per satu.

Dan tujuan tidak mempelajari apa pun. Inilah yang membuat pemisahan ini murah, bukan sebuah kompromi. Baik restic maupun Borg melakukan enkripsi sebelum apa pun meninggalkan sumber, sehingga host repository menyimpan blob yang kuncinya tidak ia miliki. Ia tidak tahu file apa saja yang disimpannya, berapa banyak, atau apa namanya. Kamu tidak sedang memberi kepercayaan pada pihak kedua; kamu hanya menyewa disk yang tidak bisa membaca dirinya sendiri. Itu juga jawaban jujur untuk pertanyaan "haruskah aku memakai penyedia yang tidak sepenuhnya kupercayai sebagai target backup?" — untuk repository terenkripsi, kepercayaan nyaris tidak berperan sama sekali.

Latensi bukan faktor penentu. Helsinki ke Reykjavík berjarak 30 ms di backbone, Helsinki ke Stockholm 8 ms, Stockholm ke Oslo 11 ms. Backup malam hari tidak peduli dengan angka-angka itu, begitu juga proses restore yang dibatasi oleh throughput disk. Pilih pasangan lokasi berdasarkan jarak hukum, bukan jarak jaringan — jarak jaringan di kawasan Nordik cuma selisih pembulatan.

Satu hal lagi yang layak dikatakan terus terang, karena inilah alasan panduan ini ada di situs ini dan bukan di blog sysadmin generik: mesin kedua membuka kembali setiap pertanyaan yang sudah dijawab oleh mesin pertama. Jika VPS kerja dipesan tanpa dokumen identitas dan dibayar dengan Monero, lalu mesin backup-nya justru dipesan dengan kartu perusahaan dan scan paspor, maka pasangan ini akan sama mudah diidentifikasi seperti bagian yang paling lemah. Panduan utama tentang hosting VPS anonim membahas tiga lapisan itu — pendaftaran, pembayaran, jaringan — dan semuanya berlaku sama persis untuk target backup seperti halnya untuk web server.