Në këtë artikull do të bëhet një krahasim i mjeteve për krijimin e kopjeve rezervë, por së pari është e rëndësishme të dimë se si ato përballen shpejt dhe mirë me rikuperimin e të dhënave nga kopjet rezervë.
Për thjeshtësi krahasimi do të merret në konsideratë rikuperimi nga një kopje rezervë e plotë, sidomos pasi ky modalitet është mbështetur nga të gjithë kandidatët. Për thjeshtësi, numrat janë marrë si mesatarë (mesatarja aritmetike nga disa ekzekutime). Rezultatet do të përmblidhen në një tabelë, në të cilën do të ketë informacion edhe për mundësitë: prania e ndërfaqes në web, thjeshtësia në konfigurim dhe përdorim, aftësia për automatizim, prania e mundësive të ndryshme shtesë (p.sh., kontrolli i integritetit të të dhënave) etj. Grafikat do të tregojnë ngarkesën e serverit, ku të dhënat do të aplikohen (jo serverin për ruajtjen e kopjeve rezervë).
Rigjenerimi i të dhënave
Si pikë reference do të përdoren rsync dhe tar, pasi skriptet më të thjeshta për krijimin e kopjeve rezervë.
Rsync ka përfunduar testin me grupin e të dhënave për 4 minuta dhe 28 sekonda, duke treguar
këto ngarkesa
Processi i rikuperimit u shpĂ«rbĂ« nĂ« kufizimin e nĂ«nĂ«s disk tĂ« serverit tĂ« ruajtjes sĂ« kopjeve rezervĂ« (grafikĂ«t me thikĂ«). Po ashtu, Ă«shtĂ« e qartĂ« ngarkesa e njĂ« bĂ«rthamĂ« pa ndonjĂ« problem tĂ« veçantĂ« (iowait i ulĂ«t dhe softirq â nuk ka probleme me diskun dhe rrjetin pĂ«rkatĂ«s). Duke qenĂ« se dy programet e tjera, konkretisht rdiff-backup dhe rsnapshot, janĂ« tĂ« bazuara nĂ« rsync dhe ofrojnĂ« si mjet rikuperimi rsyncin e zakonshĂ«m, ato do tĂ« kenĂ« njĂ« profil ngarkese dhe njĂ« kohĂ« rikuperimi tĂ« ngjashme.
Tar e përfundoi pak më shpejt, për
2 minuta dhe 43 sekonda:
Ngarkesa e plotĂ« e sistemit ishte mĂ« e lartĂ« mesatarisht me 20% pĂ«r shkak tĂ« rritjes sĂ« softirq â rriten shpenzimet nĂ« funksionimin e nĂ«nĂ«s rrjet.
Nëse arkivi kompresohet edhe më tej, koha e rikuperimit rritet në 3 minuta 19 sekonda me
këtë ngarkesë në serverin kryesor (shkëputja në anën e serverit kryesor):
Procesi i deshifrimit merr të dy bërthamat e procesorit, pasi kryhen dy procese. Në përgjithësi, ky është një rezultat i pritur. Një rezultat i ngjashëm (3 minuta dhe 20 sekonda) u arrit gjithashtu duke ekzekutuar gzip në server me kopje rezervë, dhe ngarkesa në serverin kryesor ishte shumë e ngjashme me ekzekutimin e tar pa kompresorin gzip (shiko grafikun e mëparshëm).
Në rdiff-backup mund të sinkronizoni kopjen e fundit të bërë 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 e bëri rikuperimin për 17 minuta dhe 17 sekonda, duke treguar
këtë ngarkesë:
Ndoshta kështu është menduar, për çdo rast për të limituar shpejtësinë autorët . Procesi i rikuperimit të kopjes rezervë merr pak më pak se një e gjysmë bërthame, me një performancë proporcionale të ngjashme (kjo do të thotë 2-5 herë më e ngadalshme) mbi disk dhe rrjet me rsync.
Rsnapshot proponon të përdorë rsync të zakonshëm për rikuperim, prandaj rezultatet e tij do të jenë të ngjashme. Në përgjithësi, kështu ndodhi.
Burp u përballë me detyrën e rikuperimit të kopjës rezervë për 7 minuta dhe 2 sekonda me
të tillë ngarkese:
Funksionoi mjaft shpejt dhe, së paku, shumë më komod se rsync i pastër: nuk është e nevojshme të mbash mend ndonjë flag, ndërfaqe CLI e thjeshtë dhe intuitive, mbështetje e ndërtuar për shumë kopje, - megjithatë dy herë më e ngadalshme. Nëse të dhënat duhet të rikuperohen nga kopja e fundit e bërë - mund të përdoret rsync, me disa rezerva të vogla.
Programi BackupPC tregoi afërsisht të njëjtën shpejtësi dhe ngarkesë duke aktivizuar modin e transmetimit rsync, duke rikuperuar kopjen në
7 minuta dhe 42 sekonda:
Ndërsa në modin e transmetimit të të dhënave me tar, BackupPC e realizoi më ngadalë: brenda 12 minutave dhe 15 sekondash, ngarkesa e procesorit gjatë këtij procesi ishte gjithsej më e ulët
në një gjysmë here:
Duplicity pa pa qartë më të mira, duke e bërë rivendosjen e kopjës brenda 10 minutash e 58 sekondash. Nëse aktivizohet enkriptimi me gpg, koha e rivendosjes rritet në 15 minuta e 3 sekonda. Po ashtu, kur krijoni një depo për ruajtjen e kopjave, mund të përcaktoni madhësinë e arkivit që do të përdoret gjatë ndarjes së fluxit të të dhënave të hyrjes. Në përgjithësi, në hard diskët e zakonshëm, po ashtu për shkak të mënyrës njëkanalëshe të funksionimit, nuk ka ndonjë dallim të veçantë. Mundësia ndoshta do të shfaqet me madhësi të ndryshme bllokesh, kur përdoren ruajtje hibride. Ngarkesa në serverin kryesor gjatë rivendosjes ishte e tillë:
pa enkriptim
me enkriptim
Duplicati tregon një shpejtësi rivendosjeje të ngjashme, duke u përballur brenda 13 minutash e 45 sekondash. Rreth 5 minuta mori verifikimi i saktësisë së të dhënave të rikuperuara (në total rreth 19 minuta). Ngarkesa në këtë rast ishte
mjaft e lartë:
Kur aktivizuam enkriptimin aes me mjete të brendshme, koha e rikuperimit ishte 21 minuta e 40 sekonda, me ngarkesë maksimale të procesorit (të dy bërthamat!) gjatë rikuperimit; gjatë kontrollit të të dhënave ishte aktiv vetëm një proces, duke zënë një bërthamë procesori. Kontrolli i të dhënave pas rikuperimit zgjati të njëjtat 5 minuta (në total afërsisht 27 minuta).
Rezultati
Pak më shpejt dublikuar përfundoi rikuperimin duke përdorur një program të jashtëm gpg për enkriptim, por në përgjithësi dallimet nga moda e mëparshme janë minimale. Koha e punës ishte 16 minuta e 30 sekonda, me kontrollin e të dhënave në 6 minuta. Ngarkesa ishte
ashtu:
AMANDA, e cila përdor tar, përfundoi për 2 minuta e 49 sekonda, e cila, në parim, është shumë afër tar-it të zakonshëm. Ngarkesa në sistem në parim
është e njëjtë:
Gjatë rikuperimit të kopjes rezervë me mjete zbackup këto rezultate u arritën:
enkriptime, kompresim lzma
Koha e punës 11 minuta e 8 sekonda
enkriptime aes, kompresim lzma
Koha e punës 14 minuta
enkriptime aes, kompresim lz0
Koha e punës 6 minuta, 19 sekonda
NĂ« pĂ«rgjithĂ«si, nuk Ă«shtĂ« keq. E gjithĂ« kjo varet nga shpejtĂ«sia e procesorit nĂ« serverin e kopjimit, e cila Ă«shtĂ« e dukshme nĂ« kohĂ«n e funksionimit tĂ« programit me kompresorĂ« tĂ« ndryshĂ«m. Nga ana e serverit tĂ« kopjimit Ă«shtĂ« ekzekutuar tar-i i zakonshĂ«m, kĂ«shtu qĂ« nĂ«se e krahasojmĂ« me tĂ« â rikuperimi punon 3 herĂ« mĂ« ngadalĂ«. Ndoshta duhet tĂ« kontrolloni funksionimin nĂ« mĂ«nyrĂ« shumĂ«thithĂ«se, me numrin e rrymave mĂ« shumĂ« se dy.
BorgBackup në mënyrën pa enkriptim rezultoi të jetë pak më i ngadalshëm se tar, për 2 minuta e 45 sekonda, megjithatë, ndryshe nga tar-i i njëjtë, u shfaq mundësia e deduplikimit të depozitës. Ngarkesa në këtë rast ishte
e tillë:
Nëse aktivizoni enkriptimin duke përdorur blake, atëherë shpejtësia e rikuperimit të kopjimeve ngadalësohet pak. Koha e rikuperimit në këtë mënyrë është 3 minuta e 19 sekonda, ndërsa ngarkesa rezultoi
e tillë:
Enkriptimi aes punon pak më ngadalë, koha e rikuperimit është 3 minuta e 23 sekonda, ngarkesa nuk ka ndryshuar shumë:
nuk e është ndarë:
Duke Borg mund tĂ« funksionojĂ« nĂ« mĂ«nyrĂ« shumĂ«thĂ«she â ngarkesa e procesorit Ă«shtĂ« maksimale, ndĂ«rsa gjatĂ« aktivizimit tĂ« funksioneve shtesĂ« vetĂ«m rritet koha e dytĂ«. Me sa duket, duhet tĂ« hetojmĂ« shumĂ«thĂ«shmĂ«rinĂ« e funksionimit tĂ« ngjashĂ«m me zbackup.
Restic u rikuperua pak më ngadalë, koha e funksionimit ishte 4 minuta 28 sekonda. Ngarkesa dukej
ashtu:
Me sa duket, procesi i rikuperimit funksionon në disa tema, por efikasiteti nuk është aq i lartë sa ai i BorgBackup, por është krahasues me kohën e zakonshme të rsync.
Me UrBackup arriti të rikuperojë të dhënat për 8 minuta dhe 19 sekonda, ngarkesa ishte
ashtu:
Edhe njëherë tregohet se ngarkesa nuk është shumë e lartë, madje edhe më e ulët se ajo e tar. Herë pas here ka shpërthime, por jo më shumë se ngarkesa e një bërthame.
Zgjedhja dhe arsyetimi i kritereve për krahasim
Siç u tha në një nga artikujt e mëparshëm, sistemi i kopjimit duhet të përputhet me kriteret e mëposhtme:
- Thjeshtësia në punë
- Universialiteti
- Stabiliteti
- Shpejtësia
Duhet të shqyrtojmë secilën pikë veçmas në detaje të mëtejshme.
Thjeshtësia e punës
MĂ« sĂ« miri, Ă«shtĂ« kur ka njĂ« buton "BĂ«j gjithçka mirĂ«", por nĂ«se kthehemi te programet reale â do tĂ« ishte mĂ« e lehtĂ« njĂ« parim i zakonshĂ«m dhe standard i punĂ«s.
PĂ«rdoruesve shumicĂ«, me siguri do t'ju jetĂ« mĂ« mirĂ« nĂ«se nuk duhet tĂ« mbani mend njĂ« mori çelĂ«sash pĂ«r CLI, tĂ« konfiguroni njĂ« sĂ«rĂ« opsionesh tĂ« ndryshme, shpesh tĂ« paqartĂ« pĂ«rmes web ose TUI, dhe tĂ« vendosni alarmin pĂ«r puna tĂ« dĂ«shtuar. KĂ«tu hyn edhe 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, mundĂ«sia e instalimit me menaxherin e pakove, ose nĂ« njĂ«âdy komandat si "shkarko dhe nxirr". curl lidhje | sudo bash â metodĂ« e komplikuar, pasi duhet tĂ« kontrolloni se çfarĂ« mbĂ«rrin pĂ«rmes lidhjes.
Për shembull, nga kandidatët e shqyrtuar, një zgjidhje e thjeshtë është burp, rdiff-backup dhe restic, të cilat kanë çelësa që janë të lehtë për t'u kujtuar për mënyra të ndryshme funksionimi. Pak më e komplikuar është borg dhe duplicity. Më e komplikuar ishte AMANDA. Të tjerat janë diku në mes në nivelin e lehtësisë së përdorimit. Në çdo rast, nëse nevojitet më shumë se 30 sekonda për të lexuar manualin e përdoruesit, ose duhet të kërkoni në Google ose një motor tjetër kërkimi, si dhe të shfletoni një ndihmë të gjatë, zgjidhja është e komplikuar, kështu ose ashtu.
Disa nga kandidatĂ«t e shqyrtuar dinĂ« tĂ« dĂ«rgojnĂ« automatikisht njĂ« mesazh pĂ«rmes e-mail jabber, ndĂ«rsa tĂ« tjerĂ«t mbĂ«shteten nĂ« njoftimet e konfigurara nĂ« sistem. NĂ« kĂ«to raste, shpesh zgjidhjet komplekse kanĂ« konfigurime njoftimi qĂ« nuk janĂ« shumĂ« tĂ« dukshme. MegjithatĂ«, nĂ«se programi i krijimit tĂ« kopjeve rezervĂ« jep njĂ« kod kthyese jo zero, i cili do tĂ« kuptohet saktĂ«sisht nga shĂ«rbimi sistemor i detyrave periodike (do tĂ« dĂ«rgohet njĂ« mesazh administratorit tĂ« sistemit ose menjĂ«herĂ« nĂ« monitorim), situata Ă«shtĂ« e thjeshtĂ«. NĂ«se sistemi i kopjeve rezervĂ«, i cili funksionon jashtĂ« serverit tĂ« kopjeve rezervĂ«, nuk mund tĂ« tregojĂ« pĂ«r problemin nĂ« njĂ« mĂ«nyrĂ« tĂ« dukshme pa konfigurim â kompleksiteti tashmĂ« Ă«shtĂ« tepricĂ«. NĂ« çdo rast, dĂ«rgimi i paralajmĂ«rimeve dhe mesazheve tĂ« tjera vetĂ«m nĂ« ndĂ«rfaqen e uebit dhe/ose nĂ« regjistĂ«r Ă«shtĂ« njĂ« praktikĂ« e keqe, pasi zakonisht ato do tĂ« injorohen.
Sa i përket automatizimit - një program i thjeshtë mund të lexojë variablat e mjedisit që përcaktojnë modin e tij të punës, ose ka një CLI të zhvilluar, i cili është në gjendje të çohet plotësisht ja sjellja gjatë përdorimit përmes ndërfaqes në ueb, për shembull. Këtu përfshihet gjithashtu mundësia e punës në mënyrë të vazhdueshme, disponimi i mundësive për zgjerim, etj.
Universialiteti
Pjesërisht mbulon me seksionin e mëparshëm në lidhje me automatizimin, nuk duhet të ketë ndonjë problem të veçantë për të "futur" procesin e kopjimit rezervë në infrastrukturën ekzistuese.
Duhet të theksohet se përdorimi i porteve jo standarde (përveç ndërfaqes në ueb) për funksionimin, realizimi i enkriptimit në mënyrë jo standarde, shkëmbimi i të dhënave nëpërmjet protokollit jo standard - janë shenja të një zgjidhjeje jo universale. Kryesisht, të gjithë kandidatët kanë ndonjëherë këto për arsyen e qartë: thjeshtësia dhe universaliteti zakonisht janë të papajtueshme. Si një përjashtim - burp, ka dhe të tjera.
Si një shenjë - mundësia e punës duke përdorur ssh-në e zakonshme.
Shpejtësia e punës
Pika mĂ« controversiale dhe e diskutueshme. Nga njĂ«ra anĂ« â procesi Ă«shtĂ« nisur, ka funksionuar maksimalisht shpejt dhe nuk pengon detyrat kryesore. Nga ana tjetĂ«r â njĂ« shpĂ«rthim i trafikut dhe ngarkesĂ«s nĂ« procesor gjatĂ« ruajtjes sĂ« kopjeve rezervĂ«. Duhet tĂ« shĂ«nojmĂ« gjithashtu se programet mĂ« tĂ« shpejta pĂ«r krijimin e kopjeve zakonisht janĂ« mĂ« tĂ« varfĂ«ra nĂ« funksionalitete qĂ« janĂ« tĂ« rĂ«ndĂ«sishme pĂ«r pĂ«rdoruesit. PĂ«rsĂ«ri: nĂ«se pĂ«r tĂ« nxjerrĂ« njĂ« dosje tĂ« thjeshtĂ« tekstuale disa dhjetĂ«ra byte me fjalĂ«kalim, dhe pĂ«r kĂ«tĂ« arsye tĂ« gjithĂ« shĂ«rbimi tĂ« dĂ«shtojĂ« (po, po, e kuptoj se procesi i ruajtjes sĂ« kopjeve zakonisht nuk Ă«shtĂ« fajtor kĂ«tu), dhe duhet tĂ« rishikosh njĂ« nga njĂ« tĂ« gjitha dosjet nĂ« repositorin ose tĂ« zbulosh njĂ« arkiv tĂ« tĂ«rĂ« â sistemi i ruajtjes sĂ« kopjeve asnjĂ«herĂ« nuk Ă«shtĂ« i shpejtĂ«. NjĂ« tjetĂ«r pikĂ«, e cila shpesh bĂ«het njĂ« pengesĂ« â shpejtĂ«sia e rikthimit tĂ« njĂ« kopjeje rezervĂ« nga arkivi. KĂ«tu ka njĂ« avantazh tĂ« qartĂ« pĂ«r ata qĂ« mund tĂ« kopjojnĂ« ose zhvendosin thjesht dosjet nĂ« vendin e duhur pa manovra tĂ« veçanta (rsync, pĂ«r shembull), por zakonisht problemi duhet tĂ« zgjidhet nĂ« mĂ«nyrĂ« organizative, pĂ«rmes njĂ« procedure empirik: matni kohĂ«n e rikthimit tĂ« kopjes rezervĂ« dhe informoni hapur pĂ«rdoruesit pĂ«r kĂ«tĂ«.
Stabiliteti
Duhet kuptuar kĂ«shtu: nga njĂ«ra anĂ«, duhet tĂ« ketĂ« mundĂ«si pĂ«r tĂ« rikthyer njĂ« kopje rezervĂ« nĂ« çdo rast, nga ana tjetĂ«r â qĂ«ndrueshmĂ«ri ndaj problemeve tĂ« ndryshme: ndalesa e rrjetit, dĂ«shtimi i diskut, fshirja e njĂ« pjese tĂ« depozitĂ«s.
Krahasimi i mjeteve të kopjimit
Koha e krijimit të kopjes
Koha e rikthimit të kopjes
Instalim i lehtë
Konfigurim i lehtë
Përdorim i thjeshtë
Automatizim i thjeshtë
Nevojitet klient-server?
Kontrolli i integritetit të depozitës
Kopje diferenciale
Puna përmes pipe
Universialiteti
Autonomia
Transparenca e depozitës
Shifrimi
Komprimi
Deduplication
Ndërfaqja Web
Ngarkimi në re
Mbështetje 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
no encryption
16m48s
10m58s
po
po
jo
po
jo
po
po
jo
jo
po
jo
po
po
jo
po
jo
po
11
gpg
17m27s
15m3s
Duplicati
no encryption
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
no encryption
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
no encryption
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
Legjenda e tabelës:
- Gjelbër, koha e punës më pak se pesë minuta, ose përgjigje 'Po' (përveç kolonës 'Nevojitet klient-server?'), 1 pikë
- E verdhë, koha e punës pesë-dhjetë minuta, 0.5 pikë
- E kuqe, koha e punës më shumë se dhjetë minuta, ose përgjigje 'Jo' (përveç kolonës 'Nevojitet klient-server?'), 0 pikë
Sipas tabelës së mësipërme, mjeti më i thjeshtë, më i shpejtë dhe njëkohësisht i fuqishëm për kopjimin është BorgBackup. Vendi i dytë e mban Restic, ndërsa kandidatët e tjerë që u shqyrtuan u renditën në mënyrë të ngjashme me një shpërndarje prej një deri në dy pikë në fund.
Faleminderit të gjithëve që e lexuat këtë cikël deri në fund, ju ftoj të diskutojmë opsionet dhe të parashtroni të tuat, nëse ka. Me kalimin e diskutimeve, tabela mund të plotësohet.
Nga ky cikël do të rezultojë një artikull përfundimtar, në të cilin do të bëjmë përpjekjen për të përcaktuar mjetin ideal, të shpejtë dhe të menaxhueshëm për kopjimin, që lejon kthimin e kopjës në kohë të shkurtër dhe njëkohësisht ofron lehtësi dhe thjeshtësi në konfigurim dhe mbështetje.
Ankandi
Backup, pjesa 6: Krahasimi i mjeteve të backup-it
Kopjimi, pjesa 7: PĂ«rfundimet
Burimi: habr.com
