Restic vs BorgBackup: Pilih yang Mana?

Restic vs BorgBackup, dalam satu paragraf

Restic dan BorgBackup memiliki fungsi inti yang sama: pencadangan server Linux yang terdeduplikasi, terenkripsi, dan inkremental. Perbedaan yang menentukan pilihan adalah lokasi penyimpanan cadangan. Restic mendukung S3 dan API object storage lainnya secara native, sehingga bucket dapat langsung digunakan sebagai target tanpa perlu memasang apa pun di sisi tujuan. Borg memerlukan program borg terpasang pada mesin yang menyimpan repositori, karena repositori Borg dilayani oleh sebuah proses, bukan oleh filesystem atau API. Jika target Anda adalah object storage, pilihannya sudah jelas. Jika target Anda adalah mesin Linux kedua yang Anda kendalikan, Borg dapat digunakan dan sering kali lebih cepat.

Perbedaan lainnya lebih kecil. Keduanya membagi file menggunakan chunking yang ditentukan oleh konten, sehingga direktori berukuran 40 GB yang berubah sebesar 200 MB akan mengunggah sekitar 200 MB. Keduanya mengenkripsi data pada client. Keduanya memasang snapshot dengan FUSE (filesystem in userspace), sehingga Anda dapat menyalin satu file dari dalamnya. Per Juli 2026, versi restic adalah 0.19.1 dan seri stabil Borg adalah 1.4, tepatnya 1.4.5. Borg 2.0 telah berstatus beta selama bertahun-tahun dan masih ditandai hanya untuk pengujian, sehingga 1.4 adalah versi yang sebaiknya Anda deploy saat ini.

Perbedaan sebenarnya terletak pada model repositori

Repositori restic adalah direktori berisi file: config, keys/, snapshots/, index/, dan data/ yang penuh dengan file pack. Tidak ada komponen lain yang diperlukan untuk membacanya. Karena itu, restic dapat menggunakan begitu banyak backend. Setiap penyimpanan yang dapat menaruh, mengambil, membuat daftar, dan menghapus blob dapat menyimpan repositori restic. Dengan demikian, satu biner dapat mendukung path lokal, SFTP, REST server miliknya sendiri, S3, Backblaze B2, Azure, Google Cloud Storage, dan semua lokasi yang dapat dijangkau oleh rclone.

Repositori Borg juga berupa file pada disk, tetapi Borg tidak pernah mengaksesnya melalui transportasi sederhana. Untuk repositori jarak jauh, Borg menjalankan borg serve di sisi lain melalui SSH, lalu menggunakan protokolnya sendiri untuk berkomunikasi dengan proses tersebut. Sisi server menjalankan pekerjaan sebenarnya: menyimpan repositori, menerapkan transaksi, dan menjawab pertanyaan tentang indeks. Inilah alasan Borg tidak memiliki backend S3 dan proyek tersebut belum menambahkannya. Tidak ada proses yang dapat dijalankan di dalam bucket.

Satu fakta desain ini menghasilkan sebagian besar perbedaan praktis berikut.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

Enkripsi: salah satunya dapat dinonaktifkan

Restic selalu menggunakan enkripsi. Tidak ada mode tanpa enkripsi. restic init meminta kata sandi, menurunkan kunci dari kata sandi tersebut dengan scrypt, lalu mengenkripsi dan mengautentikasi setiap pack file yang ditulis setelahnya. Jika kata sandi hilang, data juga hilang karena tidak ada mekanisme pemulihan yang sengaja disediakan.

Borg menjadikan enkripsi sebagai pilihan saat repository dibuat, dan pilihan tersebut bersifat permanen. borg init --encryption=repokey menyimpan kunci terenkripsi di dalam repository, sehingga passphrase saja cukup untuk melakukan pemulihan. --encryption=keyfile menyimpan kunci di client dalam ~/.config/borg/keys/, sehingga orang yang mencuri seluruh repository tetap tidak dapat mengakses apa pun. Karena itu, Anda harus mencadangkan file kunci tersebut secara terpisah. Jika tidak, arsip Anda tidak dapat dibaca. Setiap mode memiliki varian -blake2 yang menggunakan autentikasi BLAKE2b, bukan HMAC-SHA256. Varian ini lebih cepat pada hardware yang tidak memiliki akselerasi SHA. --encryption=none juga tersedia. Ini merupakan pilihan yang tepat jika repository berada pada disk terenkripsi milik Anda sendiri.

Aturan praktisnya: gunakan repokey-blake2 untuk backup server biasa, keyfile jika repository berada di lokasi yang tidak sepenuhnya Anda percayai, dan jangan pernah menggunakan none pada mesin sewaan.

Kompresi, dan mengapa restic terlambat mendukungnya

Borg telah mendukung kompresi sejak awal. Default-nya adalah lz4, yang dipilih karena cukup cepat untuk selalu diaktifkan. zstd menerima level 1 hingga 22 dan default-nya adalah 3, zlib dan lzma digunakan jika ukuran dalam byte lebih penting daripada waktu, sedangkan auto menjalankan heuristik untuk setiap chunk agar data yang sudah dikompresi tidak dikompresi ulang.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

Restic sama sekali tidak mendukung kompresi hingga format repository 2, yang memerlukan restic 0.14.0 atau yang lebih baru. Format 2 kini menjadi default untuk repository baru, dan kompresi diatur dengan --compression menggunakan nilai auto, off, atau max. Repository lama berformat 1 tetap tidak dikompresi sampai Anda memigrasikannya. Jadi, jika repository restic Anda dibuat sebelum 0.14 dan tidak pernah dimigrasikan, Anda masih menggunakan ukuran penuh untuk teks, log, dan dump database.

Target jarak jauh: S3 versus SSH

Di sinilah pilihan biasanya ditentukan.

Restic yang mengakses S3 memerlukan kredensial di environment dan tidak memerlukan proses lain yang berjalan di lokasi mana pun. Pola yang sama juga berlaku untuk bucket yang Anda host sendiri. Ini merupakan pasangan yang umum: jalankan MinIO untuk API S3 pada VPS Anda sendiri lalu arahkan restic ke sana.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Borg yang mengakses repository jarak jauh memerlukan SSH serta instalasi Borg di sisi jarak jauh. Versi di sana juga harus kompatibel dengan client. Ini menjadi kendala jika sisi jarak jauh bukan milik Anda. Namun, hal ini tidak menjadi masalah jika sisi tersebut adalah server kedua yang sudah Anda administrasikan. Pendekatan ini juga memberi kontrol terkuat terhadap ransomware yang ditawarkan kedua tool tersebut: SSH key append-only. Paksa key tersebut untuk menjalankan borg serve. Dengan begitu, client dapat menambahkan archive tetapi tidak dapat menghapusnya, sehingga mesin yang telah dibobol tidak dapat menghapus seluruh riwayatnya sendiri.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

Restic memiliki padanan hanya jika Anda menjalankan REST server miliknya sendiri, yang mendukung mode append-only. Pada S3 biasa, efek yang sama dapat diperoleh melalui bucket policy atau object lock. Pengaturan tersebut merupakan tanggung jawab provider, bukan restic. Amankan transportasinya juga, karena sisi SSH ini memerlukan perhatian yang sama seperti login lainnya: terapkan SSH hanya dengan key dan entri authorized_keys yang dibatasi pada akun backup.

Kecepatan: implikasi setiap desain

Tidak ada proyek yang menerbitkan benchmark yang dapat Anda jadikan acuan untuk data Anda sendiri. Karena itu, gunakan mekanismenya sebagai dasar penilaian.

Borg melalui SSH cepat pada koneksi dengan latensi tinggi karena sisi servernya memiliki kemampuan pemrosesan. Klien mengajukan permintaan, proses borg serve jarak jauh menjawab berdasarkan indeks repositori, lalu transaksi diselesaikan di satu tempat. Pencarian chunk tidak berubah menjadi round trip jaringan untuk setiap file kecil.

Restic pada object storage tidak memiliki pemrosesan di sisi server. Karena itu, restic harus membangun informasinya dari file indeks dan file pack yang diambil melalui HTTP. Agar jumlah permintaan tetap wajar, restic mengemas banyak chunk kecil ke dalam file pack yang lebih besar sebelum mengunggahnya. Restic juga menyimpan cache lokal di ~/.cache/restic agar proses berikutnya tidak perlu mengambil ulang seluruh indeks. Jika cache tersebut dihapus, proses pencadangan berikutnya akan lambat saat membangun ulang indeks. Pada koneksi dengan latensi tinggi dan jutaan file kecil, restic terasa lebih lambat daripada Borg untuk data yang sama.

Pada disk lokal atau LAN yang cepat, perbedaannya sebagian besar hilang. Kedua alat akhirnya dibatasi oleh kecepatan membaca dan menghitung hash sumber.

Mengunci dan mencadangkan beberapa mesin

Borg 1.4 mengambil kunci eksklusif pada repositori selama seluruh operasi. Dua klien yang menulis ke satu repositori pada saat yang sama tidak dapat berjalan: klien kedua menunggu, lalu gagal setelah waktu tunggu kunci habis. Pola yang didukung adalah satu repositori untuk setiap klien. Artinya, deduplikasi hanya terjadi di dalam repositori satu mesin, sehingga sepuluh server yang hampir identik menyimpan sepuluh salinan sistem dasar yang sama.

Restic memungkinkan beberapa klien mencadangkan data ke satu repositori secara bersamaan karena pencadangan mengambil kunci bersama, sedangkan hanya pekerjaan pemeliharaan seperti prune yang mengambil kunci eksklusif. Sepuluh server serupa yang diarahkan ke satu repositori restic dapat melakukan deduplikasi satu sama lain, sehingga server kedua dan seterusnya sering hanya menyimpan sedikit data. Konsekuensinya adalah radius dampak yang lebih besar: satu kata sandi dan satu repositori menyimpan semuanya. Jika kata sandi hilang, seluruh sepuluh cadangan ikut tidak dapat diakses.

Retensi: forget lalu prune, versus prune lalu compact

Kedua alat memisahkan “menentukan apa yang dipertahankan” dari “mengambil kembali ruang”, dan keduanya mengharuskan Anda menjalankan langkah kedua.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

Kesalahannya sama pada kedua alat dan perlu dijelaskan secara langsung. Pada Borg, borg prune menghapus arsip, tetapi tidak membebaskan ruang disk dengan sendirinya. Ruang tersedia kembali saat borg compact dijalankan. Jadi, tugas cron yang hanya menjalankan prune dan tidak pernah menjalankan compact akan membuat repositori terus membesar, meskipun daftar arsip tetap singkat. Pada restic, forget tanpa --prune hanya menghapus referensi snapshot. Data tetap ada sampai prune dijalankan.

Jalankan restic check setelah pruning. Perintah ini memverifikasi struktur repositori dan memberi tahu Anda jika ada kerusakan. Hal ini jauh lebih baik daripada baru mengetahuinya saat melakukan pemulihan.

Pemulihan adalah satu-satunya pengujian yang benar-benar penting

Kedua tool memasang snapshot sehingga Anda dapat menelusurinya. Ini adalah cara tercepat untuk mengembalikan satu file.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

Perhatikan format path pada borg extract. Path di dalam arsip disimpan tanpa garis miring di awal, sehingga etc/nginx benar. Sebaliknya, /etc/nginx tidak mencocokkan apa pun dan tidak mengekstrak apa pun. Tidak ada error yang menjelaskan penyebabnya. Proses ekstraksi juga menulis ke direktori kerja saat ini. Karena itu, pindah ke direktori scratch terlebih dahulu. Jika tidak, file aktif akan tertimpa oleh file lama.

Apa pun tool yang Anda pilih, penjadwalan hanya menyelesaikan separuh pekerjaan. Jalankan pemulihan ke direktori scratch menggunakan timer yang benar-benar Anda pantau. Lakukan dengan cara yang sama seperti walkthrough lengkap pada panduan backup restic untuk VPS, yang menggunakan timer systemd.

Mana yang unggul untuk setiap kebutuhan

Pilih restic jika targetnya adalah object storage, jika Anda menginginkan satu binary tanpa software apa pun di sisi tujuan, jika beberapa mesin perlu melakukan deduplikasi terhadap satu sama lain, atau jika orang yang melakukan pemulihan mungkin bukan Anda. restic adalah static binary tunggal dengan URL untuk repository, dan secara operasional sulit dikalahkan.

Pilih Borg jika targetnya adalah mesin Linux yang Anda kendalikan, jika koneksi memiliki latensi tinggi dan dataset berisi jutaan file kecil, jika Anda ingin menggunakan SSH key append-only sebagai pengendali terhadap ransomware, atau jika Anda ingin menyesuaikan kompresi untuk setiap pekerjaan. Borg adalah tool yang lebih lama, seri stabilnya berkembang secara perlahan, dan dalam software backup, hal itu merupakan keunggulan.

Keduanya merupakan jawaban yang benar. Jawaban yang salah adalah pilihan yang tidak pernah Anda uji. Jika Anda sudah membuat dump pada level aplikasi, pertahankan: pola dalam setup Nextcloud pada Docker dengan dump database berlaku untuk kedua tool, karena file database aktif yang disalin pada waktu acak bukanlah backup database.

FAQ

Apakah restic atau BorgBackup lebih cepat?

Pada disk lokal atau LAN cepat, keduanya hampir setara. Keduanya biasanya dibatasi oleh kecepatan pembacaan dan hashing pada sumber. Borg cenderung lebih unggul melalui koneksi SSH dengan latensi tinggi dan sangat banyak file kecil, karena proses borg serve di sisi lain dapat menjawab permintaan indeks tanpa perjalanan pulang-pergi jaringan untuk setiap chunk. Restic cenderung lebih unggul saat targetnya adalah object storage, yang sama sekali tidak dapat digunakan oleh Borg.

Dapatkah BorgBackup mencadangkan data ke S3 atau Backblaze B2?

Tidak secara langsung. Repository Borg disediakan oleh proses borg serve melalui SSH, dan tidak ada proses semacam itu yang berjalan di dalam bucket. Sebagai solusi, object storage dapat di-mount sebagai filesystem dengan rclone. Namun, project Borg tidak merekomendasikan cara ini karena mount yang terputus di tengah transaksi dapat merusak repository. Jika memerlukan object storage, gunakan restic.

Dapatkah saya menjalankan kedua tool terhadap data yang sama?

Ya, dan sebagian orang melakukannya: Borg ke server kedua untuk pemulihan lokal yang cepat, serta restic ke object storage untuk salinan offsite. Keduanya tidak berbagi data apa pun. Karena itu, biaya pembacaan dan hashing harus dibayar dua kali, dan ada dua password yang harus disimpan dengan aman. Lakukan ini hanya jika kedua proses pemulihan sudah diuji.

Apa yang terjadi jika saya kehilangan password repository?

Data tidak dapat dipulihkan pada kedua tool. Restic menurunkan key dari password menggunakan scrypt, dan tidak ada cara untuk melewatinya. Borg dalam mode repokey menyimpan key terenkripsi di dalam repository, sehingga cukup dengan passphrase untuk memulihkannya. Dalam mode keyfile, Anda juga memerlukan file key dari ~/.config/borg/keys/. Simpan password dalam password manager yang tidak berada di server yang dicadangkan, dan export key Borg dengan borg key export jika Anda menggunakan keyfile.

Haruskah saya menunggu Borg 2.0?

Tidak. Per Juli 2026, Borg 2.0 masih berstatus beta, yaitu 2.0.0b22, dan project tersebut hanya menandainya untuk pengujian. Seri stabilnya adalah 1.4, yang saat ini berada pada versi 1.4.5. Mulailah dengan 1.4 sekarang. Borg 2 mengubah format repository dan menyediakan jalur upgrade yang terdokumentasi, sehingga memulai hari ini tidak akan membuat Anda terjebak pada versi lama.