Ky artikull do të shqyrtojë softuerin rezervë që, duke e ndarë rrjedhën e të dhënave në komponentë të veçantë (copa), formon një depo.
Komponentët e depove mund të kompresohen dhe kodohen më tej, dhe më e rëndësishmja - gjatë proceseve të përsëritura rezervë - të ripërdoren.
Një kopje rezervë në një depo të tillë është një zinxhir i emërtuar i komponentëve të lidhur me njëri-tjetrin, për shembull, bazuar në funksione të ndryshme hash.
Ka disa zgjidhje të ngjashme, unë do të fokusohem në 3: zbackup, borgbackup dhe restic.
Rezultatet e pritura
Meqenëse të gjithë aplikantët kërkojnë krijimin e një depoje në një mënyrë ose në një tjetër, një nga faktorët më të rëndësishëm do të jetë vlerësimi i madhësisë së depove. Në mënyrë ideale, madhësia e tij duhet të jetë jo më shumë se 13 GB sipas metodologjisë së pranuar, ose edhe më pak - subjekt i optimizimit të mirë.
Është gjithashtu shumë e dëshirueshme që të jeni në gjendje të krijoni kopje rezervë të skedarëve drejtpërdrejt, pa përdorur arkivues si tar, si dhe të punoni me ssh/sftp pa mjete shtesë si rsync dhe sshfs.
Sjellja kur krijoni kopje rezervë:
- Madhësia e depove do të jetë e barabartë me madhësinë e ndryshimeve, ose më pak.
- Ngarkesa e rëndë e CPU-së pritet kur përdoret ngjeshja dhe/ose enkriptimi, dhe ngarkesa mjaft e lartë e rrjetit dhe e diskut është e mundshme nëse procesi i arkivimit dhe/ose i enkriptimit po ekzekutohet në një server të ruajtjes rezervë.
- Nëse depoja është e dëmtuar, një gabim i vonuar ka të ngjarë si kur krijoni kopje rezervë të reja, ashtu edhe kur përpiqeni të rivendosni. Është e nevojshme të planifikohen masa shtesë për të siguruar integritetin e depove ose të përdoren mjete të integruara për të kontrolluar integritetin e tij.
Puna me katranin merret si vlerë referencë, siç u tregua në një nga artikujt e mëparshëm.
Testimi i zbackup-it
Mekanizmi i përgjithshëm i zbackup-it është që programi gjen në zonat hyrëse të rrjedhës së të dhënave që përmbajnë të njëjtat të dhëna, pastaj i ngjesh dhe i kodon ato në mënyrë opsionale, duke ruajtur secilën zonë vetëm një herë.
Deduplikimi përdor një funksion hash të unazës 64-bit me një dritare rrëshqitëse për të kontrolluar për përputhje bajt pas bajt me blloqet ekzistuese të të dhënave (ngjashëm me mënyrën se si e zbaton rsync).
Lzma dhe lzo me shumë fije përdoren për kompresim, dhe aes për enkriptim. Versionet e fundit kanë mundësinë për të fshirë të dhënat e vjetra nga depoja në të ardhmen.
Programi është i shkruar në C++ me varësi minimale. Autori me sa duket u frymëzua nga unix-way, kështu që programi pranon të dhëna në stdin kur krijon kopje rezervë, duke prodhuar një rrjedhë të ngjashme të të dhënave në stdout gjatë restaurimit. Kështu, zbackup mund të përdoret si një "bllok ndërtimi" shumë i mirë kur shkruani zgjidhjet tuaja rezervë. Për shembull, autori i artikullit e ka përdorur këtë program si mjetin kryesor rezervë për makinat shtëpiake që rreth vitit 2014.
Rrjedha e të dhënave do të jetë një tar i rregullt nëse nuk përcaktohet ndryshe.
Le të shohim se cilat janë rezultatet:
Puna u kontrollua në 2 opsione:
- krijohet një depo dhe lëshohet zbackup në server me të dhënat burimore, më pas përmbajtja e depove transferohet në serverin e ruajtjes rezervë.
- krijohet një depo në serverin e ruajtjes rezervë, zbackup lëshohet përmes ssh në serverin e ruajtjes rezervë dhe të dhënat i dërgohen atij përmes tubit.
Rezultatet e opsionit të parë ishin si më poshtë: 43m11s - kur përdorni një depo të pakriptuar dhe kompresorin lzma, 19m13s - kur zëvendësoni kompresorin me lzo.
Ngarkesa në server me të dhënat origjinale ishte si më poshtë (një shembull me lzma tregohet; me lzo kishte afërsisht të njëjtën pamje, por pjesa e rsync ishte afërsisht një e katërta e kohës):
Është e qartë se një proces i tillë rezervë është i përshtatshëm vetëm për ndryshime relativisht të rralla dhe të vogla. Është gjithashtu shumë e këshillueshme që të kufizohet zbackup në 1 thread, përndryshe do të ketë një ngarkesë shumë të lartë CPU, sepse Programi është shumë i mirë për të punuar në tema të shumta. Ngarkesa në disk ishte e vogël, e cila në përgjithësi nuk do të ishte e dukshme me një nënsistem disku modern të bazuar në ssd. Ju gjithashtu mund të shihni qartë fillimin e procesit të sinkronizimit të të dhënave të depove në një server të largët; shpejtësia e funksionimit është e krahasueshme me rsync-in e rregullt dhe varet nga performanca e nënsistemit të diskut të serverit të ruajtjes rezervë. Disavantazhi i kësaj qasjeje është ruajtja e një depoje lokale dhe, si rezultat, dyfishimi i të dhënave.
Më interesante dhe më e zbatueshme në praktikë është opsioni i dytë, duke ekzekutuar zbackup direkt në serverin e ruajtjes rezervë.
Së pari, ne do të testojmë funksionimin pa përdorur enkriptim me kompresorin lzma:
Koha e funksionimit të çdo testi:
Nisja 1
Nisja 2
Nisja 3
39 m45s
40 m20s
40 m3s
7 m36s
8 m3s
7 m48s
15 m35s
15 m48s
15 m38s
Nëse aktivizoni enkriptimin duke përdorur aes, rezultatet janë mjaft afër:
Koha e funksionimit në të njëjtat të dhëna, me kriptim:
Nisja 1
Nisja 2
Nisja 3
43 m40s
44 m12s
44 m3s
8 m3s
8 m15s
8 m12s
15 m0s
15 m40s
15 m25s
Nëse kriptimi kombinohet me kompresimin duke përdorur lzo, duket kështu:
Orari:
Nisja 1
Nisja 2
Nisja 3
18 m2s
18 m15s
18 m12s
5 m13s
5 m24s
5 m20s
8 m48s
9 m3s
8 m51s
Madhësia e depove që rezulton ishte relativisht e njëjtë me 13 GB. Kjo do të thotë që deduplikimi po funksionon si duhet. Gjithashtu, në të dhënat tashmë të kompresuara, përdorimi i lzo jep një efekt të dukshëm; për sa i përket kohës totale të funksionimit, zbackup i afrohet duplicitetit/duplikatit, por mbetet pas atyre të bazuara në librsync me 2-5 herë.
Përparësitë janë të dukshme - kursimi i hapësirës në disk në serverin e ruajtjes rezervë. Sa i përket mjeteve të kontrollit të depove, autori i zbackup nuk i ofron ato; rekomandohet të përdorni një grup disku tolerant ndaj gabimeve ose ofrues cloud.
Në përgjithësi, një përshtypje shumë e mirë, pavarësisht se projekti ka qëndruar në vend për rreth 3 vjet (kërkesa e fundit për funksion ishte rreth një vit më parë, por pa përgjigje).
Testimi i borgbackup-it
Borgbackup është një pirun i papafingo, një sistem tjetër i ngjashëm me zbackup. I shkruar në python, ai ka një listë të aftësive të ngjashme me zbackup, por gjithashtu mund të:
- Montoni kopjet rezervë përmes siguresave
- Kontrolloni përmbajtjen e depove
- Punoni në modalitetin klient-server
- Përdorni kompresorë të ndryshëm për të dhënat, si dhe përcaktimin heuristik të llojit të skedarit gjatë kompresimit të tij.
- 2 opsione enkriptimi, aes dhe blake
- Mjet i integruar për
kontrollet e performancës
pikë referimi borgbackup crud ssh://backup_server/repo/path local_dir
Rezultatet ishin si më poshtë:
C-Z-BIG 96.51 MB/s (10 100.00 MB skedarë të gjitha zero: 10.36 s)
R-Z-BIG 57.22 MB/s (10 100.00 MB skedarë të gjitha zero: 17.48 s)
U-Z-BIG 253.63 MB/s (10 100.00 MB skedarë të gjitha zero: 3.94 s)
D-Z-BIG 351.06 MB/s (10 100.00 MB skedarë të gjitha zero: 2.85 s)
C-R-BIG 34.30 MB/s (10 100.00 MB skedarë të rastësishëm: 29.15 sekonda)
R-R-BIG 60.69 MB/s (10 100.00 MB skedarë të rastësishëm: 16.48 sekonda)
U-R-BIG 311.06 MB/s (10 100.00 MB skedarë të rastësishëm: 3.21 sekonda)
D-R-BIG 72.63 MB/s (10 100.00 MB skedarë të rastësishëm: 13.77 sekonda)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB skedarë të gjitha zero: 9.21 s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB skedarë të gjitha zero: 13.13 s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB skedarë të gjitha zero: 3.02 s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB skedarë të gjitha zero: 2.58 s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB skedarë të rastësishëm: 26.45 sekonda)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB skedarë të rastësishëm: 14.51 sekonda)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB skedarë të rastësishëm: 2.88 sekonda)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB skedarë të rastësishëm: 20.49 sekonda)
C-Z-VOGLA 11.72 MB/s (10000 Skedarë 10.00 kB të gjitha zero: 8.53 s)
R-Z-VOGLA 32.57 MB/s (10000 Skedarë 10.00 kB të gjitha zero: 3.07 s)
U-Z-VOGLA 19.37 MB/s (10000 Skedarë 10.00 kB të gjitha zero: 5.16 s)
D-Z-VOGLA 33.71 MB/s (10000 Skedarë 10.00 kB të gjitha zero: 2.97 s)
C-R-VOGLA 6.85 MB/s (10000 Skedarë të rastësishëm 10.00 kB: 14.60 sekonda)
R-R-VOGLA 31.27 MB/s (10000 Skedarë të rastësishëm 10.00 kB: 3.20 sekonda)
U-R-VOGLA 12.28 MB/s (10000 Skedarë të rastësishëm 10.00 kB: 8.14 sekonda)
D-R-VOGLA 18.78 MB/s (10000 Skedarë të rastësishëm 10.00 kB: 5.32 sekonda)
Gjatë testimit, heuristikat e kompresimit do të përdoren për të përcaktuar llojin e skedarit (compression auto), dhe rezultatet do të jenë si më poshtë:
Së pari, le të kontrollojmë se si funksionon pa kriptim:
Orari:
Nisja 1
Nisja 2
Nisja 3
4 m6s
4 m10s
4 m5s
56s
58s
54s
1 m26s
1 m34s
1 m30s
Nëse aktivizoni autorizimin e depove (modaliteti i vërtetuar), rezultatet do të jenë afër:
Orari:
Nisja 1
Nisja 2
Nisja 3
4 m11s
4 m20s
4 m12s
1 m0s
1 m3s
1 m2s
1 m30s
1 m34s
1 m31s
Kur u aktivizua enkriptimi aes, rezultatet nuk u përkeqësuan shumë:
Nisja 1
Nisja 2
Nisja 3
4 m55s
5 m2s
4 m58s
1 m0s
1 m2s
1 m0s
1 m49s
1 m50s
1 m50s
Dhe nëse e ndryshoni aes në blake, situata do të përmirësohet plotësisht:
Orari:
Nisja 1
Nisja 2
Nisja 3
4 m33s
4 m43s
4 m40s
59s
1 m0s
1 m0s
1 m38s
1 m43s
1 m40s
Ashtu si në rastin e zbackup, madhësia e depove ishte 13 GB dhe madje pak më pak, gjë që përgjithësisht pritet. Unë isha shumë i kënaqur me kohën e funksionimit; është e krahasueshme me zgjidhjet e bazuara në librsync, duke ofruar aftësi shumë më të gjera. Unë isha gjithashtu i kënaqur me aftësinë për të vendosur parametra të ndryshëm përmes variablave të mjedisit, gjë që jep një avantazh shumë serioz kur përdorni borgbackup në modalitetin automatik. Unë gjithashtu isha i kënaqur me ngarkesën gjatë kopjimit: duke gjykuar nga ngarkesa e procesorit, borgbackup funksionon në 1 fije.
Nuk kishte disavantazhe të veçanta gjatë përdorimit të tij.
testimi restrik
Pavarësisht se restiku është një zgjidhje mjaft e re (2 kandidatët e parë njiheshin në vitin 2013 e lart), ajo ka karakteristika mjaft të mira. Shkruar në Go.
Kur krahasohet me zbackup, ai gjithashtu jep:
- Kontrollimi i integritetit të depove (përfshirë kontrollin në pjesë).
- Një listë e madhe e protokolleve dhe ofruesve të mbështetur 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.
- Montimi i depove nëpërmjet siguresës.
Në përgjithësi, lista e veçorive është mjaft afër borgbackup-it, në disa vende më shumë, në të tjera më pak. Një nga veçoritë është se nuk ka asnjë mënyrë për të çaktivizuar enkriptimin, dhe për këtë arsye kopjet rezervë do të jenë gjithmonë të koduara. Le të shohim në praktikë se çfarë mund të shtrydhet nga ky softuer:
Rezultatet ishin si më poshtë:
Orari:
Nisja 1
Nisja 2
Nisja 3
5 m25s
5 m50s
5 m38s
35s
38s
36s
1 m54s
2 m2s
1 m58s
Rezultatet e performancës janë gjithashtu të krahasueshme me zgjidhjet e bazuara në rsync dhe, në përgjithësi, shumë afër borgbackup-it, por ngarkesa e CPU-së është më e lartë (fije të shumta që funksionojnë) dhe dhëmbë sharrë.
Me shumë mundësi, programi është i kufizuar nga performanca e nënsistemit të diskut në serverin e ruajtjes së të dhënave, siç ishte tashmë rasti me rsync. Madhësia e depove ishte 13 GB, ashtu si zbackup ose borgbackup, nuk kishte disavantazhe të dukshme kur përdorni këtë zgjidhje.
Gjetjet
Në fakt, të gjithë kandidatët arritën rezultate të ngjashme, por me çmime të ndryshme. Borgbackup performoi më së miri nga të gjitha, restiku ishte pak më i ngadalshëm, zbackup ndoshta nuk ia vlen të filloni të përdorni,
dhe nëse është tashmë në përdorim, provo ta ndryshosh në borgbackup ose restic.
Gjetjet
Zgjidhja më premtuese duket se është rezistenca, sepse... është ai që ka raportin më të mirë të aftësive me shpejtësinë e funksionimit, por le të mos nxitojmë në përfundime të përgjithshme tani për tani.
Borgbackup në thelb nuk është më keq, por zbackup ndoshta zëvendësohet më mirë. Vërtetë, zbackup mund të përdoret ende për të siguruar funksionimin e rregullit 3-2-1. Për shembull, përveç objekteve rezervë të bazuara në (lib)rsync.
Shpallje
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