restic vs BorgBackup: Backup Terenkripsi dan Terdeduplikasi

Setiap layanan yang saya jalankan pada akhirnya butuh strategi backup yang benar-benar saya percayai: sesuatu yang dienkripsi sebelum meninggalkan mesin, terdeduplikasi agar snapshot malam tidak memakan biaya satu salinan penuh, dan cukup cepat untuk dipulihkan saat genting. Selama bertahun-tahun, dua alat yang selalu saya gunakan adalah restic dan BorgBackup. Keduanya menyelesaikan masalah yang sama dengan filosofi berbeda, dan memilih yang salah untuk target storage Anda akan memakan biaya nyata dan waktu restore nyata.

Ini adalah perbandingan yang saya harap sudah saya miliki sebelum merangkai pipeline backup VPS. Saya sudah menjalankan restic ke object storage kompatibel S3 dan Borg lewat SSH ke storage box murah, dan perbedaan di bawah ini adalah yang benar-benar penting di produksi, bukan sekadar di grafik benchmark.

Bagaimana tiap alat memandang sebuah repository

Kedua alat menyimpan backup dalam sebuah repository: penyimpanan blob terenkripsi dan content-addressed yang Anda inisialisasi sekali lalu Anda tambahkan snapshot ke dalamnya. Model mentalnya hampir identik. Anda mengarahkan alat ke lokasi repository, alat memecah file menjadi chunk berukuran variabel, mengenkripsi tiap chunk, dan hanya menyimpan chunk yang belum pernah dilihat. Sebuah snapshot hanyalah daftar referensi ke chunk store tersebut, itulah kenapa backup kedua dari filesystem yang sebagian besar tidak berubah menjadi sangat kecil.

# restic: init a repo on S3-compatible object storage
export RESTIC_REPOSITORY="s3:https://s3.example.com/my-backups"
export RESTIC_PASSWORD="a-long-random-passphrase"
restic init
restic backup /srv /etc /var/lib/postgresql

# BorgBackup: init an encrypted repo over SSH, then create an archive
borg init --encryption=repokey-blake2 user@storagebox:/backups/vps
borg create --stats --compression zstd,6 \
    user@storagebox:/backups/vps::vps-{now:%Y-%m-%d} \
    /srv /etc /var/lib/postgresql

Backend: di mana data terenkripsi Anda tinggal

Ini adalah faktor penentu terbesar. restic punya backend native dan kelas satu untuk banyak target, jadi Anda jarang butuh perekat. Borg dibangun di sekitar repository lokal dan yang bisa dijangkau lewat SSH, dan tidak bicara object storage sendirian.

• restic: disk lokal, SFTP, REST server khusus, Amazon S3 dan store kompatibel S3 apa pun (MinIO, Wasabi, Cloudflare R2), Backblaze B2, Azure Blob, Google Cloud Storage, dan apa pun yang bisa dijangkau rclone.
• Borg (1.4 stable): hanya path lokal dan SSH. Untuk menjangkau object storage Anda menambahkan rclone mount, sshfs, atau wrapper seperti borgmatic, yang menambah komponen bergerak yang bisa merusak jalur restore Anda.
• Borg 2.0 (saat ini beta): menambahkan abstraksi storage baru dengan backend berbasis rclone, menutup sebagian besar celah ini, tetapi saat tulisan ini dibuat belum menjadi rilis stabil.

Enkripsi dan deduplikasi

Keduanya mengenkripsi semuanya di sisi klien sebelum menyentuh backend, termasuk nama file dan struktur direktori, jadi penyedia storage tidak belajar apa pun. restic memakai AES-256 mode counter dengan autentikasi Poly1305 dan menurunkan kunci dengan scrypt. Borg 1.4 memakai AES-256-CTR dengan HMAC-SHA256; mode repokey menyimpan kunci terenkripsi di dalam repo sehingga Anda hanya mengelola passphrase. Borg 2.0 memodernkan ini dengan mode AES-OCB dan chacha20-poly1305.

Untuk deduplikasi keduanya memakai content-defined chunking, tetapi Borg cenderung memakai ukuran chunk rata-rata lebih kecil, sehingga mendeduplikasi sedikit lebih halus dan sering unggul 10 sampai 15 persen pada dataset penuh file kecil yang berubah sebagian. Klaim yang sering diulang online bahwa restic tidak punya kompresi sudah usang: restic mendukung kompresi zstd sejak versi 0.14, dan Anda mengaktifkannya dengan flag repository. Borg sudah menawarkan kompresi lz4, zstd, zlib dan lzma selama bertahun-tahun.

# restic: enable zstd compression on the whole repo (0.14+)
restic backup --compression max /srv

# or set it once as an environment default
export RESTIC_COMPRESSION=auto

# Borg: choose the compression per-archive
borg create --compression zstd,10 repo::archive /srv

Prune, retensi, dan membebaskan ruang

Kebijakan retensi adalah tempat jebakan halus Borg bersembunyi. Kedua alat menyatakan retensi dengan cara ramah yang sama: simpan sekian snapshot harian, mingguan, bulanan dan tahunan lalu buang sisanya. Di restic, perintah forget dengan flag prune sekaligus menghapus referensi snapshot dan mengemas ulang data, membebaskan ruang dalam satu langkah. Di Borg, prune hanya menghapus entri arsip; ruang disk tidak dikembalikan sampai Anda menjalankan borg compact secara terpisah. Lewatkan itu dan repository Anda terus membesar walau kebijakan retensi terlihat benar.

# restic: forget by policy AND reclaim space in one command
restic forget \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
    --prune

# Borg: prune by policy, THEN compact to actually free disk
borg prune --list \
    --keep-daily=7 --keep-weekly=4 --keep-monthly=6 repo
borg compact repo   # do not forget this second step

Kecepatan dan keandalan restore

Restore adalah satu-satunya metrik backup yang penting ketika keadaan sedang genting. Borg konsisten cepat memulihkan dari storage lokal atau SSH karena membaca chunk berurutan dari disk terdekat. restic dahulu punya restorer lebih lambat, tetapi mesin restore-nya yang ditulis ulang memparalelkan unduhan chunk, yang sangat penting saat repository Anda berada di object storage lintas jaringan. Ringkasan jujurnya: untuk target lokal dan SSH, Borg biasanya memulihkan lebih cepat; untuk target object storage, unduhan paralel restic menutup celah dan sering menang karena Borg toh tidak bisa bicara ke backend itu secara langsung.

Yang saya pilih

Aturan saya sederhana dan berdasarkan di mana byte-nya mendarat. Jika tujuan backup adalah object storage, yang untuk VPS self-hosted biasanya berarti bucket kompatibel S3 murah, saya pakai restic: backend native, binary tunggal, dan prune satu perintah membuat seluruh pipeline sepele untuk di-script di GitHub Actions atau cron job. Jika tujuannya adalah storage box khusus yang saya jangkau lewat SSH, atau disk lokal kedua, saya pakai Borg untuk deduplikasi lebih halus dan restore lokal lebih cepat, dan saya tidak pernah lupa langkah compact. Keduanya sangat bagus; backend-lah yang menentukan.