Restic dhidi ya BorgBackup: Ipi Utumie?

Restic dhidi ya BorgBackup, kwa aya moja

Restic na BorgBackup hufanya kazi kuu ileile: hifadhi rudufu za seva ya Linux zenye uondoaji wa nakala zinazojirudia, usimbaji fiche na nyongeza. Tofauti inayoamua chaguo ni mahali hifadhi rudufu inapowekwa. Restic hutumia S3 na API nyingine za hifadhi ya vitu moja kwa moja, kwa hiyo bucket ni lengwa kuu bila kusakinisha chochote upande wa mbali. Borg inahitaji programu ya borg isakinishwe kwenye mashine inayohifadhi repository, kwa sababu repository ya Borg hutolewa na mchakato, si na mfumo wa faili au API. Ikiwa lengwa lako ni hifadhi ya vitu, hilo ndilo jibu tayari. Ikiwa lengwa lako ni mashine ya pili ya Linux unayoidhibiti, Borg ni chaguo linalowezekana na mara nyingi huwa ya haraka zaidi.

Tofauti nyingine zote ni ndogo. Zote hugawanya faili kwa kutumia chunking inayobainishwa na maudhui, kwa hiyo directory ya 40 GB iliyobadilishwa kwa 200 MB hupakia takriban 200 MB. Zote husimba data kwa njia fiche kwenye mteja. Zote huweka snapshot kama mfumo wa faili kwa kutumia FUSE (mfumo wa faili katika userspace), ili uweze kunakili faili moja. Kufikia July 2026, Restic iko kwenye 0.19.1, na mfululizo thabiti wa Borg ni 1.4, ukiwa kwenye 1.4.5. Borg 2.0 imekuwa katika beta kwa miaka kadhaa na bado imewekwa kuwa ya majaribio pekee, kwa hiyo 1.4 ndiyo toleo unalopaswa kupeleka leo.

Muundo wa hazina ndio tofauti halisi

Hazina ya restic ni saraka ya mafaili: config, keys/, snapshots/, index/, na data/ zilizojaa mafaili ya pack. Hakuna kitu kingine kinachohitajika ili kuisoma. Ndiyo maana restic inaweza kutumia backend nyingi sana. Hifadhi yoyote inayoweza kuweka, kupata, kuorodhesha na kufuta blobs inaweza kuhifadhi hazina ya restic. Hivyo binary moja inaunga mkono njia za ndani, SFTP, REST server yake yenyewe, S3, Backblaze B2, Azure, Google Cloud Storage, na mahali popote panapofikiwa na rclone.

Hazina ya Borg pia ni mafaili kwenye diski, lakini Borg haiwasilishi data humo kupitia transport isiyo na uwezo wa ziada. Kwa hazina ya mbali, Borg huanzisha borg serve upande wa mbali kupitia SSH na hutumia itifaki yake kuwasiliana na mchakato huo. Upande wa server hufanya kazi halisi: huhifadhi hazina, hutekeleza transaction, na hujibu maswali kuhusu index. Ndiyo maana Borg haina backend ya S3 na kwa nini mradi haujaongeza backend hiyo. Hakuna mchakato wa kuendesha ndani ya bucket.

Jambo hilo moja la muundo linasababisha tofauti nyingi za kiutendaji zilizo hapa chini.

# 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

Usimbaji fiche: mmoja wao unaweza kuzimwa

Restic husimba data kwa njia fiche kila wakati. Hakuna hali ya data isiyosimbwa kwa njia fiche. restic init huomba nenosiri, hutengeneza ufunguo kutokana nalo kwa kutumia scrypt, na kila faili ya pack inayoandikwa baada ya hapo husimbwa kwa njia fiche na kuthibitishwa. Ukipoteza nenosiri, data inapotea kwa sababu hakuna njia ya kurejesha iliyoundwa kwa makusudi.

Borg hufanya usimbaji fiche kuwa chaguo wakati wa kuunda repository, na chaguo hilo ni la kudumu. borg init --encryption=repokey huhifadhi ufunguo uliosimbwa kwa njia fiche ndani ya repository, hivyo passphrase pekee inaweza kurejesha data. --encryption=keyfile huhifadhi ufunguo kwenye client katika ~/.config/borg/keys/, hivyo mtu anayeiba repository nzima bado hana chochote, na lazima uhifadhi nakala ya faili hiyo ya ufunguo kando; la sivyo archives zako haziwezi kusomeka. Kila hali ina toleo la -blake2 linalothibitisha data kwa BLAKE2b badala ya HMAC-SHA256. Hii huwa haraka zaidi kwenye hardware isiyo na uharakishaji wa SHA. --encryption=none pia ipo, na ni chaguo halisi wakati repository iko kwenye diski iliyosimbwa kwa njia fiche unayomiliki.

Kanuni ya vitendo: tumia repokey-blake2 kwa nakala rudufu ya kawaida ya server, tumia keyfile wakati repository iko mahali ambapo huwezi kuamini kikamilifu, na usitumie kamwe none kwenye mashine ya kukodi.

Ukandamizaji, na kwa nini restic ilichelewa kuutumia

Borg imekuwa na ukandamizaji tangu mwanzo. Chaguo-msingi ni lz4, lililochaguliwa kwa sababu ni la haraka kiasi cha kuachwa likiwashwa kwa kila kitu. zstd inakubali viwango vya 1 hadi 22 na chaguo-msingi ni 3. zlib na lzma hutumika unapojali zaidi ukubwa wa baiti kuliko muda wa utekelezaji. auto hutumia kanuni ya kukadiria kwa kila kipande ili data iliyokwisha kandamizwa isikandamizwe tena.

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

Restic haikuwa na ukandamizaji hadi muundo wa hazina wa 2, unaohitaji restic 0.14.0 au toleo jipya zaidi. Muundo wa 2 sasa ndiyo chaguo-msingi kwa hazina mpya, na ukandamizaji huwekwa kwa --compression kwa kutumia thamani auto, off au max. Hazina ya zamani ya muundo wa 1 hubaki bila ukandamizaji hadi uiwasilishe kwenye muundo mpya. Kwa hiyo, ikiwa hazina yako ya restic ni ya kabla ya 0.14 na hujawahi kuihamisha, bado unalipia ukubwa kamili wa maandishi, kumbukumbu za mfumo na nakala za hifadhidata.

Malengo ya mbali: S3 dhidi ya SSH

Hapa ndipo uchaguzi hufanywa kwa kawaida.

Restic inapofikia S3, inahitaji vitambulisho vya ufikiaji katika mazingira ya mfumo, na hakuna kingine kinachohitaji kuendeshwa mahali pengine. Mfumo huo huo hufanya kazi kwa bucket unayojihudumia mwenyewe. Huu ni mchanganyiko unaotumika sana: endesha MinIO kwa API ya S3 kwenye VPS yako mwenyewe na uelekeze restic huko.

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 inapofikia repository ya mbali, inahitaji SSH pamoja na usakinishaji wa Borg upande wa mbali. Pia inahitaji toleo la huko liendane na mteja. Hili huwa kikwazo ikiwa upande wa mbali si wako. Halina tatizo ikiwa upande wa mbali ni seva ya pili unayoisimamia tayari. Pia hukupa udhibiti thabiti zaidi dhidi ya ransomware kuliko chaguo lolote kati ya zana hizi: SSH key ya append only. Lazimisha key hiyo itekeleze borg serve, na mteja ataweza kuongeza archives lakini hataweza kuzifuta. Kwa hiyo, mashine iliyovamiwa haiwezi kufuta historia yake yenyewe.

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

Restic ina njia inayolingana tu unapoendesha REST server yake yenyewe, ambayo inatumia hali ya append only. Kwa S3 ya kawaida, unapata athari hiyo hiyo kupitia sera ya bucket au object lock. Hilo ni jukumu la mtoa huduma, si la restic. Zuia pia usafirishaji wa data, kwa sababu upande wa SSH unahitaji uangalifu sawa na login nyingine yoyote: tumia SSH inayotumia key pekee yenye ingizo lenye vizuizi katika authorized_keys kwenye akaunti ya nakala rudufu.

Kasi: kila muundo unamaanisha nini

Hakuna mradi unaochapisha kipimo cha utendaji unachopaswa kukiamini kwa data yako mwenyewe, kwa hiyo toa hitimisho kutokana na utaratibu wa utendaji badala yake.

Borg kupitia SSH ni ya haraka kwenye muunganisho wenye ucheleweshaji kwa sababu upande wa seva una uwezo wa kuchakata maombi. Mteja huuliza swali, mchakato wa mbali wa borg serve hujibu kutoka kwenye faharasa ya hazina, na muamala hukamilishwa mahali pamoja. Utafutaji wa vipande haugeuki kuwa safari za mtandao kwa kila faili ndogo.

Restic kwenye hifadhi ya vitu haina upande wa seva, kwa hiyo lazima ijenge picha yake kutoka kwenye faili za faharasa na faili za pack inazopakua kupitia HTTP. Ili kuweka idadi ya maombi katika kiwango kinachofaa, huweka vipande vingi vidogo kwenye faili kubwa za pack kabla ya kupakia, na huhifadhi akiba ya ndani katika ~/.cache/restic ili uendeshaji unaofuata usipakue tena faharasa yote. Ukifuta akiba hiyo, nakala rudufu inayofuata huwa polepole inapoiunda upya. Kwenye muunganisho wenye ucheleweshaji mkubwa na mamilioni ya faili ndogo, hapa ndipo restic huhisi kuwa ya polepole kuliko Borg kwenye data hiyo hiyo.

Kwenye diski ya ndani au LAN yenye kasi, tofauti hupungua kwa kiasi kikubwa, na zana zote mbili huishia kuzuiwa na kasi ya kusoma na kukokotoa heshi ya chanzo.

Kufunga na kuhifadhi nakala za mashine kadhaa

Borg 1.4 huchukua kufuli la kipekee kwenye hazina kwa muda wote wa operesheni. Wateja wawili wanaoandika kwenye hazina moja kwa wakati mmoja hawafanyi kazi: wa pili husubiri, kisha hushindwa kwa sababu muda wa kusubiri kufuli umeisha. Muundo unaoungwa mkono ni kuwa na hazina moja kwa kila mteja. Hii pia inamaanisha kuwa uondoaji wa nakala zinazojirudia hutokea tu ndani ya hazina ya mashine moja, kwa hiyo seva kumi zinazokaribiana huhifadhi nakala kumi za mfumo huo wa msingi.

Restic huruhusu wateja kadhaa kuhifadhi nakala kwenye hazina moja kwa wakati mmoja, kwa sababu operesheni ya kuhifadhi nakala huchukua kufuli la pamoja, na kazi za matengenezo pekee kama vile prune huchukua kufuli la kipekee. Seva kumi zinazofanana zinazoelekezwa kwenye hazina moja ya restic huondoa nakala zinazojirudia kwa kulinganisha data zao, na seva ya pili mara nyingi huhifadhi data kidogo sana. Hasara ni ukubwa wa athari: nenosiri moja na hazina moja inayohifadhi kila kitu, kwa hiyo kupoteza nenosiri hupoteza seva zote kumi.

Uhifadhi: forget pamoja na prune, dhidi ya prune pamoja na compact

Zana zote mbili hutenganisha “kuamua cha kuhifadhi” na “kurejesha nafasi”, na zote zinakulazimisha utekeleze hatua ya pili.

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

Mtego ni uleule katika zana zote mbili, na ni muhimu kuueleza wazi. Katika Borg, borg prune huondoa nyaraka za kumbukumbu lakini haiachilii nafasi ya diski yenyewe. Nafasi hupatikana tena borg compact inapotekelezwa. Kwa hiyo, kazi ya cron inayotekeleza prune bila compact huacha repository ikikua bila kikomo, huku orodha ya nyaraka za kumbukumbu ikibaki fupi. Katika restic, forget bila --prune huondoa tu marejeo ya snapshot, na data hubaki hadi prune itekelezwe.

Tekeleza restic check baada ya pruning. Huthibitisha miundo ya repository na kukuarifu ikiwa kuna uharibifu. Hilo ni bora zaidi kuliko kugundua tatizo wakati wa kurejesha data.

Kurejesha, ndilo jaribio pekee lenye uzito

Zana zote mbili huweka snapshot kama mfumo wa faili ili uweze kuvinjari. Hii ndiyo njia ya haraka zaidi ya kurejesha faili moja.

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

Zingatia muundo wa njia katika borg extract. Njia zilizo ndani ya archive huhifadhiwa bila slash ya mwanzo, kwa hiyo etc/nginx ni sahihi, ilhali /etc/nginx hailingani na chochote na haitoi chochote, bila hitilafu yoyote kueleza sababu. Utoaji pia huandika kwenye saraka ya sasa ya kazi, kwa hiyo hamia kwenye saraka ya muda kwanza. Usipofanya hivyo, utaandika juu ya faili zinazotumika ukitumia matoleo ya zamani.

Bila kujali zana unayochagua, ratiba ni nusu tu ya kazi. Endesha urejeshaji kwenye saraka ya muda kwa kipima muda unachokifuatilia, kama vile mwongozo kamili katika mwongozo wa restic wa kuhifadhi nakala ya VPS unavyofanya kwa kipima muda cha systemd.

Kipi hushinda kwa kazi gani

Chagua restic wakati lengwa ni hifadhi ya vitu, unapotaka binary moja bila programu upande wa mbali, wakati mashine kadhaa zinapaswa kuondoa nakala rudufu kwa pamoja, au wakati huenda mtu anayerejesha data asiwe wewe. Ni binary moja tuli yenye URL ya hifadhi, na hilo ni gumu kushinda kiutendaji.

Chagua Borg wakati lengwa ni mashine ya Linux unayoidhibiti, wakati kiungo kina ucheleweshaji na seti ya data ina mamilioni ya faili ndogo, unapotaka SSH key ya append only kama udhibiti dhidi ya ransomware, au unapotaka kubinafsisha compression kwa kila kazi. Ni zana ya zamani, mfululizo wake thabiti hubadilika polepole, na katika programu ya kuhifadhi nakala hiyo ni faida.

Jibu lolote kati ya hayo ni sahihi. Jibu lisilo sahihi ni lile ambalo hujawahi kulijaribu. Ikiwa tayari unatengeneza dumps za kiwango cha application, ziendelee: muundo katika usanidi wa Nextcloud kwenye Docker wenye dumps za database unatumika kwa zana zote mbili, kwa sababu faili ya database iliyonakiliwa wakati wa nasibu ikiwa database iko hai si nakala rudufu ya database.

FAQ

Je, restic au BorgBackup ni ipi yenye kasi zaidi?

Kwenye diski ya ndani au LAN yenye kasi, tofauti ni ndogo. Zote huishia kuzuiwa na kasi ya kusoma na kuhesabu hash kwenye chanzo. Borg kwa kawaida huwa bora kupitia kiungo cha SSH chenye ucheleweshaji mkubwa na faili nyingi sana ndogo, kwa sababu mchakato wa borg serve upande wa mbali hujibu maswali ya faharasa bila safari ya mtandao kwa kila kipande. Restic kwa kawaida huwa bora lengwa linapokuwa hifadhi ya vitu, ambako Borg haiwezi kufanya kazi kabisa.

Je, BorgBackup inaweza kuhifadhi nakala kwenye S3 au Backblaze B2?

Si moja kwa moja. Repository ya Borg hutolewa na mchakato wa borg serve kupitia SSH, na hakuna mchakato kama huo unaoendesha ndani ya bucket. Baadhi ya watumiaji hujaribu hili kwa kuunganisha hifadhi ya vitu kama mfumo wa faili kwa kutumia rclone. Mradi wa Borg haupendekezi njia hii, kwa sababu mount ikikatika katikati ya muamala inaweza kuharibu repository. Ikiwa unahitaji hifadhi ya vitu, tumia restic.

Je, ninaweza kuendesha zana zote mbili dhidi ya data ileile?

Ndiyo, na baadhi ya watumiaji hufanya hivyo: Borg kwenye server ya pili kwa urejeshaji wa haraka wa ndani, na restic kwenye hifadhi ya vitu kwa nakala ya nje ya eneo. Hazishirikiani chochote, kwa hiyo utalipia gharama ya kusoma na kuhesabu hash mara mbili. Pia utakuwa na nywila mbili za kuhifadhi kwa usalama. Fanya hivi tu ikiwa umejaribu urejeshaji wote wawili.

Nini hutokea nikisahau nywila ya repository?

Data haiwezi kurejeshwa katika zana zote mbili. Restic hutengeneza key yake kutokana na nywila kwa kutumia scrypt, na hakuna njia ya kukwepa ulinzi huo. Katika hali ya repokey ya Borg, key iliyosimbwa kwa njia fiche huhifadhiwa ndani ya repository, kwa hiyo passphrase pekee inatosha kurejesha data. Katika hali ya keyfile, unahitaji pia faili ya key kutoka ~/.config/borg/keys/. Hifadhi nywila kwenye password manager ambayo haipo kwenye server inayohifadhiwa nakala. Pia, export key ya Borg kwa kutumia borg key export ikiwa unatumia keyfile.

Je, nisubiri Borg 2.0?

Hapana. Kufikia Julai 2026, Borg 2.0 bado iko kwenye beta, katika toleo 2.0.0b22, na mradi unaieleza kuwa ni ya majaribio pekee. Mfululizo thabiti ni 1.4, ambao kwa sasa uko kwenye 1.4.5. Anza na 1.4 sasa. Borg 2 hubadilisha muundo wa repository na hutoa njia ya uboreshaji iliyoandikwa katika nyaraka. Kwa hiyo kuanza leo hakutakuacha bila njia ya kuendelea.