Selles artiklis võrreldakse varundustööriistu, kuid kõigepealt peaksite välja selgitama, kui kiiresti ja hästi need varukoopiatest andmete taastamisega hakkama saavad.
Võrdluse hõlbustamiseks kaalume täielikust varukoopiast taastamist, eriti kuna kõik kandidaadid toetavad seda töörežiimi. Lihtsuse huvides on arvud juba keskmistatud (mitme jooksu aritmeetiline keskmine). Tulemused võetakse kokku tabelis, mis sisaldab teavet ka võimaluste kohta: veebiliidese olemasolu, seadistamise ja kasutamise lihtsus, automatiseerimisvõimalus, erinevate lisafunktsioonide olemasolu (näiteks andmete terviklikkuse kontrollimine) , jne. Graafikud näitavad serveri koormust, kus andmeid kasutatakse (mitte varukoopiate salvestamise serveris).
Andmete taastamine
aastast kasutatakse võrdluspunktina rsynci ja tar lihtsad skriptid varukoopiate tegemiseks.
rsync tuli testandmete komplektiga toime 4 minuti ja 28 sekundiga, näidates
selline koormus
Taasteprotsess tabas varukoopiasalvestusserveri ketta alamsüsteemi piirangut (saehamba graafikud). Samuti on selgelt näha ühe kerneli laadimine ilma probleemideta (madal iowait ja softirq - ketta ja võrguga pole probleeme vastavalt). Kuna ülejäänud kaks programmi, nimelt rdiff-backup ja rsnapshot, põhinevad rsyncil ja pakuvad ka tavalist rsynci taastetööriistana, on neil ligikaudu sama laadimisprofiil ja varukoopia taastamise aeg.
Tõrv sai natuke kiiremini tehtud
2 minutit ja 43 sekundit:
Süsteemi kogukoormus oli kõrgenenud softirq tõttu keskmiselt 20% kõrgem - kasvasid üldkulud võrgu alamsüsteemi töö ajal.
Arhiivi täiendava tihendamise korral pikeneb taastamisaeg 3 minutini 19 sekundini.
sellise koormuse korral põhiserveris (lahtipakkimine põhiserveri küljel):
Dekompressiooniprotsess võtab mõlemad protsessori tuumad, kuna töötab kaks protsessi. Üldiselt on see oodatud tulemus. Samuti saadi võrreldav tulemus (3 minutit ja 20 sekundit) gzipi käivitamisel serveri poolel koos varukoopiatega; põhiserveri laadimisprofiil oli väga sarnane tar käivitamisega ilma gzip-kompressorita (vt eelmist graafikut).
В rdiff-varukoopia saate sünkroonida viimase varukoopia, mille tegite tavalise rsynci abil (tulemused on sarnased), kuid vanemad varukoopiad tuleb siiski taastada, kasutades programmi rdiff-backup, mis viis taastamise lõpule 17 minuti ja 17 sekundiga, näidates
see koormus:
Võib-olla oli see mõeldud, vähemalt autorite kiiruse piiramiseks . Varukoopia taastamise protsess võtab rsynci abil ketta ja võrgu kaudu proportsionaalselt võrreldava jõudlusega (st 2–5 korda aeglasemalt) veidi vähem kui poole ühest tuumast.
Pilttõmmis Taastamiseks soovitab see kasutada tavalist rsynci, nii et selle tulemused on sarnased. Üldiselt läks see nii.
Röhitsema Varukoopia taastamise ülesande täitsin 7 minuti ja 2 sekundiga
selle koormusega:
See töötas üsna kiiresti ja on vähemalt palju mugavam kui puhas rsync: pole vaja ühtegi lippu meeles pidada, lihtne ja intuitiivne kliliides, sisseehitatud tugi mitme koopia jaoks – kuigi see on kaks korda aeglasem. Kui teil on vaja taastada andmed viimati tehtud varukoopiast, võite mõne ettevaatusega kasutada rsynci.
Programm näitas ligikaudu sama kiirust ja koormust VarundaminePC rsynci edastusrežiimi lubamisel juurutatakse varukoopia
7 minutit ja 42 sekundit:
Kuid andmeedastusrežiimis tuli BackupPC tõrvaga toime aeglasemalt: 12 minuti ja 15 sekundiga oli protsessori koormus üldiselt väiksem
poolteist korda:
Duplicity ilma krüptimiseta näitas veidi paremaid tulemusi, taastades varukoopia 10 minuti ja 58 sekundiga. Kui aktiveerite krüptimise gpg abil, pikeneb taastamisaeg 15 minutini ja 3 sekundini. Samuti saate koopiate hoidmiseks hoidla loomisel määrata arhiivi suuruse, mida kasutatakse sissetuleva andmevoo jagamisel. Üldiselt pole tavalistel kõvaketastel, ka ühe keermega töörežiimi tõttu, erilist vahet. Hübriidsalvestuse kasutamisel võib see kuvada erineva suurusega plokkidena. Peaserveri koormus taastamise ajal oli järgmine:
krüptimist pole
krüptimisega
Duplikaat näitas võrreldavat taastumiskiirust, lõpetades selle 13 minuti ja 45 sekundiga. Taastatud andmete õigsuse kontrollimiseks kulus veel umbes 5 minutit (kokku umbes 19 minutit). Koormus oli
üsna kõrge:
Kui AES-krüptimine oli sisemiselt lubatud, oli taastumisaeg 21 minutit 40 sekundit, protsessori kasutus oli taastamise ajal maksimaalne (mõlemad tuumad!); Andmete kontrollimisel oli aktiivne ainult üks lõim, mis hõivas ühe protsessori tuuma. Andmete kontrollimine pärast taastumist võttis aega sama 5 minutit (kokku peaaegu 27 minutit).
Tulemus
duplicati oli taastamisega veidi kiirem, kui kasutati krüptimiseks välist gpg programmi, kuid üldiselt on erinevused eelmisest režiimist minimaalsed. Tööaeg oli 16 minutit 30 sekundit, andmete kontrollimine 6 minutiga. Koormus oli
selline:
AMANDA, kasutades tõrva, läbis selle 2 minuti 49 sekundiga, mis on põhimõtteliselt väga lähedane tavalisele tõrvale. Põhimõtteliselt laadige süsteem peale
sama:
Varukoopia taastamisel kasutades zbackup saadi järgmised tulemused:
krüptimine, lzma tihendamine
Mänguaeg 11 minutit ja 8 sekundit
AES-krüptimine, lzma-tihendamine
Tööaeg 14 minutit
AES-krüptimine, lzo-tihendamine
Mänguaeg 6 minutit, 19 sekundit
Üldiselt pole paha. Kõik oleneb varuserveris oleva protsessori kiirusest, mis on erinevate kompressoritega programmi tööajast selgelt näha. Varuserveri poolelt käivitati tavaline tõrv, nii et kui sellega võrrelda, on taastumine 3 korda aeglasem. Võib-olla tasub kontrollida toimimist mitme keermega režiimis, kus on rohkem kui kaks lõime.
BorgBackup krüptimata režiimis oli see veidi aeglasem kui tar, 2 minuti 45 sekundiga, kuid erinevalt tarist sai võimalikuks hoidla deduplikatsiooni. Koormus osutus
järgnev:
Kui lubate blake-põhise krüptimise, on varukoopia taastamise kiirus veidi aeglasem. Taastumisaeg selles režiimis on 3 minutit 19 sekundit ja koormus on kadunud
nagu nii:
AES-i krüptimine on veidi aeglasem, taastumisaeg on 3 minutit 23 sekundit, koormus on eriti suur
pole muutunud:
Kuna Borg saab töötada mitme keermega režiimis, on protsessori koormus maksimaalne ja lisafunktsioonide aktiveerimisel tööaeg lihtsalt pikeneb. Ilmselt tasub zbackupi sarnasel viisil uurida mitmelõimega töötamist.
Puhata taastumisega tuli toime veidi aeglasemalt, tööaeg oli 4 minutit 28 sekundit. Koormus nägi välja selline
nii:
Ilmselt töötab taasteprotsess mitmes lõimes, kuid efektiivsus pole nii kõrge kui BorgBackupil, kuid ajaliselt võrreldav tavalise rsynciga.
Koos urBackup Andmed õnnestus taastada 8 minuti ja 19 sekundiga, koormus oli
selline:
Koormus pole ikka väga suur, isegi väiksem kui tõrval. Kohati on purunemisi, kuid mitte rohkem kui ühe südamiku koormus.
Võrdluskriteeriumide valik ja põhjendus
Nagu ühes eelmises artiklis öeldud, peab varusüsteem vastama järgmistele kriteeriumidele:
- Kasutusmugavus
- mitmekülgsus
- Stabiilsus
- Kiirus
Tasub kaaluda iga punkti eraldi üksikasjalikumalt.
Kasutamise lihtsus
Parim on, kui on üks nupp "Tee kõik hästi", kuid kui naasete pärisprogrammide juurde, on kõige mugavam mõni tuttav ja tavaline tööpõhimõte.
Enamikul kasutajatel on tõenäoliselt parem, kui nad ei pea meeles pidama hunnikut cli klahve, konfigureerima veebi või tui kaudu erinevaid, sageli ebaselgeid valikuid ega seadistama teatisi ebaõnnestunud toimingute kohta. See hõlmab ka võimalust varunduslahendust lihtsalt olemasolevasse infrastruktuuri "sobitada" ning varundusprotsessi automatiseerimist. Samuti on võimalik installida paketihalduri abil või ühe või kahe käsuga, näiteks "allalaadimine ja lahtipakkimine". curl ссылка | sudo bash - keeruline meetod, kuna peate kontrollima, mis lingi kaudu saabub.
Näiteks vaadeldavatest kandidaatidest on lihtsaks lahenduseks burp, rdiff-backup ja restic, millel on erinevate töörežiimide jaoks märguandeklahvid. Veidi keerulisemad on borg ja kahepalgelisus. Kõige raskem oli AMANDA. Ülejäänud on kasutusmugavuse poolest kuskil keskel. Igal juhul, kui vajate kasutusjuhendi lugemiseks rohkem kui 30 sekundit või peate minema Google’i või mõne teise otsingumootori poole ja lisaks ka pikka abilehte kerima, on otsus nii või teisiti raske.
Mõned kaalutud kandidaadid suudavad automaatselt e-posti teel sõnumi saata, teised aga tuginevad süsteemis konfigureeritud hoiatustele. Pealegi pole keerukatel lahendustel enamasti täiesti selged hoiatusseaded. Igal juhul, kui varundusprogramm toodab nullist erineva tagastuskoodi, millest süsteemiteenus perioodiliste toimingute jaoks õigesti aru saab (saadetakse teade süsteemiadministraatorile või otse jälgimisele) - olukord on lihtne. Kui aga varusüsteemi, mis ei tööta varuserveris, ei saa konfigureerida, on probleemi kohta ilmselge, et keerukus on juba liigne. Igal juhul on hoiatuste ja muude teadete väljastamine ainult veebiliidesele või logile halb tava, kuna enamasti jäetakse need tähelepanuta.
Mis puudutab automatiseerimist, siis lihtne programm suudab lugeda keskkonnamuutujaid, mis määravad selle töörežiimi, või on tal välja töötatud klii, mis suudab käitumist täielikult dubleerida näiteks veebiliidese kaudu töötades. See hõlmab ka pideva töötamise võimalust, laienemisvõimaluste olemasolu jne.
mitmekülgsus
Osaliselt kordades eelmist automatiseerimise alajaotist, ei tohiks olla eriline probleem varundusprotsessi olemasolevasse taristusse “sobitamine”.
Väärib märkimist, et mittestandardsete portide (noh, välja arvatud veebiliidese) kasutamine tööks, krüptimise rakendamine mittestandardsel viisil, andmevahetus mittestandardse protokolli abil on märgid mittestandardsest. - universaalne lahendus. Enamasti on kõigil kandidaatidel need ühel või teisel moel ilmselgel põhjusel: lihtsus ja mitmekülgsus tavaliselt kokku ei käi. Erandina - röhits, on ka teisi.
Märgiks - võime töötada tavalist ssh-d kasutades.
Töö kiirus
Kõige vastuolulisem ja vastuolulisem punkt. Ühest küljest käivitasime protsessi, see toimis võimalikult kiiresti ega seganud põhiülesannete täitmist. Teisest küljest on varundamise perioodil liiklus ja protsessori koormus suurenenud. Märkimist väärib ka see, et kõige kiiremad koopiate tegemise programmid on kasutajatele oluliste funktsioonide poolest enamasti kõige viletsamad. Jällegi: kui ühe õnnetu, mitmekümnebaidise tekstifaili saamiseks parooliga ja selle tõttu kogu teenus maksab (jah, jah, ma saan aru, et varundusprotsess pole siin enamasti süüdi), ja peate järjestikku uuesti läbi lugema kõik hoidlas olevad failid või laiendama kogu arhiivi – varundussüsteem pole kunagi kiire. Teine punkt, mis sageli komistuskiviks saab, on arhiivist varukoopia juurutamise kiirus. Siin on selge eelis neil, kes saavad faile lihtsalt kopeerida või liigutada soovitud asukohta ilma suurema manipuleerimiseta (nt rsync), kuid enamasti tuleb probleem lahendada organisatsiooniliselt, empiiriliselt: mõõtes varukoopia taastamise aega. ja kasutajaid sellest avalikult teavitades.
Stabiilsus
Seda tuleks mõista nii: ühest küljest peab olema võimalik varukoopiat mis tahes viisil tagasi juurutada, teisalt peab see olema vastupidav erinevatele probleemidele: võrgukatkestus, ketta rike, osa kustutamine hoidla.
Varundustööriistade võrdlus
Koopia loomise aeg
Kopeeri taastamise aeg
Lihtne paigaldada
Lihtne seadistamine
Lihtne kasutamine
Lihtne automatiseerimine
Kas vajate kliendiserverit?
Hoidla terviklikkuse kontrollimine
Diferentsiaalkoopiad
Töötamine toru kaudu
mitmekülgsus
Iseseisvus
Hoidla läbipaistvus
Krüpteerimine
kokkusurumine
Deduplikatsioon
Veebi liides
Pilve täitmine
Windowsi tugi
Skoor
rsync
4m15s
4m28s
jah
ei
ei
ei
jah
ei
ei
jah
ei
jah
jah
ei
ei
ei
ei
ei
jah
6
Tõrv
puhas
3m12s
2m43s
jah
ei
ei
ei
ei
ei
jah
jah
ei
jah
ei
ei
ei
ei
ei
ei
jah
8,5
gzip
9m37s
3m19s
jah
Rdiff-varukoopia
16m26s
17m17s
jah
jah
jah
jah
jah
ei
jah
ei
jah
ei
jah
ei
jah
jah
jah
ei
jah
11
Pilttõmmis
4m19s
4m28s
jah
jah
jah
jah
ei
ei
jah
ei
jah
ei
jah
ei
ei
jah
jah
ei
jah
12,5
Röhitsema
11m9s
7m2s
jah
ei
jah
jah
jah
jah
jah
ei
jah
jah
ei
ei
jah
ei
jah
ei
jah
10,5
Duplicity
krüptimist pole
16m48s
10m58s
jah
jah
ei
jah
ei
jah
jah
ei
ei
jah
ei
jah
jah
ei
jah
ei
jah
11
gpg
17m27s
15m3s
Duplikaat
krüptimist pole
20m28s
13m45s
ei
jah
ei
ei
ei
jah
jah
ei
ei
jah
ei
jah
jah
jah
jah
jah
jah
11
AES
29m41s
21m40s
gpg
26m19s
16m30s
zbackup
krüptimist pole
40m3s
11m8s
jah
jah
ei
ei
ei
jah
jah
jah
ei
jah
ei
jah
jah
jah
ei
ei
ei
10
AES
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
krüptimist pole
4m7s
2m45s
jah
jah
jah
jah
jah
jah
jah
jah
jah
jah
ei
jah
jah
jah
jah
ei
jah
16
AES
4m58s
3m23s
blake2
4m39s
3m19s
Puhata
5m38s
4m28s
jah
jah
jah
jah
ei
jah
jah
jah
jah
jah
ei
jah
ei
jah
ei
jah
jah
15,5
urBackup
8m21s
8m19s
jah
jah
jah
ei
jah
ei
jah
ei
jah
jah
ei
jah
jah
jah
jah
ei
jah
12
Amanda
9m3s
2m49s
jah
ei
ei
jah
jah
jah
jah
ei
jah
jah
jah
jah
jah
ei
jah
jah
jah
13
VarundaminePC
rsync
12m22s
7m42s
jah
ei
jah
jah
jah
jah
jah
ei
jah
ei
ei
jah
jah
ei
jah
ei
jah
10,5
tõrv
12m34s
12m15s
Tabeli legend:
- Roheline, tööaeg alla viie minuti või vastus "Jah" (v.a veerg "Kas vajate kliendiserverit?"), 1 punkt
- Kollane, tööaeg viis kuni kümme minutit, 0.5 punkti
- Punane, tööaeg on üle kümne minuti või vastus on "Ei" (v.a veerg "Kas vajate kliendiserverit?"), 0 punkti
Ülaltoodud tabeli järgi on kõige lihtsam, kiirem ja samas mugavam ja võimsam varundustööriist BorgBackup. Restic saavutas teise koha, ülejäänud kaalutud kandidaadid paigutati ligikaudu võrdselt ühe või kahe punktilise vahega.
Tänan kõiki, kes sarja lõpuni lugesid, kutsun teid arutlema võimaluste üle ja pakkuma oma, kui neid on. Arutelu edenedes võidakse tabelit täiendada.
Sarja tulemuseks on viimane artikkel, milles püütakse välja töötada ideaalne, kiire ja juhitav varundustööriist, mis võimaldab teil koopia võimalikult lühikese aja jooksul tagasi juurutada ning samal ajal olla mugav ja lihtne konfigureerimiseks ja hooldamiseks.
Kuulutus
Varundamine 6. osa: varundustööriistade võrdlemine
Varukoopia 7. osa: Järeldused
Allikas: www.habr.com