Þessi grein mun bera saman öryggisafritunarverkfæri, en fyrst ættir þú að komast að því hversu fljótt og vel þau takast á við að endurheimta gögn úr afritum.
Til að auðvelda samanburð, munum við íhuga að endurheimta úr fullu afriti, sérstaklega þar sem allir umsækjendur styðja þennan aðgerðarmáta. Til einföldunar eru tölurnar nú þegar meðaltal (reiknings meðaltal nokkurra hlaupa). Niðurstöðurnar verða teknar saman í töflu sem mun einnig innihalda upplýsingar um möguleikana: tilvist vefviðmóts, auðveld uppsetning og notkun, getu til að gera sjálfvirkni, tilvist ýmissa viðbótareiginleika (til dæmis að athuga gagnaheilleika) , o.s.frv. Gröfin munu sýna álagið á þjóninum þar sem gögnin verða notuð (ekki þjóninn til að geyma öryggisafrit).
Bati gagna
rsync og tar verða notuð sem viðmiðunarpunktur síðan einföld forskrift til að búa til öryggisafrit.
Rsync tókst á við prófunargögnin á 4 mínútum og 28 sekúndum, sem sýnir
þvílíkt álag
Endurheimtunarferlið náði takmörkun á diskundirkerfi öryggisafritunargeymsluþjónsins (sagtönn graf). Þú getur líka greinilega séð hleðslu á einum kjarna án vandræða (lágt iowait og softirq - engin vandamál með diskinn og netið, í sömu röð). Þar sem hin tvö forritin, nefnilega rdiff-backup og rsnapshot, eru byggð á rsync og bjóða einnig upp á venjulegt rsync sem endurheimtartæki, munu þau hafa um það bil sama hleðslusnið og endurheimtartíma öryggisafrits.
Tar gerði það aðeins hraðar
2 mínútur og 43 sekúndur:
Heildarálag kerfisins var að meðaltali hærra um 20% vegna aukinnar mýktar - kostnaður við rekstur netundirkerfisins jókst.
Ef skjalasafnið er þjappað frekar saman eykst batatíminn í 3 mínútur og 19 sekúndur.
með svona álagi á aðalþjóninn (upptaka á hliðinni á aðalþjóninum):
Þjöppunarferlið tekur upp báða örgjörvakjarna vegna þess að það eru tvö ferli í gangi. Almennt séð er þetta væntanleg niðurstaða. Einnig fékkst sambærileg niðurstaða (3 mínútur og 20 sekúndur) þegar gzip var keyrt á netþjóninum með öryggisafritum; hleðslusniðið á aðalþjóninum var mjög svipað því að keyra tar án gzip þjöppunnar (sjá fyrra graf).
В rdiff-afrit þú getur samstillt síðasta öryggisafrit sem þú tókst með því að nota venjulegan rsync (niðurstöðurnar verða svipaðar), en enn þarf að endurheimta eldri afrit með því að nota rdiff-afritunarforritið, sem kláraði endurheimtina á 17 mínútum og 17 sekúndum, sem sýnir
þetta álag:
Kannski var þessu ætlað, að minnsta kosti til að takmarka hraða höfunda . Ferlið við að endurheimta öryggisafrit sjálft tekur aðeins minna en helming af einum kjarna, með hlutfallslega sambærilegum árangri (þ.e. 2-5 sinnum hægari) yfir disk og net með rsync.
Rsnapshot Fyrir bata bendir það til þess að nota venjulegan rsync, svo niðurstöður þess verða svipaðar. Almennt séð var þetta svona.
Burp Ég kláraði það verkefni að endurheimta öryggisafrit á 7 mínútum og 2 sekúndum með
með þessu álagi:
Það virkaði nokkuð fljótt og er að minnsta kosti miklu þægilegra en hreint rsync: þú þarft ekki að muna neina fána, einfalt og leiðandi cli viðmót, innbyggður stuðningur fyrir mörg eintök - þó það sé tvisvar sinnum hægara. Ef þú þarft að endurheimta gögn úr síðasta öryggisafriti sem þú tókst, geturðu notað rsync, með nokkrum fyrirvörum.
Forritið sýndi nokkurn veginn sama hraða og álag Backupc þegar kveikt er á rsync flutningsham, setja öryggisafritið fyrir
7 mínútur og 42 sekúndur:
En í gagnaflutningsham tókst BackupPC við tjöru hægar: á 12 mínútum og 15 sekúndum var álag á örgjörva almennt minna
einu og hálfu sinni:
Duplicity án dulkóðunar sýndi aðeins betri árangur og endurheimti öryggisafrit á 10 mínútum og 58 sekúndum. Ef þú virkjar dulkóðun með gpg eykst batatíminn í 15 mínútur og 3 sekúndur. Einnig, þegar þú býrð til geymsla til að geyma afrit, geturðu tilgreint stærð skjalasafnsins sem verður notuð þegar gagnastraumnum er skipt upp. Almennt séð er ekki mikill munur á hefðbundnum harða diskum, einnig vegna einþráðs rekstrarhamsins. Það getur birst í mismunandi blokkastærðum þegar blendingsgeymsla er notuð. Álagið á aðalþjóninn við endurheimt var sem hér segir:
engin dulkóðun
með dulkóðun
Afrit sýndi sambærilegt batahlutfall og kláraði það á 13 mínútum og 45 sekúndum. Það tók um það bil 5 mínútur í viðbót að athuga réttmæti endurheimtu gagna (samtals um 19 mínútur). Álagið var
frekar hátt:
Þegar aes dulkóðun var virkjuð innbyrðis var batatíminn 21 mínútur og 40 sekúndur, með CPU nýtingu í hámarki (báðir kjarna!) meðan á bata stóð; Þegar gögn voru skoðuð var aðeins einn þráður virkur og tók einn örgjörvakjarna. Athugun á gögnum eftir endurheimt tók sömu 5 mínútur (alls tæpar 27 mínútur).
Niðurstaðan
duplicati var aðeins hraðari með endurheimt þegar ytra gpg forritið var notað fyrir dulkóðun, en almennt er munurinn frá fyrri stillingu í lágmarki. Notkunartíminn var 16 mínútur og 30 sekúndur, með sannprófun gagna á 6 mínútum. Álagið var
slík:
AMANDA, með tjöru, kláraði það á 2 mínútum og 49 sekúndum, sem í grundvallaratriðum er mjög nálægt venjulegri tjöru. Álag á kerfið í grundvallaratriðum
það sama:
Þegar öryggisafrit er endurheimt með því að nota zbackup eftirfarandi niðurstöður fengust:
dulkóðun, lzma þjöppun
Sýningartími 11 mínútur og 8 sekúndur
AES dulkóðun, lzma þjöppun
Vinnutími 14 mínútur
AES dulkóðun, lzo þjöppun
Sýningartími 6 mínútur, 19 sekúndur
Á heildina litið, ekki slæmt. Það veltur allt á hraða örgjörvans á öryggisafritunarþjóninum, sem sést vel af keyrslutíma forritsins með mismunandi þjöppum. Á öryggisafritunarþjóninum var venjuleg tjara sett í gang, þannig að ef þú berð hana saman við hana er batinn 3 sinnum hægari. Það gæti verið þess virði að athuga aðgerðina í fjölþráðum ham, með fleiri en tveimur þráðum.
BorgBackup í ódulkóðuðu stillingu var það aðeins hægara en tjara, á 2 mínútum og 45 sekúndum, hins vegar, ólíkt tjöru, varð mögulegt að afrita geymsluna. Álagið reyndist vera
eftirfarandi:
Ef þú virkjar dulkóðun sem byggir á blake er endurheimtarhraði öryggisafrits aðeins hægari. Endurheimtartími í þessari stillingu er 3 mínútur og 19 sekúndur og álagið er farið
svona:
AES dulkóðun er aðeins hægari, batatími er 3 mínútur 23 sekúndur, álagið er sérstaklega
hefur ekki breyst:
Þar sem Borg getur unnið í fjölþráðum ham er álag á örgjörva hámark og þegar viðbótaraðgerðir eru virkjaðar eykst notkunartíminn einfaldlega. Svo virðist sem það er þess virði að kanna multithreading á svipaðan hátt og zbackup.
Restic tókst aðeins hægar á batanum, aðgerðatíminn var 4 mínútur 28 sekúndur. Álagið leit út eins og
svona:
Svo virðist sem bataferlið virkar í nokkrum þráðum, en skilvirknin er ekki eins mikil og BorgBackup, en sambærileg í tíma og venjulegt rsync.
Með urBackup Það var hægt að endurheimta gögnin á 8 mínútum og 19 sekúndum, álagið var
slík:
Álagið er samt ekki mjög mikið, jafnvel lægra en á tjörunni. Sums staðar eru sprungur, þó ekki meira en álag eins kjarna.
Val og rökstuðningur viðmiða til samanburðar
Eins og fram kemur í einni af fyrri greinum þarf varakerfið að uppfylla eftirfarandi skilyrði:
- Auðvelt í notkun
- Fjölhæfni
- Stöðugleiki
- Hraði
Það er þess virði að íhuga hvert atriði fyrir sig nánar.
Auðvelt í rekstri
Það er best þegar það er einn hnappur „Gerðu allt vel,“ en ef þú ferð aftur í alvöru forrit er það þægilegasta sem er einhver kunnugleg og staðlað rekstrarregla.
Flestir notendur munu líklegast hafa það betra ef þeir þurfa ekki að muna fullt af lyklum fyrir cli, stilla fullt af mismunandi, oft óskýrum valkostum í gegnum vef eða tui, eða setja upp tilkynningar um misheppnaða aðgerð. Þetta felur einnig í sér möguleika á að „passa“ öryggisafritunarlausn inn í núverandi innviði, svo og sjálfvirkni í afritunarferlinu. Það er líka möguleiki á uppsetningu með því að nota pakkastjóra, eða í einni eða tveimur skipunum eins og "hala niður og taka upp". curl ссылка | sudo bash - flókin aðferð, þar sem þú þarft að athuga hvað kemur í gegnum hlekkinn.
Til dæmis, af þeim umsækjendum sem teknir eru til greina, er einföld lausn burp, rdiff-backup og restic, sem eru með minnislykla fyrir mismunandi vinnuhami. Örlítið flóknari eru borg og tvískinnungur. Erfiðast var AMANDA. Restin er einhvers staðar í miðjunni hvað varðar vellíðan í notkun. Í öllum tilvikum, ef þú þarft meira en 30 sekúndur til að lesa notendahandbókina, eða þú þarft að fara á Google eða aðra leitarvél, og einnig fletta í gegnum langt blað af hjálp, er ákvörðunin erfið, með einum eða öðrum hætti.
Sumir umsækjenda sem eru taldir geta sent skilaboð sjálfkrafa með tölvupósti á meðan aðrir treysta á stilltar viðvaranir í kerfinu. Þar að auki hafa oftast flóknar lausnir ekki alveg augljósar viðvörunarstillingar. Í öllum tilvikum, ef varaforritið framleiðir skilakóða sem ekki er núll, sem verður rétt skilinn af kerfisþjónustunni fyrir reglubundin verkefni (skilaboð verða send til kerfisstjóra eða beint til eftirlits) - er staðan einföld. En ef ekki er hægt að stilla öryggisafritunarkerfið, sem keyrir ekki á afritunarþjóni, er augljós leið til að segja um vandamálið að flókið er nú þegar of mikið. Í öllu falli er það slæm venja að gefa út viðvaranir og önnur skilaboð eingöngu til vefviðmótsins eða skrárinnar, þar sem oftast er hunsað.
Eins og fyrir sjálfvirkni, einfalt forrit getur lesið umhverfisbreytur sem stilla rekstrarham þess, eða það hefur þróað cli sem getur algjörlega afritað hegðun þegar unnið er í gegnum vefviðmót, til dæmis. Þetta felur einnig í sér möguleika á samfelldum rekstri, framboð á stækkunarmöguleikum o.fl.
Fjölhæfni
Að hluta til endurómur fyrri undirkafla varðandi sjálfvirkni, það ætti ekki að vera sérstakt vandamál að „passa“ öryggisafritunarferlið inn í núverandi innviði.
Það er athyglisvert að notkun á óstöðluðum höfnum (ja, nema fyrir vefviðmótið) fyrir vinnu, innleiðing dulkóðunar á óhefðbundinn hátt, gagnaskipti með óstöðluðum samskiptareglum eru merki um óstöðluð -alhliða lausn. Að mestu leyti hafa allir frambjóðendur þá á einn eða annan hátt af þeirri augljósu ástæðu: einfaldleiki og fjölhæfni fara yfirleitt ekki saman. Sem undantekning - burp, það eru aðrir.
Sem merki - hæfileikinn til að vinna með venjulegum ssh.
Vinnuhraði
Umdeildasta og umdeildasta atriðið. Annars vegar settum við ferlið af stað, það virkaði eins hratt og hægt var og truflaði ekki helstu verkefnin. Á hinn bóginn er aukning í umferð og álagi örgjörva á afritunartímabilinu. Það er líka athyglisvert að fljótlegustu forritin til að búa til afrit eru yfirleitt léleg hvað varðar aðgerðir sem eru mikilvægar fyrir notendur. Aftur: ef til þess að fá eina óheppilega textaskrá upp á nokkra tugi bæta að stærð með lykilorði, og vegna þess kostar öll þjónustan (já, já, mér skilst að afritunarferlinu sé oftast ekki um að kenna hér), og þú þarft að lesa allar skrárnar í geymslunni aftur í röð eða stækka allt skjalasafnið - öryggisafritunarkerfið er aldrei hratt. Annar punktur sem oft verður ásteytingarsteinn er hraði afrits úr skjalasafni. Það er augljós kostur hér fyrir þá sem geta einfaldlega afritað eða flutt skrár á viðkomandi stað án mikillar meðhöndlunar (t.d. rsync), en oftast þarf að leysa vandamálið á skipulagslegan hátt, reynslulega: með því að mæla endurheimtartíma öryggisafrits. og upplýsa notendur um þetta opinskátt.
Stöðugleiki
Það ætti að skilja þetta þannig: annars vegar verður að vera hægt að dreifa öryggisafritinu aftur á einhvern hátt, hins vegar verður það að vera ónæmt fyrir ýmsum vandamálum: truflun á neti, bilun á diski, eyðingu hluta af geymsla.
Samanburður á öryggisafritunarverkfærum
Tími til að búa til afrit
Afritaðu batatíma
Auðveld uppsetning
Auðveld uppsetning
Einföld notkun
Einföld sjálfvirkni
Þarftu viðskiptavinaþjón?
Athugun á heilleika geymslunnar
Mismunandi eintök
Vinna í gegnum rör
Fjölhæfni
Sjálfstæði
Geymsla gagnsæi
Dulkóðun
Þjöppun
Tvíföldun
Vefviðmót
Fyllist til skýsins
Windows stuðningur
Skora
Rsync
4m15s
4m28s
já
ekki
ekki
ekki
já
ekki
ekki
já
ekki
já
já
ekki
ekki
ekki
ekki
ekki
já
6
Tar
hreint
3m12s
2m43s
já
ekki
ekki
ekki
ekki
ekki
já
já
ekki
já
ekki
ekki
ekki
ekki
ekki
ekki
já
8,5
gzip
9m37s
3m19s
já
Rdiff-afrit
16m26s
17m17s
já
já
já
já
já
ekki
já
ekki
já
ekki
já
ekki
já
já
já
ekki
já
11
Rsnapshot
4m19s
4m28s
já
já
já
já
ekki
ekki
já
ekki
já
ekki
já
ekki
ekki
já
já
ekki
já
12,5
Burp
11m9s
7m2s
já
ekki
já
já
já
já
já
ekki
já
já
ekki
ekki
já
ekki
já
ekki
já
10,5
Duplicity
engin dulkóðun
16m48s
10m58s
já
já
ekki
já
ekki
já
já
ekki
ekki
já
ekki
já
já
ekki
já
ekki
já
11
gpg
17m27s
15m3s
Afrit
engin dulkóðun
20m28s
13m45s
ekki
já
ekki
ekki
ekki
já
já
ekki
ekki
já
ekki
já
já
já
já
já
já
11
AES
29m41s
21m40s
gpg
26m19s
16m30s
zbackup
engin dulkóðun
40m3s
11m8s
já
já
ekki
ekki
ekki
já
já
já
ekki
já
ekki
já
já
já
ekki
ekki
ekki
10
AES
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
engin dulkóðun
4m7s
2m45s
já
já
já
já
já
já
já
já
já
já
ekki
já
já
já
já
ekki
já
16
AES
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
já
já
já
já
ekki
já
já
já
já
já
ekki
já
ekki
já
ekki
já
já
15,5
urBackup
8m21s
8m19s
já
já
já
ekki
já
ekki
já
ekki
já
já
ekki
já
já
já
já
ekki
já
12
amanda
9m3s
2m49s
já
ekki
ekki
já
já
já
já
ekki
já
já
já
já
já
ekki
já
já
já
13
Backupc
rsync
12m22s
7m42s
já
ekki
já
já
já
já
já
ekki
já
ekki
ekki
já
já
ekki
já
ekki
já
10,5
tar
12m34s
12m15s
Goðsögn um borð:
- Grænt, notkunartími innan við fimm mínútur, eða svarið „Já“ (nema dálkinn „Þarftu biðlaraþjón?“), 1 stig
- Gulur, notkunartími fimm til tíu mínútur, 0.5 stig
- Rauður, vinnutíminn er meira en tíu mínútur, eða svarið er „Nei“ (nema dálkinn „Þarftu viðskiptavinaþjón?“), 0 stig
Samkvæmt töflunni hér að ofan er einfaldasta, fljótlegasta og um leið þægilega og öfluga öryggisafritunartækið BorgBackup. Restic varð í öðru sæti, hinir af þeim sem komu til greina voru um það bil jafnt með eitt eða tvö stig í lokin.
Ég þakka öllum sem lásu seríuna til enda, ég býð ykkur að ræða valkostina og bjóða upp á ykkar eigin, ef einhver er. Eftir því sem líður á umræðuna gæti taflan verið stækkuð.
Afrakstur seríunnar verður lokagreinin þar sem reynt verður að þróa tilvalið, fljótlegt og viðráðanlegt öryggisafritunarverkfæri sem gerir þér kleift að dreifa afriti til baka á sem skemmstum tíma og á sama tíma vera þægilegt og auðvelt. að stilla og viðhalda.
Tilkynning
Afritunarhluti 6: Samanburður á öryggisafritunarverkfærum
Afritunarhluti 7: Ályktanir
Heimild: www.habr.com