Restic vs BorgBackup: alin ang dapat gamitin?

Restic kumpara sa BorgBackup, sa isang talata

Parehong ginagawa ng Restic at BorgBackup ang pangunahing trabaho: deduplicated, encrypted, at incremental na backup ng Linux server. Ang pagkakaibang pinakamahalaga sa pagpili ay kung saan mapupunta ang backup. Native na sinusuportahan ng Restic ang S3 at iba pang object storage API, kaya first-class target ang isang bucket at walang kailangang i-install sa kabilang dulo. Kailangan namang naka-install ang borg program sa machine na nagho-host ng repository ng Borg, dahil sine-serve 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, praktikal ang Borg at madalas itong mas mabilis.

Mas maliit ang lahat ng iba pang pagkakaiba. Parehong hinahati ng mga ito ang mga file gamit ang content-defined chunking, kaya kung 40 GB ang isang directory at 200 MB lang ang nagbago, humigit-kumulang 200 MB ang ia-upload. Parehong nag-e-encrypt sa client side. Parehong nagmo-mount ng snapshot gamit ang FUSE (filesystem in userspace) para makakopya ka ng isang file palabas. Noong July 2026, nasa 0.19.1 ang Restic at nasa stable series na 1.4 ang Borg, partikular sa 1.4.5. Ilang taon nang nasa beta ang Borg 2.0 at minamarkahan pa rin bilang 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 iba pang kailangan upang mabasa ito. Dahil dito, maraming backend ang kayang gamitin ng restic. Anumang storage na kayang maglagay, kumuha, maglista, at mag-delete ng blobs ay maaaring paglagyan ng restic repository. Kaya sinusuportahan ng iisang binary ang mga local path, SFTP, sarili nitong REST server, S3, Backblaze B2, Azure, Google Cloud Storage, at anumang maabot ng rclone.

Ang Borg repository ay mga file rin sa disk, pero hindi ito direktang kinakausap ng Borg sa pamamagitan ng dumb transport. Para sa remote repository, sinisimulan ng Borg ang borg serve sa kabilang panig gamit ang SSH, at ginagamit nito ang sariling protocol para makipag-ugnayan sa prosesong iyon. May aktuwal na gawain sa server side: hawak nito ang repository, inilalapat 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 ganoong backend. Walang prosesong maaaring patakbuhin sa loob ng bucket.

Ang iisang detalyeng 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: isa sa mga ito ay maaaring i-off

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

Sa Borg, pinipili ang encryption kapag ginagawa ang repository, at permanente ang pagpiling ito. Inilalagay ng borg init --encryption=repokey ang encrypted key sa loob ng repository, kaya passphrase lang ang kailangan para ma-restore. Inilalagay naman ng --encryption=keyfile ang key sa client, sa ~/.config/borg/keys/, kaya walang mapapakinabangan ang sinumang makakuha ng buong repository. Kailangan mong i-back up nang hiwalay ang key file na iyon; 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 makatuwiran itong piliin kapag nasa encrypted disk na pagmamay-ari mo ang repository.

Ang praktikal na tuntunin: gamitin ang repokey-blake2 para sa normal na 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 ang restic

May compression na ang Borg mula pa noong simula. Ang default ay lz4, dahil sapat ang bilis nito para palaging i-enable. Tumatanggap ang zstd ng mga level na 1 hanggang 22 at ang default ay 3. Ginagamit ang zlib at lzma kapag mas mahalaga sa iyo ang laki ng data kaysa sa oras ng pagtakbo. Tumatakbo ang auto ng heuristic sa bawat chunk upang hindi na 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 ang default para sa bagong repository, at sine-set 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 mas luma sa 0.14 ang restic repository mo at hindi mo ito kailanman ni-migrate, buong laki pa rin ang ginagamit para sa text, logs, at database dumps.

Remote targets: S3 kumpara sa SSH

Dito karaniwang ginagawa ang pagpili.

Kailangan ng restic ng credentials sa environment upang maabot ang S3, at wala nang ibang kailangang tumatakbo kahit saan. Gumagana rin ang parehong setup sa bucket na ikaw mismo ang nagho-host. Karaniwang pinagsasama ang mga ito: magpatakbo ng MinIO para sa S3 API sa sarili mong VPS at ituro rito ang restic.

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 ng Borg installation sa remote repository, at dapat compatible ang version doon sa client. Nagdudulot ito ng dagdag na hakbang kung hindi ikaw ang nag-a-administer ng remote server. Wala itong dagdag na abala kung isa itong pangalawang server na ikaw na ang namamahala. Nagbibigay rin ito ng pinakamalakas na proteksyon laban sa ransomware na kayang ibigay ng alinmang tool: isang append-only SSH key. Pilitin ang key na patakbuhin ang borg serve upang makapagdagdag ang client ng archives pero hindi makapag-delete ng mga ito. Sa ganitong paraan, hindi mabubura ng compromised machine ang sarili nitong history.

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

May katumbas nito ang restic kapag pinatakbo mo ang sarili nitong REST server, na sumusuporta sa append-only mode. Sa plain S3, makukuha ang parehong epekto gamit ang bucket policy o object lock. Tungkulin ito ng provider, hindi ng restic. I-secure din ang transport, dahil kailangan ng SSH side nito ang kaparehong pag-iingat na ibinibigay sa iba pang login: ilapat ang SSH na key-only gamit ang restricted na authorized_keys entry 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 performance batay sa mekanismo nito.

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 commit ng transaction. Hindi nagiging network round trip ang bawat chunk lookup para sa bawat maliit na file.

Walang server side ang Restic on object storage, kaya binubuo nito ang state nito mula sa index files at pack files na kinukuha nito sa HTTP. Para mapanatiling makatwiran ang bilang ng mga request, pinagsasama nito ang maraming maliit na chunk sa mas malalaking pack file bago i-upload. Nagpapanatili rin ito ng local cache sa ~/.cache/restic para hindi na 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 high-latency link na may milyon-milyong maliliit na file, ito ang sitwasyong mas mabagal maramdaman ang restic kaysa sa 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 pag-hash nila sa source.

Pag-lock at pag-back up ng ilang machine

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

Pinapayagan ng Restic na sabay-sabay mag-back up ang ilang client sa iisang repository dahil shared lock ang ginagamit ng backup, at ang maintenance work lamang gaya ng prune ang kumukuha ng exclusive lock. Kapag ang sampung magkakaparehong server ay nakaturo sa iisang restic repository, nagde-deduplicate ang mga ito laban sa isa’t isa, at kadalasan ay napakaliit na lang ng naiimbak ng ikalawang server at ng mga kasunod nito. Ang kapalit nito ay mas malawak na blast radius: iisang password at iisang repository ang naglalaman ng lahat, kaya kapag nawala ang password, mawawala ang access sa lahat ng sampu.

Pagpapanatili: forget at prune, kumpara sa prune at compact

Pinaghihiwalay ng dalawang tool ang “pagpapasya kung ano ang pananatilihin” sa “pagbawi ng space,” 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 kailangang malinaw itong sabihin. Sa Borg, inaalis ng borg prune ang mga archive pero hindi nito awtomatikong binabawi ang disk space. Nababalik lamang ang space kapag tumakbo ang borg compact. Kaya ang cron job na nagru-run ng prune pero hindi nagco-compact ay magpapalaki sa repository nang walang katapusan kahit maikli ang listahan ng mga archive. Sa restic, ang forget na walang --prune ay nag-aalis lamang ng mga reference sa snapshot. Nananatili ang data hanggang sa mag-run ng prune.

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

Pagpapanumbalik, ang tanging test na mahalaga

Parehong nagmo-mount ang dalawang tool ng snapshot para ma-browse mo ito. Ito ang pinakamabilis na paraan upang ibalik 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 matutugmang anuman ang /etc/nginx at wala rin itong ie-extract, nang walang error na magsasabi 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.

Alinman sa 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, gaya ng ginagawa ng kumpletong walkthrough sa natitirang backup guide ng restic para sa VPS gamit ang systemd timer.

Alin ang mas angkop sa bawat trabaho

Piliin ang restic kapag object storage ang target, kapag isang binary lang ang gusto mo at walang software na kailangang i-install sa kabilang dulo, kapag kailangang mag-deduplicate ang ilang machine laban sa isa’t isa, o kapag maaaring ibang tao ang magsasagawa ng restore. Isa itong static binary na may URL para sa repository, at mahirap itong higitan sa operational na paggamit.

Piliin ang Borg kapag Linux box na kontrolado mo ang target, kapag may latency ang link at milyon-milyon ang maliliit na file sa dataset, kapag gusto mong gamitin ang append-only SSH key bilang kontrol laban sa ransomware, o kapag gusto mong i-tune ang compression para sa bawat trabaho. Mas luma itong tool, mabagal ang pag-usad ng stable series nito, at sa backup software, feature iyon.

Parehong tamang sagot ang dalawang ito. Ang maling sagot ay ang hindi mo kailanman tine-test. Kung kumukuha ka na ng application-level dumps, panatilihin mo ang mga ito: naaangkop sa alinmang tool ang pattern sa setup ng Nextcloud sa Docker na may database dumps, dahil ang database file na kinopya sa random na oras habang live 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, at pareho silang nalilimitahan ng bilis ng pagbasa at pag-hash sa source. Karaniwang mas mabilis ang Borg sa SSH link na mataas ang latency at maraming maliliit na file, dahil ang borg serve process sa kabilang panig ang sumasagot sa mga query sa index nang hindi nangangailangan ng network round trip para sa bawat chunk. Karaniwang mas mabilis ang restic kapag object storage ang target, dahil hindi direktang makapagsulat ang Borg sa ganitong storage.

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

Hindi nang direkta. Inihahatid ang Borg repository ng borg serve process sa SSH, at walang ganitong process na tumatakbo sa loob ng bucket. Nilalampasan ito ng ilang user sa pamamagitan ng pag-mount ng object storage bilang filesystem gamit ang rclone, pero hindi ito inirerekomenda ng Borg project dahil maaaring ma-corrupt ang repository kapag naputol ang mount sa kalagitnaan ng transaction. Kung kailangan mo ng object storage, 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 ibinabahaging data, kaya dalawang beses mong babayaran ang read at hash cost, at kailangan mong ligtas na mag-imbak 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. Ginagamit ng restic ang scrypt upang i-derive ang key mula sa password, at walang bypass para rito. Sa Borg na nasa repokey mode, iniimbak 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 hindi nasa server na bina-back up, at i-export ang Borg key gamit ang borg key export kung ginagamit mo ang 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 pa ito ng project na para sa testing lamang. Ang stable series ay 1.4, at kasalukuyang 1.4.5. Magsimula na sa 1.4. Binabago ng Borg 2 ang repository format at mayroon itong dokumentadong upgrade path, kaya hindi ka maiipit kung magsisimula ka ngayon.