Restic atau BorgBackup: Mana Satu Patut Digunakan?

Restic berbanding BorgBackup, dalam satu perenggan

Restic dan BorgBackup menjalankan tugas teras yang sama: sandaran pelayan Linux secara deduplikasi, disulitkan dan incremental. Perbezaan yang menentukan pilihan ialah lokasi sandaran disimpan. Restic menyokong S3 dan API storan objek lain secara natif, jadi bucket ialah sasaran kelas pertama tanpa perlu memasang apa-apa pada hujung jauh. Borg memerlukan program borg dipasang pada mesin yang menyimpan repositori, kerana repositori Borg disediakan oleh proses, bukan oleh sistem fail atau API. Jika sasaran anda ialah storan objek, itu sudah menentukan pilihan. Jika sasaran anda ialah kotak Linux kedua yang anda kawal, Borg sesuai digunakan dan selalunya lebih pantas.

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

Model repositori ialah perbezaan sebenar

Repositori restic ialah direktori yang mengandungi fail: config, keys/, snapshots/, index/ dan data/ yang penuh dengan fail pack. Tiada apa-apa lagi diperlukan untuk membacanya. Sebab itu restic boleh menggunakan begitu banyak backend. Mana-mana stor yang boleh meletakkan, mendapatkan, menyenaraikan dan memadam blob boleh menyimpan repositori restic. Dengan cara ini, satu binari menyokong path 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 tersebut. Bahagian pelayan melakukan kerja sebenar: menyimpan repositori, menggunakan transaksi dan menjawab pertanyaan indeks. Sebab itu Borg tidak mempunyai backend S3 dan projek tersebut tidak menambahkannya. 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 satu daripadanya boleh dimatikan

Restic sentiasa menggunakan penyulitan. Tiada mod tanpa penyulitan. restic init meminta kata laluan, mendapatkan 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 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 sudah mencukupi untuk pemulihan. --encryption=keyfile menyimpan kunci pada klien dalam ~/.config/borg/keys/, jadi sesiapa yang mencuri keseluruhan repositori tetap tidak mempunyai kunci tersebut. Oleh itu, anda mesti membuat sandaran fail kunci itu secara berasingan. Jika tidak, arkib anda tidak boleh dibaca. Setiap mod mempunyai varian -blake2 yang menggunakan pengesahan BLAKE2b dan bukannya HMAC-SHA256. Varian ini lebih pantas pada perkakasan tanpa pecutan SHA. --encryption=none juga tersedia, dan pilihan ini wajar digunakan apabila repositori berada pada cakera yang disulitkan dan anda miliki.

Peraturan praktikal: gunakan repokey-blake2 untuk sandaran pelayan biasa, keyfile apabila repositori berada di lokasi yang tidak dipercayai sepenuhnya, dan jangan gunakan none pada mesin yang disewa.

Mampatan dan sebab restic mendapat ciri ini lewat

Borg menyokong mampatan sejak awal. Nilai lalai ialah lz4, yang dipilih kerana cukup pantas untuk diaktifkan bagi semua data. zstd menerima aras 1 hingga 22 dan menggunakan nilai lalai 3, manakala zlib dan lzma sesuai apabila saiz data lebih penting daripada masa pemprosesan. auto menggunakan heuristik bagi setiap chunk 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 mampatan sehingga format repositori 2 diperkenalkan, yang memerlukan restic 0.14.0 atau lebih baharu. Format 2 kini menjadi format lalai untuk repositori baharu, dan mampatan ditetapkan dengan --compression menggunakan nilai auto, off atau max. Repositori lama dengan format 1 kekal tanpa mampatan sehingga anda memindahkannya. Jadi, jika repositori restic anda diwujudkan sebelum 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 proses lain yang perlu berjalan di mana-mana. Corak yang sama berfungsi dengan bucket yang anda hos sendiri. Gandingan ini biasa digunakan: 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 pelayan jauh. Versi di sana juga perlu serasi dengan klien. Ini menyusahkan jika pelayan jauh bukan milik anda. Namun, ini bukan masalah jika pelayan jauh ialah pelayan kedua yang sudah anda tadbir. Pendekatan ini juga memberikan kawalan paling kukuh terhadap ransomware yang ditawarkan oleh kedua-dua alat: kunci SSH append only. Paksa kunci itu menjalankan borg serve supaya klien boleh menambah arkib tetapi tidak boleh memadamnya. Dengan itu, mesin yang telah diceroboh tidak boleh memadam sejarahnya sendiri.

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

Restic hanya mempunyai ciri yang setara apabila anda menjalankan pelayan REST sendiri, yang menyokong mod append only. Dengan S3 biasa, anda memperoleh kesan yang sama melalui dasar bucket atau object lock. Ciri itu diuruskan oleh penyedia, bukan oleh restic. Hadkan keselamatan lapisan pengangkutan juga, kerana bahagian SSH ini memerlukan perhatian yang sama seperti mana-mana log masuk lain: gunakan SSH dengan kunci sahaja dan entri authorized_keys yang terhad untuk akaun sandaran.

Kelajuan: implikasi setiap reka bentuk

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

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

Restic pada storan objek tidak mempunyai bahagian pelayan. Oleh itu, restic perlu membina gambaran datanya daripada fail indeks dan fail pack yang diambil melalui HTTP. Untuk memastikan bilangan permintaan terkawal, restic menggabungkan banyak chunk kecil ke dalam fail pack yang lebih besar sebelum memuat naiknya. Restic juga menyimpan cache setempat dalam ~/.cache/restic supaya proses seterusnya tidak perlu mengambil semula keseluruhan indeks. Jika cache itu dipadamkan, sandaran seterusnya menjadi perlahan sementara restic membinanya semula. Pada sambungan berkependaman tinggi dengan berjuta-juta fail kecil, inilah keadaan yang menyebabkan restic terasa lebih perlahan daripada Borg pada data yang sama.

Pada cakera setempat atau LAN pantas, perbezaan itu kebanyakannya hilang. Kedua-dua alat akhirnya dihadkan oleh kelajuan alat tersebut membaca dan mengira hash sumber.

Mengunci dan membuat sandaran beberapa mesin

Borg 1.4 mengambil kunci eksklusif pada repositori sepanjang operasi. Dua klien yang menulis ke satu repositori pada masa yang sama tidak berfungsi: klien kedua menunggu, kemudian gagal kerana tamat masa kunci. Corak yang disokong ialah satu repositori bagi setiap klien. Ini juga bermakna deduplikasi 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, manakala kerja penyelenggaraan seperti prune sahaja mengambil kunci eksklusif. Sepuluh pelayan yang serupa dan diarahkan ke satu repositori restic akan melakukan deduplikasi antara satu sama lain. Oleh itu, pelayan kedua dan seterusnya biasanya hanya menyimpan sedikit data. Kosnya ialah skop kesan kegagalan: satu kata laluan dan satu repositori menyimpan semuanya. Jika kata laluan hilang, kesemua sepuluh sandaran turut hilang.

Pengekalan: forget diikuti prune, berbanding prune diikuti compact

Kedua-dua alat mengasingkan tindakan “menentukan perkara yang perlu disimpan” daripada tindakan “mendapatkan 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

Perangkapnya sama bagi kedua-dua alat, dan perkara ini perlu dinyatakan dengan jelas. Dalam Borg, borg prune mengalih keluar arkib tetapi tidak membebaskan ruang cakera dengan sendiri. Ruang hanya tersedia semula apabila borg compact dijalankan. Oleh itu, tugas cron yang menjalankan prune tetapi tidak pernah menjalankan compact akan menyebabkan repositori terus membesar walaupun senarai arkib kekal pendek. Dalam restic, forget tanpa --prune hanya mengalih keluar rujukan snapshot. 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 hanya mengetahuinya semasa pemulihan.

Pemulihan ialah satu-satunya ujian yang penting

Kedua-dua alat melekapkan 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 path dalam borg extract. Path di dalam arkib disimpan tanpa slash pada permulaan. Oleh itu, etc/nginx adalah betul, manakala /etc/nginx tidak sepadan dengan apa-apa dan tidak mengekstrak apa-apa. Tiada ralat akan dipaparkan untuk menjelaskan sebabnya. Proses pengekstrakan juga menulis ke dalam direktori kerja semasa. Oleh itu, tukar ke direktori sementara terlebih dahulu. Jika tidak, fail lama akan menimpa fail aktif.

Pemulihan yang selesai tanpa ralat masih bukan bukti bahawa pemulihan berjaya. Aplikasi mempunyai takrif tersendiri tentang pemulihan lengkap. Contohnya, pelayan Immich yang dibina semula daripada salinan direktori data Postgres boleh kembali dengan semua foto masih ada pada cakera, tetapi garis masa tidak memaparkan apa-apa. Inilah kegagalan yang perlu diatasi oleh sandaran dan pemulihan Immich.

Walau apa pun alat yang dipilih, jadual hanya merangkumi separuh daripada tugas. Jalankan pemulihan ke dalam direktori sementara mengikut jadual yang benar-benar anda pantau. Gunakan kaedah yang sama seperti panduan lengkap dalam panduan sandaran restic untuk VPS, yang melakukannya dengan systemd timer.

Yang mana paling sesuai untuk setiap tugas

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. Ia ialah satu binari statik 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 berjuta-juta fail kecil, apabila anda mahukan kunci SSH append only sebagai kawalan terhadap ransomware, atau apabila anda mahu pemampatan ditala mengikut tugas. Ia ialah alat yang lebih lama, siri stabilnya berubah dengan perlahan, dan dalam perisian sandaran, itu merupakan satu kelebihan.

Kedua-duanya ialah pilihan yang betul. Pilihan yang salah ialah pilihan yang tidak pernah anda uji. Jika anda sudah menghasilkan 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 masa rawak bukanlah sandaran pangkalan data.

FAQ

Adakah restic atau BorgBackup lebih pantas?

Pada cakera setempat atau LAN yang pantas, perbezaannya kecil. Kedua-duanya biasanya dihadkan oleh kelajuan membaca dan mencincang pada sumber. Borg cenderung lebih pantas melalui pautan SSH yang mempunyai kependaman tinggi dan mengandungi sangat banyak fail kecil, kerana proses borg serve pada hujung jauh menjawab pertanyaan indeks tanpa perjalanan pergi balik rangkaian bagi setiap chunk. Restic cenderung lebih pantas apabila sasaran ialah storan objek, yang tidak boleh digunakan oleh Borg 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 mount 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 setempat yang pantas, manakala restic ke storan objek untuk salinan di luar tapak. Kedua-duanya tidak berkongsi apa-apa, jadi kos membaca dan mencincang perlu ditanggung dua kali. Anda juga perlu menyimpan dua kata laluan dengan selamat. Lakukan ini hanya jika anda telah menguji kedua-dua pemulihan.

Apakah yang berlaku jika saya kehilangan kata laluan repositori?

Data tidak boleh dipulihkan dalam kedua-dua alat. Restic memperoleh kuncinya daripada kata laluan menggunakan scrypt dan tiada cara pintas untuk memintasnya. Borg dalam mod repokey 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, dan 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 peringkat beta, iaitu 2.0.0b22, dan projek tersebut melabelkannya untuk tujuan pengujian sahaja. Siri stabil ialah 1.4, dengan versi semasa 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.