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 backup inahifadhiwa. Restic inatumia 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 hutumikiwa na mchakato (process), si kwa mfumo wa faili au API. Ikiwa lengo lako ni object storage, basi jibu ni Restic. Ikiwa lengo lako ni Linux server nyingine 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 itapakia takriban 200 MB pekee. Zote hufanya encryption kwenye 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, katika toleo la 1.4.5. Borg 2.0 imekuwa katika beta kwa miaka mingi na bado imewekwa alama ya 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/ iliyojaa 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, ndiyo maana binary moja inasaidia njia za ndani, SFTP, seva yake ya REST, 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 transport 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 backend ya S3 na kwa nini mradi huu haujaongeza moja. Hakuna mchakato wa kuendesha ndani ya bucket.

Ukweli huo mmoja wa usanifu unazalisha tofauti nyingi za kivitendo 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 kuzima moja ya njia hizi

Restic husimba data zote kila wakati. Hakuna hali ya kutotumia usimbaji fiche. restic init huomba nenosiri, hutumia scrypt kutengeneza ufunguo (key) kutoka kwa nenosiri hilo, na kila faili ya pack inayohifadhiwa baada ya hapo husimbwa na kuhakikiwa. Ukipoteza nenosiri, 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 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 iko kwenye diski iliyosimbwa unayomiliki.

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

Compression, na kwa nini restic ilichelewa kuipata

Borg imekuwa ikitumia compression tangu mwanzo. Chaguo-msingi ni lz4, iliyochaguliwa kwa sababu ina kasi ya kutosha kuachwa ikiwa imewashwa 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 data (bytes) kuliko muda, na auto huendesha heuristiki kwa kila chunk ili data iliyokwisha kuminywa isiminywe mara mbili.

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

Restic haikuwa na compression yoyote 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 compression huwekwa kwa kutumia --compression katika viwango vya auto, off au max. Repository ya zamani ya format 1 hubaki bila compression hadi utakapoihamishia kwenye format mpya. Kwa hivyo, ikiwa repository yako ya restic ni ya kabla ya toleo la 0.14 na hujawahi kuifanyia migration, bado unalipa gharama kamili ya nafasi 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) katika mazingira ya mfumo na hakuna kitu 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 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 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 yoyote 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 aina ya append-only. Lazimisha ufunguo huo kuendesha borg serve na mteja ataweza kuongeza kumbukumbu (archives) lakini hataweza 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 uwezo sawa na huu pale tu unapoiendesha kwenye seva yake ya REST, ambayo inasaidia hali ya append-only. Dhidi ya S3 ya kawaida, unapata matokeo sawa kupitia sera ya bucket au object lock, ambayo ni kazi ya mtoa huduma na si ya restic. Funga pia njia ya usafirishaji (transport), kwa sababu upande wa SSH wa hili unastahili uangalifu uleule kama login nyingine yoyote: tumia SSH ya ufunguo pekee yenye ingizo lililowekewa vikwazo kwenye authorized_keys kwa 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 over SSH ina kasi kwenye kiungo chenye latency kwa sababu upande wa seva ni wa akili. Mteja huuliza swali, mchakato wa borg serve uliopo 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 inazozipakua kupitia HTTP. Ili kuweka idadi ya maombi katika kiwango kinachokubalika, hupakia chunk nyingi ndogo kwenye faili kubwa za pack kabla ya kupakia (upload), na huhifadhi cache ya ndani kwenye ~/.cache/restic ili uendeshaji unaofuata usipakue upya index nzima. Futa cache hiyo na backup inayofuata itakuwa polepole wakati inajijenga upya. Kwenye kiungo chenye latency kubwa na mamilioni ya faili ndogo, hapa ndipo restic huonekana polepole kuliko Borg kwenye data ileile.

Kwenye diski ya ndani au LAN ya kasi, tofauti hiyo hupungua sana, na zana zote mbili huishia kuzuiliwa na kasi ya kusoma na kuhash (hash) chanzo cha data.

Kufunga, na kuhifadhi nakala za mashine kadhaa

Borg 1.4 hufunga repository kwa ukiritimba 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 tu, 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 prune ndizo huchukua lock ya ukiritimba. Seva kumi zinazofanana zikielekezwa kwenye repository moja ya restic hufanya deduplication dhidi ya nyingine, na seva ya pili na kuendelea mara nyingi huhifadhi data kidogo sana. Gharama yake ni blast radius: nenosiri moja na repository moja inayoshikilia kila kitu, kwa hivyo kupoteza nenosiri hilo kunamaanisha kupoteza zote kumi.

Retention: forget na prune, dhidi ya prune na compact

Zana zote mbili hutenganisha "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 vyema kueleza 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 itakapoendeshwa.

Endesha restic check baada ya kufanya prune. Inathibitisha miundo ya 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 hupachika (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 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 kutoa kosa lolote la kukueleza kwa nini. Utoaji (extraction) pia huandika kwenye saraka ya sasa ya kazi, kwa hivyo ingia kwenye saraka ya muda (scratch directory) kwanza au utafuta faili zilizopo kwa kuzibadilisha na zile za zamani.

Urejeshaji unaokamilika bila kosa bado si uthibitisho, kwa sababu programu iliyo juu ina mtazamo wake kuhusu urejeshaji kamili: seva ya Immich iliyojengwa upya kutoka kwa nakala ya saraka ya data ya Postgres hurudi ikiwa na kila picha kwenye diski lakini timeline haionyeshi kitu, jambo ambalo ndilo kosa ambalo kuhifadhi na kurejesha Immich lazima lishughulikie.

Zana yoyote utakayochagua, ratiba ni nusu tu ya kazi. Fanya urejeshaji kwenye saraka ya muda kwa kutumia kipima muda unachokifuatilia kikamilifu, kama vile mwongozo kamili katika mwongozo wa kuhifadhi data wa restic kwa VPS unavyofanya kwa kutumia systemd timer.

Ni ipi bora kwa kazi ipi

Chagua restic wakati unalenga object storage, unapotaka binary moja bila programu yoyote upande wa pili, wakati mashine kadhaa zinapaswa kufanya deduplication dhidi ya nyingine, au wakati mtu anayerejesha data anaweza asiwe wewe. Ni binary moja ya static yenye URL ya repository, na ni vigumu kupata zana bora zaidi kiutendaji.

Chagua Borg wakati unalenga seva ya Linux unayoimiliki, wakati muunganisho una latency na dataset ina mamilioni ya faili ndogo, unapotaka SSH key ya aina ya append-only kama kinga dhidi ya ransomware, au unapotaka 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 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 hizo, 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?

Haiwezi moja kwa moja. Repository ya Borg hutumikiwa na mchakato wa borg serve kupitia SSH, na hakuna mchakato kama huo unaoendesha ndani ya bucket. Watu hutatua hili 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 ya ofisi. 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 kupatikana tena 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 kufanya restore, 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 inayohifadhiwa, na hamisha 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