Restic au BorgBackup: ipi bora kwa backup yako?

Restic dhidi ya BorgBackup, kwa aya moja

Restic na BorgBackup zote hufanya kazi ileile ya msingi: kuhifadhi nakala za Linux server kwa njia ya deduplication, encryption, na incremental backups. Tofauti inayoamua chaguo ni mahali ambapo nakala hizo huhifadhiwa. Restic hutumia S3 na API nyingine za object storage kiasili, hivyo bucket ni sehemu kuu ya kuhifadhi bila kuhitaji programu yoyote upande wa pili. Borg inahitaji programu ya borg isakinishwe kwenye mashine inayoshikilia repository, kwa sababu repository ya Borg hutumika kupitia mchakato (process), si kupitia mfumo wa faili au API. Ikiwa lengo lako ni object storage, basi jibu ni Restic. Ikiwa lengo lako ni seva nyingine ya Linux unayoimiliki, Borg inafaa na mara nyingi huwa na kasi zaidi.

Mambo mengine yote ni tofauti ndogo. Zote hugawanya faili kwa kutumia content defined chunking, hivyo saraka ya 40 GB iliyobadilika kwa 200 MB itapakiwa kiasi cha 200 MB pekee. Zote hufanya encryption kwenye upande wa mteja (client). Zote huruhusu ku-mount snapshot kwa kutumia FUSE (filesystem in userspace) ili uweze kunakili faili moja. Kufikia Julai 2026, restic iko kwenye toleo la 0.19.1 na mfululizo wa stable wa Borg ni 1.4, ikiwa kwenye 1.4.5. Borg 2.0 imekuwa kwenye beta kwa miaka mingi na bado imewekwa kama toleo la majaribio pekee, hivyo 1.4 ndilo toleo unalopaswa kutumia leo.

Mfumo wa repository ndio tofauti ya msingi

Repository ya restic ni saraka ya faili: config, keys/, snapshots/, index/, na data/ zilizojaa faili za pack. Hakuna kingine kinachohitajika ili kuisoma. Hii ndiyo sababu restic inaweza kutumia backends nyingi sana. Hifadhi yoyote inayoweza kuweka, kuchukua, kuorodhesha na kufuta blobs inaweza kuhifadhi repository ya restic, na ndivyo binary moja inavyoweza kutumia local paths, SFTP, REST server yake yenyewe, S3, Backblaze B2, Azure, Google Cloud Storage, na chochote kinachoweza kufikiwa na rclone.

Repository ya Borg pia ni faili kwenye diski, lakini Borg haiwasiliani nayo kupitia usafirishaji rahisi. Kwa repository ya mbali, Borg huanzisha borg serve upande wa pili kupitia SSH na kuzungumza itifaki yake yenyewe na mchakato huo. Upande wa seva hufanya kazi halisi: inashikilia repository, inatekeleza transaction, na kujibu maswali ya index. Hii ndiyo sababu Borg haina S3 backend na kwa nini mradi huu haujaongeza moja. Hakuna mchakato wa kuendesha ndani ya bucket.

Ukweli huo mmoja wa usanifu unazalisha tofauti nyingi za kivitendo 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: chaguo la kuuzima

Restic husimba data kwa njia fiche kila wakati. Hakuna hali ya kutotumia usimbaji fiche. restic init huomba nenosiri, hutumia scrypt kutengeneza ufunguo (key) kutoka kwenye nenosiri hilo, na kila faili ya pack inayohifadhiwa baada ya hapo husimbwa na kuhakikiwa. Ukipoteza nenosiri hilo, data itapotea, kwa sababu hakuna njia ya kuirejesha kwa usanifu wa programu hii.

Borg hufanya usimbaji fiche kuwa chaguo wakati wa kuunda hazina (repository), na chaguo hilo ni la kudumu. borg init --encryption=repokey huhifadhi ufunguo uliosimbwa ndani ya hazina, hivyo nenosiri pekee linatosha kurejesha data. --encryption=keyfile huhifadhi ufunguo kwenye mteja (client) ndani ya ~/.config/borg/keys/, hivyo mtu akiiba hazina nzima hatapata chochote, na ni lazima uhifadhi nakala ya faili hiyo ya ufunguo kando vinginevyo kumbukumbu zako hazitasomeka. Kila hali ina lahaja ya -blake2 inayohakiki kwa kutumia BLAKE2b badala ya HMAC-SHA256, ambayo ni ya haraka zaidi kwenye maunzi (hardware) yasiyo na kasi ya SHA. --encryption=none pia ipo, na ni chaguo halali wakati hazina inapohifadhiwa kwenye diski iliyosimbwa fiche unayomiliki.

Kanuni ya kivitendo: repokey-blake2 kwa nakala rudufu ya kawaida ya seva, keyfile wakati hazina inapohifadhiwa mahali ambapo hakuamini kikamilifu, na usitumie kamwe none kwenye mashine uliyokodisha.

Ubanaji wa data, na kwa nini restic ilichelewa kuupata

Borg imekuwa ikibana data tangu kuanzishwa kwake. Chaguo-msingi ni lz4, ambalo lilichaguliwa kwa sababu lina kasi ya kutosha kuachwa likiwa limewashwa kwa kila kitu. zstd inakubali viwango kuanzia 1 hadi 22 na chaguo-msingi ni 3, zlib na lzma zipo kwa ajili ya hali ambapo unajali zaidi ukubwa wa faili kuliko muda wa kusubiri, na auto hutumia mbinu ya kihesabu (heuristic) kwa kila chunk ili data iliyokwisha banwa isibanwe mara mbili.

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

Restic haikuwa na uwezo wowote wa kubana data hadi ilipofika repository format 2, ambayo inahitaji restic 0.14.0 au toleo jipya zaidi. Format 2 ndiyo chaguo-msingi kwa repository mpya sasa, na ubanaji wa data huwekwa kwa kutumia --compression katika viwango vya auto, off au max. Repository ya zamani ya format 1 hubaki bila kubanwa hadi utakapoihamishia kwenye mfumo mpya. Kwa hivyo, ikiwa repository yako ya restic ni ya kabla ya toleo la 0.14 na hujawahi kuifanyia uhamiaji, bado unatumia nafasi kamili ya diski kwa ajili ya maandishi, logi, na database dumps.

Lengo la mbali: S3 dhidi ya SSH

Hapa ndipo chaguo hufanywa mara nyingi.

Restic inapofikia S3 inahitaji vitambulisho (credentials) kwenye mazingira (environment) na hakuna kingine kinachohitajika kuendeshwa popote. Mfumo huo huo hufanya kazi dhidi ya bucket unayojiendeshea mwenyewe, ambayo ni muunganiko wa kawaida: endesha MinIO kwa ajili ya S3 API kwenye VPS yako na uelekeze restic kwake.

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 hazina (repository) ya mbali inahitaji SSH pamoja na usakinishaji wa Borg upande wa pili, na inataka toleo lililopo huko liwe sambamba na la mteja (client). Hii ni changamoto ikiwa upande wa pili si wako. Haina shida ikiwa upande wa pili ni seva ya pili unayoisimamia tayari, na inakupa udhibiti thabiti zaidi dhidi ya ransomware kuliko zana nyingine yoyote: ufunguo wa SSH wa kuongeza pekee (append only). Lazimisha ufunguo kuendesha borg serve na mteja ataweza kuongeza kumbukumbu (archives) lakini hawezi kuzifuta, hivyo mashine iliyoathiriwa haiwezi kufuta historia yake yenyewe.

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

Restic ina kitu sawa na hiki pale tu unapoendesha seva yake ya REST, ambayo inasaidia hali ya kuongeza pekee (append only mode). Dhidi ya S3 ya kawaida unapata matokeo hayohayo kutoka kwa sera ya bucket au object lock, ambayo ni kazi ya mtoa huduma na si ya restic. Funga usafirishaji (transport) pia, kwa sababu upande wa SSH wa hili unastahili uangalifu uleule kama login nyingine yoyote: tumia SSH ya ufunguo pekee na ingizo la authorized_keys lililozuiliwa kwenye akaunti ya backup.

Kasi: maana ya kila usanifu

Hakuna mradi unaochapisha benchmark unayopaswa kuiamini kwa data yako mwenyewe, kwa hivyo fanya tathmini kulingana na utaratibu wa kazi.

Borg kupitia SSH ni ya haraka kwenye muunganisho wenye latency kwa sababu upande wa seva ni wa akili. Mteja huuliza swali, mchakato wa borg serve wa mbali hujibu kutoka kwenye index ya repository, na muamala hukamilika sehemu moja. Utafutaji wa chunk haugeuki kuwa safari za mtandao (round trips) kwa kila faili ndogo.

Restic kwenye object storage haina upande wa seva, kwa hivyo lazima ijenge picha yake kutoka kwenye faili za index na faili za pack inazopakua kupitia HTTP. Ili kuweka idadi ya maombi katika kiwango kinachokubalika, hupakia chunk nyingi ndogo kwenye faili kubwa za pack kabla ya kuzipakia, na huhifadhi cache ya ndani kwenye ~/.cache/restic ili operesheni inayofuata isipakue upya index nzima. Futa cache hiyo na backup inayofuata itakuwa polepole wakati inajijenga upya. Kwenye muunganisho wenye latency ya juu na mamilioni ya faili ndogo, hapa ndipo restic huonekana polepole kuliko Borg kwenye data ileile.

Kwenye diski ya ndani au LAN ya haraka, tofauti hiyo hupungua, na zana zote mbili huishia kupunguzwa kasi na jinsi zinavyoweza kusoma na kuhash chanzo cha data.

Kufunga, na kuhifadhi nakala za mashine kadhaa

Borg 1.4 hufunga repository kwa ukamilifu wakati wa operesheni nzima. Wateja wawili wanaoandika kwenye repository moja kwa wakati mmoja hawawezi kufanya kazi: wa pili husubiri, kisha hushindwa kwa sababu ya muda wa lock kuisha (lock timeout). Mfumo unaoungwa mkono ni repository moja kwa kila mteja. Hii pia inamaanisha kuwa deduplication hutokea ndani ya repository ya mashine moja pekee, kwa hivyo seva kumi zinazofanana huhifadhi nakala kumi za mfumo mmoja wa msingi.

Restic inaruhusu wateja kadhaa kuhifadhi nakala kwenye repository moja kwa wakati mmoja, kwa sababu backup huchukua lock ya pamoja na kazi za matengenezo pekee kama vile prune ndizo huchukua lock ya kipekee. Seva kumi zinazofanana zikielekezwa kwenye repository moja ya restic hufanya deduplication dhidi ya nyingine, na seva ya pili na kuendelea mara nyingi huhifadhi kiasi kidogo sana cha data. Gharama yake ni blast radius: nenosiri moja na repository moja inayoshikilia kila kitu, kwa hivyo kupoteza nenosiri kunamaanisha kupoteza zote kumi.

Uhifadhi: forget na prune, dhidi ya prune na compact

Zana zote mbili hutenganisha hatua ya "kuamua nini cha kuhifadhi" na "kurejesha nafasi ya diski", na zote zinakulazimisha kuendesha 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 archives lakini haitoi nafasi ya diski yenyewe. Nafasi hurejea wakati borg compact inapoendeshwa, kwa hivyo cron job inayofanya prune bila kufanya compact itaacha repository ikikua milele huku orodha ya archive ikiwa fupi. Katika restic, forget bila --prune huondoa tu marejeleo ya snapshot, na data hubaki hadi prune itakapofanyika.

Endesha restic check baada ya kufanya prune. Inathibitisha muundo wa repository na kukuambia ikiwa kuna kitu kimeharibika, jambo ambalo ni bora zaidi kuliko kuligundua wakati wa kurejesha data (restore).

Urejeshaji, ambao ndio jaribio pekee lenye maana

Zana zote mbili hupandisha (mount) snapshot ili uweze kuivinjari. Hiyo 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 (path) katika borg extract. Njia ndani ya archive huhifadhiwa bila slash ya mwanzo, kwa hivyo etc/nginx ni sahihi na /etc/nginx hailingani na kitu chochote na haitoi chochote, bila ujumbe wa kosa kukuambia kwa nini. Utoaji (extraction) pia huandika kwenye saraka ya sasa ya kazi (current working directory), kwa hivyo ingia kwenye saraka ya muda (scratch directory) kwanza au utafuta faili zilizopo kwa kuzibadilisha na za zamani.

Chombo chochote unachochagua, ratiba ni nusu tu ya kazi. Fanya urejeshaji kwenye saraka ya muda kwa kutumia kipima muda (timer) unachokifuatilia kikweli, kama vile mwongozo kamili katika mwongozo wa chelezo wa restic kwa VPS unavyofanya kwa kutumia systemd timer.

Ni ipi inayofaa kwa kazi ipi

Chagua restic wakati unalenga hifadhi ya object storage, unapotaka faili moja ya binary bila kuhitaji programu yoyote upande wa pili, wakati mashine nyingi zinapaswa kufanya deduplication dhidi ya nyingine, au wakati mtu atakayerejesha data anaweza asikuwe wewe. Hii ni binary moja tuli yenye URL ya repository, na ni vigumu kupata mbadala bora zaidi kiutendaji.

Chagua Borg wakati unalenga seva ya Linux unayoimiliki, wakati muunganisho una latency na dataset ina mamilioni ya faili ndogo, wakati unataka SSH key ya aina ya append-only kama kinga dhidi ya ransomware, au wakati unataka kurekebisha compression kwa kila kazi. Hii ni zana ya zamani zaidi, toleo lake thabiti hubadilika polepole, na katika programu za backup, hiyo ni sifa muhimu.

Zote mbili ni chaguo sahihi. Jibu lisilo sahihi ni lile ambalo hujaribu kamwe. Ikiwa tayari unachukua dumps za kiwango cha programu, ziendeleze: muundo uliopo katika usanidi wa Nextcloud kwenye Docker wenye database dumps unatumika kwa zana yoyote kati ya hizi, kwa sababu faili ya database inayotumika ikinakiliwa wakati wowote bila mpangilio si backup ya database.

FAQ

Je, restic au BorgBackup ni ya kasi zaidi?

Kwenye diski ya ndani au LAN ya kasi, zote zinafanya kazi karibu sawa, na zote huishia kuzuiwa na kasi ya kusoma na kuhash (hash) kwenye chanzo. Borg mara nyingi hufanya vizuri zaidi kwenye muunganisho wa SSH wenye latency ya juu na faili nyingi ndogo, kwa sababu mchakato wa borg serve upande wa pili hujibu maswali ya index bila kuhitaji mawasiliano ya mtandao kwa kila chunk. Restic mara nyingi hufanya vizuri zaidi wakati lengo ni object storage, ambapo Borg haiwezi kufanya kazi kabisa.

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

Hapana, si moja kwa moja. Repository ya Borg hutumikiwa na mchakato wa borg serve kupitia SSH, na mchakato kama huo hauwezi kuendeshwa ndani ya bucket. Watu hufanya kazi hiyo kwa ku-mount object storage kama mfumo wa faili kwa kutumia rclone, jambo ambalo mradi wa Borg haushauri, kwa sababu mount inayokatika katikati ya transaction inaweza kuharibu repository. Ikiwa unahitaji object storage, tumia restic.

Je, ninaweza kutumia zana zote mbili kwa data ileile?

Ndiyo, na baadhi ya watu hufanya hivyo: Borg kwenye seva ya pili kwa ajili ya restore ya haraka ya ndani, na restic kwenye object storage kwa ajili ya nakala ya nje (offsite). Hazishiriki chochote, kwa hivyo utalipa gharama ya kusoma na kuhash mara mbili, na utakuwa na nywila mbili za kuhifadhi kwa usalama. Fanya hivi tu ikiwa umejaribu restore za zote mbili.

Nini kitatokea nikipoteza nywila ya repository?

Data haiwezi kurejeshwa katika zana zote mbili. Restic hupata ufunguo wake kutoka kwa nywila kwa kutumia scrypt na hakuna njia ya kuikwepa. Borg katika hali ya repokey huhifadhi ufunguo uliosimbwa ndani ya repository, kwa hivyo passphrase pekee inatosha kurejesha, na katika hali ya keyfile unahitaji pia faili ya ufunguo kutoka ~/.config/borg/keys/. Hifadhi nywila katika meneja wa nywila (password manager) ambaye haishi kwenye seva inayochelezwa, na hamisha (export) ufunguo wa Borg kwa kutumia borg key export ikiwa unatumia keyfile.

Je, ningoje Borg 2.0?

Hapana. Kufikia Julai 2026, Borg 2.0 bado iko katika hatua ya beta, ikiwa katika toleo la 2.0.0b22, na mradi huiweka kama ya majaribio pekee. Mfululizo thabiti (stable) ni 1.4, ambao kwa sasa ni 1.4.5. Anza na 1.4 sasa. Borg 2 inabadilisha muundo wa repository na inatoa njia iliyoandikwa ya kuboresha (upgrade path), kwa hivyo kuanza leo hakutakuacha katika hali ngumu.