Në këtë shënim shqyrtohen mjete të backup-it që kryejnë kopjimin duke krijuar arkiva në serverin e rezervave.
Nga ata qĂ« plotĂ«sojnĂ« kĂ«rkesat â duplicity (pĂ«r tĂ« cilin ka njĂ« ndĂ«rfaqe tĂ« kĂ«ndshme nĂ« formĂ«n e deja dup) dhe duplicati.
NjĂ« mjet tjetĂ«r shumĂ« i dukshĂ«m pĂ«r backup Ă«shtĂ« dar, por pĂ«r shkak tĂ« listĂ«s sĂ« gjerĂ« tĂ« opsioneve â metoda e testimit pĂ«rfshin ndoshta 10% nga ajo qĂ« Ă«shtĂ« i aftĂ« â nuk do ta testojmĂ« nĂ« kĂ«tĂ« cikĂ«l.
Rezultatet e pritura
Të dy kandidatët, në një farë mënyre, krijojnë arkiva, kështu që si një pikë referimi mund të përdoret tar-i normal.
Për më tepër, do të vlerësojmë se sa mirë optimizohet ruajtja e të dhënave në serverin e ruajtjes duke krijuar kopje rezervash që përmbajnë vetëm ndryshimin midis kopjes së plotë dhe gjendjes aktuale të skedarëve, ose midis arkivave të kaluara dhe aktuale (incrementale, decrementale etj.).
Shtypi gjatë krijimit të kopjimeve rezervë:
- Numri relativisht i vogël i skedarëve në serverin e ruajtjes së kopjeve rezervë (krahasuar me numrin e kopjeve rezervë ose me madhësinë e të dhënave në GB), por mjaft i madh në madhësi (dhjetëra-qindra megabajt).
- MadhĂ«sia e depot do tĂ« pĂ«rfshijĂ« vetĂ«m ndryshimet â kopjet nuk do tĂ« ruhen, kĂ«shtu qĂ« madhĂ«sia e depot do tĂ« jetĂ« mĂ« e vogĂ«l se kur pĂ«rdoret njĂ« softuer i bazuar nĂ« rsync.
- Pritet një ngarkesë e madhe në procesor kur përdoret kompresimi dhe/ose enkriptimi, si dhe ndoshta një ngarkesë e madhe në rrjet dhe sistemin disk, nëse procesi i arkivimit dhe/ose enkriptimit do të funksionojë në serverin e ruajtjes së kopjeve rezervë.
Si një vlerë referuese, do të ekzekutojmë komandën e mëposhtme:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Rezultatet e ekzekutimit janë këto:
Koha e ekzekutimit ishte 3m12s. ĂshtĂ« e dukshme se shpejtĂ«sia Ă«shtĂ« ngjitur me sistemin disk tĂ« serverit tĂ« rezervave, ashtu siç ishte nĂ« shembullin me . VetĂ«m pak mĂ« shpejt, pasi shkarkimi bĂ«het nĂ« njĂ« skedar.
Gjithashtu, për të vlerësuar kompresimin do të ekzekutojmë të njëjtën variant, por do ta përfshijmë kompresimin në anën e serverit të backup-it:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Rezultatet janë këto:
Koha e ekzekutimit ishte 10m11s. Më së shumti, pika e ngushtë është kompresori njëanjëshe në anën që pranuesi.
E njëjtë komandë, por me shfrytezimin e kompresionit në server me të dhënat origjinale për të verifikuar hipotezën se pika e ngushtë është kompresori njëra.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"KĂ«shtu e kemi:
Koha e ekzekutimit ishte 9m37s. Qartë duket ngarkesa e një bërthame nga kompresori, duke parë se shpejtësia e transmetimit në rrjet dhe ngarkesa në sistemin e diskut të burimit janë të ngjashme.
Për vlerësimin e enkriptimit mund të përdoren openssl ose gpg, duke lidhur një komandë shtesë openssl ose gpg në pipe. Si referencë do të ishte kjo komandë:
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 10m30s, sepse ishin nisur 2 procese nĂ« anĂ«n e marrĂ«sit â pika e ngushtĂ« pĂ«rsĂ«ri ishte kompresori njĂ«ra, plus ndihmat e vogla pĂ«r enkriptimin.
UPD: NĂ« kĂ«rkesĂ« tĂ« bliznezz, po shtoj testet me pigz. NĂ«se pĂ«rdoret vetĂ«m kompresori â doli pĂ«r 6m30s, nĂ«se e shtojmĂ« edhe enkriptimin â rreth 7m. DĂ«shtimi nĂ« grafikun e poshtĂ«m â ndihma e pandarĂ« pĂ«r diskun:
Testimi i duplicity
Duplicity është një program i shkruar në python për backup duke krijuar arkiva të enkriptuara në formatin tar.
Për arkivat inkrementale përdor librsync, prandaj mund të pritet sjellja e përshkruar në .
Backup-et mund të enkriptohen dhe të nënshkruhen me gnupg, e cila është e rëndësishme gjatë përdorimit të ofruesve të ndryshëm për ruajtjen e backup-eve (s3, backblaze, gdrive etj.)
Të shohim çfarë do të jenë rezultatet:
Këto janë rezultatet e marra gjatë ekzekutimit pa enkriptim
spoiler
Koha e punës për secilën nisje testuese:
Nisja 1
Nisja 2
Nisja 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Këto janë rezultatet gjatë aktivizimit të enkriptimit gnupg, me madhësinë e çelësit 2048 bit:
Koha e punës mbi të dhënat e njëjta, me enkriptim:
Nisja 1
Nisja 2
Nisja 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
U pĂ«rcaktua madhĂ«sia e bllokut â 512 megabajt, e cila duket qartĂ« nĂ« grafikĂ«; ngarkesa e procesorit nĂ« tĂ« vĂ«rtetĂ« qĂ«ndronte nĂ« nivelin 50%, pra programi shfrytĂ«zon jo mĂ« shumĂ« se njĂ« bĂ«rthamĂ« procesori.
Po ashtu duket mjaft mirë parimi i funksionimit të programit: morëm një copë të dhënash, e kompresuam atë, e derguam në serverin e ruajtjes së backup-eve, i cili mund të jetë mjaft e ngadaltë.
Një veçori tjetër është koha e parashikueshme e punës së 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 e rriti ngarkesën e procesorit rreth 10%, gjë që mund të jetë një bonus i këndshëm.
Për fat të keq, ky program nuk arriti të identifikonte saktësisht situatën e rinovimit të katalogut, dhe madhësia përfundimtare e repository-t rezultoi të ishte e barabartë me madhësinë e ndryshimeve (dmth. të gjitha 18GB), por mundësia për të përdorur një server të panjohur për backup pa dyshim mbulon këtë sjellje.
Testimi i duplicati
Ky software është shkruar në C#, dhe ekzekutohet duke përdorur një grup bibliotekash nga Mono. Ka një GUI, si dhe një version CLI.
Lista e përafërt e mundësive kryesore është e ngjashme me duplicity, duke përfshirë ofrues të ndryshëm për ruajtjen e kopjeve rezervë, megjithatë, ndryshe nga duplicity, shumica e mundësive janë të disponueshme pa mjete të jashtme. Nëse kjo është një avantazh apo një disavantazh varet nga rasti konkret, megjithatë për fillestarët, është më e lehtë të kesh përpara një listë të gjitha mundësive, sesa të instalohet paketat për python, ashtu si në rastin e duplicity.
NjĂ« detaj tjetĂ«r i vogĂ«l â programi aktivisht shkruan njĂ« bazĂ« lokale sqlite nĂ« emĂ«r tĂ« pĂ«rdoruesit qĂ« ekzekuton backup-in, prandaj duhet tĂ« kihet parasysh qĂ« tĂ« jepet saktĂ« baza e nevojshme nĂ« çdo ekzekutim tĂ« procesit duke pĂ«rdorur CLI. Kur punoni pĂ«rmes GUI ose WEBGUI, detajet do tĂ« jenĂ« tĂ« fshehura nga pĂ«rdoruesi.
Le të shohim se cilat rezultate mund të japë kjo zgjidhje:
Nëse e çaktivizoni enkriptimin (në të vërtetë WEBGUI nuk rekomandon këtë), rezultatet janë si më poshtë:
Koha e punës:
Nisja 1
Nisja 2
Nisja 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Me enkriptimin e aktivizuar, duke përdorur aes, rezultati është kështu:
Koha e punës:
Nisja 1
Nisja 2
Nisja 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Ndërsa nëse përdorni programin e jashtëm gnupg, rezultati del kështu:
Nisja 1
Nisja 2
Nisja 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Siç duket - programi di të punojë në disa procesa, por kjo nuk e bën një zgjidhje më produktive, dhe nëse krahasojmë funksionimin e enkriptimit - ekzekutimi i programit të jashtëm
doli më i shpejtë sesa aplikimi i bibliotekës nga grupi Mono. Ndoshta, kjo lidhet me faktin se programi i jashtëm është më i optimizuar.
Një moment i këndshëm ishte gjithashtu fakti se madhësia e depozitës zë pikërisht aq sa janë të dhënat e modifikuara, dmth. duplicati zbuloi rinovimin e dosjes dhe e trajtoi korrekt këtë situatë. Këtë mund ta shihni gjatë ekzekutimit të testit të dytë.
Në përgjithësi, përshtypjet janë kryesisht pozitive për programin, duke përfshirë mjaft miqësinë për fillestarët.
Rezultatet
TĂ« dy kandidatĂ«t punuan mjaft ngadalĂ«, por nĂ« pĂ«rgjithĂ«si, krahasuar me tar-in e zakonshĂ«m, ka pĂ«rparim, tĂ« paktĂ«n me duplicati. Ămimi i kĂ«tij pĂ«rparimi Ă«shtĂ« gjithashtu e kuptueshme - ngarkesĂ« e dukshme
e procesorit. Në përgjithësi, nuk ka ndonjë devijim të veçantë në parashikimin e rezultateve.
PĂ«rfundimet
Nëse nuk keni nevojë të nguteni, dhe gjithashtu keni kapacitet në procesor - çdo një nga zgjidhjet e shqyrtuara do të ishte e përshtatshme, përndryshe është bërë një punë mjaft e madhe, që nuk duhet të përsëritet përmes shkruarjes së skripteve mbështjellëse mbi tar. Prania e enkriptimit është një veçori shumë e nevojshme, nëse serveri për ruajtjen e kopjeve rezervë nuk mund të jetë plotësisht i besueshëm.
NĂ«se e krahasojmĂ« me zgjidhjet e bazuara nĂ« â performanca mund tĂ« jetĂ« disa herĂ« mĂ« e keqe, megjithĂ«se tar-i nĂ« formĂ«n e tij tĂ« pastĂ«r punoi mĂ« shpejt se rsync me 20-30%.
Ka kursim në madhësinë e depozitës, por vetëm me duplicati.
Njoftim
Kopjimi rezervë, pjesa 3: Shqyrtimi dhe testimi i duplicity, duplicati, deja dup
Kopjimi i rezervave, pjesa 4: PĂ«rmbledhje dhe testim i zbackup, restic, borgbackup
Kopjimi i rezervave, pjesa 5: Testimi i bacula dhe veeam backup për linux
Kopjimi i rezervave, pjesa 6: Krahasimi i mjeteve për kopje rezervë
Kopjimi i rezervave, pjesa 7: PĂ«rfundime
Autori i publikimit: Pavel Demkoviç
Burimi: habr.com
