Hierdie artikel sal rugsteunnutsmiddels vergelyk, maar eers moet u uitvind hoe vinnig en goed hulle die herstel van data vanaf rugsteun hanteer.
Vir gemak van vergelyking, sal ons dit oorweeg om te herstel vanaf 'n volledige rugsteun, veral aangesien alle kandidate hierdie werkswyse ondersteun. Vir eenvoud is die getalle reeds gemiddeld (die rekenkundige gemiddelde van verskeie lopies). Die resultate sal in 'n tabel saamgevat word, wat ook inligting oor die vermoëns sal bevat: die teenwoordigheid van 'n webkoppelvlak, gemak van opstelling en werking, die vermoë om te outomatiseer, die teenwoordigheid van verskeie bykomende kenmerke (byvoorbeeld die kontrolering van data-integriteit) , ens. Die grafieke sal die las op die bediener wys waar die data gebruik gaan word (nie die bediener vir die stoor van rugsteunkopieë nie).
Data herstel
rsync en tar sal sedertdien as 'n verwysingspunt gebruik word eenvoudige skrifte vir die maak van rugsteunkopieë.
rsync het die toetsdatastel in 4 minute en 28 sekondes hanteer, wat wys
so 'n vrag
Die herstelproses het 'n beperking van die skyfsubstelsel van die rugsteunbergingbediener (saagtandgrafieke) getref. Jy kan ook duidelik die laai van een kern sien sonder enige probleme (lae iowait en softirq - geen probleme met die skyf en netwerk, onderskeidelik). Aangesien die ander twee programme, naamlik rdiff-rugsteun en rsnapshot, op rsync gebaseer is en ook gereelde rsync as 'n herstelhulpmiddel bied, sal hulle ongeveer dieselfde laaiprofiel en rugsteunhersteltyd hê.
Tar het dit 'n bietjie vinniger gedoen
2 minute en 43 sekondes:
Die totale stelsellading was gemiddeld 20% hoër as gevolg van die verhoogde softirq - die oorhoofse koste tydens die bedryf van die netwerksubstelsel het toegeneem.
As die argief verder saamgepers word, neem die hersteltyd toe na 3 minute 19 sekondes.
met so 'n las op die hoofbediener (uitpak aan die kant van die hoofbediener):
Die dekompressieproses neem beide verwerkerkerne op omdat daar twee prosesse loop. Oor die algemeen is dit die verwagte resultaat. Ook is 'n vergelykbare resultaat (3 minute en 20 sekondes) verkry wanneer gzip aan die bedienerkant met rugsteun uitgevoer word; die lasprofiel op die hoofbediener was baie soortgelyk aan die hardloop van teer sonder die gzip-kompressor (sien vorige grafiek).
В rdiff-rugsteun jy kan die laaste rugsteun wat jy gemaak het met gewone rsync sinchroniseer (die resultate sal soortgelyk wees), maar ouer rugsteun moet steeds herstel word deur die rdiff-rugsteunprogram te gebruik, wat die herstel in 17 minute en 17 sekondes voltooi het, wat wys
hierdie vrag:
Miskien was dit bedoel, ten minste om die spoed van die skrywers te beperk . Die proses om 'n rugsteunkopie self te herstel, neem 'n bietjie minder as die helfte van een kern, met proporsioneel vergelykbare werkverrigting (d.w.s. 2-5 keer stadiger) oor skyf en netwerk met rsync.
Rsnapshot Vir herstel, stel dit voor om gereelde rsync te gebruik, sodat die resultate daarvan soortgelyk sal wees. Oor die algemeen is dit hoe dit uitgedraai het.
boer Ek het die taak voltooi om 'n rugsteun in 7 minute en 2 sekondes te herstel met
met hierdie vrag:
Dit het redelik vinnig gewerk, en is ten minste baie geriefliker as suiwer rsync: jy hoef geen vlae te onthou nie, 'n eenvoudige en intuïtiewe cli-koppelvlak, ingeboude ondersteuning vir veelvuldige kopieë - hoewel dit twee keer stadiger is. As jy data van die laaste rugsteun wat jy gemaak het moet herstel, kan jy rsync gebruik, met 'n paar voorbehoude.
Die program het ongeveer dieselfde spoed en las getoon Rugsteun -PC wanneer rsync-oordragmodus geaktiveer word, ontplooi die rugsteun vir
7 minute en 42 sekondes:
Maar in data-oordragmodus het BackupPC teer stadiger hanteer: in 12 minute en 15 sekondes was die verwerkerlading oor die algemeen laer
een en 'n half keer:
Valsheid sonder enkripsie het effens beter resultate getoon en 'n rugsteun in 10 minute en 58 sekondes herstel. As jy enkripsie met gpg aktiveer, verhoog die hersteltyd na 15 minute en 3 sekondes. Ook, wanneer u 'n bewaarplek vir die stoor van kopieë skep, kan u die argiefgrootte spesifiseer wat gebruik sal word wanneer die inkomende datastroom verdeel word. Oor die algemeen, op konvensionele hardeskywe, ook as gevolg van die enkeldraad-bedryfsmodus, is daar nie veel verskil nie. Dit kan by verskillende blokgroottes verskyn wanneer basterberging gebruik word. Die las op die hoofbediener tydens herstel was soos volg:
geen enkripsie nie
met enkripsie
Dupliseer het 'n vergelykbare hersteltempo getoon en dit in 13 minute en 45 sekondes voltooi. Dit het nog sowat 5 minute geneem om die korrektheid van die herstelde data na te gaan ('n totaal van ongeveer 19 minute). Die vrag was
redelik hoog:
Wanneer aes-enkripsie intern geaktiveer is, was die hersteltyd 21 minute 40 sekondes, met SVE-benutting op sy maksimum (beide kerne!) tydens herstel; By die nagaan van data was slegs een draad aktief, wat een verwerkerkern beslaan. Die kontrolering van die data na herstel het dieselfde 5 minute geneem (byna 27 minute in totaal).
Gevolg
duplicati was 'n bietjie vinniger met herstel wanneer die eksterne gpg-program vir enkripsie gebruik is, maar oor die algemeen is die verskille van die vorige modus minimaal. Die bedryfstyd was 16 minute 30 sekondes, met dataverifikasie in 6 minute. Die vrag was
is soos volg:
AMANDA, met teer gebruik, het dit in 2 minute 49 sekondes voltooi, wat in beginsel baie naby aan gewone teer is. Laai in beginsel op die stelsel
dieselfde:
Wanneer die herstel van 'n rugsteun gebruik zbackup die volgende resultate is verkry:
enkripsie, lzma-kompressie
Looptyd 11 minute en 8 sekondes
AES-kodering, lzma-kompressie
Bedryfstyd 14 minute
AES-kodering, lzo-kompressie
Looptyd 6 minute, 19 sekondes
Oor die algemeen nie sleg nie. Dit hang alles af van die spoed van die verwerker op die rugsteunbediener, wat duidelik gesien kan word uit die looptyd van die program met verskillende kompressors. Aan die rugsteunbedienerkant is 'n gewone teer geloods, so as jy dit daarmee vergelyk, is die herstel 3 keer stadiger. Dit kan die moeite werd wees om die werking in multi-threaded-modus na te gaan, met meer as twee drade.
BorgBackup in ongeënkripteerde modus was dit 'n bietjie stadiger as teer, in 2 minute 45 sekondes, maar anders as teer, het dit moontlik geword om die bewaarplek te dedupliseer. Die vrag het geblyk te wees
die volgende:
As jy blake-gebaseerde enkripsie aktiveer, is die rugsteunherstelspoed effens stadiger. Hersteltyd in hierdie modus is 3 minute 19 sekondes, en die vrag is weg
soos hierdie:
AES-kodering is effens stadiger, herstel tyd is 3 minute 23 sekondes, die las is veral
het nie verander nie:
Aangesien Borg in multi-threaded-modus kan werk, is die verwerkerlading maksimum, en wanneer bykomende funksies geaktiveer word, neem die bedryfstyd eenvoudig toe. Dit is blykbaar die moeite werd om multithreading op 'n soortgelyke manier as zbackup te verken.
Plaatlik het die herstel 'n bietjie stadiger hanteer, die operasietyd was 4 minute 28 sekondes. Die vrag het gelyk
soos volg:
Blykbaar werk die herstelproses in verskeie drade, maar die doeltreffendheid is nie so hoog soos dié van BorgBackup nie, maar in tyd vergelykbaar met gewone rsync.
Met urBackup Dit was moontlik om die data in 8 minute en 19 sekondes te herstel, die las was
is soos volg:
Die vrag is steeds nie baie hoog nie, selfs laer as dié van teer. Op sommige plekke is daar bars, maar nie meer as die las van een kern nie.
Seleksie en motivering van kriteria vir vergelyking
Soos in een van die vorige artikels genoem, moet die rugsteunstelsel aan die volgende kriteria voldoen:
- Gemak van gebruik
- veelsydigheid
- stabiliteit
- spoed
Dit is die moeite werd om elke punt afsonderlik in meer besonderhede te oorweeg.
Gemak van operasie
Dit is die beste as daar een knoppie is "Doen alles goed," maar as jy terugkeer na regte programme, sal die mees gerieflike ding 'n bekende en standaard bedryfsbeginsel wees.
Die meeste gebruikers sal heel waarskynlik beter daaraan toe wees as hulle nie 'n klomp sleutels vir cli hoef te onthou, 'n klomp verskillende, dikwels obskure opsies via web of tui te konfigureer, of kennisgewings oor onsuksesvolle bewerking op te stel nie. Dit sluit ook die vermoë in om 'n rugsteunoplossing maklik in die bestaande infrastruktuur te "pas", asook outomatisering van die rugsteunproses. Daar is ook die moontlikheid om te installeer met behulp van 'n pakketbestuurder, of in een of twee opdragte soos "aflaai en uitpak". curl ссылка | sudo bash - 'n komplekse metode, aangesien u moet kyk wat via die skakel aankom.
Byvoorbeeld, van die kandidate wat oorweeg is, is 'n eenvoudige oplossing burp, rdiff-rugsteun en restic, wat mnemoniese sleutels vir verskillende bedryfsmodusse het. Effens meer kompleks is borg en dubbelsinnigheid. Die moeilikste was AMANDA. Die res is iewers in die middel wat gebruiksgemak betref. In elk geval, as jy meer as 30 sekondes nodig het om die gebruikershandleiding te lees, of jy moet na Google of 'n ander soekenjin gaan, en ook deur 'n lang bladsy hulp blaai, is die besluit moeilik, op een of ander manier.
Sommige van die kandidate wat oorweeg word, kan outomaties 'n boodskap per e-pos stuur, terwyl ander staatmaak op gekonfigureerde waarskuwings in die stelsel. Boonop het komplekse oplossings meestal nie heeltemal duidelike waarskuwingsinstellings nie. In elk geval, as die rugsteunprogram 'n nie-nul-terugsendingkode produseer, wat korrek deur die stelseldiens vir periodieke take verstaan sal word ('n boodskap sal aan die stelseladministrateur of direk na monitering gestuur word) - die situasie is eenvoudig. Maar as die rugsteunstelsel, wat nie op 'n rugsteunbediener loop nie, nie gekonfigureer kan word nie, is die voor die hand liggende manier om oor die probleem te sê dat die kompleksiteit reeds buitensporig is. In elk geval, die uitreik van waarskuwings en ander boodskappe slegs aan die webkoppelvlak of aan die logboek is 'n slegte praktyk, aangesien dit meestal geïgnoreer sal word.
Wat outomatisering betref, kan 'n eenvoudige program omgewingsveranderlikes lees wat sy bedryfsmodus stel, of dit het 'n ontwikkelde cli wat die gedrag heeltemal kan dupliseer wanneer byvoorbeeld deur 'n webkoppelvlak gewerk word. Dit sluit ook die moontlikheid van deurlopende bedryf, die beskikbaarheid van uitbreidingsgeleenthede, ens.
veelsydigheid
Gedeeltelik weerspieël die vorige onderafdeling rakende outomatisering, behoort dit nie 'n besondere probleem te wees om die rugsteunproses in die bestaande infrastruktuur te "pas" nie.
Dit is opmerklik dat die gebruik van nie-standaardpoorte (wel, behalwe vir die webkoppelvlak) vir werk, die implementering van enkripsie op 'n nie-standaard manier, die uitruil van data met 'n nie-standaard protokol tekens is van 'n nie-standaard -universele oplossing. Vir die grootste deel het alle kandidate dit op een of ander manier om die ooglopende rede: eenvoud en veelsydigheid gaan gewoonlik nie saam nie. As 'n uitsondering - burp, daar is ander.
As 'n teken - die vermoë om te werk met gewone ssh.
Werksnelheid
Die mees omstrede en kontroversiële punt. Aan die een kant het ons die proses van stapel gestuur, dit het so vinnig as moontlik gewerk en nie met die hooftake ingemeng nie. Aan die ander kant is daar 'n toename in verkeer en verwerkerlading gedurende die rugsteunperiode. Dit is ook opmerklik dat die vinnigste programme om kopieë te maak gewoonlik die swakste is in terme van funksies wat vir gebruikers belangrik is. Weereens: as om een ongelukkige tekslêer van etlike tiene grepe groot met 'n wagwoord te kry, en as gevolg daarvan die hele diens kos (ja, ja, ek verstaan dat die rugsteunproses meestal nie hier te blameer is nie), en jy moet al die lêers in die bewaarplek agtereenvolgens herlees of die hele argief uitbrei - die rugsteunstelsel is nooit vinnig nie. Nog 'n punt wat dikwels 'n struikelblok word, is die spoed om 'n rugsteun uit 'n argief te ontplooi. Daar is 'n duidelike voordeel hier vir diegene wat eenvoudig lêers na die verlangde plek kan kopieer of skuif sonder veel manipulasie (rsync, byvoorbeeld), maar meestal moet die probleem op 'n organisatoriese manier opgelos word, empiries: deur die rugsteunhersteltyd te meet en gebruikers openlik hieroor in te lig.
stabiliteit
Dit moet so verstaan word: aan die een kant moet dit moontlik wees om die rugsteunkopie op enige manier terug te ontplooi, aan die ander kant moet dit bestand wees teen verskeie probleme: netwerkonderbreking, skyffout, verwydering van 'n deel van die bewaarplek.
Vergelyking van rugsteungereedskap
Kopieer skeppingstyd
Kopieer hersteltyd
Maklike installasie
Maklike opstelling
Eenvoudige gebruik
Eenvoudige outomatisering
Het u 'n kliëntbediener nodig?
Kontroleer die integriteit van die bewaarplek
Differensiële kopieë
Werk via pyp
veelsydigheid
Onafhanklikheid
Bewaarplek deursigtigheid
Enkripsie
Kompressie
Deduplisering
Web koppelvlak
Vul tot die wolk
Windows ondersteuning
merk
rsync
4m15s
4m28s
Ja
geen
geen
geen
Ja
geen
geen
Ja
geen
Ja
Ja
geen
geen
geen
geen
geen
Ja
6
Tar
suiwer
3m12s
2m43s
Ja
geen
geen
geen
geen
geen
Ja
Ja
geen
Ja
geen
geen
geen
geen
geen
geen
Ja
8,5
gzip
9m37s
3m19s
Ja
Rdiff-rugsteun
16m26s
17m17s
Ja
Ja
Ja
Ja
Ja
geen
Ja
geen
Ja
geen
Ja
geen
Ja
Ja
Ja
geen
Ja
11
Rsnapshot
4m19s
4m28s
Ja
Ja
Ja
Ja
geen
geen
Ja
geen
Ja
geen
Ja
geen
geen
Ja
Ja
geen
Ja
12,5
boer
11m9s
7m2s
Ja
geen
Ja
Ja
Ja
Ja
Ja
geen
Ja
Ja
geen
geen
Ja
geen
Ja
geen
Ja
10,5
Valsheid
geen enkripsie nie
16m48s
10m58s
Ja
Ja
geen
Ja
geen
Ja
Ja
geen
geen
Ja
geen
Ja
Ja
geen
Ja
geen
Ja
11
gpg
17m27s
15m3s
Dupliseer
geen enkripsie nie
20m28s
13m45s
geen
Ja
geen
geen
geen
Ja
Ja
geen
geen
Ja
geen
Ja
Ja
Ja
Ja
Ja
Ja
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
zbackup
geen enkripsie nie
40m3s
11m8s
Ja
Ja
geen
geen
geen
Ja
Ja
Ja
geen
Ja
geen
Ja
Ja
Ja
geen
geen
geen
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
geen enkripsie nie
4m7s
2m45s
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
geen
Ja
Ja
Ja
Ja
geen
Ja
16
aes
4m58s
3m23s
blak2
4m39s
3m19s
Plaatlik
5m38s
4m28s
Ja
Ja
Ja
Ja
geen
Ja
Ja
Ja
Ja
Ja
geen
Ja
geen
Ja
geen
Ja
Ja
15,5
urBackup
8m21s
8m19s
Ja
Ja
Ja
geen
Ja
geen
Ja
geen
Ja
Ja
geen
Ja
Ja
Ja
Ja
geen
Ja
12
Amanda
9m3s
2m49s
Ja
geen
geen
Ja
Ja
Ja
Ja
geen
Ja
Ja
Ja
Ja
Ja
geen
Ja
Ja
Ja
13
Rugsteun -PC
rsync
12m22s
7m42s
Ja
geen
Ja
Ja
Ja
Ja
Ja
geen
Ja
geen
geen
Ja
Ja
geen
Ja
geen
Ja
10,5
teer
12m34s
12m15s
Tabel legende:
- Groen, bedryfstyd minder as vyf minute, of antwoord "Ja" (behalwe vir die kolom "Benodig 'n kliëntbediener?"), 1 punt
- Geel, bedryfstyd vyf tot tien minute, 0.5 punte
- Rooi, die werktyd is meer as tien minute, of die antwoord is “Nee” (behalwe vir die kolom “Het jy 'n kliëntbediener nodig?”), 0 punte
Volgens die tabel hierbo is BorgBackup die eenvoudigste, vinnigste en terselfdertyd gerieflike en kragtige rugsteunhulpmiddel. Restic het die tweede plek behaal, die res van die oorweegde kandidate is ongeveer gelyk geplaas met 'n verspreiding van een of twee punte aan die einde.
Ek bedank almal wat die reeks tot die einde gelees het, ek nooi jou uit om die opsies te bespreek en jou eie aan te bied, indien enige. Soos die bespreking vorder, kan die tabel uitgebrei word.
Die resultaat van die reeks sal die finale artikel wees, waarin daar gepoog sal word om 'n ideale, vinnige en hanteerbare rugsteunhulpmiddel te ontwikkel wat jou toelaat om 'n kopie in die kortste moontlike tyd terug te ontplooi en terselfdertyd gerieflik en maklik te wees te konfigureer en in stand te hou.
aankondiging
Rugsteun Deel 6: Vergelyk Rugsteunnutsgoed
Rugsteun Deel 7: Gevolgtrekkings
Bron: will.com