Në këtë shënim, shqyrtohen mjetet e kopjimit që kryejnë kopjimin duke krijuar arkiva në një server rezervë.
Nga ato qĂ« pĂ«rmbushin kĂ«rkesat â duplicity (pĂ«r tĂ« cilin ekziston njĂ« ndĂ«rfaqe e kĂ«ndshme si deja dup) dhe duplicati.
NjĂ« tjetĂ«r mjet shumĂ« tĂ« njohur pĂ«r kopjimin Ă«shtĂ« dar, por pasi ka njĂ« listĂ« tĂ« gjerĂ« opsionesh â metoda e testimit pĂ«rfshin sa do pak 10% tĂ« asaj qĂ« Ă«shtĂ« nĂ« gjendje, â nuk e testojmĂ« nĂ« kĂ«tĂ« cikĂ«l.
Rezultatet e pritura
Pasi të dy kandidatët krijojnë arkiva në një farë mënyre, mund të përdoret tar-i i zakonshëm si pikë referimi.
Së fundi, do të vlerësojmë sa mirë optimizohet ruajtja e të dhënave në serverin e ruajtjes duke krijuar kopje rezervë që përmbajnë vetëm ndryshimin midis kopjes së plotë dhe gjendjes aktuale të skedarëve, ose midis arkivave të kaluara dhe aktuale (inkrementale, dekrementale etj.).
Shtimi në krijimin e kopjeve rezervë:
- Numri relativisht i vogël i skedareve në serverin e ruajtjes së kopjeve (krahasuar me numrin e kopjeve ose madhësinë e të dhënave në GB), por mjaft mjaft i madh në madhësi (dhjetëra-qindra megabajt).
- MadhĂ«sia e depozitĂ«s do tĂ« pĂ«rfshijĂ« vetĂ«m ndryshimet â kopjet e dyfishta nuk do tĂ« ruhen, kĂ«shtu qĂ« madhĂ«sia e depozitĂ«s do tĂ« jetĂ« mĂ« e vogĂ«l se nĂ« rastin e pĂ«rdorimit tĂ« software-it bazuar nĂ« rsync.
- Pritet ngarkesë e madhe në procesor gjatë përdorimit të kompresimit dhe/ose enkriptimit, si dhe, ndoshta, një ngarkesë mjaft të madhe në rrjet dhe në nënstrukturën e diskeve, nëse procesi i arkivimit dhe/ose enkriptimit do të funksionojë në serverin e ruajtjes së kopjeve.
Si 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 dolën si më poshtë:
Koha e ekzekutimit 3m12s. E dukshme se shpejtësia u kufizua nga nënstruktura e diskeve të serverit të ruajtjes së kopjeve, ashtu si në shembullin me . Pak më e shpejtë, pasi shkrimi shkon në një skedar të vetëm.
Gjithashtu, për të vlerësuar kompresimin, do të ekzekutojmë të njëjtën variant, por duke përfshirë kompresimin në anën e serverit të rezervimit:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Rezultatet janë:
Koha e ekzekutimit Ă«shtĂ« 10m11s. ĂshtĂ« me gjasĂ« ngushtica â kompresori njĂ«-pjesĂ«sh nĂ« anĂ«n marrĂ«se.
I njĂ«jti komandĂ«, por me bartjen e kompresimit nĂ« serverin me tĂ« dhĂ«nat origjinale pĂ«r tĂ« verifikuar hipotezĂ«n qĂ« ngushtica â kompresori njĂ«-pjesĂ«sh.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Doli kështu:
Koha e ekzekutimit ishte 9m37s. Qartë shikohet ngarkesa e një bërthame nga kompresori, pasi shpejtësia e transmetimit në rrjet dhe ngarkesa në sistemin diskor të burimit janë të ngjashme.
Për vlerësimin e enkriptimit mund të përdorni openssl ose gpg, duke lidhur komandën shtesë openssl ose gpg në pipe. Si referencë do të jetë një komandë e tillë:
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 të tilla:
Koha e ekzekutimit ishte 10m30s, pasi u nisĂ«n 2 procese nĂ« anĂ«n marrĂ«se â ngushtica pĂ«rsĂ«ri ishte kompresori njĂ«-pjesĂ«sh, plus disa tĂ« dhĂ«na shtesĂ« pĂ«r enkriptimin.
UPD: Me kĂ«rkesĂ« tĂ« bliznezz po shtoj testet me pigz. NĂ«se pĂ«rdoret vetĂ«m kompresori â rezultati ishte pĂ«r 6m30s, nĂ«se shtojmĂ« edhe enkriptimin â afĂ«rsisht 7m. DĂ«shtimi nĂ« grafikun e poshtĂ«m â cache-i i diskut i pabĂ«rĂ« tĂ« zbrazet:
Testimi i duplicitetit
Duplicity â njĂ« software nĂ« python pĂ«r krijimin e kopjeve rezervĂ« pĂ«rmes arkivave tĂ« enkriptuar nĂ« formatin tar.
Për arkivat inkrementale përdoret librsync, prandaj, mund të pritet një sjellje e përshkruar në .
Kopjet rezervë mund të enkriptohen dhe nënshkruhen me gnupg, çka është e rëndësishme kur përdoren ofrues të ndryshëm për ruajtjen e kopjeve rezervë (s3, backblaze, gdrive, etj.)
Le të shohim se çfarë rezultate do të kemi:
Këto janë rezultatet nga ekzekutimi pa enkriptim
spoiler
Koha e ekzekutimit për çdo test:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Këto janë rezultatet kur aktivizohet enkriptimi gnupg, me madhësinë e çelësit 2048 bit:
Koha e ekzekutimit në të njëjtat të dhëna, me enkriptim:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Madhësia e bllokut u caktua në 512 megabajt, që dukshëm shihet në grafikë; ngarkesa e procesorit në fakt mbeti në nivelin 50%, që do të thotë se programi përdor jo më shumë se një bërthame procesori.
Gjithashtu është mjaft e qartë në lidhje me parimin e funksionimit të programit: morëm një copë të dhënash, e kompresuam, dhe e dërguam në serverin e ruajtjes së kopjeve, 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 dobishëm.
Fatkeqësisht, ky program nuk arriti të zbulojë korrektësisht situatën e rinomimin të katalogut, dhe madhësia përfundimtare e depozitës rezultoi të ishte e barabartë me madhësinë e ndryshimeve (dmth. të rreth 18GB), por mundësia për të përdorur një server të paqartë për ruajtjen e kopjeve e tejkalon në mënyrë të qartë këtë sjellje.
Testimi i duplicati
Ky software është shkruar në C#, dhe ekzekutohet duke përdorur një set bibliotekash nga Mono. Ka një GUI, si dhe një version cli.
Lista e mundshme e funksioneve kryesore është e ngjashme me duplicity, duke përfshirë ofrues të ndryshëm për ruajtjen e kopjeve rezervë, megjithatë, në kontrast me duplicity, shumica e funksioneve janë të disponueshme pa mjete të jashtme. Nëse është një avantazh apo disavantazh varet nga rasti specifik, por për fillestarët, është më e lehtë të kemi para syve një listë të gjitha funksioneve, sesa të instalojmë paketa për python, siç ndodh me duplicity.
NjĂ« detaj tjetĂ«r i vogĂ«l â programi aktivisht shkruan njĂ« bazĂ« lokale sqlite nĂ« emĂ«r tĂ« atij pĂ«rdoruesi, i cili nis kopjen rezervĂ«, prandaj duhet tĂ« kujdesemi pĂ«r specifikimin e duhur tĂ« bazĂ«s nĂ« çdo fillim procesi 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 tregues mund të japë kjo zgjidhje:
Nëse çaktivizoni enkriptimin (madje WEBGUI nuk e rekomandon këtë), rezultatet janë këto:
Koha e funksionimit:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Me enkriptim aktiv, përdorimi i aes jep këto rezultate:
Koha e funksionimit:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Dhe nëse përdorni programin e jashtëm gnupg, rezultati është kështu:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Siç duket â programa punon me shumĂ« rrjedha, por kjo nuk do tĂ« thotĂ« se Ă«shtĂ« njĂ« zgjidhje mĂ« e fuqishme, dhe nĂ«se krahasojmĂ« punĂ«n e enkriptimit â nisjen e njĂ« programi tĂ« jashtĂ«m.
doli më e shpejtë se përdorimi i bibliotekës nga grupi Mono. Ndoshta, kjo është e lidhur me faktin se programi i jashtëm është optimizuar më shumë.
Një moment më i këndshëm ishte se madhësia e depozitës zë saktësisht aq sa ishin të dhënat e vërteta të ndryshuara, domethënë, duplicati zbuloi rinovimin e katalogut dhe e trajtoi këtë situatë siç duhet. Kjo mund të shihet gjatë ekzekutimit të testit të dytë.
Në përgjithësi, përshtypje mjaft pozitive nga programi, duke përfshirë një miqësi të mjaftueshme 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 nga duplicati. Ămimi i kĂ«tij progresi Ă«shtĂ« gjithashtu i qartĂ« â njĂ« 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 ke ndonjĂ« ngut, dhe gjithashtu ke kapacitet tĂ« mjaftueshĂ«m pĂ«r procesorin â çdo njĂ« nga zgjidhjet e shqyrtuara do tĂ« jetĂ« e pĂ«rshtatshme, nĂ« çdo rast Ă«shtĂ« bĂ«rĂ« njĂ« punĂ« mjaft e madhe, e cila nuk duhet tĂ« pĂ«rsĂ«ritet duke shkruar skripte rreth tar. Prania e enkriptimit Ă«shtĂ« njĂ« atribut shumĂ« i dobishĂ«m, nĂ«se serveri pĂ«r ruajtjen e kopjeve rezervĂ« nuk mund tĂ« besohet plotĂ«sisht.
NĂ«se e krahasojmĂ« me zgjidhjet e bazuara nĂ« â performanca mund tĂ« jetĂ« disa herĂ« mĂ« e keqe, megjithĂ«se nĂ« versionin e pastĂ«r tar ka punuar mĂ« shpejt se rsync me 20-30%.
Ekonomia në madhësinë e depozitës ekziston, por vetëm me duplicati.
Ankandi
Kopja rezervë, pjesa 3: Rishikimi dhe testingu i duplicity, duplicati, deja dup
Kopjimi, pjesa 4: PĂ«rmbledhje dhe testim i zbackup, restic, borgbackup
Kopjimi, pjesa 5: Testimi i bacula dhe veeam backup për linux
Backup, pjesa 6: Krahasimi i mjeteve të backup-it
Kopjimi, pjesa 7: PĂ«rfundimet
Autori i publikimit: Pavël Demkoviç
Burimi: habr.com
