Hierdie nota bespreek rugsteunnutsgoed wat rugsteun uitvoer deur argiewe op 'n rugsteunbediener te skep.
Onder diegene wat aan die vereistes voldoen, is duplicity (wat 'n lekker koppelvlak in die vorm van deja dup het) en duplicati.
Nog 'n baie merkwaardige rugsteuninstrument is dar, maar aangesien dit 'n baie uitgebreide lys opsies het - die toetsmetodologie dek skaars 10% van waartoe dit in staat is - toets ons dit nie as deel van die huidige siklus nie.
Verwagte resultate
Aangesien beide kandidate argiewe op die een of ander manier skep, kan gewone teer as riglyn gebruik word.
Daarbenewens sal ons evalueer hoe goed databerging op die stoorbediener geoptimaliseer is deur rugsteunkopieë te skep wat slegs die verskil tussen 'n volledige kopie en die huidige toestand van die lêers bevat, of tussen die vorige en huidige argiewe (inkrementeel, dekrementeel, ens.) .
Gedrag wanneer rugsteun geskep word:
- 'n Relatief klein aantal lêers op die rugsteunbergingbediener (vergelykbaar met die aantal rugsteunkopieë of die grootte van data in GB), maar hul grootte is redelik groot (tien tot honderde megagrepe).
- Die bewaarplekgrootte sal slegs veranderinge insluit - geen duplikate sal gestoor word nie, dus sal die bewaarplekgrootte kleiner wees as met rsync-gebaseerde sagteware.
- Verwag swaar SVE-lading wanneer kompressie en/of enkripsie gebruik word, en waarskynlik redelik hoë netwerk- en skyflading as die argivering- en/of enkripsieproses op 'n rugsteunbergingbediener loop.
Kom ons voer die volgende opdrag as 'n verwysingswaarde uit:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Die uitvoeringsresultate was soos volg:
Uitvoeringstyd 3m12s. Dit kan gesien word dat die spoed beperk word deur die skyfsubstelsel van die rugsteunbergingbediener, soos in die voorbeeld met . Net 'n bietjie vinniger, want... opname gaan na een lêer.
Om kompressie te evalueer, laat ons ook dieselfde opsie uitvoer, maar aktiveer kompressie aan die rugsteunbedienerkant:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Die resultate is:
Uitvoeringstyd 10m11s. Heel waarskynlik is die bottelnek die enkelvloeikompressor aan die ontvangkant.
Dieselfde opdrag, maar met kompressie oorgedra na die bediener met die oorspronklike data om die hipotese te toets dat die bottelnek 'n enkeldraadkompressor is.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Dit het so uitgedraai:
Die uitvoeringstyd was 9m37s. Die las op een kern deur die kompressor is duidelik sigbaar, want Die netwerkoordragspoed en die las op die bronskyfsubstelsel is soortgelyk.
Om enkripsie te evalueer, kan jy openssl of gpg gebruik deur 'n bykomende opdrag te koppel openssl of gpg in pyp. Vir verwysing sal daar 'n opdrag soos hierdie wees:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Die resultate het soos volg uitgekom:
Die uitvoeringstyd het geblyk 10m30s te wees, aangesien 2 prosesse aan die ontvangkant geloop het - die bottelnek is weer 'n enkeldraadkompressor, plus klein enkripsie bokoste.
UPS: Op versoek van bliznezz voeg ek toetse met pigz by. As jy net die kompressor gebruik, sal dit 6m30s neem, as jy ook enkripsie byvoeg, sal dit ongeveer 7m wees. Die daling in die onderste grafiek is 'n ongespoelde skyfkas:
Duplikaat toetse
Duplicity is 'n python-sagteware vir rugsteun deur geënkripteerde argiewe in teerformaat te skep.
Vir inkrementele argiewe word librsync gebruik, sodat u die gedrag wat in beskryf word, kan verwag .
Rugsteune kan geïnkripteer en onderteken word met gnupg, wat belangrik is wanneer verskillende verskaffers gebruik word vir die stoor van rugsteun (s3, backblaze, gdrive, ens.)
Kom ons kyk wat die resultate sal wees:
Dit is die resultate wat ons gekry het toe ons sonder enkripsie hardloop
bederf
Looptyd van elke toetslopie:
Begin 1
Begin 2
Begin 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
En hier is die resultate wanneer gnupg-enkripsie geaktiveer is, met 'n sleutelgrootte van 2048 bisse:
Bedryfstyd op dieselfde data, met enkripsie:
Begin 1
Begin 2
Begin 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Die blokgrootte is aangedui - 512 megagrepe, wat duidelik sigbaar is in die grafieke; Die verwerkerlading het eintlik op 50% gebly, wat beteken dat die program nie meer as een verwerkerkern gebruik nie.
Die beginsel van die program se werking is ook baie duidelik sigbaar: hulle het 'n stukkie data geneem, dit saamgepers en dit na 'n rugsteunbergingbediener gestuur, wat redelik stadig kan wees.
Nog 'n kenmerk is die voorspelbare looptyd van die program, wat slegs afhang van die grootte van die veranderde data.
Die aktivering van enkripsie het nie die program se looptyd aansienlik verhoog nie, maar dit het die verwerkerlading met ongeveer 10% verhoog, wat nogal 'n goeie bonus kan wees.
Ongelukkig was hierdie program nie in staat om die situasie met die hernoeming van die gids korrek op te spoor nie, en die gevolglike bewaarplekgrootte was gelyk aan die grootte van die veranderinge (d.w.s. almal 18 GB), maar die vermoë om 'n onbetroubare bediener vir rugsteun te gebruik duidelik dek hierdie gedrag.
Duplikaat toetse
Hierdie sagteware is in C# geskryf en werk met 'n stel biblioteke van Mono. Daar is 'n GUI sowel as 'n CLI-weergawe.
Die benaderde lys van die hoofkenmerke is soortgelyk aan duplisering, insluitend verskeie rugsteunbergingsverskaffers, maar anders as duplisering, is die meeste kenmerke beskikbaar sonder derdeparty-nutsgoed. Of dit 'n plus of minus is, hang af van die spesifieke geval, maar vir beginners is dit heel waarskynlik makliker om 'n lys van al die kenmerke gelyktydig voor hulle te hê, eerder as om bykomende pakkette vir luislang te installeer, soos dit is die geval met dubbelsinnigheid.
Nog 'n klein nuanse - die program skryf aktief 'n plaaslike SQLite-databasis namens die gebruiker wat die rugsteun begin, so jy moet addisioneel verseker dat die vereiste databasis korrek gespesifiseer word elke keer as die proses met die cli begin word. Wanneer deur GUI of WEBGUI gewerk word, sal besonderhede vir die gebruiker versteek word.
Kom ons kyk watter aanwysers hierdie oplossing kan produseer:
As jy enkripsie afskakel (en WEBGUI beveel nie aan om dit te doen nie), is die resultate soos volg:
ure:
Begin 1
Begin 2
Begin 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Met enkripsie geaktiveer, met behulp van aes, lyk dit soos volg:
ure:
Begin 1
Begin 2
Begin 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
En as jy die eksterne program gnupg gebruik, kom die volgende resultate uit:
Begin 1
Begin 2
Begin 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Soos u kan sien, kan die program in verskeie drade werk, maar dit maak dit nie 'n meer produktiewe oplossing nie, en as u die enkripsiewerk vergelyk, begin dit 'n eksterne program
blyk vinniger te wees as om die biblioteek van die Mono-stel te gebruik. Dit kan wees as gevolg van die feit dat die eksterne program meer geoptimaliseer is.
Nog 'n lekker ding was die feit dat die grootte van die bewaarplek presies soveel neem as die werklike veranderde data, m.a.w. duplicati het 'n gidshernoem opgespoor en hierdie situasie korrek hanteer. Dit kan gesien word wanneer die tweede toets uitgevoer word.
In die algemeen, redelik positiewe indrukke van die program, insluitend om redelik vriendelik te wees vir beginners.
Bevindinge
Albei kandidate het redelik stadig gewerk, maar oor die algemeen, in vergelyking met gewone teer, is daar vordering, ten minste met duplicati. Die prys van sulke vordering is ook duidelik - 'n merkbare las
verwerker. Oor die algemeen is daar geen spesiale afwykings in die voorspelling van die resultate nie.
Bevindinge
As jy nêrens heen hoef te jaag nie, en ook 'n spaarverwerker het, sal enige van die oplossings wat oorweeg word doen, in elk geval, nogal baie werk is gedoen wat nie herhaal moet word deur omvou-skrifte bo-op teer te skryf nie . Die teenwoordigheid van enkripsie is 'n baie noodsaaklike eienskap as die bediener vir die berging van rugsteunkopieë nie ten volle vertrou kan word nie.
In vergelyking met oplossings gebaseer - prestasie kan 'n paar keer slegter wees, ten spyte van die feit dat teer in sy suiwer vorm 20-30% vinniger gewerk het as rsync.
Daar is besparings op die grootte van die bewaarplek, maar slegs met duplicati.
aankondiging
Rugsteun Deel 3: Hersien en toets duplicity, duplicati, deja dup
Rugsteun Deel 4: Hersiening en toetsing van zbackup, restic, borgbackup
Rugsteun Deel 5: Toets bacula en veeam rugsteun vir Linux
Rugsteun Deel 6: Vergelyk Rugsteunnutsgoed
Rugsteun Deel 7: Gevolgtrekkings
Pos skrywer: Pavel Demkovich
Bron: will.com