Ky artikull do të krahasojë mjetet rezervë, por së pari duhet të zbuloni se sa shpejt dhe mirë përballen me rikthimin e të dhënave nga kopjet rezervë.
Për lehtësi krahasimi, ne do të konsiderojmë rikthimin nga një kopje rezervë e plotë, veçanërisht pasi të gjithë kandidatët mbështesin këtë mënyrë funksionimi. Për thjeshtësi, numrat tashmë janë mesatarizuar (mesatarja aritmetike e disa ekzekutimeve). Rezultatet do të përmblidhen në një tabelë, e cila gjithashtu do të përmbajë informacion në lidhje me aftësitë: prania e një ndërfaqe në internet, lehtësia e konfigurimit dhe funksionimit, aftësia për të automatizuar, prania e veçorive të ndryshme shtesë (për shembull, kontrollimi i integritetit të të dhënave) , etj. Grafikët do të tregojnë ngarkesën në serverin ku do të përdoren të dhënat (jo serverin për ruajtjen e kopjeve rezervë).
Rimëkëmbja e të dhënave
rsync dhe tar do të përdoren si pikë referimi që nga ajo kohë skriptet e thjeshta për të bërë kopje rezervë.
rsync u përball me grupin e të dhënave të testimit në 4 minuta e 28 sekonda, duke treguar
një ngarkesë të tillë
Procesi i rikuperimit goditi një kufizim të nënsistemit të diskut të serverit të ruajtjes rezervë (grafikët me dhëmbë sharrë). Ju gjithashtu mund të shihni qartë ngarkimin e një kernel pa asnjë problem (i ulët iowait dhe softirq - pa probleme me diskun dhe rrjetin, përkatësisht). Meqenëse dy programet e tjera, domethënë rdiff-backup dhe rsnapshot, bazohen në rsync dhe gjithashtu ofrojnë rsync të rregullt si një mjet rikuperimi, ata do të kenë afërsisht të njëjtin profil ngarkese dhe kohë të rikuperimit të rezervës.
katran e bëri atë pak më shpejt
2 minuta e 43 sekonda:
Ngarkesa totale e sistemit ishte mesatarisht më e lartë me 20% për shkak të rritjes së softirq - kostot e përgjithshme gjatë funksionimit të nënsistemit të rrjetit u rritën.
Nëse arkivi kompresohet më tej, koha e rikuperimit rritet në 3 minuta 19 sekonda.
me një ngarkesë të tillë në serverin kryesor (zhpaketimi në anën e serverit kryesor):
Procesi i dekompresimit përfshin të dy bërthamat e procesorit sepse ka dy procese që funksionojnë. Në përgjithësi, ky është rezultati i pritur. Gjithashtu, një rezultat i krahasueshëm (3 minuta dhe 20 sekonda) u mor kur përdorni gzip në anën e serverit me kopje rezervë; profili i ngarkesës në serverin kryesor ishte shumë i ngjashëm me funksionimin e tar pa kompresorin gzip (shih grafikun e mëparshëm).
В rdiff-backup mund të sinkronizoni kopjen rezervë të fundit që keni bërë duke përdorur rsync të rregullt (rezultatet do të jenë të ngjashme), por kopjet rezervë të vjetra ende duhet të restaurohen duke përdorur programin rdiff-backup, i cili përfundoi restaurimin në 17 minuta e 17 sekonda, duke treguar
kjo ngarkesë:
Ndoshta kjo kishte për qëllim, të paktën për të kufizuar shpejtësinë e autorëve . Vetë procesi i rivendosjes së një kopje rezervë kërkon pak më pak se gjysmën e një bërthame, me performancë proporcionalisht të krahasueshme (d.m.th. 2-5 herë më e ngadaltë) mbi disk dhe rrjet me rsync.
Rsnapshot Për rikuperim, sugjeron përdorimin e rsync të rregullt, kështu që rezultatet e tij do të jenë të ngjashme. Në përgjithësi, kështu doli.
Gërvishtje Përfundova detyrën e rivendosjes së një kopje rezervë në 7 minuta e 2 sekonda me
me këtë ngarkesë:
Ai funksionoi mjaft shpejt dhe të paktën është shumë më i përshtatshëm se rsync i pastër: nuk keni nevojë të mbani mend asnjë flamur, një ndërfaqe të thjeshtë dhe intuitive cli, mbështetje të integruar për kopje të shumta - megjithëse është dy herë më i ngadalshëm. Nëse keni nevojë të rivendosni të dhënat nga rezervimi i fundit që keni bërë, mund të përdorni rsync, me disa paralajmërime.
Programi tregoi afërsisht të njëjtën shpejtësi dhe ngarkesë BackupPC kur aktivizoni modalitetin e transferimit rsync, duke vendosur kopjen rezervë për
7 minuta e 42 sekonda:
Por në modalitetin e transferimit të të dhënave, BackupPC u përball me tar më ngadalë: në 12 minuta dhe 15 sekonda, ngarkesa e procesorit ishte përgjithësisht më e ulët
një herë e gjysmë:
hipokrizi pa kriptim tregoi rezultate pak më të mira, duke rivendosur një kopje rezervë në 10 minuta e 58 sekonda. Nëse aktivizoni enkriptimin duke përdorur gpg, koha e rikuperimit rritet në 15 minuta e 3 sekonda. Gjithashtu, kur krijoni një depo për ruajtjen e kopjeve, mund të specifikoni madhësinë e arkivit që do të përdoret gjatë ndarjes së rrjedhës së të dhënave në hyrje. Në përgjithësi, në disqet konvencionale të ngurtë, gjithashtu për shkak të mënyrës së funksionimit me një fije, nuk ka shumë ndryshim. Mund të shfaqet në madhësi të ndryshme blloku kur përdoret ruajtja hibride. Ngarkesa në serverin kryesor gjatë rikuperimit ishte si më poshtë:
nuk ka enkriptim
me enkriptim
Dublikatë tregoi një shkallë të krahasueshme rikuperimi, duke e përfunduar atë në 13 minuta e 45 sekonda. U deshën rreth 5 minuta të tjera për të kontrolluar korrektësinë e të dhënave të rikuperuara (gjithsej rreth 19 minuta). Ngarkesa ishte
mjaft e lartë:
Kur enkriptimi aes u aktivizua nga brenda, koha e rikuperimit ishte 21 minuta 40 sekonda, me përdorimin e CPU-së në maksimum (të dy bërthamat!) gjatë rikuperimit; Gjatë kontrollit të të dhënave, vetëm një thread ishte aktiv, duke zënë një bërthamë procesori. Kontrollimi i të dhënave pas rikuperimit zgjati të njëjtat 5 minuta (pothuajse 27 minuta në total).
Result
Duplicati ishte pak më i shpejtë me rikuperimin kur përdorni programin e jashtëm gpg për enkriptim, por në përgjithësi ndryshimet nga mënyra e mëparshme janë minimale. Koha e funksionimit ishte 16 minuta 30 sekonda, me verifikimin e të dhënave në 6 minuta. Ngarkesa ishte
është si vijon:
AMANDA, duke përdorur katranin, e përfundoi për 2 minuta 49 sekonda, që në parim është shumë afër katranit të rregullt. Ngarkoni në sistem në parim
e njëjta:
Kur rivendosni një kopje rezervë duke përdorur zbackup janë marrë rezultatet e mëposhtme:
enkriptim, kompresim lzma
Koha e shfaqjes 11 minuta e 8 sekonda
Kriptimi AES, kompresimi lzma
Koha e funksionimit 14 minuta
Kriptimi AES, kompresimi lzo
Koha e veprimit 6 minuta, 19 sekonda
Në përgjithësi, jo keq. E gjitha varet nga shpejtësia e procesorit në serverin rezervë, gjë që mund të shihet qartë nga koha e funksionimit të programit me kompresorë të ndryshëm. Në anën e serverit rezervë, u lançua një tar i rregullt, kështu që nëse e krahasoni me të, rikuperimi është 3 herë më i ngadalshëm. Mund të ia vlen të kontrolloni funksionimin në modalitetin me shumë fije, me më shumë se dy fije.
BorgBackup në modalitetin e pakriptuar ishte pak më i ngadalshëm se tar, në 2 minuta 45 sekonda, megjithatë, ndryshe nga tar, u bë e mundur të fshihej depoja. Ngarkesa doli të ishte
në vijim:
Nëse aktivizoni enkriptimin e bazuar në blake, shpejtësia e rikuperimit të rezervës është pak më e ngadaltë. Koha e rikuperimit në këtë modalitet është 3 minuta 19 sekonda dhe ngarkesa është zhdukur
si kjo:
Kriptimi AES është pak më i ngadalshëm, koha e rikuperimit është 3 minuta 23 sekonda, ngarkesa është veçanërisht
nuk ka ndryshuar:
Meqenëse Borg mund të funksionojë në modalitetin me shumë fije, ngarkesa e procesorit është maksimale dhe kur aktivizohen funksione shtesë, koha e funksionimit thjesht rritet. Me sa duket, ia vlen të eksploroni multithreading në një mënyrë të ngjashme me zbackup.
Vendas e përballoi rikuperimin pak më ngadalë, koha e funksionimit ishte 4 minuta 28 sekonda. Ngarkesa dukej si
si më poshtë:
Me sa duket, procesi i rikuperimit funksionon në disa tema, por efikasiteti nuk është aq i lartë sa ai i BorgBackup, por i krahasueshëm në kohë me rsync-in e rregullt.
Me urBackup Ishte e mundur të rivendoseshin të dhënat në 8 minuta e 19 sekonda, ngarkesa ishte
është si vijon:
Ngarkesa nuk është ende shumë e lartë, madje edhe më e ulët se ajo e katranit. Në disa vende ka breshëri, por jo më shumë se ngarkesa e një bërthame.
Përzgjedhja dhe arsyetimi i kritereve për krahasim
Siç u tha në një nga artikujt e mëparshëm, sistemi rezervë duhet të plotësojë kriteret e mëposhtme:
- Lehtësinë e përdorimit
- shkathtësi e mendjes
- stabilitet
- shpejtësi
Vlen të merret në konsideratë çdo pikë veç e veç në më shumë detaje.
Lehtësia e funksionimit
Është më mirë kur ka një buton "Bëni gjithçka mirë", por nëse ktheheni te programet reale, gjëja më e përshtatshme do të jetë një parim i njohur dhe standard i funksionimit.
Shumica e përdoruesve ka shumë të ngjarë të jenë më mirë nëse nuk duhet të mbajnë mend një sërë çelësash për cli, të konfigurojnë një sërë opsionesh të ndryshme, shpesh të paqarta nëpërmjet ueb-it ose tui, ose të konfigurojnë njoftime për funksionimin e pasuksesshëm. Kjo përfshin gjithashtu aftësinë për të "përshtatur" lehtësisht një zgjidhje rezervë në infrastrukturën ekzistuese, si dhe automatizimin e procesit rezervë. Ekziston gjithashtu mundësia e instalimit duke përdorur një menaxher paketash, ose në një ose dy komanda si "shkarkoni dhe shpaketoni". curl ссылка | sudo bash - një metodë komplekse, pasi duhet të kontrolloni se çfarë arrin përmes lidhjes.
Për shembull, nga kandidatët e konsideruar, një zgjidhje e thjeshtë është burp, rdiff-backup dhe restic, të cilat kanë çelësa mnemonikë për mënyra të ndryshme funksionimi. Pak më komplekse janë borg dhe dyfishtë. Më e vështira ishte AMANDA. Pjesa tjetër janë diku në mes për sa i përket lehtësisë së përdorimit. Në çdo rast, nëse ju duhen më shumë se 30 sekonda për të lexuar manualin e përdorimit, ose duhet të shkoni te Google ose një motor tjetër kërkimi, si dhe të lëvizni nëpër një fletë të gjatë ndihme, vendimi është i vështirë, në një mënyrë ose në një tjetër.
Disa nga kandidatët e konsideruar janë në gjendje të dërgojnë automatikisht një mesazh përmes e-mailjabber, ndërsa të tjerët mbështeten në sinjalizimet e konfiguruara në sistem. Për më tepër, më shpesh zgjidhjet komplekse nuk kanë cilësime alarmi plotësisht të dukshme. Në çdo rast, nëse programi rezervë prodhon një kod kthimi jo zero, i cili do të kuptohet saktë nga shërbimi i sistemit për detyrat periodike (një mesazh do t'i dërgohet administratorit të sistemit ose drejtpërdrejt në monitorim) - situata është e thjeshtë. Por nëse sistemi rezervë, i cili nuk funksionon në një server rezervë, nuk mund të konfigurohet, mënyra e qartë për të thënë për problemin është se kompleksiteti tashmë është i tepërt. Në çdo rast, lëshimi i paralajmërimeve dhe mesazheve të tjera vetëm në ndërfaqen e internetit ose në regjistrin është një praktikë e keqe, pasi më shpesh ato do të shpërfillen.
Për sa i përket automatizimit, një program i thjeshtë mund të lexojë variablat e mjedisit që vendosin mënyrën e tij të funksionimit, ose ka një klikim të zhvilluar që mund të kopjojë plotësisht sjelljen kur punoni, për shembull, përmes një ndërfaqe në internet. Kjo përfshin gjithashtu mundësinë e funksionimit të vazhdueshëm, disponueshmërinë e mundësive të zgjerimit, etj.
shkathtësi e mendjes
Duke i bërë jehonë pjesërisht nënseksionit të mëparshëm në lidhje me automatizimin, nuk duhet të jetë një problem i veçantë "përshtatja" e procesit rezervë në infrastrukturën ekzistuese.
Vlen të përmendet se përdorimi i porteve jo standarde (mirë, përveç ndërfaqes në internet) për punë, zbatimi i kriptimit në një mënyrë jo standarde, shkëmbimi i të dhënave duke përdorur një protokoll jo standard janë shenja të një jo standarde. -zgjidhje universale. Në pjesën më të madhe, të gjithë kandidatët i kanë ato në një mënyrë ose në një tjetër për arsyen e qartë: thjeshtësia dhe shkathtësia zakonisht nuk shkojnë së bashku. Si përjashtim - gromësirë, ka të tjerë.
Si shenjë - aftësia për të punuar duke përdorur ssh të rregullt.
Shpejtësia e punës
Pika më e diskutueshme dhe më e diskutueshme. Nga njëra anë, ne nisëm procesin, ai funksionoi sa më shpejt që të ishte e mundur dhe nuk ndërhyri në detyrat kryesore. Nga ana tjetër, ka një rritje të trafikut dhe ngarkesës së procesorit gjatë periudhës së rezervimit. Vlen gjithashtu të theksohet se programet më të shpejta për të bërë kopje janë zakonisht më të varfërit për sa i përket funksioneve që janë të rëndësishme për përdoruesit. Përsëri: nëse për të marrë një skedar teksti të pafat prej disa dhjetëra bajt në madhësi me një fjalëkalim, dhe për shkak të tij i gjithë shërbimi kushton (po, po, e kuptoj që procesi i rezervimit më shpesh nuk është fajtor këtu), dhe ju duhet të rilexoni në mënyrë sekuenciale të gjithë skedarët në depo ose të zgjeroni të gjithë arkivin - sistemi rezervë nuk është kurrë i shpejtë. Një pikë tjetër që shpesh bëhet pengesë është shpejtësia e vendosjes së një kopje rezervë nga një arkiv. Këtu ka një avantazh të qartë për ata që thjesht mund të kopjojnë ose zhvendosin skedarët në vendndodhjen e dëshiruar pa shumë manipulime (rsync, për shembull), por më shpesh problemi duhet të zgjidhet në një mënyrë organizative, në mënyrë empirike: duke matur kohën e rikuperimit të rezervës. dhe duke informuar hapur përdoruesit për këtë.
stabilitet
Duhet kuptuar në këtë mënyrë: nga njëra anë, duhet të jetë e mundur të vendoset kopja rezervë në çfarëdo mënyre, nga ana tjetër, duhet të jetë rezistente ndaj problemeve të ndryshme: ndërprerja e rrjetit, dështimi i diskut, fshirja e një pjese të depo.
Krahasimi i mjeteve rezervë
Koha e krijimit të kopjes
Kopjoni kohën e rikuperimit
Instalim i lehtë
Konfigurim i lehtë
Përdorim i thjeshtë
Automatizimi i thjeshtë
Keni nevojë për një server klienti?
Kontrollimi i integritetit të depove
Kopje diferenciale
Puna përmes tubit
shkathtësi e mendjes
pavarësi
Transparenca e depove
encryption
Ngjeshja
Dedublikim
Ndërfaqja në ueb
Mbushje deri në re
mbështetje për Windows
Mark
rsync
4 m15s
4 m28s
po
jo
jo
jo
po
jo
jo
po
jo
po
po
jo
jo
jo
jo
jo
po
6
katran
i pastër
3 m12s
2 m43s
po
jo
jo
jo
jo
jo
po
po
jo
po
jo
jo
jo
jo
jo
jo
po
8,5
gzip
9 m37s
3 m19s
po
Rdiff-backup
16 m26s
17 m17s
po
po
po
po
po
jo
po
jo
po
jo
po
jo
po
po
po
jo
po
11
Rsnapshot
4 m19s
4 m28s
po
po
po
po
jo
jo
po
jo
po
jo
po
jo
jo
po
po
jo
po
12,5
Gërvishtje
11 m9s
7 m2s
po
jo
po
po
po
po
po
jo
po
po
jo
jo
po
jo
po
jo
po
10,5
hipokrizi
pa enkriptim
16 m48s
10 m58s
po
po
jo
po
jo
po
po
jo
jo
po
jo
po
po
jo
po
jo
po
11
GPG
17 m27s
15 m3s
Dublikatë
pa enkriptim
20 m28s
13 m45s
jo
po
jo
jo
jo
po
po
jo
jo
po
jo
po
po
po
po
po
po
11
aes
29 m41s
21 m40s
GPG
26 m19s
16 m30s
Rikthimi
pa enkriptim
40 m3s
11 m8s
po
po
jo
jo
jo
po
po
po
jo
po
jo
po
po
po
jo
jo
jo
10
aes
42 m0s
14 m1s
aes+lzo
18 m9s
6 m19s
BorgBackup
pa enkriptim
4 m7s
2 m45s
po
po
po
po
po
po
po
po
po
po
jo
po
po
po
po
jo
po
16
aes
4 m58s
3 m23s
blake2
4 m39s
3 m19s
Vendas
5 m38s
4 m28s
po
po
po
po
jo
po
po
po
po
po
jo
po
jo
po
jo
po
po
15,5
urBackup
8 m21s
8 m19s
po
po
po
jo
po
jo
po
jo
po
po
jo
po
po
po
po
jo
po
12
amanda
9 m3s
2 m49s
po
jo
jo
po
po
po
po
jo
po
po
po
po
po
jo
po
po
po
13
BackupPC
rsync
12 m22s
7 m42s
po
jo
po
po
po
po
po
jo
po
jo
jo
po
po
jo
po
jo
po
10,5
katran
12 m34s
12 m15s
Legjenda e tabelës:
- E gjelbër, koha e funksionimit më pak se pesë minuta ose përgjigjuni "Po" (përveç kolonës "Kë nevojë për një server klienti?"), 1 pikë
- E verdhë, koha e funksionimit pesë deri në dhjetë minuta, 0.5 pikë
- E kuqe, koha e punës është më shumë se dhjetë minuta, ose përgjigja është "Jo" (përveç kolonës "A keni nevojë për një server klienti?"), 0 pikë
Sipas tabelës së mësipërme, mjeti më i thjeshtë, më i shpejtë dhe në të njëjtën kohë i përshtatshëm dhe i fuqishëm i rezervimit është BorgBackup. Restic zuri vendin e dytë, pjesa tjetër e kandidatëve të konsideruar u vendosën afërsisht në mënyrë të barabartë me një shtrirje prej një ose dy pikësh në fund.
Falenderoj të gjithë ata që e lexuan serialin deri në fund, ju ftoj të diskutoni opsionet dhe të ofroni tuajat, nëse ka. Ndërsa diskutimi përparon, tabela mund të zgjerohet.
Rezultati i serisë do të jetë artikulli përfundimtar, në të cilin do të ketë një përpjekje për të zhvilluar një mjet rezervë ideal, të shpejtë dhe të menaxhueshëm që ju lejon të vendosni një kopje përsëri në kohën më të shkurtër të mundshme dhe në të njëjtën kohë të jetë i përshtatshëm dhe i lehtë. për të konfiguruar dhe mirëmbajtur.
Shpallje
Rezervimi Pjesa 6: Krahasimi i mjeteve rezervë
Pjesa rezervë 7: Përfundime
Burimi: www.habr.com