Në këtë artikull do të shqyrtojmë mjete softuerike për kopjimi rezervë, të cilat duke ndarë rrjedhën e të dhënave në komponente të veçanta (chunks), formojnë një depo.
KomponentĂ«t e depoes mund tĂ« kompresohen dhe enkriptohen pĂ«r mĂ« tepĂ«r, dhe mĂ« e rĂ«ndĂ«sishmja â gjatĂ« proceseve tĂ« pĂ«rsĂ«ritura tĂ« kopjimit rezervĂ« â mund tĂ« ribashkohen.
Një kopje rezervë në një depo të tillë është një zinxhir i emëruar i komponentëve të lidhur me njëri-tjetrin, për shembull, mbi baza të funksioneve të ndryshme hash.
Ka disa zgjidhje të tilla, unë do të ndalem në 3: zbackup, borgbackup dhe restic.
Rezultatet e pritura
Duke qenĂ« se tĂ« gjithĂ« pretendentĂ«t gjithsesi kĂ«rkojnĂ« krijimin e njĂ« depoje, njĂ« nga faktorĂ«t mĂ« tĂ« rĂ«ndĂ«sishĂ«m do tĂ« jetĂ« vlerĂ«simi i madhĂ«sisĂ« sĂ« depoes. NĂ« pĂ«rkryerĂ«si, madhĂ«sia e saj nuk duhet tĂ« kalojĂ« 13 GB sipas metodologjisĂ« sĂ« pranuar, madje tĂ« jetĂ« edhe mĂ« e vogĂ«l â me kusht qĂ« optimizimi tĂ« jetĂ« i mirĂ«.
Po ashtu, është shumë e dëshirueshme të kemi mundësinë për të krijuar kopje rezervë të skedarëve direkt, pa përdorimin e arkivave si tar, si dhe të punojmë me ssh/sftp pa mjete shtesë si rsync dhe sshfs.
Shtimi në krijimin e kopjeve rezervë:
- Madhësia e depoes do të barazohet me madhësinë e ndryshimeve, ose do të jetë më e vogël.
- Pritet ngarkesë e madhe në procesor kur përdoret kompresimi dhe/ose enkriptimi, si dhe është e mundur që të ketë ngarkesë të konsiderueshme në rrjet dhe në sistemin e diskëve, nëse procesi i arkivimit dhe/ose enkriptimit kryhet në serverin e ruajtjes së kopjeve rezervë.
- Nëse dëmtat repositori, është e mundur që gabimi të shfaqet më vonë gjatë krijimit të kopjeve të reja rezervë, si dhe gjatë përpjekjeve për rikuperim. Duhet planifikuar masa shtesë për sigurimin e integritetit të repositorit ose të përdoren mjetet e ndërtuara për verifikimin e integritetit të tij.
Si një vlerë referuese është marrë puna me tar, siç është treguar në një nga artikujt e mëparshëm.
Testimi i zbackup
Mekanizmi i përgjithshëm i funksionimit të zbackup përfshin atë që programa gjen në rrjedhën e të dhënave që jepen si input zona që përmbajnë të dhëna të njëjta, pastaj opsionalisht i kompreson, i enkripton, duke ruajtur secilën zonë vetëm një herë.
Për deduplifikimin përdoret një funksion hash ring 64-bit me një dritare lëvizëse për kontrollin byte me byte të përputhjes me blloqet e dhënave që already exist (diçka e ngjashme me atë që është realizuar në rsync).
PĂ«r kompresim pĂ«rdoren lzma dhe lzo nĂ« ekzekutim tĂ« shumĂ«fishtĂ«, ndĂ«rsa pĂ«r enkriptim â aes. NĂ« versionet mĂ« tĂ« fundit ka mundĂ«sinĂ« pĂ«r tĂ« fshirĂ« tĂ« dhĂ«nat e vjetra nga repositori nĂ« tĂ« ardhmen.
Programi Ă«shtĂ« shkruar nĂ« C++ me varĂ«si minime. Autori duket se Ă«shtĂ« frymĂ«zuar nga metoda unix-way, kĂ«shtu qĂ« programa merr tĂ« dhĂ«na nĂ« stdin gjatĂ« krijimit tĂ« kopjeve rezervĂ«, duke dhĂ«nĂ« njĂ« rrjedhĂ« tĂ« ngjashme tĂ« tĂ« dhĂ«nave nĂ« stdout gjatĂ« rikuperimit. KĂ«shtu, zbackup mund tĂ« pĂ«rdoret si njĂ« ândihmĂ«sâ i shkĂ«lqyer pĂ«r tĂ« ndihmuar nĂ« zhvillimin e zgjidhjeve tuaja pĂ«r kopje rezervĂ«. PĂ«r shembull, ky program Ă«shtĂ« mjeti kryesor i autorit pĂ«r kopje rezervĂ« tĂ« kompjuterĂ«ve tĂ« shtĂ«pisĂ« qĂ« nga viti 2014.
Si rrjedhë të dhënash do të përdoret tar-i i zakonshëm, nëse nuk është thënë ndryshe.
Le të shohim se çfarë rezultate do të kemi:
Kontrolli i funksionimit është kryer në 2 variante:
- krijohet një repositor dhe zbackup aktivizohet në serverin me të dhënat burimore, pastaj përmbajtja e repositorit dërgohet në serverin për ruajtjen e kopjeve rezervë.
- krijohet një repositor në serverin për ruajtjen e kopjeve rezervë, zbackup aktivizohet përmes ssh në serverin për ruajtjen e kopjeve rezervë, të dhënat i jepen atij përmes pipe.
Rezultatet e versionit tĂ« parĂ« ishin tĂ« tilla: 43m11s â duke pĂ«rdorur depozitĂ«n e pa enkriptuar dhe kompresorin lzma, 19m13s â kur u zĂ«vendĂ«sua kompresori me lzo.
Ngarkesa në serverin me të dhënat origjinale ishte si më poshtë (tregohet një shembull me lzma, me lzo ishte përafërsisht e njëjtë, por pjesa e rsync ishte afërsisht një e katërta e kohës):
ĂshtĂ« qartĂ« se njĂ« proces i tillĂ« kopjimi rezervĂ« Ă«shtĂ« i pĂ«rshtatshĂ«m vetĂ«m kur ndodhin ndryshime relativisht tĂ« rralla dhe tĂ« vogla. Gjithashtu, Ă«shtĂ« shumĂ« e dĂ«shirueshme tĂ« kufizohet puna e zbackup nĂ« 1 thread, pĂ«rndryshe do tĂ« ketĂ« njĂ« ngarkesĂ« tĂ« lartĂ« nĂ« procesor, pasi programi di tĂ« punojĂ« shumĂ« mirĂ« nĂ« disa thread. Ngarkesa nĂ« disk ishte e vogĂ«l, qĂ« nĂ« pĂ«rgjithĂ«si, me sistemin modern tĂ« pĂ«rbĂ«rjes sĂ« diskut tĂ« bazuar nĂ« ssd, do tĂ« jetĂ« e padukshme. Gjithashtu, Ă«shtĂ« qartĂ« se procesi i sinkronizimit tĂ« tĂ« dhĂ«nave tĂ« depozitĂ«s nĂ« serverin e largĂ«t po niset, shpejtĂ«sia e punĂ«s Ă«shtĂ« e krahasueshme me rsync-nĂ« e zakonshme dhe ngushtohet nĂ« performancĂ«n e sistemit tĂ« diskut tĂ« serverit pĂ«r ruajtjen e kopjeve rezervĂ«. NjĂ« mangĂ«si e qasjes Ă«shtĂ« ruajtja e depozitĂ«s lokale dhe, si pasojĂ«, â dyfishimi i tĂ« dhĂ«nave.
Ndryshe dhe më praktike është varianti i dytë me nisjen e zbackup direkt në serverin e ruajtjes së kopjeve rezervë.
Fillimisht do të kontrollohet funksionimi pa përdorur enkriptim me kompresorin lzma:
Koha e ekzekutimit për çdo test:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Nëse aktivizohet enkriptimi me përdorimin e aes, rezultatet janë mjaft të afërta:
Koha e ekzekutimit në të njëjtat të dhëna, me enkriptim:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Nëse enkriptimi kombinohet me kompresionin lzo, del kështu:
Koha e funksionimit:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Të dhënat e rezultatit ishin relativisht të njëjta dhe përbënin 13 GB. Kjo tregon se deduplication funksionon korrekt. Gjithashtu, aplikimi i lzo mbi të dhënat e kompresuara ka një efekt të dukshëm, me kohën totale të punës së zbackup duke iu afruar duplicity/duplicati, megjithatë mbetet pas atyre të bazuara në librsync nga 2-5 herë.
Avantazhet janë të dukshme - kursim hapësire disk në serverin e ruajtjes së kopjeve rezervë. Sa i përket mjeteve për verifikimin e repositorit - autori i zbackup nuk i ka parashikuar ato, rekomandohet të përdoret një grumbull diskesh me qëndrueshmëri ose një ofrues të shërbimeve në re.
Në përgjithësi një përshtypje mjaft e mirë, përkundër faktit se projekti është rreth 3 vjet pa përparim (kërkesa e fundit për funksionalitet ishte rreth një vit më parë, por pa përgjigje).
Testimi i borgbackup
Borgbackup Ă«shtĂ« njĂ« fork i attic, njĂ« tjetĂ«r sistem i ngjashĂ«m me zbackup. ĂshtĂ« shkruar nĂ« python, ka njĂ« listĂ« funksionesh tĂ« ngjashme me zbackup, por pĂ«rveç kĂ«saj di tĂ«:
- Muntosh kopjet rezervë përmes fuse
- Kontrollosh përmbajtjen e repositorit
- Punoje në modin klient-server
- Përdorësh kompresorë të ndryshëm për të dhënat, si dhe përcaktimin heuristik të llojit të skedarit gjatë kompresimit.
- 2 variante enkriptimi, aes dhe blake
- Një mjet të integruar për
kontrollin e performancës
borgbackup benchmark crud://backup_server/repo/path local_dir
Rezultatet dolën këto:
C-Z-BIG 96.51 MB/s (10 100.00 MB skedarë me zeros: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB skedarë me zeros: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB skedarë me zeros: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB skedarë me zeros: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB skedarë të rastit: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB skedarë të rastit: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB skedarë të rastit: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB skedarë të rastit: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB skedarë me zeros: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB skedarë me zeros: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB skedarë me zeros: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB skedarë me zeros: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB skedarë të rastit: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB skedar të rastësishëm: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB skedar të rastësishëm: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB skedar të rastësishëm: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB skedar të gjitha zero: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB skedar të gjitha zero: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB skedar të gjitha zero: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB skedar të gjitha zero: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB skedar të rastësishëm: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB skedar të rastësishëm: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB skedar të rastësishëm: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB skedar të rastësishëm: 5.32s)
Gjatë testimit do të përdoret heuristika për kompresimin me përcaktimin e tipit të skedarit (kompresimi automatik), dhe rezultatet do të jenë si më poshtë:
Fillimisht do të verifikojmë funksionimin pa enkriptim:
Koha e funksionimit:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Nëse aktivizohet autorizimi i depozitës (rethi i autorizuar), rezultatet do të jenë afër:
Koha e funksionimit:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Kur aktivizohet enkriptimi aes rezultatet nuk përkeqësohen shumë:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Por nëse e zëvendësojmë aes me blake, situata do të përmirësohet:
Koha e funksionimit:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Si në rastin e zbackup, madhësia e repositorit ishte 13GB dhe pak më pak, që në përgjithësi është e pritshme. Koha e funksionimit ishte mjaft inkurajuese, duke u krahasuar me zgjidhjet e bazuara në librsync, duke ofruar mundësi shumë më të gjera. Një tjetër avantazh ishte mundësia për të caktuar parametra të ndryshëm përmes variablave të mjedisit, e cila ofron një përparësi të konsiderueshme kur përdoret borgbackup në mënyrë automatike. Po ashtu, ngarkesa gjatë kopjimit të rezervave ishte mjaft e ulët: sipas ngarkesës së procesorit, borgbackup punon në 1 rrjedh.
Nuk u zbuluan disavantazhe të veçanta gjatë përdorimit.
Testimi i restic
MegjithĂ«se restic Ă«shtĂ« njĂ« zgjidhje relativisht e re (dy kandidatĂ«t e parĂ« ishin tĂ« njohur qĂ« nga viti 2013 e mĂ« herĂ«t), ai ka karakteristika mjaft tĂ« mira. ĂshtĂ« shkruar nĂ« Go.
NĂ« krahasim me zbackup, ofron gjithashtu:
- Kontrollin e integritetit të repositorit (duke përfshirë kontrollin në pjesë).
- NjĂ« listĂ« tĂ« madhe tĂ« protokolleve dhe ofruesve tĂ« mbĂ«shtetjes pĂ«r ruajtjen e kopjeve rezervĂ«, si dhe mbĂ«shtetje pĂ«r rclone â rsync pĂ«r zgjidhjet âcloudâ.
- Krahasimi i 2 kopjeve rezervë me njëri-tjetrin.
- Mundësia për të montuar repositorin përmes fuse.
NĂ« pĂ«rgjithĂ«si, lista e mundĂ«sive Ă«shtĂ« mjaft e ngjashme me borgbackup, ndonjĂ«herĂ« mĂ« shumĂ«, ndonjĂ«herĂ« mĂ« pak. Nga veçoritĂ« â mungesa e mundĂ«sisĂ« pĂ«r tĂ« çaktivizuar enkriptimin, prandaj, kopjet rezervĂ« do tĂ« jenĂ« gjithmonĂ« tĂ« enkriptuara. Le tĂ« shohim nĂ« praktikĂ« se çfarĂ« mund tĂ« nxjerrim nga kjo softuer:
Rezultatet ishin si më poshtë:
Koha e funksionimit:
Ekzekutimi 1
Ekzekutimi 2
Ekzekutimi 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Rezultatet e punës janë gjithashtu krahasuese me zgjidhjet që bazohen në rsync dhe, në përgjithësi, janë mjaft të ngjashme me borgbackup, por ngarkesa në procesor është më e lartë (punon me disa rryma) dhe me një formë zig-zag.
Më shumë gjasa, programi has në performancën e nën-sistemit të diskut në serverin e ruajtjes së të dhënave, ashtu siç ka ndodhur tashmë me rsync. Madhësia e depozitës ishte 13GB, si me zbackup ashtu edhe me borgbackup, nuk u gjetën disavantazhe të dukshme gjatë përdorimit të kësaj zgjidhjeje.
Rezultatet
Në fakt, të gjithë kandidatet kishin tregues të ngjashëm, megjithatë, me çmime të ndryshme. Borgbackup i tregoi rezultatet më të mira, pak më i ngadalshëm ishte restic, zbackup nuk ka vlerë të fillohet të përdoret,
dhe nĂ«se Ă«shtĂ« duke u pĂ«rdorur tashmĂ« â provoni tĂ« kaloni nĂ« borgbackup ose restic.
PĂ«rfundimet
Zgjidhja më premtuese duket të jetë restic, pasi ka raportin më të mirë të mundësive ndaj shpejtësisë, por për momentin nuk do të nxitojmë me përfundimet tona të përgjithshme.
Borgbackup në thelb nuk është më pak i mirë, ndërsa zbackup ndoshta duhet zëvendësuar. Megjithatë, për të garantuar funksionimin e rregullave 3-2-1, zbackup akoma mund të përdoret. Për shembull, në përputhje me mjetet përkopjimi që bazohen në (lib)rsync.
Ankandi
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
