Restic vs BorgBackup: Pilih yang Mana?

Restic vs BorgBackup dalam satu paragraf

Restic dan BorgBackup menjalankan fungsi inti yang sama: pencadangan inkremental, terenkripsi, dan dengan deduplikasi untuk server Linux. 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 memasang apa pun di sisi tujuan. Borg memerlukan program borg terpasang pada mesin yang menyimpan repository, karena repository Borg dilayani oleh sebuah proses, bukan oleh filesystem atau API. Jika target Anda adalah object storage, jawabannya 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 content-defined chunking, sehingga direktori berukuran 40 GB yang berubah sebesar 200 MB akan mengunggah kira-kira 200 MB. Keduanya mengenkripsi data pada sisi client. Keduanya memasang snapshot dengan FUSE (filesystem in userspace), sehingga Anda dapat menyalin satu file. Per July 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, jadi gunakan 1.4 untuk deployment saat ini.

Perbedaan sebenarnya terletak pada model repositori

Repositori restic adalah direktori yang berisi file: config, keys/, snapshots/, index/, dan data/ yang penuh dengan file pack. Tidak ada hal lain yang diperlukan untuk membacanya. Karena itu, restic dapat menggunakan begitu banyak backend. Setiap penyimpanan yang dapat menulis, mengambil, mencantumkan, dan menghapus blob dapat menyimpan repositori restic. Inilah yang memungkinkan satu binary mendukung path lokal, SFTP, REST server bawaannya, S3, Backblaze B2, Azure, Google Cloud Storage, serta semua lokasi yang dapat dijangkau rclone.

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

Fakta desain tunggal 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 file pack yang ditulis setelahnya. Jika kata sandi hilang, data tidak dapat dipulihkan karena sejak awal memang tidak ada mekanisme pemulihan.

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

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 menambahkannya

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 proses. auto menjalankan heuristik untuk setiap chunk sehingga data yang sudah terkompresi tidak dikompresi ulang.

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

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

Target remote: S3 versus SSH

Di sinilah pilihan biasanya ditentukan.

Restic yang mengakses S3 memerlukan kredensial di environment dan tidak memerlukan proses lain yang berjalan di tempat lain. Pola yang sama berlaku untuk bucket yang Anda host sendiri. Ini merupakan pasangan yang umum: jalankan MinIO untuk API S3 pada VPS milik 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 remote memerlukan SSH serta instalasi Borg di sisi remote. Versi Borg di sana juga harus kompatibel dengan client. Hal ini menjadi kendala jika sisi remote bukan milik Anda. Namun, hal ini tidak menjadi masalah jika sisi remote adalah server kedua yang sudah Anda administrasikan. Pendekatan ini memberi perlindungan terkuat terhadap ransomware yang ditawarkan kedua tool tersebut: SSH key append-only. Paksa key tersebut untuk menjalankan borg serve agar client dapat menambahkan archive, tetapi tidak dapat menghapusnya. Dengan demikian, mesin yang telah dibobol tidak dapat menghapus riwayat backup-nya sendiri.

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

Restic memiliki padanan fitur ini hanya jika Anda menjalankan REST server miliknya sendiri, yang mendukung mode append-only. Pada S3 biasa, Anda mendapatkan efek yang sama melalui bucket policy atau object lock. Fitur tersebut merupakan tanggung jawab provider, bukan restic. Amankan transport dengan baik, karena sisi SSH memerlukan perlindungan yang sama seperti login lainnya: terapkan SSH hanya dengan key dan entri authorized_keys terbatas 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. Client mengajukan permintaan, proses borg serve pada server remote menjawabnya berdasarkan indeks repository, dan transaksi dikomit di satu tempat. Pencarian chunk tidak berubah menjadi round trip jaringan untuk setiap file kecil.

Restic pada object storage tidak memiliki sisi server. Karena itu, restic harus membangun informasinya dari file indeks dan file pack yang diambil melalui HTTP. Agar jumlah request tetap terkendali, restic menggabungkan 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, backup berikutnya berjalan lambat karena restic harus membangunnya kembali. Pada koneksi dengan latensi tinggi dan jutaan file kecil, restic terasa lebih lambat daripada Borg untuk data yang sama.

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

Penguncian dan pencadangan beberapa mesin

Borg 1.4 mengambil exclusive lock pada repository selama seluruh operasi berlangsung. Dua client yang menulis ke satu repository secara bersamaan tidak dapat bekerja: client kedua menunggu, lalu gagal karena lock timeout. Pola yang didukung adalah satu repository untuk setiap client. Artinya, deduplikasi hanya terjadi di dalam repository satu mesin, sehingga sepuluh server yang hampir identik menyimpan sepuluh salinan base system yang sama.

Restic memungkinkan beberapa client mencadangkan data ke satu repository secara bersamaan karena operasi pencadangan mengambil shared lock, sedangkan hanya operasi pemeliharaan seperti prune yang mengambil exclusive lock. Sepuluh server serupa yang diarahkan ke satu repository restic melakukan deduplikasi satu sama lain, sehingga server kedua dan seterusnya biasanya hanya menyimpan sedikit data. Konsekuensinya adalah blast radius yang lebih besar: satu password dan satu repository menampung semua data, sehingga kehilangan password berarti kehilangan seluruh data dari sepuluh server tersebut.

Retensi: forget lalu prune, dibandingkan prune lalu compact

Kedua tool memisahkan tindakan “menentukan apa yang dipertahankan” dari “mengembalikan 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 tool dan perlu dijelaskan secara langsung. Pada Borg, borg prune menghapus archive, tetapi tidak membebaskan ruang disk dengan sendirinya. Ruang baru tersedia kembali saat borg compact dijalankan. Karena itu, cron job yang hanya menjalankan prune dan tidak pernah menjalankan compact akan membuat repository terus membesar, meskipun daftar archive tetap pendek. Pada restic, forget tanpa --prune hanya menghapus referensi snapshot. Datanya tetap tersimpan sampai prune dijalankan.

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

Pemulihan adalah satu-satunya pengujian yang menentukan

Kedua tool melakukan mount pada 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 bentuk path dalam borg extract. Path di dalam arsip disimpan tanpa garis miring di awal, sehingga etc/nginx benar, sedangkan /etc/nginx tidak cocok dengan apa pun dan tidak mengekstrak apa pun. Tidak ada error yang menjelaskan penyebabnya. Proses ekstraksi juga menulis ke direktori kerja saat ini. Karena itu, pindahlah ke direktori scratch terlebih dahulu agar file aktif tidak tertimpa file lama.

Pemulihan yang selesai tanpa error tetap bukan bukti keberhasilan. Aplikasi yang berjalan di atasnya memiliki definisi sendiri tentang pemulihan lengkap. Server Immich yang dibangun ulang dari salinan direktori data Postgres dapat kembali dengan semua foto tersedia di disk, tetapi timeline tetap kosong. Kondisi inilah yang harus diatasi oleh pencadangan dan pemulihan Immich.

Apa pun tool yang Anda pilih, jadwal hanya mencakup separuh pekerjaan. Jalankan pemulihan ke direktori scratch menggunakan timer yang benar-benar Anda monitor, seperti yang dilakukan panduan lengkap pencadangan restic untuk VPS dengan systemd timer.

Mana yang unggul untuk setiap kebutuhan

Pilih restic jika targetnya adalah object storage, jika Anda menginginkan satu binary tanpa software pada sisi tujuan, jika beberapa mesin perlu melakukan deduplikasi satu sama lain, atau jika orang yang melakukan pemulihan mungkin bukan Anda. restic adalah static binary tunggal yang menggunakan URL untuk repository, dan dari sisi operasional pendekatan ini sulit dikalahkan.

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

Keduanya adalah pilihan yang benar. Pilihan yang salah adalah pilihan yang tidak pernah Anda uji. Jika Anda sudah membuat dump pada tingkat aplikasi, tetap gunakan dump tersebut: pola pada setup Nextcloud di 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 memiliki kinerja yang hampir sama. Keduanya pada akhirnya 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 bolak-balik jaringan untuk setiap chunk. Restic cenderung lebih unggul saat targetnya adalah object storage, yang sama sekali tidak dapat digunakan Borg.

Apakah BorgBackup dapat 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 jalan keluar, sebagian pengguna memasang object storage sebagai filesystem dengan rclone. Namun, proyek Borg tidak merekomendasikan cara ini, karena mount yang terputus di tengah transaksi dapat merusak repository. Jika Anda memerlukan object storage, gunakan restic.

Apakah saya dapat menjalankan kedua tool pada data yang sama?

Ya, dan sebagian orang memang melakukannya: Borg ke server kedua untuk pemulihan lokal yang cepat, serta restic ke object storage untuk salinan di lokasi lain. Keduanya tidak berbagi data apa pun. Karena itu, Anda membayar biaya pembacaan dan hashing dua kali, serta harus menyimpan dua password dengan aman. Lakukan ini hanya jika Anda telah menguji kedua proses pemulihan.

Apa yang terjadi jika saya kehilangan password repository?

Data tidak dapat dipulihkan pada kedua tool. Restic menurunkan key dari password menggunakan scrypt dan tidak memiliki bypass. Borg dalam mode repokey menyimpan key terenkripsi di dalam repository, sehingga passphrase saja cukup untuk memulihkan data. 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 ekspor 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 proyek tersebut menetapkannya hanya 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.