Restic atau BorgBackup: Mana Satu Patut Digunakan?

Restic berbanding BorgBackup, dalam satu perenggan

Restic dan BorgBackup menjalankan tugas teras yang sama: sandaran tambahan Linux server yang dinyahduplikasi dan disulitkan. Perbezaan yang menentukan pilihan ialah lokasi sandaran disimpan. Restic menyokong S3 dan API storan objek lain secara natif. Oleh itu, bucket ialah sasaran kelas pertama tanpa perlu memasang apa-apa pada hujung yang satu lagi. Borg memerlukan program borg dipasang pada mesin yang menyimpan repositori. Hal ini demikian kerana repositori Borg disediakan oleh proses, bukan 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 biasanya lebih pantas.

Perbezaan lain adalah lebih kecil. Kedua-duanya memecahkan fail menggunakan pembahagian chunk yang ditentukan kandungan. Oleh itu, direktori berukuran 40 GB yang berubah sebanyak 200 MB akan memuat naik kira-kira 200 MB. Kedua-duanya menyulitkan data pada client. Kedua-duanya melekapkan snapshot dengan FUSE (filesystem in userspace), supaya anda boleh menyalin satu fail keluar. Setakat July 2026, restic berada pada versi 0.19.1 dan siri stabil Borg ialah 1.4, khususnya 1.4.5. Borg 2.0 telah berada dalam beta selama bertahun-tahun dan masih ditandakan untuk ujian sahaja. Oleh itu, gunakan 1.4 untuk deployment hari ini.

Model repositori ialah perbezaan sebenar

Repositori restic ialah direktori fail: config, keys/, snapshots/, index/, dan data/ yang mengandungi fail pack. Tiada perkara lain diperlukan untuk membacanya. Oleh itu, restic boleh menggunakan begitu banyak backend. Mana-mana stor yang boleh meletakkan, mendapatkan, menyenaraikan dan memadam blob boleh menyimpan repositori restic. Atas sebab ini, satu binari menyokong laluan tempatan, SFTP, pelayan RESTnya sendiri, S3, Backblaze B2, Azure, Google Cloud Storage dan apa-apa sahaja yang boleh dicapai oleh rclone.

Repositori Borg juga terdiri daripada fail pada cakera, tetapi Borg tidak pernah berkomunikasi dengannya melalui pengangkutan mudah. Untuk repositori jauh, Borg memulakan borg serve di hujung jauh melalui SSH dan menggunakan protokolnya sendiri untuk berkomunikasi dengan proses itu. Bahagian pelayan melaksanakan kerja sebenar: menyimpan repositori, menggunakan transaksi dan menjawab pertanyaan indeks. Oleh itu, Borg tidak mempunyai backend S3 dan projek ini tidak menambahnya. Tiada proses untuk dijalankan di dalam bucket.

Satu fakta reka bentuk ini 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 satunya boleh dimatikan

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

Borg menjadikan penyulitan sebagai pilihan semasa penciptaan repositori, dan pilihan itu kekal. borg init --encryption=repokey menyimpan kunci yang disulitkan di dalam repositori, jadi frasa laluan sahaja boleh digunakan untuk pemulihan. --encryption=keyfile menyimpan kunci pada klien dalam ~/.config/borg/keys/, jadi sesiapa yang mencuri keseluruhan repositori tetap tidak memperoleh apa-apa, dan anda mesti membuat sandaran fail kunci itu secara berasingan atau arkib anda tidak boleh dibaca. Setiap mod mempunyai varian -blake2 yang melakukan pengesahan menggunakan BLAKE2b dan bukannya HMAC-SHA256. Varian ini lebih pantas pada perkakasan tanpa pecutan SHA. --encryption=none juga tersedia, dan merupakan pilihan yang sesuai apabila repositori berada pada cakera yang disulitkan milik anda.

Peraturan praktikal: gunakan repokey-blake2 untuk sandaran pelayan biasa, keyfile apabila repositori berada di lokasi yang tidak anda percayai sepenuhnya, dan jangan sekali-kali gunakan none pada mesin sewaan.

Pemampatan dan sebab restic memperkenalkannya kemudian

Borg menyokong pemampatan sejak awal. Nilai lalai ialah lz4 kerana ia cukup pantas untuk sentiasa diaktifkan. zstd menerima tahap 1 hingga 22 dan menggunakan nilai lalai 3. zlib dan lzma digunakan apabila saiz dalam bait lebih penting daripada masa. auto menjalankan heuristik bagi setiap bahagian supaya data yang telah dimampatkan tidak dimampatkan sekali lagi.

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

restic tidak menyokong pemampatan sehingga format repositori 2 diperkenalkan. Format ini memerlukan restic 0.14.0 atau lebih baharu. Format 2 kini menjadi format lalai bagi repositori baharu, dan pemampatan ditetapkan dengan --compression menggunakan nilai auto, off atau max. Repositori lama berformat 1 kekal tanpa pemampatan sehingga anda memindahkannya. Jadi, jika repositori restic anda lebih lama daripada 0.14 dan anda tidak pernah memindahkannya, anda masih menggunakan saiz penuh untuk teks, log dan dump pangkalan data.

Sasaran jauh: S3 berbanding SSH

Di sinilah pilihan biasanya dibuat.

Restic yang mengakses S3 memerlukan kelayakan dalam persekitaran dan tiada perkhidmatan lain yang perlu dijalankan di mana-mana. Corak yang sama berfungsi dengan bucket yang anda hos sendiri. Ini ialah gabungan yang biasa: jalankan MinIO untuk API S3 pada VPS anda sendiri dan arahkan 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 mengakses repositori jauh memerlukan SSH serta pemasangan Borg pada pihak jauh. Versi di sana juga mesti serasi dengan klien. Ini menyukarkan keadaan jika pihak jauh bukan milik anda. Ia tidak menjadi masalah jika pihak jauh ialah pelayan kedua yang sudah anda tadbir. Kaedah ini juga memberikan kawalan paling kukuh terhadap ransomware yang ditawarkan oleh kedua-dua alat: kunci SSH append-only. Paksa kunci itu menjalankan borg serve. Dengan itu, klien boleh menambah arkib tetapi tidak boleh memadamkannya. Oleh itu, mesin yang telah diceroboh tidak boleh memadamkan sejarahnya sendiri.

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

Restic hanya mempunyai padanan yang setara apabila anda menjalankan pelayan REST sendiri, yang menyokong mod append-only. Dengan S3 biasa, anda boleh mendapatkan kesan yang sama melalui dasar bucket atau object lock. Tindakan itu dikendalikan oleh penyedia, bukan restic. Hadkan keselamatan pengangkutan juga, kerana bahagian SSH ini memerlukan penjagaan yang sama seperti log masuk lain: gunakan SSH dengan kunci sahaja dan entri authorized_keys terhad pada akaun sandaran.

Kelajuan: implikasi setiap reka bentuk

Tiada satu pun projek menerbitkan penanda aras yang patut anda percayai untuk data anda sendiri. Oleh itu, buat pertimbangan berdasarkan mekanismenya.

Borg melalui SSH pantas pada pautan yang mempunyai kependaman kerana bahagian pelayannya pintar. Klien mengemukakan pertanyaan, proses borg serve jauh menjawabnya daripada indeks repositori, dan transaksi dilakukan di satu tempat. Carian cebisan tidak menyebabkan perjalanan pergi balik rangkaian bagi setiap fail kecil.

Restic pada storan objek tidak mempunyai bahagian pelayan. Oleh itu, restic perlu membina gambaran berdasarkan fail indeks dan fail pack yang diambil melalui HTTP. Untuk memastikan bilangan permintaan terkawal, restic menggabungkan banyak cebisan kecil ke dalam fail pack yang lebih besar sebelum memuat naiknya. Restic juga menyimpan cache setempat dalam ~/.cache/restic supaya pelaksanaan seterusnya tidak perlu mengambil semula keseluruhan indeks. Jika cache itu dipadamkan, sandaran seterusnya menjadi perlahan semasa cache dibina semula. Pada pautan berkependaman tinggi dengan jutaan fail kecil, inilah keadaan apabila restic terasa lebih perlahan daripada Borg pada data yang sama.

Pada cakera setempat atau LAN pantas, perbezaannya kebanyakannya berkurang. Kedua-dua alat akhirnya dihadkan oleh kelajuan alat tersebut membaca dan mencincang sumber.

Penguncian dan sandaran beberapa mesin

Borg 1.4 mengambil kunci eksklusif pada repositori sepanjang keseluruhan operasi. Dua klien yang menulis ke satu repositori pada masa yang sama tidak dapat berfungsi: klien kedua menunggu, kemudian gagal selepas tamat masa menunggu kunci. Corak yang disokong ialah satu repositori bagi setiap klien. Ini juga bermaksud pendeduplikasian hanya berlaku dalam repositori satu mesin, jadi sepuluh pelayan yang hampir serupa menyimpan sepuluh salinan sistem asas yang sama.

Restic membenarkan beberapa klien membuat sandaran ke satu repositori pada masa yang sama, kerana operasi sandaran mengambil kunci dikongsi dan hanya kerja penyelenggaraan seperti prune mengambil kunci eksklusif. Sepuluh pelayan yang serupa dan menunjuk kepada satu repositori restic akan melakukan pendeduplikasian sesama sendiri, dan pelayan kedua dan seterusnya biasanya menyimpan data yang sangat sedikit. Risikonya ialah skop kerosakan: satu kata laluan dan satu repositori menyimpan segala-galanya, jadi kehilangan kata laluan menyebabkan kesemua sepuluh sandaran hilang.

Retention: lupakan kemudian prune berbanding prune kemudian compact

Kedua-dua alat memisahkan tindakan "menentukan perkara yang perlu disimpan" daripada "menuntut semula ruang", dan kedua-duanya memerlukan 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

Kesilapan yang sama berlaku pada kedua-dua alat dan wajar dinyatakan dengan jelas. Dalam Borg, borg prune mengalih keluar arkib tetapi tidak mengosongkan ruang cakera dengan sendirinya. Ruang hanya tersedia semula apabila borg compact dijalankan. Oleh itu, tugas cron yang menjalankan prune tetapi tidak pernah menjalankan compact menyebabkan repositori terus berkembang selama-lamanya, walaupun senarai arkib kekal pendek. Dalam restic, forget tanpa --prune hanya mengalih keluar rujukan syot kilat, manakala data kekal sehingga prune dijalankan.

Jalankan restic check selepas prune. Perintah ini mengesahkan struktur repositori dan memberitahu anda jika terdapat kerosakan. Ini jauh lebih baik daripada mengetahuinya semasa pemulihan.

Pemulihan ialah satu-satunya ujian yang penting

Kedua-dua alat memasang snapshot supaya anda boleh menyemak kandungannya. Ini ialah 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 garis miring di hadapan. Oleh itu, etc/nginx adalah betul, manakala /etc/nginx tidak sepadan dengan apa-apa dan tidak mengekstrak apa-apa. Tiada ralat dilaporkan untuk menjelaskan sebabnya. Pengekstrakan juga menulis ke direktori kerja semasa. Oleh itu, tukar ke direktori sementara terlebih dahulu. Jika tidak, fail aktif akan ditulis ganti dengan versi lama.

Walau apa pun alat yang dipilih, jadual hanyalah separuh daripada tugas. Jalankan pemulihan ke direktori sementara menggunakan pemasa yang benar-benar anda pantau, sama seperti panduan lengkap dalam panduan sandaran restic untuk VPS yang menggunakan pemasa systemd.

Yang mana sesuai untuk tugas tertentu

Pilih restic apabila sasaran ialah storan objek, apabila anda mahukan satu binari tanpa perisian pada hujung jauh, apabila beberapa mesin perlu melakukan deduplikasi antara satu sama lain, atau apabila orang yang melakukan pemulihan mungkin bukan anda. restic ialah satu binari statik tunggal dengan URL untuk repositori, dan ciri itu sukar ditandingi dari segi operasi.

Pilih Borg apabila sasaran ialah kotak Linux yang anda kawal, apabila sambungan mempunyai kependaman dan set data mengandungi jutaan fail kecil, apabila anda mahukan kunci SSH append-only sebagai kawalan terhadap ransomware, atau apabila anda mahu pemampatan dilaraskan bagi setiap tugas. Borg ialah alat yang lebih lama, siri stabilnya berubah dengan perlahan, dan dalam perisian sandaran, itu merupakan kelebihan.

Kedua-duanya ialah pilihan yang betul. Pilihan yang salah ialah pilihan yang tidak pernah anda uji. Jika anda sudah membuat dump pada peringkat aplikasi, teruskan penggunaannya: corak dalam persediaan Nextcloud pada Docker dengan dump pangkalan data terpakai pada kedua-dua alat, kerana fail pangkalan data langsung yang disalin pada waktu rawak bukanlah sandaran pangkalan data.

FAQ

Adakah restic atau BorgBackup lebih pantas?

Pada cakera tempatan atau LAN yang pantas, perbezaannya kecil. Kedua-duanya biasanya terhad oleh kelajuan membaca dan pencincangan pada sumber. Borg cenderung lebih pantas melalui sambungan SSH dengan kependaman tinggi yang mengandungi banyak fail kecil, kerana proses borg serve di hujung jauh menjawab pertanyaan indeks tanpa perjalanan ulang-alik rangkaian bagi setiap bahagian. restic cenderung lebih pantas apabila sasaran ialah storan objek, kerana Borg tidak menyokongnya sama sekali.

Bolehkah BorgBackup membuat sandaran ke S3 atau Backblaze B2?

Tidak secara langsung. Repositori Borg disediakan oleh proses borg serve melalui SSH, dan proses sedemikian tidak berjalan di dalam bucket. Sebagai penyelesaian, sesetengah pengguna melekapkan storan objek sebagai sistem fail menggunakan rclone. Projek Borg tidak mengesyorkan kaedah ini kerana pelekap yang terputus di tengah-tengah transaksi boleh merosakkan repositori. Jika anda memerlukan storan objek, gunakan restic.

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

Ya, dan sesetengah pengguna berbuat demikian: Borg ke pelayan kedua untuk pemulihan tempatan yang pantas, dan restic ke storan objek untuk salinan luar tapak. Kedua-duanya tidak berkongsi apa-apa, jadi kos membaca dan mencincang perlu dibayar dua kali. Anda juga perlu menyimpan dua kata laluan dengan selamat. Lakukan ini hanya selepas anda menguji kedua-dua pemulihan.

Apakah yang berlaku jika saya kehilangan kata laluan repositori?

Data tidak boleh dipulihkan dengan kedua-dua alat. restic memperoleh kuncinya daripada kata laluan menggunakan scrypt dan tiada cara untuk memintasnya. Dalam mod repokey, Borg menyimpan kunci yang disulitkan di dalam repositori, jadi frasa laluan sahaja mencukupi untuk pemulihan. 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 disandarkan. Eksport kunci Borg menggunakan borg key export jika anda menggunakan keyfile.

Patutkah saya menunggu Borg 2.0?

Tidak. Setakat July 2026, Borg 2.0 masih dalam versi beta, iaitu 2.0.0b22, dan projek tersebut melabelkannya untuk tujuan pengujian sahaja. Siri stabil ialah 1.4, dan versi semasa ialah 1.4.5. Mulakan dengan 1.4 sekarang. Borg 2 mengubah format repositori dan menyediakan laluan naik taraf yang didokumenkan. Oleh itu, memulakan penggunaan hari ini tidak akan menyebabkan anda terperangkap.