Restic vs BorgBackup: Mana Pilihan Terbaik?

Restic berbanding BorgBackup, dalam satu perenggan

Restic dan BorgBackup kedua-duanya melaksanakan tugas teras yang sama: sandaran (backup) berincremental, disulitkan, dan dinyahduplikasi bagi pelayan Linux. Perbezaan yang menentukan pilihan adalah lokasi destinasi sandaran tersebut. Restic menyokong API S3 dan storan objek lain secara natif, maka bucket menjadi sasaran utama tanpa perlu memasang sebarang perisian di hujung sana. Borg memerlukan program borg dipasang pada mesin yang menyimpan repositori, kerana repositori Borg dihidangkan oleh satu proses, bukannya oleh sistem fail atau API. Jika sasaran anda ialah storan objek, itulah jawapannya. Jika sasaran anda ialah kotak Linux kedua yang anda kawal, Borg boleh digunakan dan selalunya lebih pantas.

Perkara lain hanyalah perbezaan kecil. Kedua-duanya memecahkan fail menggunakan chunking berasaskan kandungan, jadi direktori bersaiz 40 GB yang berubah sebanyak 200 MB hanya akan memuat naik kira-kira 200 MB data. Kedua-duanya melakukan penyulitan pada klien. Kedua-duanya boleh melekapkan snapshot menggunakan FUSE (filesystem in userspace) supaya anda boleh menyalin keluar satu fail sahaja. Setakat Julai 2026, restic berada pada versi 0.19.1 dan siri stabil Borg ialah 1.4, pada versi 1.4.5. Borg 2.0 telah berada dalam fasa beta selama bertahun-tahun dan masih ditandakan sebagai ujian sahaja, jadi 1.4 adalah versi yang patut anda gunakan hari ini.

Model repositori adalah perbezaan sebenar

Repositori restic ialah direktori fail: config, keys/, snapshots/, index/, dan data/ yang penuh dengan fail pek. Tiada perkara lain diperlukan untuk membacanya. Itulah sebabnya restic boleh memacu begitu banyak backend. Mana-mana storan yang boleh meletakkan, mendapatkan, menyenaraikan dan memadam blob boleh menyimpan repositori restic, yang merupakan cara satu binari menyokong laluan tempatan, SFTP, pelayan REST sendiri, S3, Backblaze B2, Azure, Google Cloud Storage, dan apa sahaja yang boleh dicapai oleh rclone.

Repositori Borg juga merupakan fail pada cakera, tetapi Borg tidak pernah berkomunikasi dengannya melalui pengangkutan mudah (dumb transport). Untuk repositori jauh, Borg memulakan borg serve di bahagian hujung sana melalui SSH dan menggunakan protokolnya sendiri untuk proses tersebut. Bahagian pelayan melakukan kerja sebenar: ia memegang repositori, melaksanakan transaksi, dan menjawab soalan indeks. Inilah sebabnya Borg tidak mempunyai backend S3 dan mengapa projek tersebut tidak menambahnya. Tiada proses yang boleh dijalankan di dalam baldi (bucket).

Fakta reka bentuk tunggal itu menghasilkan kebanyakan perbezaan praktikal di bawah.

# 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

Penyulitan: salah satu daripadanya boleh dimatikan

Restic sentiasa disulitkan. Tiada mod tanpa penyulitan. restic init meminta kata laluan, menerbitkan kunci daripadanya menggunakan scrypt, dan setiap fail pek yang ditulis selepas itu akan disulitkan serta disahkan. Jika kata laluan hilang, data tersebut akan lenyap kerana tiada laluan pemulihan yang direka bentuk.

Borg menjadikan penyulitan sebagai pilihan semasa penciptaan repositori, dan pilihan tersebut adalah kekal. borg init --encryption=repokey menyimpan kunci yang disulitkan di dalam repositori, jadi frasa laluan sahaja sudah cukup untuk melakukan pemulihan. --encryption=keyfile menyimpan kunci pada klien di dalam ~/.config/borg/keys/, jadi sesiapa yang mencuri keseluruhan repositori tetap tidak akan mendapat apa-apa, dan anda mesti menyandarkan fail kunci tersebut secara berasingan atau arkib anda tidak boleh dibaca. Setiap mod mempunyai varian -blake2 yang mengesahkan dengan BLAKE2b dan bukannya HMAC-SHA256, yang lebih pantas pada perkakasan tanpa pecutan SHA. --encryption=none juga wujud, dan ia merupakan pilihan yang wajar apabila repositori berada pada cakera terenkripsi milik anda.

Peraturan praktikalnya: repokey-blake2 untuk sandaran pelayan biasa, keyfile apabila repositori berada di tempat yang tidak dipercayai sepenuhnya, dan jangan sekali-kali none pada mesin sewaan.

Pemampatan, dan sebab restic lambat menyediakannya

Borg telah menyokong pemampatan sejak awal lagi. Pilihan lalai ialah lz4, yang dipilih kerana kelajuannya mencukupi untuk digunakan pada semua data. zstd menerima tahap 1 hingga 22 dengan nilai lalai 3, zlib dan lzma disediakan untuk situasi yang mengutamakan penjimatan ruang storan berbanding masa pemprosesan, manakala auto menjalankan heuristik bagi setiap ketulan (chunk) supaya data yang telah dimampatkan tidak dimampatkan buat kali kedua.

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

Restic tidak mempunyai sebarang fungsi pemampatan sehingga format repositori 2 diperkenalkan, yang memerlukan restic 0.14.0 atau lebih baharu. Format 2 kini merupakan format lalai bagi repositori baharu, dan pemampatan ditetapkan dengan --compression pada nilai auto, off atau max. Repositori format 1 yang lama akan kekal tanpa pemampatan sehingga anda melakukan migrasi. Oleh itu, jika repositori restic anda dibuat sebelum versi 0.14 dan anda tidak pernah melakukan migrasi, anda masih menggunakan saiz penuh untuk fail teks, log dan dump pangkalan data.

Sasaran jauh: S3 berbanding SSH

Di sinilah pilihan biasanya dibuat.

Restic yang mencapai S3 memerlukan kelayakan dalam persekitaran dan tiada apa-apa lagi yang perlu dijalankan di mana-mana. Corak yang sama berfungsi terhadap bucket yang anda hoskan sendiri, yang merupakan gandingan biasa: jalankan MinIO untuk API S3 pada VPS anda sendiri dan halakan restic kepadanya.

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 mencapai repositori jauh memerlukan SSH serta pemasangan Borg di bahagian hujung, dan ia memerlukan versi di sana agar serasi dengan klien. Itu menjadi kekangan jika bahagian hujung bukan milik anda. Ia tidak menjadi masalah jika bahagian hujung adalah pelayan kedua yang sudah anda tadbir, dan ia memberikan anda kawalan paling kuat terhadap perisian tebusan (ransomware) yang ditawarkan oleh kedua-dua alat tersebut: kunci SSH jenis append-only. Paksa kunci untuk menjalankan borg serve dan klien boleh menambah arkib tetapi tidak boleh memadamnya, jadi mesin yang terjejas tidak boleh memadam sejarahnya sendiri.

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

Restic mempunyai fungsi setara hanya apabila anda menjalankan pelayan REST miliknya sendiri, yang menyokong mod append-only. Terhadap S3 biasa, anda mendapat kesan yang sama daripada polisi bucket atau object lock, yang merupakan tugas penyedia dan bukan tugas restic. Kawal juga pengangkutan data tersebut, kerana bahagian SSH ini memerlukan penjagaan yang sama seperti log masuk lain: gunakan SSH berasaskan kunci sahaja dengan entri authorized_keys yang terhad pada akaun sandaran.

Kelajuan: implikasi setiap reka bentuk

Tiada satu pun projek menerbitkan penanda aras yang boleh anda percayai untuk data anda sendiri, jadi buatlah pertimbangan berdasarkan mekanismenya.

Borg melalui SSH adalah pantas pada pautan dengan kependaman (latency) kerana bahagian pelayan adalah pintar. Pelanggan bertanyakan soalan, proses borg serve jauh menjawabnya daripada indeks repositori, dan transaksi dilakukan di satu tempat. Carian ketulan (chunk) tidak bertukar menjadi perjalanan pergi-balik rangkaian bagi setiap fail kecil.

Restic pada storan objek tidak mempunyai bahagian pelayan, jadi ia mesti membina gambaran daripada fail indeks dan fail pek yang diambil melalui HTTP. Untuk memastikan bilangan permintaan kekal munasabah, ia membungkus banyak ketulan kecil ke dalam fail pek yang lebih besar sebelum memuat naik, dan ia menyimpan cache tempatan dalam ~/.cache/restic supaya larian seterusnya tidak mengambil semula keseluruhan indeks. Padamkan cache tersebut dan sandaran seterusnya akan menjadi perlahan sementara ia membina semula. Pada pautan dengan kependaman tinggi yang mempunyai berjuta-juta fail kecil, inilah keadaan di mana restic terasa lebih perlahan berbanding Borg pada data yang sama.

Pada cakera tempatan atau LAN yang pantas, jurang tersebut kebanyakannya tertutup, dan kedua-dua alat akhirnya dihadkan oleh kepantasan ia membaca dan melakukan hashing pada sumber.

Penguncian dan sandaran beberapa mesin

Borg 1.4 mengambil kunci eksklusif pada repositori untuk keseluruhan operasi. Dua klien yang menulis ke satu repositori pada masa yang sama tidak akan berfungsi: klien kedua akan menunggu, kemudian gagal dengan tamat masa kunci (lock timeout). Corak yang disokong ialah satu repositori bagi setiap klien. Ini juga bermakna penyahduplikasian (deduplication) hanya berlaku di dalam repositori satu mesin, jadi sepuluh pelayan yang hampir serupa akan menyimpan sepuluh salinan sistem asas yang sama.

Restic membenarkan beberapa klien membuat sandaran ke dalam satu repositori pada masa yang sama, kerana sandaran mengambil kunci kongsi dan hanya kerja penyelenggaraan seperti prune yang mengambil kunci eksklusif. Sepuluh pelayan serupa yang dihalakan ke satu repositori restic akan melakukan penyahduplikasian antara satu sama lain, dan pelayan kedua dan seterusnya sering kali hanya menyimpan data yang sangat sedikit. Kosnya ialah radius impak (blast radius): satu kata laluan dan satu repositori menyimpan segala-galanya, jadi kehilangan kata laluan tersebut bermakna kehilangan kesemua sepuluh sandaran.

Pengekalan: forget dan prune, berbanding prune dan compact

Kedua-dua alat ini memisahkan proses "menentukan apa yang perlu disimpan" daripada "menuntut semula ruang storan", dan kedua-duanya memerlukan anda menjalankan langkah kedua tersebut.

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

Perangkapnya adalah sama bagi kedua-dua alat dan perlu dinyatakan dengan jelas. Dalam Borg, borg prune membuang arkib tetapi tidak membebaskan ruang cakera dengan sendirinya. Ruang akan kembali apabila borg compact dijalankan, jadi tugasan cron yang melakukan prune tetapi tidak pernah melakukan compact akan menyebabkan repositori terus membesar walaupun senarai arkib kekal pendek. Dalam restic, forget tanpa --prune hanya menggugurkan rujukan snapshot, dan data akan kekal sehingga prune dijalankan.

Jalankan restic check selepas melakukan prune. Ia mengesahkan struktur repositori dan memberitahu anda jika terdapat kerosakan, yang jauh lebih baik daripada mengetahuinya semasa proses pemulihan (restore).

Pemulihan, satu-satunya ujian yang penting

Kedua-dua alat ini melekapkan (mount) snapshot supaya anda boleh melayarinya. Ini adalah cara terpantas untuk mendapatkan semula satu fail.

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 laluan dalam borg extract. Laluan di dalam arkib disimpan tanpa palang (slash) di hadapan, jadi etc/nginx adalah betul dan /etc/nginx tidak memadankan apa-apa serta tidak mengekstrak apa-apa, tanpa ralat untuk memberitahu anda sebabnya. Proses ekstraksi juga menulis ke dalam direktori kerja semasa, jadi tukar ke direktori sementara (scratch directory) terlebih dahulu atau anda akan menulis ganti fail semasa dengan fail lama.

Tidak kira alat mana yang anda pilih, jadual hanyalah separuh daripada tugas tersebut. Jalankan pemulihan ke dalam direktori sementara mengikut pemasa yang anda benar-benar pantau, sama seperti panduan lengkap dalam panduan sandaran restic untuk VPS yang melakukannya dengan pemasa systemd.

Pilihan yang manakah sesuai untuk tugasan tertentu

Pilih restic apabila sasaran adalah storan objek, apabila anda mahukan satu binari tanpa perisian tambahan pada hujung destinasi, apabila beberapa mesin perlu melakukan penyahduplikasian antara satu sama lain, atau apabila orang yang melakukan pemulihan mungkin bukan anda. Ia merupakan satu binari statik tunggal dengan URL untuk repositori, dan dari segi operasi, ini sukar ditandingi.

Pilih Borg apabila sasaran adalah mesin Linux yang anda kawal, apabila pautan mempunyai kependaman (latency) dan set data terdiri daripada berjuta-juta fail kecil, apabila anda mahukan kunci SSH jenis 'append-only' sebagai kawalan terhadap perisian tebusan (ransomware), atau apabila anda mahu pelarasan mampatan dilakukan mengikut tugasan. Ia merupakan alat yang lebih lama, siri stabilnya bergerak perlahan, dan dalam perisian sandaran, itu adalah satu kelebihan.

Kedua-duanya adalah jawapan yang betul. Jawapan yang salah ialah jawapan yang tidak pernah anda uji. Jika anda sudah mengambil dump pada peringkat aplikasi, teruskan melakukannya: corak dalam persediaan Nextcloud pada Docker dengan dump pangkalan data terpakai untuk kedua-dua alat tersebut, kerana fail pangkalan data yang sedang berjalan dan disalin pada waktu rawak bukanlah sandaran pangkalan data yang sah.

FAQ

Adakah restic atau BorgBackup lebih pantas?

Pada cakera tempatan atau LAN yang pantas, kelajuannya hampir sama, dan kedua-duanya akhirnya dihadkan oleh kelajuan bacaan dan hash pada sumber. Borg cenderung lebih unggul melalui pautan SSH dengan kependaman tinggi yang mempunyai banyak fail kecil, kerana proses borg serve di bahagian jauh menjawab soalan indeks tanpa memerlukan pusingan rangkaian bagi setiap ketulan data. Restic cenderung lebih unggul apabila sasaran adalah storan objek, di mana Borg tidak boleh beroperasi langsung.

Bolehkah BorgBackup membuat sandaran ke S3 atau Backblaze B2?

Tidak secara terus. Repositori Borg dihidangkan oleh proses borg serve melalui SSH, dan tiada proses sedemikian berjalan di dalam baldi (bucket). Pengguna mengatasi perkara ini dengan melekapkan storan objek sebagai sistem fail menggunakan rclone, yang mana projek Borg tidak mengesyorkannya, kerana lekap yang terputus di tengah transaksi boleh merosakkan repositori. Jika anda memerlukan storan objek, gunakan restic.

Bolehkah saya menjalankan kedua-dua alat terhadap data yang sama?

Ya, dan sesetengah orang melakukannya: Borg ke pelayan kedua untuk pemulihan tempatan yang pantas, restic ke storan objek untuk salinan di luar tapak. Kedua-duanya tidak berkongsi apa-apa, jadi anda perlu menanggung kos bacaan dan hash sebanyak dua kali, dan anda mempunyai dua kata laluan untuk disimpan dengan selamat. Hanya lakukan ini jika anda telah menguji kedua-dua pemulihan tersebut.

Apa yang berlaku jika saya kehilangan kata laluan repositori?

Data tidak dapat dipulihkan dalam kedua-dua alat tersebut. Restic memperoleh kuncinya daripada kata laluan dengan scrypt dan tiada jalan pintas. Borg dalam mod repokey menyimpan kunci yang disulitkan di dalam repositori, jadi frasa laluan sahaja sudah memadai untuk pemulihan, manakala dalam mod keyfile anda juga memerlukan fail kunci daripada ~/.config/borg/keys/. Simpan kata laluan dalam pengurus kata laluan yang tidak berada pada pelayan yang sedang disandarkan, dan eksport kunci Borg dengan borg key export jika anda menggunakan keyfile.

Patutkah saya menunggu Borg 2.0?

Tidak. Setakat Julai 2026, Borg 2.0 masih dalam peringkat beta, pada versi 2.0.0b22, dan projek tersebut melabelkannya sebagai ujian sahaja. Siri stabil adalah 1.4, kini pada 1.4.5. Mulakan dengan 1.4 sekarang. Borg 2 mengubah format repositori dan menyediakan laluan naik taraf yang didokumentasikan, jadi bermula hari ini tidak akan menyukarkan anda pada masa hadapan.