Selles artiklis võrreldakse varundustarkvara, kuid kõigepealt on hea mõista, kui kiiresti ja tõhusalt nad andmeid varukoopiatest taastavad.
Võrdluse lihtsustamiseks keskendutakse täielikest varukoopiatest taastamisele, kuna seda töörežiimi toetavad kõik kandidaadid. Numbrid on lihtsuse huvides juba keskmistatud (arvutatud mitmest proovist). Tulemused koondatakse tabelisse, kus on ka teave võimaluste kohta: veebiliidese olemasolu, seadistamise ja kasutamise lihtsus, automatiseerimisvõime, erinevaid täiendavaid funktsioone (näiteks andmete terviklikkuse kontrollimine) jne. Graafikud näitavad serveri koormust, kus andmeid rakendatakse (mitte varukoopiate salvestamise serverit).
Andmete taastamine
Viidatud punktidena kasutatakse rsynci ja tar‘i, kuna lihtsaimatele varundusskriptidele.
Rsync lahendas testkomplekti andmed 4 minuti ja 28 sekundi jooksul, näidates
sellist koormust
Taasteprotsess jõudis serveri varukoopia salvestusseadmestiku piirangutesse (saagide graafikud). Samuti on selgelt näha ühe tuuma koormust ilma eriliste probleemideta (madal iowait ja softirq — ei ole probleeme ketaste ja võrgu osas vastavalt). Kuna kaks muud programmi, nimelt rdiff-backup ja rsnapshot, põhinevad rsync'il ning pakuvad taastamisvahendina tavalist rsync'i, on neil ligikaudu samasugused koormusprofiilid ja varukoopia taastamisaeg.
Tar kõikus ka pisut kiiremini, kuludes
2 minutit ja 43 sekundit:
Süsteemi täiskoormus oli keskmiselt 20% kõrgem tänu suurenenud softirq'le — võrgu alamsüsteemi töö suurenenud kulu tõttu.
Kui arhiiv täiendavalt kokku suruda, siis taastamisaeg tõuseb 3 minutini ja 19 sekundini
sellise koormuse all põhiserveril (dekompressioon põhiserveris):
Pakkimisprotsess kasutab mõlemat protsessorituuma, kuna käivitatakse kaks protsessi. Kokkuvõttes on see oodatud tulemus. Samuti saadi sarnane tulemus (3 minutit ja 20 sekundit) gzip'i käivitamisel serveri küljel varukoopiate jaoks; põhilise serveri koormusprofiil sarnanes väga gzip'i kompressori käivitamisega tar'i puhul (vt eelmist diagrammi).
V rdiff-backup Viimase loodud varukoopia saab sünkroonida tavapärase rsync'i abil (tulemused on sarnased), kuid vanemad varukoopiad tuleb ikkagi taastada rdiff-backup programmi abil, mis suutis taastamise hõlpsasti teostada 17 minuti ja 17 sekundi jooksul, näidates
sellist koormust:
Võib-olla oli see tõesti niimoodi mõeldud, igal juhul soovitavad autorid kiiruspiiranguid . Varukoopia taastamise protsess ise kasutab vähem kui pool ühe tuuma ressurssidest, pakkudes proportsionaalselt sarnast tootlikkust (st 2-5 korda aeglasem) andmeedastus ja võrgu rsync'i kaudu.
Rsnapshot soovitab taastamiseks kasutada tavalist rsync'i, mistõttu on selle tulemused sarnased. Kokkuvõttes see just nii läkski.
Burp sai varukoopia taastamise ülesandega toime tulla 7 minuti ja 2 sekundiga
sellise koormuse puhul:
Töötas piisavalt kiiresti ja oli igal juhul palju mugavam kui puhas rsync: ei pea meeles pidama mingeid lippusid, lihtne ja intuitiivne cli-liides, sisseehitatud toetus mitmele koopiale — tõsi, umbes kaks korda aeglasem. Kui andmeid tuleb taastada eelmisel korral tehtud varukoopiast — võib kasutada rsync'i, mõningate eranditega.
Umbes sama kiirus ja koormus näitas programm BackupPC rsync'i ülekande režiimi sisselülitamisel, avades varukoopia
7 minuti ja 42 sekundi jooksul:
Kuid andmete ülekande režiimis tar BackupPC suutis aeglasemalt: 12 minuti ja 15 sekundi jooksul, protsessori koormus oli üldiselt madalam
koold poolteist korda:
Duplicity ilma krüpteeringuta näitas veidi paremaid tulemusi, taastades varukoopia 10 minuti ja 58 sekundi jooksul. Kui aktiveerida krüpteerimine gpg abil, pikeneb taastamisaeg 15 minutini ja 3 sekundini. Samuti, kui luua varukoopiate salvestamiseks hoidla, saab määrata arhiivi suuruse, mida kasutatakse siseneva andmevoo jagamisel. Üldiselt ei ole tavaliste kõvakettade korral, tulenevalt ka ühe niidi töörežiimist, erilist erinevust. See võib ilmneda erinevate plokkide suuruste kasutamisel hübriidhoidlate puhul. Peamise serveri koormus taastamise ajal oli selline:
ilma krüpteerimise
krüpteerimisega
Duplicati näitas võrreldavat taastamiskiirust, saavutades selle 13 minuti ja 45 sekundi jooksul. Andmete taastamise korrektsuse kontrollimiseks kulus veel umbes 5 minutit (kokku umbes 19 minutit). Koormus oli sel ajal
piisavalt kõrge:
Kui aes krüpteerimine aktiveeriti sisemiste vahenditega, oli taastamisaeg 21 minutit ja 40 sekundit, kusjuures protsessori koormus oli taastamise ajal maksimaalne (kaks tuuma!). Andmete kontrollimisel oli aktiivne ainult üks lõime, mis kasutas ühte protsessorituuma. Andmete kontrollimine pärast taastamist kestis sama kaua, 5 minutit (kokku peaaegu 27 minutit).
Tulemus
Veidi kiiremini kell duplicati saavutas taastamise, kasutades krüpteerimisel välist programmi gpg, kuid kokkuvõttes on erinevused eelmisest režiimist minimaalsed. Töönäitajad olid 16 minutit ja 30 sekundit, andmete kontrollimise ajal 6 minutit. Koormus oli
selline:
AMANDA, mis kasutab tar, saavutas aja 2 minutit ja 49 sekundit, mis on põhimõtteliselt üsna lähedane tavapärasele tar-ile. Süsteemi koormus on põhimõtteliselt
samuti sama:
Taastamise varukoopia vahenditega zbackup saadi järgmised tulemused:
krüpteerimine, kompressioon lzma
Tööntaeg 11 minutit ja 8 sekundit
krüpteerimine aes, kompressioon lzma
Tööntaeg 14 minutit
krüpteerimine aes, kompressioon lzo
Tööntaeg 6 minutit, 19 sekundit
Kokkuvõttes on see üsna kena. Kõik sõltub backup-serveri protsessori kiirusest, mida on selgelt näha, kui võrreldakse erinevate tihenditega programmide tööaegu. Backup-serverist käivitati tavaline tar, seega, kui võrrelda sellega, siis taastamine töötab kolm korda aeglasemalt. Võib-olla tasuks proovida tööd mitme lõimega, kus lõimede arv on suurem kui kaks.
BorgBackup ilma krüpteerimisrežiimis toimis see veidi aeglasemalt kui tar, 2 minutit 45 sekundit, kuid erinevalt samast tar'ist, on tekkinud võimalus repositoriumi dedupeerida. Koormus sel juhul osutus
järgnevaks:
Kui aktiveerida blake-põhine krüpteerimine, siis backup'i taastamise kiirus veidi aeglustub. Taastamis aeg on sel režiimil 3 minutit 19 sekundit ja koormus oli
selline:
AES-krüpteerimine töötab veidi aeglasemalt, taastamisaeg on 3 minutit 23 sekundit, koormus ei ole eriti
muutunud:
Kuna Borg suudab töötada mitme lõime režiimis, on protsessori koormus maksimaalne, samas kui täiendavate funktsioonide aktiveerimisel kasvab lihtsalt tööaeg. Tundub, et tasub uurida töö mitme lõime kasutuse mõju sarnaselt zbackup'iga.
Restic taastas andmed veidi aeglasemalt, tööaeg oli 4 minutit ja 28 sekundit. Koormus näis sel ajal olevat
nii:
Tundub, et taastamisprotsess töötab mitme lõimega, kuid efektiivsus ei ole nii kõrge kui BorgBackup'il, kuid ajaliselt on see võrreldav tavalise rsync'iga.
Käesoleva abil UrBackup õnnestus andmed taastada 8 minutiga ja 19 sekundiga, samal ajal oli koormus
selline:
Kõik näitab endiselt mitte eriti kõrget koormust, isegi madalam kui tar. Kohati esinevad tõusud, kuid mitte rohkem kui ühe tuuma koormus.
Kriteeriumide valik ja põhjendamine võrdlemiseks
Kuidas öeldi ühes varasemas artiklis, peab varundussüsteem vastama järgmistele kriteeriumidele:
- Lihtsus töös
- Universaalsus
- Stabiilsus
- Kiirus
Iga punkti tuleks eraldi põhjalikumalt vaadata.
Töötamise lihtsus
Parim on siis, kui on olemas üks nupp "Tee kõik õigesti", kuid kui minna tagasi tõeliselt toimivate programmide juurde, siis on mugavaim mõni tuttav ja standardne tööpõhimõte.
Enamiku kasutajate jaoks oleks parem, kui ei peaks mäletama hulka klahve CLI jaoks, seadistama palju erinevaid, tihti arusaamatuid valikuid veebis või TUI-s ning seadistama ebaõnnestumise teavitusi. Siia kuulub ka võimalus hõlpsasti „mugandada“ varukoopiate lahendus olemasolevasse infrastruktuuri ja varukoopiate protsessi automatiseerimine. Samuti peaks olema võimalus paigaldada paketihalduri kaudu või vaid ühe–kahe käsuga, nagu "laadi ja lahenda". curl link | sudo bash — keeruline meetod, kuna tuleb kontrollida, mis linkide kaudu tuleb.
Näiteks on arutatud kandidaatide hulgast lihtsaim lahendus burp, rdiff-backup ja restic, millel on erinevates töörežiimides lihtsasti meeldejäävad võtmed. Veidi keerulisemad lahendused on borg ja duplicity. Kõige keerulisem oli AMANDA. Ülejäänud jäävad kasutusmugavuse poolest kusagile nende vahele. Igal juhul, kui kasutajate käsiraamatule lugemiseks kulub rohkem kui 30 sekundit, või peab minema Google'i või mõnda teise otsingumootorisse ning sirvima pikka abiteksti, siis on lahendus keeruline, ükskõik kuidas vaadata.
Mõned hinnatud kandidaadid oskavad automaatselt saata sõnumit e-mail jabberis, teised toetuvad aga süsteemis seadistatud teavitustele. Enamasti on keerukad lahendused omamoodi keerulised teavitussätted. Igal juhul, kui varukoopia programm annab nullist erineva tagastuskoodi, mille süsteemne teenus saab õigesti mõista (kas saadab teate süsteemi administraatorile või kohe jälgimisele) — olukord on lihtne. Kuid kui varundussüsteem, mis ei tööta varukoopiaseeral, ei saa õigesti konfigureerimata öelda probleemist lihtsal viisil — olukord on juba keeruline. Igal juhul teavituste ja muude sõnumite väljastamine ainult veebiliideses ja/või ajaloos — on halb praktika, kuna need lähevad enamasti tähelepanuta.
Mis automaatika osas oskab lihtne programm lugeda töökeskkonna muutujaid, mis määravad selle töörežiimi, või tal on hästi välja arendatud CLI, mis suudab täielikult dubleerida käitumist veebiliidese kaudu, näiteks. Siia kuulub ka võimalus voogedastuseks, laiendamisvõimaluste olemasolu jne.
Universaalsus
See osaliselt kattub eelmise alapeaga automatiseerimise osas ja ei tohiks olla erilist probleemi, et «sobitada» varundusprotsessi olemasolevasse infrastruktuuri.
Tasub märkida, et ebastandardsed pordid (välja arvatud veebiliides) tööks, krüpteerimise rakendamine mittetavapärasel viisil, andmeedastamine mittetavapärase protokolli kaudu — on mitteuniversaalsete lahenduste tunnuseks. Suures osas on kõik kandidaadid seda isegi mingil määral oma ilmselge põhjuse tõttu: lihtsus ja universaalsus ei ole tavaliselt ühilduvad. Erandina on burp, on ka teisi.
Tunnusena — võimalus töötada tavapärase SSH kasutamise kaudu.
Töökiirus
Kõige vastuolulisem ja vaieldavam punkt. Ühelt poolt — käivitasime protsessi, see toimis maksimaalselt kiiresti ja ei seganud põhitegevusi. Teiselt poolt — liikluse ja protsessori koormuse püsimine varukoopiate tegemise ajal. Samuti tasub märkida, et kiireimad varundusprogrammid on tavaliselt funktsioonide poolest vaesed, mis on kasutajatele olulised. Taas: kui selleks, et leida üks õnnetu tekstifail, mille suurus on vaid paar kymmet baiti ja see on parooliga kaitstud, on kogu teenus ohus (jah, ma mõistan, et sageli ei ole varundusprotsess selles süüdi) ning tuleb järjestikku läbi lugeda kõik failid repos või avada terve arhiiv — varundussüsteem ei ole sugugi kiire. Veel üks punkt, mis sageli muutub takistuseks — varukoopia taastamise kiirus arhiivist. Siin on selge eelis neil, kes saavad lihtsalt faile vajalikku kohta kopeerida või teisaldada ilma eriliste manipulatsioonideta (nt rsync), kuid enamikul juhtudel tuleb probleem lahendada organisatsiooniliselt, empiiriliselt: mõõta varukoopia taastamise aega ja sellest kasutajatele avameelselt teatada.
Stabiilsus
Oluline on mõista, et ühelt poolt peab olema võimalus varukoopia igal ajal taastada, teiselt poolt peab olema vastupidavus erinevates probleemides: võrgu katkestused, kettahäired, osa hoidla kustutamine.
Varundamisvahendite võrdlus
Varukoopia loomise aeg
Varukoopia taastamise aeg
Lihtne paigaldus
Lihtne seadistamine
Lihtne kasutamine
Lihtne automatiseerimine
Kas on vaja kliendiserverit?
Hoidla terviklikkuse kontrollimine
Diferentsiaalsed varukoopiad
Töö pipe kaudu
Universaalsus
Iseseisvus
Hoidla läbipaistvus
Krüpteerimine
Kompresseerimine
Deduplication
Veebiliides
Pilve üleslaadimine
Windowsi tugi
Punkt
Rsync
4m15s
4m28s
jah
ei
ei
ei
jah
ei
ei
jah
ei
jah
jah
ei
ei
ei
ei
ei
jah
6
Tar
puhtad
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-backup
16m26s
17m17s
jah
jah
jah
jah
jah
ei
jah
ei
jah
ei
jah
ei
jah
jah
jah
ei
jah
11
Rsnapshot
4m19s
4m28s
jah
jah
jah
jah
ei
ei
jah
ei
jah
ei
jah
ei
ei
jah
jah
ei
jah
12,5
Burp
11m9s
7m2s
jah
ei
jah
jah
jah
jah
jah
ei
jah
jah
ei
ei
jah
ei
jah
ei
jah
10,5
Duplicity
no encryption
16m48s
10m58s
jah
jah
ei
jah
ei
jah
jah
ei
ei
jah
ei
jah
jah
ei
jah
ei
jah
11
gpg
17m27s
15m3s
Duplicati
no encryption
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
no encryption
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
no encryption
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
Restic
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
BackupPC
rsync
12m22s
7m42s
jah
ei
jah
jah
jah
jah
jah
ei
jah
ei
ei
jah
jah
ei
jah
ei
jah
10,5
tar
12m34s
12m15s
Tabeli legend:
- Roheline, tööaeg alla viie minuti või vastus "Jah" (välja arvatud veerg "Kas on vaja kliendiserverit?"), 1 punkt
- Kollane, tööaeg viis-kümme minutit, 0.5 punkti
- Punane, tööaeg üle kümne minuti või vastus "Ei" (välja arvatud veerg "Kas on vaja kliendiserverit?"), 0 punkti
Vastavalt ülaltoodud tabelile on kõige lihtsam, kiirem ja samas mugav ning võimas varundamistööriist BorgBackup. Teisel kohal on Restic, teised käsitletud kandidaadid jagunesid umbes võrdselt, jäädes ühe kuni kahe punkti vahele lõpus.
Tänan kõiki, kes lugesid tsükli lõpuni, ja pakun välja arutada võimalusi, esitada oma ideid, kui need on olemas. Arutelu käigus võib tabelit täiendada.
Tsükli tulemusena valmib lõppartikkel, milles püütakse välja selgitada ideaalne, kiire ja hallatav varundamisvahend, mis võimaldab lühikese ajaga taastada koopia ning samas pakkuda mugavust ja lihtsust seadistamisel ja hooldamisel.
Teade
Varundamine, osa 6: Varundamisvahendite võrdlus
Varundamine, osa 7: Järeldused
Allikas: habr.com
