Restic vs BorgBackup: Pilih yang Mana?

Restic vs BorgBackup dalam satu paragraf

Restic dan BorgBackup memiliki fungsi inti yang sama: pencadangan inkremental Linux server yang terenkripsi dan menggunakan deduplikasi. Perbedaan yang menentukan pilihan adalah lokasi penyimpanan cadangan. Restic mendukung S3 dan API object storage lainnya secara native, sehingga bucket dapat menjadi target utama tanpa perlu memasang apa pun di sisi tujuan. Borg memerlukan program borg yang terpasang pada mesin tempat repository disimpan, karena repository 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 content-defined chunking, sehingga direktori berukuran 40 GB yang berubah sebesar 200 MB akan mengunggah sekitar 200 MB. Keduanya mengenkripsi data di sisi client. Keduanya memasang snapshot dengan FUSE (filesystem in userspace), sehingga Anda dapat menyalin satu file. Per Juli 2026, versi restic adalah 0.19.1 dan seri stabil Borg adalah 1.4, dengan versi 1.4.5. Borg 2.0 telah berada dalam tahap beta selama bertahun-tahun dan masih ditandai hanya untuk pengujian, jadi gunakan 1.4 untuk deployment saat ini.

Model repositori adalah perbedaan yang sebenarnya

Repositori restic adalah direktori berisi file: config, keys/, snapshots/, index/, dan data/ yang berisi file pack. Tidak ada hal lain yang diperlukan untuk membacanya. Karena itu, restic dapat menggunakan banyak backend. Setiap penyimpanan yang dapat menulis, mengambil, mencantumkan, dan menghapus blob dapat menyimpan repositori restic. Dengan demikian, satu binary mendukung path lokal, SFTP, REST server miliknya sendiri, S3, Backblaze B2, Azure, Google Cloud Storage, dan apa pun yang dapat dijangkau rclone.

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

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

Borg menjadikan enkripsi sebagai pilihan saat membuat repositori, dan pilihan tersebut bersifat permanen. borg init --encryption=repokey menyimpan kunci terenkripsi di dalam repositori, sehingga frasa sandi saja cukup untuk memulihkannya. --encryption=keyfile menyimpan kunci di sisi klien dalam ~/.config/borg/keys/, sehingga orang yang mencuri seluruh repositori tetap tidak dapat mengakses data. Namun, Anda harus mencadangkan berkas kunci tersebut secara terpisah. Jika tidak, arsip tidak dapat dibaca. Setiap mode memiliki varian -blake2 yang melakukan autentikasi dengan BLAKE2b, bukan HMAC-SHA256. Varian ini lebih cepat pada perangkat keras yang tidak memiliki akselerasi SHA. --encryption=none juga tersedia. Mode ini merupakan pilihan yang tepat jika repositori berada di disk terenkripsi milik Anda.

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

Kompresi dan alasan restic terlambat mendukungnya

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

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

restic tidak mendukung kompresi hingga format repositori 2, yang memerlukan restic 0.14.0 atau versi lebih baru. Format 2 sekarang menjadi default untuk repositori baru, dan kompresi diatur dengan --compression menggunakan nilai auto, off, atau max. Repositori lama dengan format 1 tetap tidak dikompresi hingga Anda memigrasikannya. Jadi, jika repositori restic Anda dibuat sebelum 0.14 dan belum pernah dimigrasikan, Anda masih membayar ukuran penuh untuk teks, log, dan dump database.

Target jarak jauh: S3 dibandingkan dengan SSH

Di sinilah pilihan biasanya ditentukan.

Restic yang mengakses S3 memerlukan kredensial di lingkungan dan tidak memerlukan proses lain yang berjalan di lokasi mana pun. Pola yang sama berlaku untuk bucket yang Anda kelola sendiri. Kombinasi ini umum digunakan: jalankan MinIO untuk API S3 di VPS Anda sendiri dan 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 repositori jarak jauh memerlukan SSH serta instalasi Borg di sisi jarak jauh. Versi di sana juga harus kompatibel dengan klien. Hal ini menjadi kendala jika sisi jarak jauh bukan milik Anda. Namun, hal ini tidak menjadi masalah jika sisi jarak jauh adalah server kedua yang sudah Anda kelola. Konfigurasi ini memberi perlindungan terkuat terhadap ransomware yang ditawarkan salah satu alat tersebut: kunci SSH append-only. Paksa kunci tersebut menjalankan borg serve. Dengan demikian, klien dapat menambahkan arsip tetapi tidak dapat menghapusnya, sehingga mesin yang dibobol tidak dapat menghapus riwayatnya sendiri.

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

Restic memiliki padanan yang setara hanya jika Anda menjalankan REST server miliknya sendiri, yang mendukung mode append-only. Untuk S3 biasa, Anda dapat memperoleh efek yang sama melalui kebijakan bucket atau object lock. Pengaturan tersebut merupakan tanggung jawab penyedia, bukan restic. Amankan transportasinya juga, karena sisi SSH ini memerlukan perhatian yang sama seperti login lainnya: terapkan SSH yang hanya menggunakan kunci dengan entri authorized_keys terbatas pada akun pencadangan.

Kecepatan: implikasi setiap desain

Kedua proyek tidak menerbitkan tolok ukur yang dapat Anda andalkan untuk data Anda sendiri. Karena itu, gunakan mekanismenya sebagai dasar penilaian.

Borg melalui SSH cepat pada koneksi dengan latensi tinggi karena sisi servernya cerdas. Klien mengirimkan permintaan, proses borg serve jarak jauh menjawabnya berdasarkan indeks repositori, dan transaksi diterapkan di satu tempat. Pencarian chunk tidak berubah menjadi perjalanan bolak-balik jaringan untuk setiap file kecil.

Restic pada penyimpanan objek tidak memiliki sisi server, sehingga harus membangun informasinya dari file indeks dan file pack yang diambil melalui HTTP. Agar jumlah permintaan 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, pencadangan berikutnya berjalan lambat karena cache harus dibangun ulang. 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 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 berlangsung. Dua klien yang menulis ke satu repositori secara bersamaan tidak dapat bekerja: klien kedua menunggu, lalu gagal karena waktu tunggu kunci habis. Pola yang didukung adalah satu repositori untuk setiap klien. Ini juga berarti 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 pekerjaan pemeliharaan seperti prune mengambil kunci eksklusif. Sepuluh server serupa yang diarahkan ke satu repositori restic melakukan deduplikasi satu sama lain, dan server kedua serta server berikutnya biasanya hanya menyimpan sangat sedikit data. Konsekuensinya adalah dampak kegagalan yang lebih luas: satu kata sandi dan satu repositori menampung semuanya, sehingga kehilangan kata sandi berarti kehilangan seluruh data dari sepuluh server.

Retensi: lupakan lalu prune, dibandingkan dengan prune lalu compact

Kedua alat memisahkan tindakan “menentukan apa yang dipertahankan” dari tindakan “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 alat dan perlu dijelaskan dengan tegas. Pada Borg, borg prune menghapus arsip, tetapi tidak membebaskan ruang disk secara langsung. Ruang tersedia kembali saat borg compact dijalankan. Karena itu, tugas cron yang menjalankan prune tetapi tidak pernah menjalankan compact akan membuat repositori terus membesar, meskipun daftar arsip tetap singkat. Pada restic, forget tanpa --prune hanya menghapus referensi snapshot. Datanya 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.

Memulihkan, satu-satunya pengujian yang penting

Kedua alat 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 bentuk path dalam borg extract. Path di dalam arsip disimpan tanpa garis miring di awal, sehingga etc/nginx benar. /etc/nginx tidak cocok dengan apa pun dan tidak mengekstrak apa pun, tanpa error yang menjelaskan penyebabnya. Ekstraksi juga menulis ke direktori kerja saat ini. Karena itu, pindah ke direktori sementara terlebih dahulu agar file aktif tidak tertimpa file lama.

Apa pun alat yang Anda pilih, penjadwalan hanya mencakup separuh pekerjaan. Jalankan pemulihan ke direktori sementara berdasarkan timer yang benar-benar Anda pantau, seperti yang dilakukan panduan lengkap panduan backup restic untuk VPS dengan timer systemd.

Pilihan yang tepat untuk setiap kebutuhan

Pilih restic jika targetnya adalah penyimpanan objek, jika Anda menginginkan satu biner tanpa perangkat lunak di sisi tujuan, jika beberapa mesin harus melakukan deduplikasi satu sama lain, atau jika pihak yang melakukan pemulihan mungkin bukan Anda. restic adalah satu biner statis dengan URL untuk repositori, dan hal ini sulit dikalahkan dari sisi operasional.

Pilih Borg jika targetnya adalah mesin Linux yang Anda kendalikan, jika koneksi memiliki latensi dan dataset terdiri atas jutaan file kecil, jika Anda menginginkan kunci SSH append-only sebagai pengendalian terhadap ransomware, atau jika Anda ingin mengatur kompresi untuk setiap pekerjaan. Borg adalah alat yang lebih lama, seri stabilnya berkembang secara perlahan, dan dalam perangkat lunak pencadangan hal ini merupakan keunggulan.

Keduanya merupakan pilihan yang benar. Pilihan yang salah adalah pilihan yang tidak pernah Anda uji. Jika Anda sudah membuat dump tingkat aplikasi, pertahankan: pola dalam penyiapan Nextcloud pada Docker dengan dump basis data berlaku untuk kedua alat tersebut, karena file basis data aktif yang disalin pada waktu acak bukanlah cadangan basis data.

FAQ

Mana yang lebih cepat, restic atau BorgBackup?

Pada disk lokal atau LAN cepat, keduanya memiliki kinerja yang hampir sama. Keduanya akhirnya dibatasi oleh kecepatan membaca dan hashing pada sumber. Borg cenderung lebih unggul melalui koneksi SSH dengan latensi tinggi dan jumlah file kecil yang sangat banyak, karena proses borg serve di sisi jarak jauh menjawab kueri indeks tanpa perjalanan bolak-balik jaringan untuk setiap chunk. Restic cenderung lebih unggul saat targetnya adalah penyimpanan objek, yang sama sekali tidak dapat digunakan oleh Borg.

Apakah BorgBackup dapat mencadangkan data ke S3 atau Backblaze B2?

Tidak secara langsung. Repository Borg dilayani oleh proses borg serve melalui SSH. Tidak ada proses seperti itu yang berjalan di dalam bucket. Sebagai solusi, pengguna memasang penyimpanan objek sebagai filesystem dengan rclone. Namun, proyek Borg tidak merekomendasikan cara ini, karena mount yang terputus di tengah transaksi dapat merusak repository. Jika memerlukan penyimpanan objek, gunakan restic.

Apakah saya dapat menjalankan kedua alat pada data yang sama?

Ya, dan sebagian pengguna melakukannya: Borg ke server kedua untuk pemulihan lokal yang cepat, serta restic ke penyimpanan objek untuk salinan di lokasi terpisah. Keduanya tidak berbagi data apa pun. Akibatnya, Anda membayar biaya membaca dan hashing dua kali serta harus menyimpan dua kata sandi dengan aman. Lakukan ini hanya jika Anda telah menguji kedua proses pemulihan.

Apa yang terjadi jika saya kehilangan kata sandi repository?

Data tidak dapat dipulihkan pada kedua alat. Restic menurunkan key-nya dari kata sandi menggunakan scrypt, dan tidak ada cara untuk melewatinya. Borg dalam mode repokey menyimpan key terenkripsi di dalam repository, sehingga passphrase saja cukup untuk memulihkannya. Dalam mode keyfile, Anda juga memerlukan file key dari ~/.config/borg/keys/. Simpan kata sandi di password manager yang tidak berada di server yang dicadangkan. 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 dalam tahap beta, yaitu 2.0.0b22, dan proyek tersebut menandainya 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 sekarang tidak akan membuat Anda terjebak.