Ky shënim diskuton mjetet rezervë që kryejnë kopje rezervë duke krijuar arkiva në një server rezervë.
Ndër ato që plotësojnë kërkesat janë dupliciteti (i cili ka një ndërfaqe të këndshme në formën e deja dup) dhe duplicati.
Një tjetër mjet shumë i shquar rezervë është dar, por meqenëse ai ka një listë shumë të gjerë opsionesh - metodologjia e testimit mbulon mezi 10% të asaj që është në gjendje - ne nuk po e testojmë atë si pjesë e ciklit aktual.
Rezultatet e pritura
Meqenëse të dy kandidatët krijojnë arkiva në një mënyrë ose në një tjetër, katrani i rregullt mund të përdoret si udhëzues.
Për më tepër, ne do të vlerësojmë se sa mirë është optimizuar ruajtja e të dhënave në serverin e ruajtjes duke krijuar kopje rezervë që përmbajnë vetëm ndryshimin midis një kopjeje të plotë dhe gjendjes aktuale të skedarëve, ose midis arkivave të mëparshme dhe aktuale (në rritje, zvogëlim, etj.) .
Sjellja kur krijoni kopje rezervë:
- Një numër relativisht i vogël skedarësh në serverin e ruajtjes rezervë (i krahasueshëm me numrin e kopjeve rezervë ose madhësinë e të dhënave në GB), por madhësia e tyre është mjaft e madhe (dhjetëra deri në qindra megabajt).
- Madhësia e depove do të përfshijë vetëm ndryshime - nuk do të ruhen kopje identike, kështu që madhësia e depove do të jetë më e vogël se sa me softuerin e bazuar në rsync.
- Prisni ngarkesë të madhe të CPU-së kur përdorni kompresim dhe/ose enkriptim, dhe ka të ngjarë të jetë një ngarkesë mjaft e lartë e rrjetit dhe e diskut nëse procesi i arkivimit dhe/ose i enkriptimit po ekzekutohet në një server të ruajtjes rezervë.
Le të ekzekutojmë komandën e mëposhtme si vlerë referencë:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Rezultatet e ekzekutimit ishin si më poshtë:
Koha e ekzekutimit 3m12s. Mund të shihet se shpejtësia është e kufizuar nga nënsistemi i diskut të serverit të ruajtjes rezervë, si në shembullin me . Vetëm pak më shpejt, sepse... regjistrimi shkon në një skedar.
Gjithashtu, për të vlerësuar kompresimin, le të ekzekutojmë të njëjtin opsion, por aktivizojmë kompresimin në anën e serverit rezervë:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Rezultatet janë:
Koha e ekzekutimit 10m11s. Me shumë mundësi, pengesa është kompresori me një rrjedhë në skajin marrës.
E njëjta komandë, por me kompresim të transferuar në server me të dhënat origjinale për të testuar hipotezën se bottleneck është një kompresor me një fije.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Doli kështu:
Koha e ekzekutimit ishte 9m37s. Ngarkesa në një bërthamë nga kompresori është qartë e dukshme, sepse Shpejtësia e transferimit të rrjetit dhe ngarkesa në nënsistemin e diskut burimor janë të ngjashme.
Për të vlerësuar enkriptimin, mund të përdorni openssl ose gpg duke lidhur një komandë shtesë openssl ose gpg në tub. Për referencë do të ketë një komandë si kjo:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Rezultatet dolën kështu:
Koha e ekzekutimit doli të ishte 10 m30s, pasi 2 procese po funksiononin në anën marrëse - fyti i ngushtë është përsëri një kompresor me një fije, plus sipërfaqja e vogël e kriptimit.
UPD: Me kerkese te bliznezz po shtoj teste me pigz. Nëse përdorni vetëm kompresorin, do të duheshin 6 m30 sekonda, nëse shtoni edhe enkriptim, do të ishte rreth 7 m. Zhytja në grafikun e poshtëm është një cache e diskut të pashuar:
Testimi i dyfishtë
Duplicity është një softuer python për kopje rezervë duke krijuar arkiva të koduara në formatin tar.
Për arkivat në rritje, përdoret librsync, kështu që mund të prisni sjelljen e përshkruar në .
Rezervimet mund të kodohen dhe nënshkruhen duke përdorur gnupg, gjë që është e rëndësishme kur përdorni ofrues të ndryshëm për ruajtjen e kopjeve rezervë (s3, backblaze, gdrive, etj.)
Le të shohim se cilat janë rezultatet:
Këto janë rezultatet që morëm kur punuam pa kriptim
prishës
Koha e funksionimit të çdo testi:
Nisja 1
Nisja 2
Nisja 3
16 m33s
17 m20s
16 m30s
8 m29s
9 m3s
8 m45s
5 m21s
6 m04s
5 m53s
Dhe këtu janë rezultatet kur enkriptimi gnupg është i aktivizuar, me një madhësi çelësi prej 2048 bit:
Koha e funksionimit në të njëjtat të dhëna, me kriptim:
Nisja 1
Nisja 2
Nisja 3
17 m22s
17 m32s
17 m28s
8 m52s
9 m13s
9 m3s
5 m48s
5 m40s
5 m30s
Madhësia e bllokut u tregua - 512 megabajt, e cila është qartë e dukshme në grafikë; Ngarkesa e procesorit në fakt mbeti në 50%, që do të thotë se programi nuk përdor më shumë se një bërthamë procesori.
Parimi i funksionimit të programit është gjithashtu mjaft i dukshëm: ata morën një pjesë të të dhënave, e kompresuan dhe e dërguan në një server të ruajtjes rezervë, i cili mund të jetë mjaft i ngadaltë.
Një veçori tjetër është koha e parashikueshme e funksionimit të programit, e cila varet vetëm nga madhësia e të dhënave të ndryshuara.
Aktivizimi i enkriptimit nuk e rriti ndjeshëm kohën e funksionimit të programit, por rriti ngarkesën e procesorit me rreth 10%, që mund të jetë një bonus mjaft i mirë.
Fatkeqësisht, ky program nuk ishte në gjendje të zbulonte saktë situatën me riemërtimin e drejtorisë dhe madhësia e depove që rezulton doli të jetë e barabartë me madhësinë e ndryshimeve (d.m.th., të gjitha 18 GB), por aftësia për të përdorur një server të pabesueshëm për kopje rezervë në mënyrë të qartë mbulon këtë sjellje.
Testimi i dyfishtë
Ky softuer është i shkruar në C# dhe funksionon duke përdorur një grup bibliotekash nga Mono. Ekziston një version GUI si dhe një version CLI.
Lista e përafërt e veçorive kryesore është e ngjashme me dyfishin, duke përfshirë ofrues të ndryshëm të ruajtjes rezervë, megjithatë, ndryshe nga dyfishimi, shumica e veçorive janë të disponueshme pa mjete të palëve të treta. Nëse ky është një plus ose një minus varet nga rasti specifik, por për fillestarët, ka shumë të ngjarë që më lehtë të kenë një listë të të gjitha veçorive përpara tyre menjëherë, në vend që të duhet të instaloni paketa shtesë për python, siç është rasti me dyfytyrësi.
Një nuancë tjetër e vogël - programi shkruan në mënyrë aktive një bazë të dhënash lokale sqlite në emër të përdoruesit që fillon kopjimin, kështu që duhet të siguroheni gjithashtu që baza e të dhënave të kërkuara të specifikohet saktë sa herë që procesi fillon duke përdorur cli. Kur punoni përmes GUI ose WEBGUI, detajet do të fshihen nga përdoruesi.
Le të shohim se çfarë treguesish mund të prodhojë kjo zgjidhje:
Nëse fikni enkriptimin (dhe WEBGUI nuk rekomandon ta bëni këtë), rezultatet janë si më poshtë:
Orari:
Nisja 1
Nisja 2
Nisja 3
20 m43s
20 m13s
20 m28s
5 m21s
5 m40s
5 m35s
7 m36s
7 m54s
7 m49s
Me enkriptimin e aktivizuar, duke përdorur aes, duket kështu:
Orari:
Nisja 1
Nisja 2
Nisja 3
29 m9s
30 m1s
29 m54s
5 m29s
6 m2s
5 m54s
8 m44s
9 m12s
9 m1s
Dhe nëse përdorni programin e jashtëm gnupg, dalin rezultatet e mëposhtme:
Nisja 1
Nisja 2
Nisja 3
26 m6s
26 m35s
26 m17s
5 m20s
5 m48s
5 m40s
8 m12s
8 m42s
8 m15s
Siç mund ta shihni, programi mund të funksionojë në disa tema, por kjo nuk e bën atë një zgjidhje më produktive, dhe nëse krahasoni punën e kriptimit, është duke nisur një program të jashtëm
doli të ishte më i shpejtë se përdorimi i bibliotekës nga grupi Mono. Kjo mund të jetë për shkak të faktit se programi i jashtëm është më i optimizuar.
Një tjetër gjë e bukur ishte fakti që madhësia e depove merr saktësisht aq sa të dhënat aktuale të ndryshuara, d.m.th. duplicati zbuloi një riemërtim të drejtorisë dhe e trajtoi si duhet këtë situatë. Kjo mund të shihet kur ekzekutoni testin e dytë.
Në përgjithësi, përshtypjet mjaft pozitive të programit, duke përfshirë të qenit mjaft miqësor me fillestarët.
Gjetjet
Të dy kandidatët punuan mjaft ngadalë, por në përgjithësi, krahasuar me katranin e rregullt, ka përparim, të paktën me dublikatat. Çmimi i një progresi të tillë është gjithashtu i qartë - një barrë e dukshme
procesor. Në përgjithësi, nuk ka devijime të veçanta në parashikimin e rezultateve.
Gjetjet
Nëse nuk keni nevojë të nxitoni askund, dhe gjithashtu keni një procesor rezervë, çdo zgjidhje e konsideruar do të bëjë, në çdo rast, është bërë mjaft punë që nuk duhet të përsëritet duke shkruar skriptet mbështjellëse sipër katranit. . Prania e kriptimit është një pronë shumë e nevojshme nëse serveri për ruajtjen e kopjeve rezervë nuk mund të besohet plotësisht.
Krahasuar me zgjidhjet e bazuara - performanca mund të jetë disa herë më e keqe, pavarësisht nga fakti se në formën e tij të pastër katrani funksionoi 20-30% më shpejt se rsync.
Ka kursime në madhësinë e depove, por vetëm me dublikatë.
Shpallje
Rezervimi Pjesa 3: Rishikimi dhe testimi i duplicitetit, duplicati, deja dup
Rezervimi Pjesa 4: Rishikimi dhe testimi i zbackup, restic, borgbackup
Rezervimi Pjesa 5: Testimi i kopjes rezervë të bakulës dhe veeam për linux
Rezervimi Pjesa 6: Krahasimi i mjeteve rezervë
Pjesa rezervë 7: Përfundime
Postuar nga: Pavel Demkovich
Burimi: www.habr.com