Nakala hii itazingatia programu ya chelezo ambayo, kwa kuvunja mkondo wa data katika sehemu tofauti (chunks), huunda hazina.
Vipengee vya uhifadhi vinaweza kubanwa zaidi na kusimbwa kwa njia fiche, na muhimu zaidi - wakati wa michakato ya kurudia ya kuhifadhi - kutumika tena.
Nakala ya chelezo katika hifadhi kama hiyo ni mlolongo wa vipengele vilivyounganishwa kwa kila mmoja, kwa mfano, kulingana na kazi mbalimbali za hashi.
Kuna suluhisho kadhaa zinazofanana, nitazingatia 3: zbackup, borgbackup na restic.
Matokeo yanayotarajiwa
Kwa kuwa waombaji wote wanahitaji kuundwa kwa hifadhi kwa njia moja au nyingine, moja ya mambo muhimu zaidi itakuwa kukadiria ukubwa wa hifadhi. Kwa kweli, saizi yake haipaswi kuwa zaidi ya GB 13 kulingana na mbinu iliyokubaliwa, au hata chini - chini ya uboreshaji mzuri.
Pia inafaa sana kuweza kuunda nakala rudufu za faili moja kwa moja, bila kutumia kumbukumbu kama tar, na pia kufanya kazi na ssh/sftp bila zana za ziada kama rsync na sshfs.
Tabia wakati wa kuunda nakala rudufu:
- Saizi ya hazina itakuwa sawa na saizi ya mabadiliko, au chini.
- Upakiaji mzito wa CPU unatarajiwa unapotumia mbano na/au usimbaji fiche, na mtandao wa juu kabisa na upakiaji wa diski kuna uwezekano ikiwa mchakato wa kuhifadhi kumbukumbu na/au usimbaji unaendelea kwenye seva ya hifadhi mbadala.
- Ikiwa hazina imeharibiwa, hitilafu iliyochelewa inawezekana wakati wa kuunda nakala mpya na wakati wa kujaribu kurejesha. Inahitajika kupanga hatua za ziada ili kuhakikisha uadilifu wa hazina au kutumia zana zilizojengwa kwa kuangalia uadilifu wake.
Kufanya kazi na lami inachukuliwa kama dhamana ya kumbukumbu, kama ilivyoonyeshwa katika moja ya vifungu vilivyotangulia.
Inajaribu zbackup
Utaratibu wa jumla wa zbackup ni kwamba programu hupata katika maeneo ya mkondo wa data ya pembejeo iliyo na data sawa, kisha kwa hiari inafinyiza na kusimba kwa njia fiche, kuokoa kila eneo mara moja tu.
Utoaji rudufu hutumia kazi ya heshi ya pete ya biti 64 na kidirisha cha kuteleza ili kuangalia mechi za byte-byte dhidi ya vizuizi vya data vilivyopo (sawa na jinsi rsync inavyoitekeleza).
Lzma na lzo zenye nyuzi nyingi hutumiwa kwa ukandamizaji, na aes kwa usimbaji fiche. Matoleo ya hivi punde yana uwezo wa kufuta data ya zamani kutoka kwa hazina katika siku zijazo.
Mpango huo umeandikwa katika C++ na utegemezi mdogo. Mwandishi inaonekana alihamasishwa na unix-njia, kwa hivyo programu inakubali data kwenye stdin wakati wa kuunda chelezo, ikitoa mtiririko sawa wa data kwenye stdout wakati wa kurejesha. Kwa hivyo, zbackup inaweza kutumika kama "jengo" nzuri sana wakati wa kuandika suluhu zako za chelezo. Kwa mfano, mwandishi wa makala ametumia programu hii kama zana kuu ya kuhifadhi nakala za mashine za nyumbani tangu takriban 2014.
Mtiririko wa data utakuwa tar ya kawaida isipokuwa imeelezwa vinginevyo.
Wacha tuone matokeo ni nini:
Kazi iliangaliwa katika chaguzi 2:
- hazina imeundwa na zbackup inazinduliwa kwenye seva na data ya chanzo, kisha yaliyomo kwenye hazina huhamishiwa kwenye seva ya hifadhi ya chelezo.
- hazina imeundwa kwenye seva ya kuhifadhi chelezo, zbackup inazinduliwa kupitia ssh kwenye seva ya hifadhi ya chelezo, na data hutumwa kwake kupitia bomba.
Matokeo ya chaguo la kwanza yalikuwa kama ifuatavyo: 43m11s - wakati wa kutumia hazina isiyofichwa na compressor ya lzma, 19m13s - wakati wa kuchukua nafasi ya compressor na lzo.
Mzigo kwenye seva na data asili ulikuwa kama ifuatavyo (mfano na lzma umeonyeshwa; na lzo kulikuwa na takriban picha sawa, lakini sehemu ya rsync ilikuwa karibu robo ya wakati):
Ni wazi kuwa mchakato kama huo wa chelezo unafaa tu kwa mabadiliko ya nadra na madogo. Inashauriwa pia kupunguza uhifadhi wa zbackup hadi nyuzi 1, vinginevyo kutakuwa na mzigo mkubwa wa CPU, kwa sababu. Mpango huo ni mzuri sana katika kufanya kazi katika nyuzi nyingi. Mzigo kwenye diski ulikuwa mdogo, ambao kwa ujumla haungeonekana na mfumo wa kisasa wa diski ya msingi wa ssd. Unaweza pia kuona wazi mwanzo wa mchakato wa kusawazisha data ya kumbukumbu kwa seva ya mbali; kasi ya utendakazi inalinganishwa na rsync ya kawaida na inategemea utendakazi wa mfumo mdogo wa diski wa seva ya hifadhi ya chelezo. Hasara ya mbinu hii ni uhifadhi wa hifadhi ya ndani na, kwa sababu hiyo, kurudia data.
Kuvutia zaidi na kutumika katika mazoezi ni chaguo la pili, kuendesha zbackup moja kwa moja kwenye seva ya hifadhi ya chelezo.
Kwanza, tutajaribu operesheni bila kutumia usimbuaji fiche na compressor ya lzma:
Muda wa utekelezaji wa kila jaribio:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
39m45
40m20
40m3
7m36
8m3
7m48
15m35
15m48
15m38
Ukiwezesha usimbuaji kwa kutumia aes, matokeo yako karibu kabisa:
Muda wa kufanya kazi kwenye data sawa, na usimbaji fiche:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
43m40
44m12
44m3
8m3
8m15
8m12
15m0
15m40
15m25
Ikiwa usimbaji fiche umejumuishwa na ukandamizaji kwa kutumia lzo, inaonekana kama hii:
Masaa:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
18m2
18m15
18m12
5m13
5m24
5m20
8m48
9m3
8m51
Saizi ya hazina iliyosababishwa ilikuwa sawa kwa 13GB. Hii ina maana kwamba uondoaji unafanya kazi kwa usahihi. Pia, kwenye data iliyoshinikizwa tayari, kutumia lzo kunatoa athari inayoonekana; kwa suala la jumla ya muda wa kufanya kazi, zbackup inakaribia kurudiwa/duplicati, lakini iko nyuma ya zile za msingi wa librsync kwa mara 2-5.
Faida ni dhahiri - kuokoa nafasi ya diski kwenye seva ya kuhifadhi chelezo. Kuhusu zana za kukagua hazina, mwandishi wa zbackup haiwapi; inashauriwa kutumia safu ya diski inayostahimili makosa au mtoaji wa wingu.
Kwa ujumla, hisia nzuri sana, licha ya ukweli kwamba mradi umesimama kwa karibu miaka 3 (ombi la mwisho la kipengele lilikuwa karibu mwaka mmoja uliopita, lakini bila jibu).
Inajaribu kuhifadhi nakala rudufu
Borgbackup ni uma ya attic, mfumo mwingine sawa na zbackup. Imeandikwa katika python, ina orodha ya uwezo sawa na zbackup, lakini kwa kuongeza inaweza:
- Weka nakala rudufu kupitia fuse
- Angalia yaliyomo kwenye hazina
- Fanya kazi katika hali ya seva ya mteja
- Tumia compressors mbalimbali kwa data, pamoja na uamuzi wa heuristic wa aina ya faili wakati wa kuibana.
- Chaguo 2 za usimbaji fiche, aes na blake
- Zana iliyojengwa ndani ya
ukaguzi wa utendaji
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Matokeo yalikuwa kama ifuatavyo:
CZ-BIG 96.51 MB/s (10 100.00 MB faili za sufuri zote: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB faili za sufuri zote: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB faili za sufuri zote: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB faili za sufuri zote: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB faili za nasibu: 29.15s)
RR-BIG 60.69 MB/s (10 100.00 MB faili za nasibu: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB faili za nasibu: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB faili za nasibu: 13.77s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB faili za sufuri zote: 9.21s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB faili za sufuri zote: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB faili za sufuri zote: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB faili za sufuri zote: 2.58s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB faili za nasibu: 26.45s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB faili za nasibu: 14.51s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB faili za nasibu: 2.88s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB faili za nasibu: 20.49s)
CZ-NDOGO 11.72 MB/s (10000 10.00 kB faili zote sufuri: 8.53s)
RZ-NDOGO 32.57 MB/s (10000 10.00 kB faili zote sufuri: 3.07s)
UZ-NDOGO 19.37 MB/s (10000 10.00 kB faili zote sufuri: 5.16s)
DZ-NDOGO 33.71 MB/s (10000 10.00 kB faili zote sufuri: 2.97s)
CR-NDOGO 6.85 MB/s (10000 10.00 kB faili nasibu: sekunde 14.60)
RR-NDOGO 31.27 MB/s (10000 10.00 kB faili nasibu: sekunde 3.20)
UR-NDOGO 12.28 MB/s (10000 10.00 kB faili nasibu: sekunde 8.14)
DR-SMALL 18.78 MB/s (10000 10.00 kB faili nasibu: sekunde 5.32)
Wakati wa kupima, heuristics ya compression itatumika kuamua aina ya faili (compression auto), na matokeo yatakuwa kama ifuatavyo:
Kwanza, hebu tuangalie jinsi inavyofanya kazi bila usimbaji fiche:
Masaa:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
4m6
4m10
4m5
56s
58s
54s
1m26
1m34
1m30
Ukiwezesha uidhinishaji wa hazina (hali iliyothibitishwa), matokeo yatakuwa karibu:
Masaa:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
4m11
4m20
4m12
1m0
1m3
1m2
1m30
1m34
1m31
Wakati usimbaji fiche wa aes ulipoamilishwa, matokeo hayakuharibika sana:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
4m55
5m2
4m58
1m0
1m2
1m0
1m49
1m50
1m50
Na ukibadilisha aes kuwa blake, hali itaboresha kabisa:
Masaa:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
4m33
4m43
4m40
59s
1m0
1m0
1m38
1m43
1m40
Kama ilivyo kwa zbackup, saizi ya hazina ilikuwa 13GB na hata kidogo kidogo, ambayo kwa ujumla inatarajiwa. Nilifurahishwa sana na wakati unaoendelea; inalinganishwa na suluhisho kulingana na librsync, kutoa uwezo mpana zaidi. Pia nilifurahishwa na uwezo wa kuweka vigezo mbalimbali kupitia vigezo vya mazingira, ambayo inatoa faida kubwa sana wakati wa kutumia borgbackup katika hali ya moja kwa moja. Pia nilifurahishwa na mzigo wakati wa kuhifadhi nakala: kuhukumu kwa mzigo wa processor, borgbackup inafanya kazi katika thread 1.
Hakukuwa na hasara fulani wakati wa kuitumia.
mtihani wa kupumzika
Licha ya ukweli kwamba restic ni suluhisho mpya kabisa (watahiniwa 2 wa kwanza walijulikana mnamo 2013 na zaidi), ina sifa nzuri kabisa. Imeandikwa katika Go.
Ikilinganishwa na zbackup, inatoa kwa kuongeza:
- Kuangalia uadilifu wa hazina (pamoja na kuangalia katika sehemu).
- Orodha kubwa ya itifaki zinazoungwa mkono na watoa huduma za kuhifadhi nakala rudufu, na vile vile usaidizi wa rclone - rsync kwa suluhisho za wingu.
- Kulinganisha chelezo 2 na kila mmoja.
- Kuweka hazina kupitia fuse.
Kwa ujumla, orodha ya vipengele ni karibu kabisa na borgbackup, katika baadhi ya maeneo zaidi, kwa wengine chini. Moja ya vipengele ni kwamba hakuna njia ya kuzima usimbaji fiche, na kwa hivyo nakala za chelezo zitasimbwa kila wakati. Wacha tuone kwa vitendo kile kinachoweza kubanwa kutoka kwa programu hii:
Matokeo yalikuwa kama ifuatavyo:
Masaa:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
5m25
5m50
5m38
35s
38s
36s
1m54
2m2
1m58
Matokeo ya utendaji pia yanalinganishwa na suluhu zenye msingi wa rsync na, kwa ujumla, karibu sana na hifadhi rudufu, lakini mzigo wa CPU ni wa juu zaidi (nyuzi nyingi zinazoendesha) na sawtooth.
Uwezekano mkubwa zaidi, programu imepunguzwa na utendaji wa mfumo mdogo wa diski kwenye seva ya kuhifadhi data, kama ilivyokuwa tayari kwa rsync. Saizi ya hazina ilikuwa 13GB, kama vile zbackup au borgbackup, hakukuwa na shida dhahiri wakati wa kutumia suluhisho hili.
Matokeo
Kwa kweli, wagombea wote walipata matokeo sawa, lakini kwa bei tofauti. Borgbackup ilifanya vizuri kuliko yote, restic ilikuwa polepole kidogo, zbackup labda haifai kuanza kutumia,
na ikiwa tayari inatumika, jaribu kuibadilisha kuwa chelezo ya borgup au restic.
Matokeo
Suluhisho la kuahidi zaidi linaonekana kuwa la utulivu, kwa sababu ... ni yeye ambaye ana uwiano bora wa uwezo kwa kasi ya uendeshaji, lakini hebu tusikimbilie hitimisho la jumla kwa sasa.
Borgbackup kimsingi sio mbaya zaidi, lakini zbackup labda inabadilishwa bora. Kweli, zbackup bado inaweza kutumika ili kuhakikisha sheria ya 3-2-1 inafanya kazi. Kwa mfano, kwa kuongeza (lib) vifaa vya chelezo vya msingi vya rsync.
Tangazo
Chelezo Sehemu ya 5: Kujaribu bacula na veeam chelezo kwa linux
Chelezo Sehemu ya 6: Kulinganisha Zana za Hifadhi Nakala
Chelezo Sehemu ya 7: Hitimisho
Imechapishwa na: Pavel Demkovich
Chanzo: mapenzi.com