Dizze notysje besprekt backup-ark dy't backups útfiere troch argiven te meitsjen op in backup-tsjinner.
Under dyjingen dy't foldogge oan de easken binne duplicity (dat hat in moaie ynterface yn 'e foarm fan deja dup) en duplicati.
In oar heul opmerklik reservekopy-ark is dar, mar om't it in heul wiidweidige list fan opsjes hat - de testmetodology beslacht amper 10% fan wat it yn steat is - testen wy it net as ûnderdiel fan 'e hjoeddeistige syklus.
Ferwachte útkomsten
Om't beide kandidaten op ien of oare wize argiven meitsje, kin gewoane tar as gids brûkt wurde.
Derneist sille wy evaluearje hoe goed gegevensopslach op 'e opslachtsjinner is optimalisearre troch it meitsjen fan reservekopyen dy't allinich it ferskil befetsje tusken in folsleine kopy en de aktuele steat fan' e bestannen, of tusken de foarige en aktuele argiven (inkrementeel, dekrementeel, ensfh.) .
Gedrach by it meitsjen fan backups:
- In relatyf lyts oantal triemmen op de reservekopy opslach tsjinner (fergelykber mei it oantal reservekopy kopyen of de grutte fan gegevens yn GB), mar harren grutte is frij grut (tsientallen oant hûnderten megabytes).
- De repositorygrutte sil allinich wizigingen omfetsje - gjin duplikaten wurde opslein, sadat de repositorygrutte lytser wêze sil as mei rsync-basearre software.
- Ferwachtsje swiere CPU-belêsting by it brûken fan kompresje en/of fersifering, en wierskynlik frij hege netwurk- en skiifbelêsting as it argyf- en/of fersiferingsproses rint op in reservekopy-opslachtsjinner.
Litte wy it folgjende kommando útfiere as referinsjewearde:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"De útfieringsresultaten wiene as folget:
Utfiertiid 3m12s. It kin sjoen wurde dat de snelheid wurdt beheind troch de skiif subsysteem fan de reservekopy opslach tsjinner, lykas yn it foarbyld mei . Allinnich wat flugger, want... opname giet nei ien triem.
Om kompresje te evaluearjen, litte wy deselde opsje útfiere, mar kompresje ynskeakelje oan 'e kant fan' e reservekopyserver:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"De resultaten binne:
Utfiertiid 10m11s. Meast wierskynlik is de knelpunt de single-flow compressor op it ûntfangende ein.
Itselde kommando, mar mei kompresje oerbrocht nei de tsjinner mei de orizjinele gegevens om de hypoteze te testen dat de knelpunt in single-threaded compressor is.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"It kaam sa út:
De útfieringstiid wie 9m37s. De lading op ien kearn troch de compressor is dúdlik sichtber, omdat De netwurk oerdracht snelheid en de lading op de boarne skiif subsysteem binne fergelykber.
Om fersifering te evaluearjen, kinne jo openssl of gpg brûke troch in ekstra kommando te ferbinen openssl of gpg yn pyp. Foar referinsje sil d'r in kommando wêze as dit:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"De resultaten kamen sa út:
De útfieringstiid die bliken 10m30s te wêzen, om't 2 prosessen oan 'e ûntfangende kant rûnen - de knelpunt is wer in single-threaded compressor, plus lytse fersiferingsoverhead.
UPD: Op fersyk fan bliznezz foegje ik tests ta mei pigz. As jo allinich de compressor brûke, soe it 6m30s nimme, as jo ek fersifering tafoegje, soe it sawat 7m wêze. It gat yn 'e ûnderste grafyk is in unflushed diskcache:
Duplikaat testen
Duplicity is in python-software foar reservekopy troch it meitsjen fan fersifere argiven yn tar-formaat.
Foar inkrementele argiven wurdt librsync brûkt, sadat jo it gedrach beskreaun kinne ferwachtsje yn .
Reservekopy kinne wurde fersifere en ûndertekene mei gnupg, wat wichtich is by it brûken fan ferskate providers foar it bewarjen fan backups (s3, backblaze, gdrive, ensfh.)
Litte wy sjen wat de resultaten binne:
Dit binne de resultaten dy't wy krigen by it rinnen sûnder fersifering
spoiler
Running tiid fan elke test run:
Start 1
Start 2
Start 3
16 m33s
17 m20s
16 m30s
8 m29s
9 m3s
8 m45s
5 m21s
6 m04s
5 m53s
En hjir binne de resultaten as gnupg-fersifering ynskeakele is, mei in kaaigrutte fan 2048 bits:
Bedriuwstiid op deselde gegevens, mei fersifering:
Start 1
Start 2
Start 3
17 m22s
17 m32s
17 m28s
8 m52s
9 m13s
9 m3s
5 m48s
5 m40s
5 m30s
De blokgrutte waard oanjûn - 512 megabytes, wat dúdlik te sjen is yn 'e grafiken; De prosessorlading bleau eins op 50%, wat betsjut dat it programma net mear as ien prosessorkearn brûkt.
It prinsipe fan 'e wurking fan it programma is ek frij dúdlik sichtber: se namen in stikje gegevens, komprimearre it en stjoerde it nei in reservekopy-opslachtsjinner, dy't frij stadich kin wêze.
In oare funksje is de foarsisbere rinnende tiid fan it programma, dy't allinich hinget fan 'e grutte fan' e feroare gegevens.
It ynskeakeljen fan fersifering fergrutte de rinnende tiid fan it programma net signifikant, mar it fergrutte de prosessorlading mei sawat 10%, wat nochal in moaie bonus kin wêze.
Spitigernôch wie dit programma net yn steat om de situaasje goed te ûntdekken mei de omneaming fan 'e map, en de resultearjende repositorygrutte die bliken gelyk te wêzen oan' e grutte fan 'e wizigingen (dus allegear 18GB), mar de mooglikheid om in net-fertroude server te brûken foar reservekopy dúdlik covers dit gedrach.
Duplikaat testen
Dizze software is skreaun yn C # en rint mei in set fan bibleteken út Mono. D'r is in GUI en ek in CLI-ferzje.
De ûngefear list fan 'e haadfunksjes is te fergelykjen mei duplisiteit, ynklusyf ferskate oanbieders fan backup-opslach, lykwols, yn tsjinstelling ta duplisiteit, binne de measte funksjes beskikber sûnder ark fan tredden. Oft dit in plus of in minus is hinget ôf fan it spesifike gefal, mar foar begjinners is it nei alle gedachten makliker om in list mei alle funksjes tagelyk foar har te hawwen, ynstee fan ekstra pakketten foar python te ynstallearjen, lykas is it gefal mei dupliziteit.
In oare lytse nuânse - it programma skriuwt aktyf in lokale sqlite-databank út namme fan 'e brûker dy't de reservekopy begjint, dus jo moatte ek soargje dat de fereaske databank korrekt wurdt oantsjutte elke kear as it proses wurdt begon mei de cli. By it wurkjen fia GUI of WEBGUI, sille details wurde ferburgen foar de brûker.
Litte wy sjen hokker yndikatoaren dizze oplossing kin produsearje:
As jo fersifering útsette (en WEBGUI advisearret dit net te dwaan), binne de resultaten as folgjend:
Wurkstikken:
Start 1
Start 2
Start 3
20 m43s
20 m13s
20 m28s
5 m21s
5 m40s
5 m35s
7 m36s
7 m54s
7 m49s
Mei fersifering ynskeakele, mei help fan aes, sjocht it der sa út:
Wurkstikken:
Start 1
Start 2
Start 3
29 m9s
30 m1s
29 m54s
5 m29s
6 m2s
5 m54s
8 m44s
9 m12s
9 m1s
En as jo it eksterne programma gnupg brûke, komme de folgjende resultaten út:
Start 1
Start 2
Start 3
26 m6s
26 m35s
26 m17s
5 m20s
5 m48s
5 m40s
8 m12s
8 m42s
8 m15s
Sa't jo sjen kinne, kin it programma yn ferskate diskusjes wurkje, mar dit makket it net in mear produktive oplossing, en as jo it fersiferingswurk fergelykje, lanseart it in ekstern programma
die bliken flugger te wêzen as it brûken fan de bibleteek út 'e Mono-set. Dit kin komme troch it feit dat it eksterne programma mear optimalisearre is.
In oar moai ding wie it feit dat de grutte fan 'e repository krekt safolle nimt as de feitlik feroare gegevens, d.w.s. duplicati ûntdutsen in map omneame en behannele dizze situaasje goed. Dit kin sjoen wurde by it útfieren fan de twadde test.
Oer it algemien frij positive yndrukken fan it programma, ynklusyf frij freonlik wêze foar newbies.
Resultaten
Beide kandidaten wurken frij stadich, mar yn 't algemien, yn ferliking mei gewoane tar, is der foarútgong, alteast mei duplicati. De priis fan sa'n foarútgong is ek dúdlik - in merkber lêst
prosessor. Yn 't algemien binne d'r gjin spesjale ôfwikingen yn it foarsizzen fan de resultaten.
befinings
As jo net nedich hawwe om oeral te haasten, en ek in ekstra prosessor hawwe, sil ien fan 'e beskôge oplossingen dwaan, yn alle gefallen is der nochal in soad wurk dien dat net werhelle wurde moat troch wrapperskripts boppe op tar te skriuwen . De oanwêzigens fan fersifering is in heul needsaaklike eigenskip as de tsjinner foar it bewarjen fan reservekopyen net folslein fertroud wurde kin.
Yn ferliking mei oplossings basearre - prestaasje kin ferskate kearen slimmer, nettsjinsteande it feit dat yn syn suvere foarm tar wurke 20-30% flugger as rsync.
D'r binne besparring op repositorygrutte, mar allinich mei duplicati.
Meidieling
Reservekopy Diel 3: Kontrolearje en testen duplicity, duplicati, deja dup
Reservekopy Part 4: Zbackup, restic, borgbackup resinsje en testen
Reservekopy, diel 5: Bacula en veeam-backup testen foar Linux
Reservekopy Diel 6: Fergeliking fan reservekopy-ark
Reservekopy Part 7: Konklúzjes
Pleatst troch: Pavel Demkovich
Boarne: www.habr.com