Në këtë artikull do të shqyrtohen mjetet software për kopjim rezervë, të cilat, duke ndarë fluksin e të dhënave në komponente të veçanta (chunks), formojnë një depo.
Komponentët e depozitës mund të kompresohen dhe të enkriptohen, dhe më e rëndësishmja, gjatë proceseve të përsëritura të kopjimit rezervë, mund të ripërdoren.
Një kopje rezervë në një depo të tillë është një zinxhir i emëruar i komponenteve që lidhen njëri me tjetrin, për shembull, mbi baza të ndryshme funksionesh hash.
Ka disa të tilla zgjidhje, unë do të ndalem në 3: zbackup, borgbackup dhe restic.
Rezultatet e pritura
Duke qenë se të gjithë pretenduesit kërkojnë njëri në një mënyrë apo në një tjetër krijimin e një depoje, një nga faktorët më të rëndësishëm do të jetë vlerësimi i madhësisë së depozitës. Në rastin ideal, madhësia e saj nuk duhet të kalojë 13 GB sipas metodologjisë së pranuar, ose madje edhe më pak, nëse optimizimi është i mirë.
Gjithashtu, është jashtëzakonisht e dëshirueshme të ketë mundësinë për të krijuar kopje rezervë të skedarëve direkt, pa përdorur arkivues si tar, si dhe të funksionojë me ssh/sftp pa mjete shtesë si rsync dhe sshfs.
Shtypi gjatë krijimit të kopjimeve rezervë:
- Madhësia e depozitës do të jetë e barabartë me madhësinë e ndryshimeve, ose më pak.
- Pritet një ngarkesë e madhe e procesorit gjatë përdorimit të kompresimit dhe/ose enkriptimit, si dhe ka një probabilitet të konsiderueshëm për ngarkesë në rrjet dhe në sistemin e diskut, nëse procesi i arkivimit dhe/ose enkriptimit do të funksionojë në serverin që ruan kopjet rezervë.
- Nëse depoja dëmtohet, është e mundur të ndodhin gabime të vonuara si gjatë krijimit të kopjeve rezervë të reja ashtu edhe gjatë përpjekjeve për rikuperim. Duhet planifikuar masa shtesë për ruajtjen e integritetit të depozitës ose të përdoren mjete të integruara për kontrollin e integritetit të saj.
Si një vlerë referimi, është pranuar puna me tar, ashtu siç u tregua në një nga artikujt e kaluar.
Testimi i zbackup
Mekanizmi i përgjithshëm i funksionimit të zbackup përfshin faktin se programi gjen në fluksin e të dhënave, të ofruara në hyrje, zona që përmbajnë të dhëna të njëjta, pastaj opcionalisht i kompreson, i enkripton, duke ruajtur çdo zonë vetëm një herë.
Për deduplication, përdoret një funksion hash i ringës 64-bit me një dritare lëvizëse për kontrollin byte për byte të përshtatjes me blloqet ekzistues të të dhënave (ndërlikuar siç realizohet në rsync).
Për kompresimin përdoren lzma dhe lzo në një ekzekutim me shumë fije, dhe për enkriptimin — aes. Në versionet më të fundit ekziston mundësia në të ardhmen për të fshirë të dhënat e vjetra nga repositori.
Programi është shkruar në C++ me varësi minimale. Autori duket se është frymëzuar nga UNIX-way, kështu që programa merr të dhënat 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ë 'tullë' e shkëlqyer në krijimin e zgjidhjeve tuaja të kopjimit. Për shembull, për autorin e artikullit ky program është mjeti kryesor i kopjimit për kompjuterët e shtëpisë që nga viti 2014.
Si rrjedhë të dhënash do të përdoret tar-i standard, nëse nuk shprehet ndryshe.
Të shohim çfarë do të jenë rezultatet:
Kontrolli i funksionimit është realizuar në 2 variante:
- krijohet një repositor dhe zbackup aktivizohet në serverin me të dhënat origjinale, pastaj përmbajtja e repositorit transferohet në serverin e ruajtjes së kopjeve rezervë.
- krijohet një repositor në serverin e ruajtjes së kopjeve rezervë, zbackup aktivizohet përmes ssh në serverin e ruajtjes së kopjeve rezervë, dhe të dhënat i jepen atij përmes pipe.
Rezultatet e variantit të parë ishin si më poshtë: 43m11s — duke përdorur repositorin e pa enkriptuar dhe kompresorin lzma, 19m13s — duke e zëvendësuar kompresorin me lzo.
Ngarkesa në serverin me të dhënat origjinale ishte si më poshtë (tregohet një shembull me lzma, me lzo ishte një pamje e ngjashme, por pjesa e rsync ishte rreth një të katërtën e kohës):
Është e qartë se një proces i tillë rezervimi është i përshtatshëm vetëm për ndryshime relativisht të rralla dhe të vogla. Gjithashtu, është shumë e dëshirueshme të kufizohet puna e zbackup në 1 proces, nd otherwise do të ketë ngarkesë shumë të lartë në procesor, pasi programi është shumë i aftë për të punuar në disa procese. Ngarkesa në disk ishte e vogël, që në përgjithësi me një sistem të modern të disqeve të bazuar në SSD do të kalojë pa u vënë re. Është gjithashtu shumë e qartë që procesi i sinkronizimit të të dhënave të depozitës po fillon në serverin e largët, shpejtësia e punës është e krahasueshme me rsync-n e zakonshëm dhe mbështetet në performancën e sistemit të disqeve të serverit të ruajtjes së kopjeve. Një mangësi e këtij qasjeje është ruajtja e depozitës lokale dhe, si rezultat, - dyfishimi i të dhënave.
Varianti i dytë, që fillon zbackup direkt në serverin e ruajtjes së kopjeve, është më interesant dhe më praktik.
Për fillim, do të kontrollohet funksionimi pa përdorimin e enkriptimit me kompresorin lzma:
Koha e punës për secilën nisje testuese:
Nisja 1
Nisja 2
Nisja 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Nëse aktivizohet enkriptimi me aes, rezultatet janë mjaft të ngjashme:
Koha e punës mbi të dhënat e njëjta, me enkriptim:
Nisja 1
Nisja 2
Nisja 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Nëse enkriptimi kombinohet me kompresimin në lzo, doli kështu:
Koha e punës:
Nisja 1
Nisja 2
Nisja 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Të dhënat e depozitës rezultuese ishin relativisht të njëjta dhe arrinin në 13 GB. Kjo do të thotë se deduplikimi punon siç duhet. Gjithashtu, përdorimi i lzo mbi të dhënat tashmë të kompresuara ka një efekt të ndjeshëm, në tërësi koha e punës e zbackup-i afrohet shumë me duplicity/duplicati, megjithatë mbetet prapa atyre që bazohen në librsync me 2-5 herë.
Përparësitë janë të qarta - kursimi i hapësirës në disk në serverin e ruajtjes së kopjeve. Sa i përket mjeteve për verifikimin e depozitës - ato nuk janë parashikuar nga autori i zbackup-it, rekomandohet të përdoret një grumbull diskësh me qëndrueshmëri ose një ofrues cloud.
Përgjithësisht, përshtypja është mjaft e mirë, përveç se projekti është rreth 3 vjet që ka mbetur në vend (kërkesa më e fundit funksionale ishte rreth një viti më parë, por pa përgjigje).
Testimi i borgbackup
Borgbackup është një fork i attic, një tjetër sistem i ngjashëm me zbackup. E shkruar në python, ka një listë mundësish të ngjashme me zbackup-in, por për më tepër, ajo di të:
- Mundoni kopjet e sigurta përmes fuse
- Kontrolloni përmbajtjen e depozitës
- Punoni në modalitetin klient-server
- Përdorni kompresorë të ndryshëm për të dhënat dhe përcaktoni automatikisht llojin e skedarit gjatë kompresimit.
- 2 variante të enkriptimit, aes dhe blake
- Mjet i integruar për
kontrollin e performancës
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Rezultatet dolën të tilla:
C-Z-BIG 96.51 MB/s (10 100.00 MB skedarë të gjithë zero: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB skedarë të gjithë zero: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB skedarë të gjithë zero: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB skedarë të gjithë zero: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB skedarë të rastësishëm: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB skedarë të rastësishëm: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB skedarë të rastësishëm: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB skedarë të rastësishëm: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB skedarë të gjithë zero: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB skedarë të gjithë zero: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB skedarë të gjithë zero: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB skedarë të gjithë zero: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB skedarë të rastësishëm: 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ë gjithë zero: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB skedarë të gjithë zero: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB skedarë të gjithë zero: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB skedarë të gjithë 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 gjatë kompresimit me përcaktimin e llojit të skedarit (compression auto), dhe rezultatet do të jenë këto:
Fillimisht, do të kontrollojmë funksionimin pa enkriptim:
Koha e punës:
Nisja 1
Nisja 2
Nisja 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Nëse aktivizoni autorizimin e depozitës (modaliteti authenticated), rezultatet do të jenë të ngjashme:
Koha e punës:
Nisja 1
Nisja 2
Nisja 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Kur aktivizohet enkriptimi aes, rezultatet nuk përkeqësohen shumë:
Nisja 1
Nisja 2
Nisja 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Dhe nëse zëvendësojmë aes me blake, situata përmirësohet ndjeshëm:
Koha e punës:
Nisja 1
Nisja 2
Nisja 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Ashtu siç ndodh me zbackup, madhësia e depozitës ishte 13GB dhe madje pak më pak, gjë që ishte e pritur. Kohëzgjatja e punës ishte shumë e kënaqshme, e krahasueshme me zgjidhjet e bazuara në librsync, duke ofruar mundësi shumë më të gjera. Po ashtu, ishte e këndshme të kishte mundësinë të vendosësh parametrat e ndryshëm përmes variablave të mjedisit, që ofron një avantazh të rëndësishëm kur përdoret borgbackup në modalitetin automatik. Po ashtu, përdorimi gjatë kopjimit të rezervave ishte emigrues: gjykuar nga ngarkesa e procesorit — borgbackup punon në 1 rrjedhë.
Nuk u gjetën disavantazhe të veçanta gjatë përdorimit.
Testimi i restic
Megjithëse restic është një zgjidhje relativisht e re (kandidatet e para ishin të njohura që me 2013 dhe më herët), ai ka karakteristika mjaft të mira. Është shkruar në Go.
Nëse e krahasojmë me zbackup, ai ofron gjithashtu:
- Kontrollin e integritetit të depozitës (duke përfshirë kontrollin sipas pjesëve).
- Një listë të madhe protokoresh dhe ofruesish për ruajtjen e kopjeve rezervë, si dhe mbështetje për rclone - rsync për zgjidhje "në cloud".
- Krahasimin e 2 kopjeve rezervë me njëra-tjetrën.
- Montimin e depozitës përmes fuse.
Në përgjithësi, lista e mundësive është mjaft e afërt me borgbackup, ndonjëherë më shumë, ndonjëherë më pak. Nga karakteristikat e veçanta - mungesa e mundësisë për të çaktivizuar enkriptimin, pra, kopjet rezervë gjithmonë do të jenë të enkriptohen. Le të shohim në praktikë, se çfarë mund të nxjerrim nga kjo software:
Rezultatet ishin si më poshtë:
Koha e punës:
Nisja 1
Nisja 2
Nisja 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Rezultatet gjithashtu janë të krahasueshme me zgjidhje të bazuara në rsync dhe, në përgjithësi, shumë afër borgbackup, por ngarkesa në procesor është më e lartë (punon me disa thjeshtësi) dhe me një formë zigzag.
Me shumë gjasë, programma depërton në performancën e sistemit të diskut në serverin e ruajtjes së të dhënave, ashtu siç ndodhi me rsync. Madhësia e depozitës ishte 13GB, si te zbackup apo borgbackup, nuk u zbuluan disavantazhe të qarta kur përdoret kjo zgjidhje.
Rezultatet
Në fakt, të gjithë kandidatët kishin tregues të ngjashëm, megjithatë me çmime të ndryshme. Borgbackup tregohet më i mirë, pak më ngadalë është restic, zbackup, me sa duket, nuk ia vlen të fillosh ta përdorësh,
dhe nëse është përdorur tashmë - provo ta ndryshosh me borgbackup ose restic.
Përfundimet
Zgjidhja më premtuese duket të jetë restic, pasi ai ka marrëdhënien më të mirë të mundësive me shpejtësinë e punës, por për momentin le të mos nxitimi me përfundimet e përgjithshme.
Borgbackup në parim nuk është më i dobët, ndërsa zbackup për të përmirësuar shpresohet që të zëvendësohet. Megjithatë, për të siguruar funksionimin e rregullit 3-2-1, zbackup akoma mund të përdoret. Për shembull, në mënyrë shtesë ndaj mjeteve të kopjimit të bazuara në (lib)rsync.
Njoftim
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
