Në këtë artikull do të bëhet një krahasim i mjeteve të kopjimit, por së pari është e rëndësishme të kuptohet se si ato përballen shpejt dhe mirë me rikuperimin e të dhënave nga kopjet rezervë.
Për thjeshtësi krahasimi do të shqyrtohet rikuperimi nga një kopje rezervë e plotë, sidomos sepse ky mod i punës mbështetet nga të gjithë kandidatët. Për thjeshtësi, numrat janë marrë të mesatarizuar (mesatarja aritmetike nga disa ekzekutime). Rezultatet do të përmblidhen në një tabelë, në të cilën do të ketë gjithashtu informacion mbi mundësitë: prania e një ndërfaqeje në web, thjeshtësia në konfigurim dhe përdorim, aftësia për automatizim, si dhe mundësi të tjera shtesë (për shembull, kontrolli i integritetit të të dhënave) etj. Grafikët do të tregojnë ngarkesën e serverit, ku të dhënat do të aplikohen (jo serveri për ruajtjen e kopjeve rezervë).
Rikuperimi i të dhënave
Si pikë referimi do të përdoren rsync dhe tar, pasi skritpat më të thjeshta për marrjen e kopjeve rezervë.
Rsync e përfundoi setin e të dhënave testuese për 4 minuta dhe 28 sekonda, duke treguar
këtë ngarkesë
Procedura e rikuperimit u pĂ«rball me kufizimin e sistemit tĂ« disave tĂ« diskut tĂ« serverit tĂ« ruajtjes sĂ« kopjeve rezervĂ« (grafikĂ«t zigzag). Gjithashtu, ngarkesa e njĂ« bĂ«rthame Ă«shtĂ« e dukshme pa probleme tĂ« veçanta (iowait i ulĂ«t dhe softirq â pa probleme me diskun dhe rrjetin pĂ«rkatĂ«s). Duke qenĂ« se dy programet e tjera, dmth. rdiff-backup dhe rsnapshot, janĂ« tĂ« bazuara nĂ« rsync, si dhe ofrojnĂ« rsync si metodĂ« rikuperimi, ato do tĂ« kenĂ« njĂ« profil ngarkese dhe kohĂ« rikuperimi tĂ« ngjashme.
Tar u përfundua pak më shpejt, për
2 minuta dhe 43 sekonda:
Ngarkesa e plotĂ« e sistemit ishte mĂ« e lartĂ« nĂ« mesatarisht 20% pĂ«r shkak tĂ« rritjes sĂ« softirq â rritja e kostove tĂ« operimit tĂ« sistemit tĂ« rrjetit.
Nëse arkivi do të kompresohej për më tej, koha e rikuperimit rritet në 3 minuta 19 sekonda me
këtë ngarkesë në serverin kryesor (çmontimi në anën e serverit kryesor):
Procesi i shpĂ«rndarjes merr tĂ« dy bĂ«rthamat e procesorit, pasi punon me dy procese. NĂ« pĂ«rgjithĂ«si â rezultat i pritur. NjĂ« rezultat i krahasueshĂ«m (3 minuta dhe 20 sekonda) u arrit gjithashtu kur u fillua gzip nĂ« anĂ«n e serverit me kopjet rezervĂ«, ngarkesa e pĂ«rdorimit nĂ« serverin kryesor ishte mjaft e ngjashme me fillimin e tar pa kompresorin gzip (shih grafikun e mĂ«parshĂ«m).
Në rdiff-backup mund të sinkronizoni kopjen rezervë më të fundit me rsync të zakonshëm (rezultatet do të jenë të ngjashme), por kopjet më të vjetra duhet ende të rikuperohen me programin rdiff-backup, i cili përfundoi rikuperimin për 17 minuta dhe 17 sekonda, duke treguar
ngarkesën e tillë:
Ndoshta kështu ishte menduar, të paktën për të kufizuar shpejtësinë autorët . Procesi i rikuperimit të kopjeve rezervë merr pak më pak se gjysma e një bërthame, me performancë proporcionalisht të krahasueshme (dmth. 2-5 herë më ngadalë) për disk dhe rrjet me rsync.
Rsnapshot për rikuperim ofron përdorimin e rsync të zakonshëm, kështu që rezultatet e tij do të jenë të ngjashme. Në përgjithësi, kështu ndodhi.
Burp për detyrën e rikuperimit të kopjes rezervë u angazhua për 7 minuta dhe 2 sekonda me
ngarkesën e tillë:
Punoi mjaft shpejt, dhe, tĂ« paktĂ«n, shumĂ« mĂ« komode se rsync i pastĂ«r: nuk Ă«shtĂ« e nevojshme tĂ« mbash mend ndonjĂ« flamur, njĂ« ndĂ«rfaqe cli e thjeshtĂ« dhe intuitiv, mbĂ«shtetje e integruar pĂ«r kopje tĂ« shumta, â pĂ«r tĂ« vĂ«rtetĂ« dy herĂ« mĂ« ngadalĂ«. NĂ«se tĂ« dhĂ«nat duhet tĂ« rikuperohen nga kopja rezervĂ« mĂ« e fundit e bĂ«rĂ« â mund tĂ« pĂ«rdorni rsync, me disa rezervata tĂ« vogla.
Programi i ngjashëm BackupPC në aktivizimin e modit të transmetimit rsync, përfundoi rikuperimin për
7 minuta dhe 42 sekonda:
Por në modin e transmetimit të të dhënave me tar BackupPC përfundoi më ngadalë: për 12 minuta dhe 15 sekonda, ngarkesa e procesorit në këtë rast ishte gjithashtu më e ulët
për një dhe një gjysmë herë:
Duplicity pa shifrimin tregoi rezultate pak më të mira, duke arritur të rikuperojë një kopje rezervë për 10 minuta dhe 58 sekonda. Nëse aktivizohet shifrimi me gpg, koha e rikuperimit rritet në 15 minuta dhe 3 sekonda. Gjithashtu, kur krijoni një depo për ruajtjen e kopjeve, mund të përcaktoni madhësinë e arkivës që do të përdoret gjatë ndarjes së fluxit të të dhënave të hyrjes. Në përgjithësi, në diskët e zakonshëm të ngurtë, gjithashtu për shkak të modit njëpotencial, nuk ka ndonjë diferencë të madhe. Ajo, ndoshta, do të shfaqet me madhësi të ndryshme bllokesh, kur përdoren magazinat hibride. Ngarkesa në serverin kryesor gjatë rikuperimit ishte e tillë:
pa shifrimin
me shifrimin
Duplicati tregoi shpejtësi rikuperimi të krahasueshme, duke arritur për 13 minuta dhe 45 sekonda. Rreth 5 minuta iu deshën për verifikimin e saktësisë së të dhënave të rikuperuara (në total rreth 19 minuta). Ngarkesa gjatë kësaj ishte
mjaft e lartë:
Kur shifrimi aes u aktivizua me mjete të brendshme, koha e rikuperimit ishte 21 minuta 40 sekonda, për më shumë, ngarkesa në procesor ishte maksimale (të dy bërthamat!) gjatë rikuperimit; gjatë verifikimit të të dhënave ishte aktiv vetëm një nyjë, që zinte një bërthamë të procesorit. Verifikimi i të dhënave pas rikuperimit zgjati të njëjtën 5 minuta (në total pothuajse 27 minuta).
Rezultati
Pak më shpejt duplicati arriti të menaxhojë rikuperimin duke përdorur një program të jashtëm gpg për shifrimin, por në përgjithësi diferencat nga moda e mëparshme janë minimale. Koha e punës ishte 16 minuta 30 sekonda, me verifikimin e të dhënave në 6 minuta. Ngarkesa ishte
e tillë:
AMANDA, që përdor tar, arriti për 2 minuta 49 sekonda, që, në thelb, është shumë afër tar-it të zakonshëm. Ngarkesa në sistem në përgjithësi
është e njëjtë:
Gjatë rikuperimit të kopjës rezervë me mjete zbackup u arritën rezultatet e mëposhtme:
shifrimi, kompaktimi lzma
Koha e punës 11 minuta dhe 8 sekonda
shifrimi aes, kompaktimi lzma
Koha e punës 14 minuta
shifrimi aes, kompaktimi lzo
Koha e punës 6 minuta, 19 sekonda
NĂ« pĂ«rgjithĂ«si, nuk Ă«shtĂ« keq. TĂ« gjitha varet nga shpejtĂ«sia e CPU-sĂ« nĂ« serverin e kopjimit, e cila duket qartĂ« nga koha e funksionimit tĂ« programit me kompresorĂ« tĂ« ndryshĂ«m. Nga ana e serverit tĂ« kopjimit Ă«shtĂ« aktivizuar tar-i i zakonshĂ«m, kĂ«shtu qĂ« nĂ«se e krahasojmĂ« me tĂ« â riparimi funksionon 3 herĂ« mĂ« ngadalĂ«. Ndoshta, duhet tĂ« verifikojmĂ« punĂ«n nĂ« modin shumĂ«thĂ«rmues, me numĂ«r mĂ« tĂ« madh se dy.
BorgBackup në modin pa enkriptim u përball me pak më ngadalë se tar, për 2 minuta e 45 sekonda, megjithatë, në krahasim me tar, u shfaq mundësia e deduplikimit të depozitës. Ngarkesa në këtë rast doli
e tillë:
Nëse aktivizoni enkriptimin mbi blake, shpejtësia e riparimit të kopjimit ngadalësohet pak. Koha e riparimit në këtë mod është 3 minuta e 19 sekonda, dhe ngarkesa doli
e tillë:
Enkriptimi aes funksionon pak më ngadalë, koha e riparimit është 3 minuta e 23 sekonda, ngarkesa nuk u
ndryshua ndjeshëm:
Duke qenĂ« se Borg mund tĂ« punojĂ« nĂ« modin shumĂ«thĂ«rmues â ngarkesa e CPU-sĂ« Ă«shtĂ« maksimale, ndĂ«rsa me aktivizimin e funksioneve shtesĂ«, koha e punĂ«s rritet. NĂ« dukje, ia vlen tĂ« studiohet ĐŒĐœĐŸĐłĐŸĐżĐŸŃĐŸŃĐœŃŃŃŃ igore ngjashĂ«m me zbackup.
Restic u përball me riparimin pak më ngadalë, koha e punës ishte 4 minuta e 28 sekonda. Ngarkesa në këtë rast dukej
e tillë:
Duket se procesi i riparimit punon në disa thesare, por efikasiteti nuk është aq i lartë sa BorgBackup, por është krahasues në kohë me rsync-n e zakonshëm.
Me ndihmën e UrBackup arriti të riparojë të dhënat në 8 minuta e 19 sekonda, ngarkesa në këtë rast ishte
e tillë:
Edhe kështu duket se ngarkesa nuk është shumë e lartë, madje më e ulët se ajo e tar. Disa herë ka shpërthime, por jo më shumë se ngarkesa e një bërthame.
Zgjedhja dhe justifikimi i kritereve për krahasim
Siç u tha në një nga artikujt e mëparshëm, sistemi i kopjimit duhet të përmbushë këto kritere:
- Thjeshtësia në punë
- Universialiteti
- Stabiliteti
- Shpejtësia
Duket se duhet të shqyrtojmë secilën pikë veçmas në detaje.
Thjeshtësia e punës
MĂ« mirĂ« Ă«shtĂ« kur ka njĂ« buton "BĂ«j gjithçka mirĂ«", por nĂ«se kthehemi nĂ« programet e vĂ«rteta â do tĂ« ishte mĂ« e pĂ«rshtatshme njĂ« parim punimi pak mĂ« tĂ« njohur dhe standard.
PĂ«r shumicĂ«n e pĂ«rdoruesve, do tĂ« jetĂ« mĂ« mirĂ« nĂ«se nuk Ă«shtĂ« e nevojshme tĂ« mbani mend shumĂ« çelĂ«sa pĂ«r cli, tĂ« konfiguroni shumĂ« opsione tĂ« ndryshme, shpesh tĂ« paqarta, pĂ«rmes web ose tui, tĂ« konfiguroni njoftime pĂ«r dĂ«shtimin e punĂ«s. KĂ«tu pĂ«rfshihet gjithashtu mundĂ«sia pĂ«r tĂ« «shkruar» lehtĂ«sisht njĂ« zgjidhje pĂ«r backup nĂ« infrastrukturĂ«n ekzistuese, si dhe automatizimi i procesit tĂ« backup-it. Po ashtu, njihet mundĂ«sia pĂ«r t'u instaluar pĂ«rmes menaxherit tĂ« paketave, ose me njĂ« ose dy komanda tĂ« tipit «shkarko dhe shpaketo». curl lidhja | sudo bash â njĂ« metodĂ« e komplikuar, pasi duhet tĂ« kontrolloni se çfarĂ« vjen pĂ«rmes lidhjes.
PĂ«r shembull, nga kandidatĂ«t e shqyrtuar, zgjidhja e thjeshtĂ« Ă«shtĂ« burp, rdiff-backup dhe restic, tĂ« cilat kanĂ« çelĂ«sa tĂ« memorizueshĂ«m pĂ«r mĂ«nyra tĂ« ndryshme pune. MĂ« e komplikuar Ă«shtĂ« borg dhe duplicity. MĂ« e vĂ«shtirĂ« ishte AMANDA. TĂ« tjerĂ«t janĂ« aty-kĂ«tu pĂ«r sa i pĂ«rket pĂ«rdorshmĂ«risĂ«. NĂ« çdo rast, nĂ«se ju nevojiten mĂ« shumĂ« se 30 sekonda pĂ«r tĂ« lexuar manualin e pĂ«rdoruesit, ose duhet tĂ« shkoni nĂ« Google ose njĂ« motor tjetĂ«r kĂ«rkimi, si dhe tĂ« rrotulloheni nĂ« njĂ« listĂ« tĂ« gjatĂ« ndihme â zgjidhja Ă«shtĂ« e komplikuar, nĂ« njĂ« farĂ« mĂ«nyre.
Disa nga kandidatĂ«t e shqyrtuar dinĂ« automatikisht tĂ« dĂ«rgojnĂ« njĂ« mesazh pĂ«r e-mail jabber, ndĂ«rsa tĂ« tjerĂ«t mbĂ«shteten nĂ« njoftimet e konfiguruara nĂ« sistem. MegjithatĂ«, shpesh zgjidhjet e komplikuara kanĂ« konfigurime tĂ« njoftimit qĂ« nuk janĂ« tĂ« qarta. NĂ« çdo rast, nĂ«se programi i backup-it jep njĂ« kod kthimi jo zero, i cili do tĂ« kuptohet siç duhet nga shĂ«rbimi sistemor i detyrave periodike (do tĂ« dĂ«rgohet njĂ« mesazh administratorit tĂ« sistemit ose direkt nĂ« monitorim) â situata Ă«shtĂ« e thjeshtĂ«. Por nĂ«se sistemi i backup-it, i cili nuk funksionon nĂ« serverin e backup-it, nuk mund tĂ« njoftojĂ« pĂ«r problemin nĂ« njĂ« mĂ«nyrĂ« tĂ« qartĂ« pa konfigurom, atĂ«herĂ« kompleksiteti Ă«shtĂ« i tepĂ«rt. NĂ« çdo rast, dhĂ«nia e paralajmĂ«rimeve dhe mesazheve tĂ« tjera vetĂ«m nĂ« ndĂ«rfaqen web ose nĂ« regjistrat â Ă«shtĂ« njĂ« praktikĂ« e keqe, pasi shumicĂ«n e rasteve ato do tĂ« injorohen.
Sa i pĂ«rket automatizimit â njĂ« program i thjeshtĂ« di tĂ« lexojĂ« variablat e mjedisit, tĂ« cilat pĂ«rcaktojnĂ« modin e tij tĂ« punĂ«s, ose ka njĂ« cli tĂ« zhvilluar, i cili mund tĂ« dyfishojĂ« plotĂ«sisht sjelljen e tij gjatĂ« punĂ«s pĂ«rmes ndĂ«rfaqes web, pĂ«r shembull. KĂ«tu pĂ«rfshihet gjithashtu mundĂ«sia e punĂ«s nĂ« rrjedhĂ«, si dhe ekzistenca e mundĂ«sive pĂ«r zgjerim etj.
Universialiteti
Pjesërisht përputhet me nënkapitullin e mëparshëm në lidhje me automatizimin, nuk duhet të jetë ndonjë problem i veçantë "të inkorporosh" procesin e kopjimit në infrastrukturën ekzistuese.
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se pĂ«rdorimi i porteve jo-standard pĂ«r funksionimin (pĂ«rveç ndĂ«rfaqes sĂ« web-it), implementimi i enkriptimit nĂ« njĂ« mĂ«nyrĂ« jo-standard dhe shkĂ«mbimi i tĂ« dhĂ«nave nĂ« njĂ« protokol jo-standard janĂ« tregues tĂ« njĂ« zgjidhje jo-universale. NĂ« shumicĂ«n e rasteve, kandidatĂ«t i kanĂ« kĂ«to pĂ«r arsye evidente: thjeshtĂ«sia dhe universaliteti zakonisht nuk janĂ« tĂ« pĂ«rputhshme. Si pĂ«rjashtim, burp ka dhe tĂ« tjera.
Si një tregues - mundësia për të punuar duke përdorur ssh të zakonshëm.
Shpejtësia e punës
Pika më e kundërshtueshme dhe e diskutueshme. Nga njëra anë - procesi është nisur, ai ka punuar sa më shpejt dhe nuk pengon detyrat kryesore. Nga ana tjetër - një shpërthim i trafik dhe ngarkesës në procesor gjatë procesit të kopjimit. Duhet gjithashtu të theksohet se programet më të shpejta për marrjen e kopjave zakonisht kanë funksione të varfëra, të rëndësishme për përdoruesit. Sërish: nëse për të marrë një skedë të vetme tekstuale që peshon disa dhjetëra byte me një fjalëkalim, dhe për këtë arsye ndalon gjithë shërbimin (po, po, e kuptoj që këtu procesi i kopjimit shpesh nuk është fajtor), dhe duhet të rilexosh radhazi të gjitha skedat në depo, ose të zhvendosësh një arkiv të tërë - sistemi i kopjimit nuk është aspak i shpejtë. Një pikë tjetër që shpesh bëhet një shkak i problemit - shpejtësia e zhvillimit të kopjisë nga arkiva. Këtu ka një avantazh të qartë ata që mund të kopjojnë ose të lëvizin thjesht skedat në vendin e duhur pa ndonjë manipulim të veçantë (rsync për shembull), por shpeshherë problemi duhet të zgjidhet në mënyrë organizative, me një qasje empirike: të matim kohën e rikuperimit të kopjës dhe të informojmë hapur përdoruesit për këtë.
Stabiliteti
Duhet të kuptohet kështu: nga njëra anë, duhet të jetë një mundësi për të rikthyer kopjimin në çdo rast, nga ana tjetër - qëndrueshmëria ndaj problemeve të ndryshme: ndërprerje të rrjetit, dështimi i harduerit, fshirja e disa pjesëve të depo.
Krahasimi i mjeteve të kopjimit
Koha e krijimit të kopjës
Koha e rikuperimit të kopjës
Instalim i thjeshtë
Konfigurim i thjeshtë
Përdorim i thjeshtë
Automatizim i thjeshtë
A është e nevojshme klient-server?
Kontrolli i integritetit të depozitës
Kopje ndryshore
Puna përmes pipe
Universialiteti
Pavarësia
Transparenca e depozitës
Kriptimi
Kompresimi
Dedupikimi
Ndërfaqja Web
Ngarkimi në re
Përkrahja për Windows
Pika
Rsync
4m15s
4m28s
po
jo
jo
jo
po
jo
jo
po
jo
po
po
jo
jo
jo
jo
jo
po
6
Tar
pure
3m12s
2m43s
po
jo
jo
jo
jo
jo
po
po
jo
po
jo
jo
jo
jo
jo
jo
po
8,5
gzip
9m37s
3m19s
po
Rdiff-backup
16m26s
17m17s
po
po
po
po
po
jo
po
jo
po
jo
po
jo
po
po
po
jo
po
11
Rsnapshot
4m19s
4m28s
po
po
po
po
jo
jo
po
jo
po
jo
po
jo
jo
po
po
jo
po
12,5
Burp
11m9s
7m2s
po
jo
po
po
po
po
po
jo
po
po
jo
jo
po
jo
po
jo
po
10,5
Duplicity
pa kriptim
16m48s
10m58s
po
po
jo
po
jo
po
po
jo
jo
po
jo
po
po
jo
po
jo
po
11
gpg
17m27s
15m3s
Duplicati
pa kriptim
20m28s
13m45s
jo
po
jo
jo
jo
po
po
jo
jo
po
jo
po
po
po
po
po
po
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
Zbackup
pa kriptim
40m3s
11m8s
po
po
jo
jo
jo
po
po
po
jo
po
jo
po
po
po
jo
jo
jo
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
pa kriptim
4m7s
2m45s
po
po
po
po
po
po
po
po
po
po
jo
po
po
po
po
jo
po
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
po
po
po
po
jo
po
po
po
po
po
jo
po
jo
po
jo
po
po
15,5
UrBackup
8m21s
8m19s
po
po
po
jo
po
jo
po
jo
po
po
jo
po
po
po
po
jo
po
12
Amanda
9m3s
2m49s
po
jo
jo
po
po
po
po
jo
po
po
po
po
po
jo
po
po
po
13
BackupPC
rsync
12m22s
7m42s
po
jo
po
po
po
po
po
jo
po
jo
jo
po
po
jo
po
jo
po
10,5
tar
12m34s
12m15s
Legenda e tabelës:
- E gjelber, kohe funksionimi më pak se pesë minuta, ose përgjigje "Po" (përveç kolonës "Nevojitet klient server?"), 1 pikë
- E verdhë, kohe funksionimi pesë-dhjetë minuta, 0.5 pikë
- E kuqe, kohe funksionimi më shumë se dhjetë minuta, ose përgjigje "Jo" (përveç kolonës "Nevojitet klient server?"), 0 pikë
Sipas tabelës mësipër, mjeti më i thjeshtë, më i shpejtë, dhe njëkohësisht i rehatshëm e të fuqishëm për backup është BorgBackup. Vendi i dytë zuri Restic, kandidatët e tjerë të shqyrtuar u vendosën në mënyrë të ngjashme me një përhapje prej një deri në dy pikë në fund.
Faleminderit të gjithëve që e lexuat ciklin deri në fund, ofroj që ta diskutojmë mundësitë, të propozojmë të tuat, nëse ka. Me kalimin e diskutimeve, tabela mund të plotësohet.
Rezultati i ciklit do tĂ« jetĂ« njĂ« artikull pĂ«rfundimtar, nĂ« tĂ« cilin do tĂ« mundohem tĂ« nxjerr pĂ«rfundimin mĂ« tĂ« pĂ«rsosur, tĂ« shpejtĂ« dhe tĂ« menaxhueshĂ«m pĂ«r mjetin e backup-it, duke lejuar qĂ« nĂ« njĂ« kohĂ« tĂ« shkurtĂ«r tĂ« ristartojmĂ« kopjen dhe njĂ«kohĂ«sisht â tĂ« kemi rehatinĂ« dhe thjeshtĂ«sinĂ« nĂ« konfigurim dhe mbĂ«shtetje.
Njoftim
Kopjimi i rezervave, pjesa 6: Krahasimi i mjeteve për kopje rezervë
Kopjimi i rezervave, pjesa 7: PĂ«rfundime
Burimi: habr.com
