Restic vs BorgBackup: Alin ang Dapat Gamitin?

Restic kumpara sa BorgBackup, sa isang talata

Parehong ginagawa ng Restic at BorgBackup ang pangunahing gawain: deduplicated, encrypted, incremental backup ng Linux server. Ang pangunahing pagkakaiba sa pagpili ay kung saan ilalagay ang backup. Katutubong sinusuportahan ng Restic ang S3 at iba pang object storage API, kaya ang isang bucket ay direktang target at walang kailangang i-install sa kabilang dulo. Kailangang naka-install ang borg program ng Borg sa machine na naglalaman ng repository, dahil inihahatid ang Borg repository ng isang process, hindi ng filesystem o API. Kung object storage ang target mo, iyon na ang sagot. Kung pangalawang Linux box na kontrolado mo ang target, puwedeng gamitin ang Borg at madalas itong mas mabilis.

Mas maliit ang iba pang mga pagkakaiba. Parehong hinahati ng mga ito ang mga file gamit ang content-defined chunking, kaya kung nagbago ng 200 MB ang isang directory na 40 GB, humigit-kumulang 200 MB ang ia-upload. Parehong nag-e-encrypt sa client. Parehong nagmo-mount ng snapshot gamit ang FUSE (filesystem in userspace) para makopya mo ang isang file palabas. Noong July 2026, nasa 0.19.1 ang Restic at ang stable series ng Borg ay 1.4, partikular na 1.4.5. Ilang taon nang nasa beta ang Borg 2.0 at minamarkahan pa rin bilang pang-testing lamang, kaya 1.4 ang dapat mong i-deploy ngayon.

Ang repository model ang tunay na pagkakaiba

Ang restic repository ay isang directory ng mga file: config, keys/, snapshots/, index/, at data/ na naglalaman ng mga pack file. Wala nang ibang kailangan para mabasa ito. Kaya kayang gumamit ng restic ng maraming backend. Anumang storage na kayang maglagay, kumuha, maglista, at mag-delete ng mga blob ay maaaring paglagyan ng restic repository. Dahil dito, sinusuportahan ng isang binary ang mga local path, SFTP, sarili nitong REST server, S3, Backblaze B2, Azure, Google Cloud Storage, at anumang naaabot ng rclone.

Ang Borg repository ay mga file rin sa disk, pero hindi ito kinakausap ng Borg gamit ang simpleng transport. Para sa remote repository, sinisimulan ng Borg ang borg serve sa kabilang panig gamit ang SSH at ginagamit ang sarili nitong protocol para makipag-ugnayan sa prosesong iyon. Gumagawa ng aktuwal na trabaho ang server side: iniimbak nito ang repository, ina-apply ang transaction, at sumasagot sa mga query tungkol sa index. Ito ang dahilan kung bakit walang S3 backend ang Borg at kung bakit hindi ito nagdagdag ng ganoon. Walang prosesong maaaring patakbuhin sa loob ng bucket.

Ang iisang katotohanang ito ang nagdudulot ng karamihan sa mga praktikal na pagkakaiba sa ibaba.

# 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

Encryption: maaaring i-off ang isa sa mga ito

Palaging naka-encrypt ang Restic. Walang unencrypted mode. Humihingi ang restic init ng password, kumukuha ito ng key mula rito gamit ang scrypt, at ang bawat pack file na isinusulat pagkatapos nito ay naka-encrypt at authenticated. Kapag nawala ang password, mawawala ang data dahil sadyang walang recovery path.

Ginagawang opsyon ng Borg ang encryption kapag gumagawa ng repository, at permanente ang pagpiling ito. Inilalagay ng borg init --encryption=repokey ang encrypted key sa loob ng repository, kaya sapat na ang passphrase para sa pag-restore. Inilalagay naman ng --encryption=keyfile ang key sa client sa ~/.config/borg/keys/, kaya kahit manakaw ng isang tao ang buong repository, wala pa rin siyang makukuha. Dahil dito, kailangan mong i-back up nang hiwalay ang key file; kung hindi, hindi mababasa ang iyong mga archive. May -blake2 variant ang bawat mode na gumagamit ng BLAKE2b para sa authentication sa halip na HMAC-SHA256. Mas mabilis ito sa hardware na walang SHA acceleration. Mayroon ding --encryption=none, at praktikal itong piliin kapag nasa encrypted disk na pagmamay-ari mo ang repository.

Ang praktikal na tuntunin: gamitin ang repokey-blake2 para sa karaniwang server backup, ang keyfile kapag nasa lugar na hindi mo lubos na pinagkakatiwalaan ang repository, at huwag kailanman gamitin ang none sa rented machine.

Compression, at kung bakit nahuli ito sa restic

May compression na ang Borg mula pa sa simula. Ang default ay lz4, dahil sapat itong mabilis para laging i-enable. Tumatanggap ang zstd ng mga level mula 1 hanggang 22 at ang default nito ay 3. Ginagamit ang zlib at lzma kapag mas mahalaga ang laki ng data kaysa sa oras ng pagtakbo. Gumagamit ang auto ng heuristic sa bawat chunk upang hindi muling i-compress ang data na compressed na.

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

Walang compression ang restic hanggang sa repository format 2, na nangangailangan ng restic 0.14.0 o mas bago. Ang format 2 na ngayon ang default para sa bagong repository, at itinatakda ang compression gamit ang --compression sa mga value na auto, off o max. Mananatiling walang compression ang lumang format 1 repository hanggang i-migrate mo ito. Kaya kung nauna sa 0.14 ang restic repository mo at hindi mo ito kailanman ni-migrate, buong laki pa rin ng text, logs at database dumps ang ginagamit nito.

Mga remote target: S3 kumpara sa SSH

Dito karaniwang ginagawa ang pagpili.

Kailangan ng restic ng credentials sa environment para ma-access ang S3, at wala nang ibang kailangang patakbuhin kahit saan. Gumagana rin ang parehong pattern sa bucket na ikaw mismo ang nagho-host. Karaniwan itong pinaparis sa pamamagitan ng pagpapatakbo ng MinIO para sa S3 API sa sarili mong VPS at pagturo ng restic dito.

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

Kailangan ng Borg ng SSH at naka-install na Borg sa remote repository. Dapat compatible ang bersyon doon sa client. Nagdudulot ito ng karagdagang komplikasyon kung hindi iyo ang remote server. Walang problema ito kung pangalawang server ito na ikaw na ang nangangasiwa. Kapalit nito, makakakuha ka ng pinakamalakas na proteksyon laban sa ransomware na maiaalok ng alinmang tool: isang append only SSH key. I-configure ang key na patakbuhin ang borg serve. Makakapagdagdag ang client ng archives ngunit hindi makakapagtanggal ng mga ito. Dahil dito, hindi mabubura ng breached na machine ang sarili nitong history.

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

May katumbas na kakayahan ang restic kapag nagpapatakbo ka ng sarili nitong REST server, na sumusuporta sa append only mode. Sa plain S3, makukuha mo ang parehong resulta gamit ang bucket policy o object lock. Responsibilidad ito ng provider, hindi ng restic. Higpitan din ang seguridad ng transport, dahil dapat kasing-ingat ang SSH side nito gaya ng anumang login. Ilapat ang SSH na key lamang na may limitadong entry sa authorized_keys sa backup account.

Bilis: ano ang ipinahihiwatig ng bawat disenyo

Walang inilalabas na benchmark ang alinmang project na dapat mong pagkatiwalaan para sa sarili mong data. Kaya unawain ang mekanismo sa halip.

Mabilis ang Borg over SSH sa link na may latency dahil intelligent ang server side. Nagtatanong ang client, sinasagot ito ng remote borg serve process mula sa repository index, at sa isang lugar ginagawa ang transaction commit. Hindi nagiging network round trip ang bawat paghahanap ng chunk para sa bawat maliit na file.

Walang server side ang Restic sa object storage. Kaya binubuo nito ang impormasyon mula sa index files at pack files na kinukuha nito sa HTTP. Para manatiling makatuwiran ang bilang ng mga request, pinagsasama nito ang maraming maliliit na chunk sa mas malalaking pack files bago i-upload. Nagpapanatili rin ito ng local cache sa ~/.cache/restic para hindi nito muling kunin ang buong index sa susunod na run. Kapag dinelete mo ang cache na iyon, mabagal ang susunod na backup habang binubuo itong muli. Sa link na mataas ang latency at may milyun-milyong maliliit na file, mas mabagal ang pakiramdam ng restic kaysa Borg sa parehong data.

Sa local disk o mabilis na LAN, halos nawawala ang agwat. Parehong nalilimitahan ang dalawang tool ng bilis ng pagbasa at pagha-hash sa source.

Pag-lock at pag-back up ng ilang machine

Ang Borg 1.4 ay kumukuha ng exclusive lock sa repository sa buong operasyon. Hindi gumagana ang dalawang client na sabay na nagsusulat sa isang repository: maghihintay ang pangalawa, at pagkatapos ay mabibigo dahil sa lock timeout. Ang suportadong pattern ay isang repository para sa bawat client. Nangangahulugan din ito na nangyayari lamang ang deduplication sa loob ng repository ng isang machine, kaya ang sampung halos magkakaparehong server ay nag-iimbak ng sampung kopya ng parehong base system.

Pinapayagan ng Restic ang ilang client na sabay-sabay na mag-back up sa isang repository, dahil shared lock ang ginagamit ng backup at mga maintenance operation lamang, gaya ng prune, ang kumukuha ng exclusive lock. Ang sampung magkakahawig na server na tumuturo sa iisang restic repository ay nagde-deduplicate laban sa isa't isa, at kadalasang napakaliit na lang ang iniimbak ng ikalawang server. Ang kapalit nito ay mas malawak na blast radius: isang password at isang repository ang naglalaman ng lahat, kaya kapag nawala ang password, mawawala ang access sa lahat ng sampu.

Retention: paglimot at prune, kumpara sa prune at compact

Pinaghihiwalay ng dalawang tool ang “pagpapasya kung ano ang pananatiliin” mula sa “pagbawi ng espasyo,” at kailangan mong patakbuhin ang ikalawang hakbang sa parehong tool.

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

Pareho ang karaniwang pagkakamali sa dalawang tool, kaya dapat itong linawin. Sa Borg, inaalis ng borg prune ang mga archive pero hindi nito awtomatikong binabawi ang disk space. Nababalik ang espasyo kapag tumakbo ang borg compact. Kaya ang cron job na nagpapatakbo ng prune pero hindi ng compact ay magpapalaki nang tuloy-tuloy sa repository kahit maikli ang listahan ng archive. Sa restic, ang forget nang walang --prune ay nag-aalis lamang ng mga reference sa snapshot. Nanatili ang data hanggang sa magpatakbo ka ng prune.

Patakbuhin ang restic check pagkatapos ng pruning. Bine-verify nito ang mga istruktura ng repository at ipinapaalam kung may nasira. Mas mabuti ito kaysa matuklasan ang problema habang nagsasagawa ng restore.

Ang pagpapanumbalik ang tanging pagsubok na mahalaga

Parehong nagmo-mount ang dalawang tool ng snapshot para ma-browse mo ito. Ito ang pinakamabilis na paraan para maibalik ang isang 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

Pansinin ang anyo ng path sa borg extract. Ang mga path sa loob ng archive ay naka-store nang walang nauunang slash, kaya tama ang etc/nginx. Walang natutugma ang /etc/nginx at walang nae-extract, nang walang error na magsasabi sa iyo kung bakit. Nagsusulat din ang extraction sa kasalukuyang working directory, kaya lumipat muna sa isang scratch directory. Kung hindi, mao-overwrite mo ang mga live file gamit ang mga lumang file.

Anumang tool ang piliin mo, kalahati lamang ng trabaho ang schedule. Magpatakbo ng restore sa isang scratch directory gamit ang timer na aktuwal mong mino-monitor. Gawin ito sa parehong paraan ng full walkthrough sa gabay sa restic backup para sa isang VPS, na gumagamit ng systemd timer.

Alin ang angkop para sa bawat gawain

Piliin ang restic kapag object storage ang target, kapag gusto mo ng isang binary lang at walang software sa kabilang dulo, kapag kailangang mag-deduplicate ang ilang machine laban sa isa't isa, o kapag maaaring ibang tao ang magsagawa ng restore. Isang static binary ito na may URL para sa repository, kaya mahirap itong talunin sa operational na paggamit.

Piliin ang Borg kapag Linux box na kontrolado mo ang target, kapag may latency ang link at milyon ang maliliit na file sa dataset, kapag gusto mo ang append-only SSH key bilang proteksiyon laban sa ransomware, o kapag gusto mong iangkop ang compression sa bawat job. Mas lumang tool ito, mabagal magbago ang stable series nito, at sa backup software, feature iyon.

Parehong wastong sagot ang dalawang ito. Ang maling sagot ay ang hindi mo kailanman sinusubukan. Kung kumukuha ka na ng application-level dump, ipagpatuloy mo iyon: naaangkop sa alinmang tool ang pattern sa setup ng Nextcloud sa Docker na may database dump, dahil ang database file na kinopya sa isang random na sandali habang ginagamit ang database ay hindi backup ng database.

FAQ

Mas mabilis ba ang restic o BorgBackup?

Sa local disk o mabilis na LAN, halos magkapantay ang bilis ng mga ito. Pareho silang nalilimitahan ng bilis ng pagbasa at pagha-hash sa source. Karaniwang mas mahusay ang Borg sa high-latency na SSH link na maraming maliliit na file, dahil ang borg serve process sa kabilang panig ay sumasagot sa mga query sa index nang hindi nangangailangan ng network round trip para sa bawat chunk. Karaniwang mas mahusay ang restic kapag object storage ang target, dahil hindi talaga makakapunta roon ang Borg.

Maaari bang mag-back up ang BorgBackup sa S3 o Backblaze B2?

Hindi nang direkta. Ang Borg repository ay inihahatid ng borg serve process sa SSH, at walang ganitong process na tumatakbo sa loob ng bucket. Karaniwang workaround ang pag-mount ng object storage bilang filesystem gamit ang rclone, ngunit hindi ito inirerekomenda ng Borg project, dahil maaaring ma-corrupt ang repository kapag naputol ang mount sa kalagitnaan ng transaction. Kung object storage ang kailangan mo, gamitin ang restic.

Maaari ko bang gamitin ang dalawang tool sa parehong data?

Oo, at ginagawa ito ng ilang user: Borg sa pangalawang server para sa mabilis na local restore, at restic sa object storage para sa offsite copy. Wala silang pinagsasaluhang data, kaya dalawang beses mong babayaran ang read at hash cost, at kailangan mong ligtas na mag-store ng dalawang password. Gawin lamang ito kung nasubukan mo na ang parehong restore.

Ano ang mangyayari kung mawala ko ang repository password?

Hindi na mare-recover ang data sa parehong tool. Kinukuha ng restic ang key nito mula sa password gamit ang scrypt, at walang bypass. Sa Borg na nasa repokey mode, naka-store ang encrypted key sa loob ng repository, kaya sapat ang passphrase para sa restore. Sa keyfile mode, kailangan mo rin ang key file mula sa ~/.config/borg/keys/. Itago ang password sa isang password manager na wala sa server na bina-back up, at i-export ang Borg key gamit ang borg key export kung gumagamit ka ng keyfile.

Dapat ba akong maghintay para sa Borg 2.0?

Hindi. Noong July 2026, beta pa rin ang Borg 2.0, nasa 2.0.0b22, at itinuturing ito ng project na pang-testing lamang. Ang stable series ay 1.4, at kasalukuyang nasa 1.4.5. Magsimula ngayon sa 1.4. Binabago ng Borg 2 ang repository format at may documented upgrade path, kaya hindi ka maiipit kung magsisimula ka ngayon.