DevOps
restic vs BorgBackup: Backup Terenkripsi dan Terdeduplikasi
Juli 20269 menit baca
restic adalah pilihan lebih baik untuk S3 dan object storage lain. Ia punya dukungan native dan kelas satu untuk Amazon S3, store kompatibel S3 apa pun seperti MinIO atau Cloudflare R2, Backblaze B2, Azure dan Google Cloud. BorgBackup 1.4 hanya bicara ke repository lokal dan SSH serta butuh alat seperti rclone atau borgmatic untuk menjangkau object storage, yang menambah lapisan ekstra yang rapuh.
Ya, kedua alat mengenkripsi semuanya di sisi klien sebelum meninggalkan mesin Anda, termasuk nama file dan struktur direktori, sehingga penyedia storage tidak tahu apa pun tentang data Anda. restic memakai AES-256 dengan autentikasi Poly1305, dan Borg memakai AES-256 dengan HMAC-SHA256 di seri stabil 1.4. Anda hanya perlu melindungi passphrase atau file kunci.
Karena borg prune hanya menghapus entri arsip; ia tidak membebaskan ruang disk. Anda harus menjalankan borg compact sebagai langkah kedua terpisah setelah prune untuk benar-benar membebaskan ruang di repository. restic menangani keduanya dalam satu langkah saat Anda menjalankan forget dengan flag prune.
Tergantung di mana repository berada. Borg konsisten lebih cepat memulihkan dari disk lokal atau storage yang dijangkau SSH karena membaca chunk berurutan di dekatnya. Mesin restore restic yang ditulis ulang memparalelkan unduhan chunk, sehingga bekerja lebih baik ketika repository berada di object storage lintas jaringan.
Ya. Klaim usang yang umum adalah restic tidak punya kompresi, padahal ia mendukung kompresi zstd sejak versi 0.14 yang dirilis tahun 2022. Anda mengaktifkannya dengan flag repository atau variabel lingkungan RESTIC_COMPRESSION. BorgBackup sudah menawarkan kompresi lz4, zstd, zlib dan lzma selama bertahun-tahun.
Ringkasan Utama
restic dan BorgBackup sama-sama memberi backup terenkripsi dan terdeduplikasi, tetapi komprominya berbeda. restic bicara langsung ke S3, Backblaze B2, Azure dan GCS serta hadir sebagai satu binary Go. Borg lebih cepat di storage lokal dan SSH, mendeduplikasi lebih halus, dan butuh langkah compact terpisah untuk benar-benar membebaskan ruang setelah prune.
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.
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/postgresqlIni 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.
Jika target backup Anda adalah object storage seperti S3, R2 atau B2, pilih restic dulu. Menjalankan Borg di atas rclone mount berjalan lancar sampai mount putus diam-diam di tengah backup dan Anda mendapat arsip setengah tertulis. Semakin sedikit lapisan berarti semakin sedikit kejutan jam 3 pagi.
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 /srvKebijakan 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 stepAlat mana pun yang Anda pilih, selalu akhiri proses backup dengan pemeriksaan integritas terjadwal: restic check --read-data-subset=5% atau borg check. Deduplikasi berarti satu chunk rusak bisa meracuni banyak snapshot, jadi memverifikasi bahwa chunk masih terbaca bukanlah opsional.
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.
| Dimensi | restic (0.18.x) | BorgBackup (1.4.x) |
|---|---|---|
| Bahasa / distribusi | Satu binary Go statis | Python, dipasang lewat paket atau binary |
| Backend native | Lokal, SFTP, REST, S3, B2, Azure, GCS, rclone | Hanya lokal dan SSH (object storage di 2.0 beta) |
| Enkripsi | AES-256-CTR + Poly1305, kunci scrypt | AES-256-CTR + HMAC-SHA256 (OCB di 2.0) |
| Kompresi | zstd (sejak 0.14) | lz4, zstd, zlib, lzma |
| Pembebasan ruang setelah prune | Satu langkah: forget --prune | Dua langkah: prune lalu compact |
| Target restore terbaik | Object storage (unduhan paralel) | Storage lokal / SSH (kecepatan berurutan) |
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.
Apa pun pilihan Anda, uji restore nyata ke direktori sementara minimal sebulan sekali. Backup yang belum pernah Anda pulihkan adalah hipotesis, bukan backup. Otomatiskan latihan periksa-dan-restore dengan cara yang sama seperti Anda mengotomatiskan backup itu sendiri.