Dokezo hili linajadili zana za chelezo ambazo huhifadhi nakala kwa kuunda kumbukumbu kwenye seva mbadala.
Miongoni mwa wale wanaokidhi mahitaji ni duplicity (ambayo ina interface nzuri kwa namna ya deja dup) na duplicati.
Zana nyingine ya ajabu sana ya kuhifadhi nakala ni dar, lakini kwa kuwa ina orodha pana sana ya chaguo - mbinu ya majaribio inashughulikia takriban 10% ya uwezo wake - hatuijaribu kama sehemu ya mzunguko wa sasa.
Matokeo yanayotarajiwa
Kwa kuwa watahiniwa wote wawili huunda kumbukumbu kwa njia moja au nyingine, tar ya kawaida inaweza kutumika kama mwongozo.
Zaidi ya hayo, tutatathmini jinsi uhifadhi wa data kwenye seva ya hifadhi unavyoboreshwa kwa kuunda nakala rudufu zilizo na tofauti pekee kati ya nakala kamili na hali ya sasa ya faili, au kati ya kumbukumbu za awali na za sasa (za kuongezeka, kupungua, n.k.) .
Tabia wakati wa kuunda nakala rudufu:
- Idadi ndogo ya faili kwenye seva ya hifadhi ya chelezo (ikilinganishwa na idadi ya nakala za chelezo au saizi ya data katika GB), lakini saizi yao ni kubwa kabisa (makumi hadi mamia ya megabytes).
- Saizi ya hazina itajumuisha mabadiliko tu - hakuna nakala zitahifadhiwa, kwa hivyo saizi ya hazina itakuwa ndogo kuliko na programu inayotegemea rsync.
- Tarajia upakiaji mzito wa CPU unapotumia mbano na/au usimbaji fiche, na uwezekano wa mtandao kuwa wa juu kabisa na upakiaji wa diski ikiwa mchakato wa kuhifadhi kumbukumbu na/au usimbaji unaendelea kwenye seva ya hifadhi mbadala.
Wacha tuendeshe amri ifuatayo kama dhamana ya kumbukumbu:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Matokeo ya utekelezaji yalikuwa kama ifuatavyo:
Wakati wa utekelezaji 3m12s. Inaweza kuonekana kuwa kasi ni mdogo na mfumo mdogo wa diski ya seva ya uhifadhi wa chelezo, kama katika mfano na . Haraka kidogo tu, kwa sababu ... kurekodi huenda kwa faili moja.
Pia, ili kutathmini mgandamizo, wacha tuendeshe chaguo sawa, lakini wezesha ukandamizaji kwenye upande wa seva ya chelezo:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Matokeo ni:
Wakati wa utekelezaji 10m11s. Uwezekano mkubwa zaidi, kizuizi ni compressor ya mtiririko mmoja kwenye mwisho wa kupokea.
Amri sawa, lakini kwa mgandamizo kuhamishiwa kwa seva na data asili ili kupima hypothesis kwamba kizuizi ni compressor moja-threaded.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Ilibadilika kama hii:
Wakati wa utekelezaji ulikuwa 9m37s. Mzigo kwenye msingi mmoja na compressor inaonekana wazi, kwa sababu Kasi ya uhamishaji wa mtandao na mzigo kwenye mfumo mdogo wa diski ya chanzo ni sawa.
Ili kutathmini usimbaji fiche, unaweza kutumia openssl au gpg kwa kuunganisha amri ya ziada openssl au gpg katika bomba. Kwa kumbukumbu kutakuwa na amri kama hii:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Matokeo yalitoka kama hii:
Wakati wa utekelezaji uligeuka kuwa 10m30, kwa kuwa michakato 2 ilikuwa ikiendeshwa kwa upande wa kupokea - kizuizi ni compressor yenye nyuzi moja, pamoja na kichwa kidogo cha usimbuaji.
UPS: Kwa ombi la bliznezz ninaongeza vipimo na nguruwe. Ikiwa unatumia compressor tu, itachukua 6m30s, ikiwa pia utaongeza usimbuaji, itakuwa karibu 7m. Kuchovya kwenye grafu ya chini ni kashe ya diski ambayo haijasafishwa:
Jaribio la kurudia
Duplicity ni programu ya python ya chelezo kwa kuunda kumbukumbu zilizosimbwa katika umbizo la tar.
Kwa kumbukumbu zinazoongezeka, librsync hutumiwa, kwa hivyo unaweza kutarajia tabia iliyoelezewa ndani .
Hifadhi rudufu zinaweza kusimbwa na kusainiwa kwa kutumia gnupg, ambayo ni muhimu unapotumia watoa huduma tofauti kuhifadhi nakala (s3, backblaze, gdrive, n.k.)
Wacha tuone matokeo ni nini:
Haya ndio matokeo tuliyopata tulipokuwa tukiendesha bila usimbaji fiche
nyara
Muda wa utekelezaji wa kila jaribio:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
16m33
17m20
16m30
8m29
9m3
8m45
5m21
6m04
5m53
Na haya ndio matokeo wakati usimbaji fiche wa gnupg umewezeshwa, na saizi kuu ya biti 2048:
Muda wa kufanya kazi kwenye data sawa, na usimbaji fiche:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
17m22
17m32
17m28
8m52
9m13
9m3
5m48
5m40
5m30
Ukubwa wa kuzuia ulionyeshwa - megabytes 512, ambayo inaonekana wazi katika grafu; Mzigo wa processor kwa kweli ulibaki 50%, ambayo inamaanisha kuwa programu haitumii zaidi ya msingi mmoja wa kichakataji.
Kanuni ya uendeshaji wa programu pia inaonekana wazi kabisa: walichukua kipande cha data, wakaikandamiza, na kuituma kwa seva ya hifadhi ya chelezo, ambayo inaweza kuwa polepole sana.
Kipengele kingine ni wakati unaotabirika wa uendeshaji wa programu, ambayo inategemea tu ukubwa wa data iliyobadilishwa.
Uwezeshaji wa usimbaji fiche haukuongeza sana muda wa uendeshaji wa programu, lakini uliongeza mzigo wa kichakataji kwa takriban 10%, ambayo inaweza kuwa bonasi nzuri kabisa.
Kwa bahati mbaya, programu hii haikuweza kutambua kwa usahihi hali hiyo kwa kubadilisha jina la saraka, na saizi iliyosababishwa ya hazina iligeuka kuwa sawa na saizi ya mabadiliko (yaani, 18GB zote), lakini uwezo wa kutumia seva isiyoaminika kwa chelezo wazi. inashughulikia tabia hii.
Jaribio la kurudia
Programu hii imeandikwa katika C # na huendesha kwa kutumia seti ya maktaba kutoka Mono. Kuna GUI na toleo la CLI.
Orodha ya takriban ya vipengele vikuu ni sawa na uduara, ikiwa ni pamoja na watoa huduma mbalimbali za hifadhi, hata hivyo, tofauti na marudio, vipengele vingi vinapatikana bila zana za tatu. Ikiwa hii ni nyongeza au minus inategemea kesi maalum, lakini kwa wanaoanza, kuna uwezekano rahisi kuwa na orodha ya huduma zote mbele yao mara moja, badala ya kulazimika kusakinisha vifurushi vya ziada vya chatu, kama ilivyo. kesi na duplicity.
Nuance nyingine ndogo - programu inaandika kikamilifu hifadhidata ya sqlite ya ndani kwa niaba ya mtumiaji ambaye anaanza chelezo, kwa hivyo unahitaji kuhakikisha kuwa hifadhidata inayohitajika imeainishwa kwa usahihi kila wakati mchakato unapoanza kwa kutumia cli. Unapofanya kazi kupitia GUI au WEBGUI, maelezo yatafichwa kutoka kwa mtumiaji.
Wacha tuone ni viashiria gani suluhisho hili linaweza kutoa:
Ukizima usimbaji fiche (na WEBGUI haipendekezi kufanya hivi), matokeo ni kama ifuatavyo.
Masaa:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
20m43
20m13
20m28
5m21
5m40
5m35
7m36
7m54
7m49
Kwa usimbaji fiche kuwezeshwa, kwa kutumia aes, inaonekana kama hii:
Masaa:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
29m9
30m1
29m54
5m29
6m2
5m54
8m44
9m12
9m1
Na ikiwa unatumia programu ya nje ya gnupg, matokeo yafuatayo yanatoka:
Uzinduzi 1
Uzinduzi 2
Uzinduzi 3
26m6
26m35
26m17
5m20
5m48
5m40
8m12
8m42
8m15
Kama unaweza kuona, programu inaweza kufanya kazi katika nyuzi kadhaa, lakini hii haifanyi kuwa suluhisho lenye tija zaidi, na ikiwa unalinganisha kazi ya usimbuaji, inazindua programu ya nje.
iligeuka kuwa haraka kuliko kutumia maktaba kutoka kwa seti ya Mono. Hii inaweza kuwa kutokana na ukweli kwamba programu ya nje imeboreshwa zaidi.
Jambo lingine nzuri lilikuwa ukweli kwamba saizi ya hazina inachukua sawasawa na data halisi iliyobadilishwa, i.e. duplicati iligundua jina la saraka na kushughulikia hali hii kwa usahihi. Hii inaweza kuonekana wakati wa kufanya mtihani wa pili.
Kwa ujumla, maoni chanya ya programu, ikiwa ni pamoja na kuwa rafiki kwa wanaoanza.
Matokeo
Wagombea wote wawili walifanya kazi polepole, lakini kwa ujumla, ikilinganishwa na lami ya kawaida, kuna maendeleo, angalau na nakala mbili. Bei ya maendeleo hayo pia ni wazi - mzigo unaoonekana
mchakataji. Kwa ujumla, hakuna tofauti maalum katika kutabiri matokeo.
Matokeo
Ikiwa hauitaji kukimbilia mahali popote, na pia kuwa na processor ya vipuri, suluhisho lolote linalozingatiwa litafanya, kwa hali yoyote, kazi nyingi zimefanywa ambazo hazipaswi kurudiwa kwa kuandika maandishi ya karatasi juu ya lami. . Uwepo wa usimbaji fiche ni sifa muhimu sana ikiwa seva ya kuhifadhi nakala za chelezo haiwezi kuaminiwa kikamilifu.
Ikilinganishwa na suluhisho kulingana - utendaji unaweza kuwa mbaya mara kadhaa, licha ya ukweli kwamba katika fomu yake safi tar ilifanya kazi 20-30% kwa kasi zaidi kuliko rsync.
Kuna akiba kwa saizi ya hazina, lakini tu na nakala mbili.
Tangazo
Hifadhi Nakala Sehemu ya 3: Kagua na ujaribu uwili, nakala, nakala ya deja
Chelezo Sehemu ya 4: Kukagua na kujaribu zbackup, restic, borgbackup
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