Selles artiklis võrreldakse varundustarkvara, kuid esmalt tasub teada saada, kui kiiresti ja tõhusalt nad andmeid varukoopiatest taastavad.
Võrdluse lihtsustamiseks käsitletakse taastamist täielikust varukoopiast, sest see töörežiim on toetatud kõigi kandidaatide poolt. Numbrid on lihtsustamise huvides võetud juba keskmistena (mitme käivitamise aritmeetiline keskmine). Tulemused koondatakse tabelisse, kus on lisainfot ka võimaluste kohta: veebiliidese olemasolu, seadistamise ja kasutamise lihtsus, automatiseerimise võimekus, erinevate lisavõimaluste olemasolu (nt andmete terviklikkuse kontroll) jne. Diagrammid näitavad serveri koormust, kus andmeid rakendatakse (mitte varukoopiate salvestamise serverit).
Andmete taastamine
Tugipunktidena kasutatakse rsynci ja tari, kuna lihtsaimatele varundamise skriptidele.
Rsync täitis testandmete kogumi 4 minuti ja 28 sekundiga, näidates
sellist koormust.
Taastamisprotsess jäi pidama varukoopiate salvestamise serveri kettasüsteemi piirangu taha (sahvatavad diagrammid). Samuti on selgelt näha ühe tuuma koormus ilma eriliste probleemideta (madal iowait ja softirq — ei esine probleeme ketta ja võrguga vastavalt). Kuna kaks muud programmi, nimelt rdiff-backup ja rsnapshot, põhinevad rsyncil ning pakuvad taastamisvahendina tavalist rsynci, on nende koormuse profiil ja varukoopia taastamise aeg ligikaudu samasugused.
Tar täitis pisut kiiremini, ajaga
2 minutit ja 43 sekundit:
Süsteemi kogukoormus oli keskmiselt 20% suurem suurenenud softirq tõttu — võrgualase töö tõttu tekkisid lisakulud.
Kui arhiivi veel edasi tihendada, suureneb taastamisaeg 3 minutile ja 19 sekundile sellise koormuse juures peamisel serveril (dekompressioon peamise serveri küljel):
такой нагрузкой на основном сервере (распаковка на стороне основного сервера):
Pakkimisprotsess kasutab kahte protsessori tuuma, kuna töötab kaks protsessi. Kokkuvõttes on see oodatav tulemus. Samuti saadi sarnane tulemus (3 minutit ja 20 sekundit), kui käivitati gzip serveripoolel varukoopiate tegemiseks, põhiserveri koormus oli üsna sarnane tar-i käivitamisele ilma gzip kompressorita (vt eelmist graafikut).
Uues rdiff-backup Viimast tehtud varukoopiat saab sünkroniseerida tavalise rsync abil (tulemused on sarnased), kuid vanemaid varukoopiaid tuleb ikkagi taastada rdiff-backup programmi kaudu, mis suutis taastamise teha 17 minuti ja 17 sekundiga, näidates
sellist koormust:
Võib-olla oli see tõesti nii mõeldud, vähemalt kiiruspiirangu osas, mida autorid . Varukoopia taastamise protsess ise võtab aega veidi vähem kui pool tuuma, suheline jõudlus on sarnane (st 2-5 korda aeglasem) mõlemal, nii kettal kui võrgus rsynciga.
Rsnapshot pakub taastamiseks kasutada tavapärast rsync'i, seega on tema tulemused sarnased. Kokkuvõttes on see just nii läinudki.
Burp sai varukoopia taastamise ülesande 7 minuti ja 2 sekundi jooksul tehtud
sellise koormusega:
Töötas piisavalt kiiresti ning vähemalt on see palju mugavam kui puhas rsync: ei pea mäletama mingeid lippe, lihtne ja intuitiivne CLI-liides, sisseehitatud tugi mitme koopia jaoks — kuigi see on kahekordselt aeglasem. Kui andmeid tuleb taastada viimati tehtud varukoopiast – saab kasutada rsync'i, väikeste eranditega.
Umbes sama kiirus ja koormus näitas programm BackupPC kui rsync ülekande režiim oli aktiivne, rajades varukoopia
7 minuti ja 42 sekundi jooksul:
Aga tar andmeedastuse režiimis saavutas BackupPC aeglasema tulemuse: 12 minuti ja 15 sekundi jooksul, protsessori koormus oli sel juhul üldiselt madalam
poolteist korda:
Duplicity ilma krüpteerimist näitas veidi paremaid tulemusi, taastades varukoopia 10 minuti ja 58 sekundi jooksul. Kui aktiveerida krüpteerimine gpg abil, ulatub taastamisaeg 15 minuti ja 3 sekundini. Samuti saab varahoidla loomisel määrata arhiveerimise suuruse, mida kasutatakse siseneva andmevoo jagamisel. Kokkuvõttes, tavalistel kõvaketastel, samuti ühesuunalise töörežiimi tõttu, ei ole erilist erinevust. See võib ilmuda erinevate plokkide suurustega, kui kasutatakse hübriidhoidlaid. Peamise serveri koormus taastamise ajal oli järgmine:
ilma krüpteerimiseta
krüpteerimisega
Duplicati näitas võrreldavat taastamiskiirus, tehes seda 13 minuti ja 45 sekundi jooksul. Veel umbes 5 minutit kulus taastatud andmete korrektuse kontrollimiseks (kokku umbes 19 minutit). Sealjuures oli koormus
oluliselt kõrge:
Kui krüpteerimine aes aktiviseeriti sisemiste vahenditega, siis taastamisaeg oli 21 minutit ja 40 sekundit, samas kui protsessori koormus oli maksimaalne (mõlemad tuumad!) taastamise ajal; andmete kontrollimiseks oli aktiivne ainult üks voog, kasutades ühte protsessorituuma. Andmete kontrollimine pärast taastamist kestis sama palju aega, umbes 5 minutit (kokku pea 27 minutit).
Tulemus
Veidi kiiremini haldas duplicati taastamist, kasutades krüpteerimiseks välist programmi gpg, kuid üldiselt on erinevused eelneva režiimiga minimaalset. Töötlemisaeg oli 16 minutit ja 30 sekundit, koos andmete kontrollimisega 6 minuti jooksul. Koormus oli
järgnev:
AMANDA, kasutades tar, haldas 2 minuti ja 49 sekundi jooksul, mis on üldiselt üsna lähedane tavalisele tar-ile. Süsteemi koormus on kokkuvõttes
sama:
Varukoopiate taastamisel kasutades zbackup saadi järgmised tulemused:
krüpteerimine, kompressioon lzma
Töötlemisaeg 11 minutit ja 8 sekundit
krüpteerimine aes, kompressioon lzma
Töötlemisaeg 14 minutit
krüpteerimine aes, kompressioon lzo
Töötlemisaeg 6 minutit, 19 sekundit
Kokkuvõttes pole paha. Kõik sõltub varundusserveri protsessorikiirusest, mida on üsna selgelt näha programmi töö ajas erinevate tihendajatega. Varundusserveris käivitati tavaline tar, seega, kui võrrelda sellega — taastamine töötab 3 korda aeglasemalt. Võib-olla tasuks kontrollida töö tegemist mitme lõime režiimis, kus lõimede arv on suurem kui kaks.
BorgBackup ilma krüpteerimiseta töötas veidi aeglasemalt kui tar, aega kulus 2 minutit ja 45 sekundit, kuid erinevalt tar-st avanes võimalus dedupplikatsiooni jaoks. Koormus oli
järgnev:
Kui aktiveerida blake-põhine krüpteerimine, siis varukoopia taastamise kiirus veidi aeglustub. Taastamisaeg selles režiimis on 3 minutit ja 19 sekundit, koormus jäi
selliseks:
AES-i krüpteerimine töötab veidi aeglasemalt, taastamisaeg on 3 minutit ja 23 sekundit, koormus eriti
ei muutunud:
Kuna Borg võib töötada mitme lõime režiimis, on protsessori koormus maksimaalne, samal ajal kui täiendavate funktsioonide aktiveerimisel lihtsalt suureneb tööaeg. Tundub, et tasub uurida ka mitme lõime töötlemist sarnaselt zbackup-iga.
Restic töötas taastamisega veidi aeglasemalt, tööaeg oli 4 minutit ja 28 sekundit. Koormus nägi välja
nii:
Tundub, et taastamisprotsess töötab mitme lõimega, kuid efektiivsus ei ole nii kõrge kui BorgBackup-is, kuid ajaliselt sarnane tavalise rsync-iga.
EL-i abil UrBackup suudeti andmed taastada 8 minutiga ja 19 sekundiga, koormus oli sel ajal
järgnev:
Jätkuvalt on nähtav mitte liiga kõrge koormus, isegi madalam kui tar-l. Kohati on äkilisi tõuse, kuid mitte rohkem kui ühe tuuma koormus.
Kriteeriumide valik ja põhjendamine
Kuidas varem öeldud, peab varundussüsteem vastama järgmistele kriteeriumidele:
- Lihtsus töös
- Universaalsus
- Stabiilsus
- Kiirus
Tasub arutada iga punkti eraldi põhjalikumalt.
Töö lihtsus
Parim on, kui on olemas üks nupp "Tee kõik hästi", kuid kui tagasi tõdede programmide juurde — on kõige mugavam mõni tuttav ja standardne tööpõhimõte.
Enamikule kasutajatele oleks tõenäoliselt parem, kui ei peaks meeles pidama hulka võtmeid CLI jaoks, seadistama erinevaid sageli ebaselgeid variante läbi veebivõi TUI, ning seadistama ebaõnnestumiste teavitusi. Siia kuulub ka võimalus hõlpsasti integreerida varunduslahendus olemasolevasse infrastruktuuri ning automatiseerida varundamisprotsess. Samuti peaks olema võimalik, et installi saab teha pakettide halduri kaudu või ühe-kahte käsku, nagu "laadi alla ja paki lahti". curl link | sudo bash — keeruline meetod, kuna tuleb kontrollida, mis linki mööda tuleb.
Näiteks on käsitletud kandidaatidest lihtsaim lahendus burp, rdiff-backup ja restic, millel on meeldejäävad võtmed erinevate töörežiimide jaoks. Veidi keerulisemad on borg ja duplicity. Kõige keerulisem oli AMANDA. Ülejäänud on kasutusmugavuse poolest kuskil keskel. Igal juhul, kui kasutusjuhendi lugemine võtab rohkem kui 30 sekundit, või tuleb minna Google'isse või mõnda teise otsingumootorisse, samuti sirvida pikka abiteksti — lahendus on keeruline, olenemata sellest.
Mõned käsitletud kandidaadid oskavad automaatselt saata teateid e-maili või jabberi kaudu, teised toetuvad süsteemis seadistatud teavitustele. Samas, keerulisemad lahendused omavad sageli mitte täiesti selgeid teavituse seadistusi. Igal juhul, kui varundusprogramm annab mittevõrdelise tagastuskoodi, mille süsteemne teenus suudab õigesti tõlgendada (saadetakse teade süsteemiadministraatorile või kohe jälgimise süsteemi) — olukord on lihtne. Aga kui varundussüsteem, mis ei tööta varundusserveris, ei suuda tõhusalt probleemist teada anda — keerukus on juba ülemäärane. Igal juhul on hoiatuste ja muude teade andmine vaid veebiliideses või logis halb praktika, kuna tihti need jäävad tähelepanuta.
Automatiseerimise osas oskab lihtne programm lugeda keskkonnamuutujaid, mis määratlevad selle töörežiimi, või omab arenenud CLI-d, mis suudab täielikult dubleerida käitumise veebiliideses töötades, näiteks. Samuti kuulub siia voogedastuse töövõime ja erinevad laiendamisvõimalused jne.
Universaalsus
Osaliselt kattub eelneva jaotusega automatiseerimise osas, ei tohiks olla erilisi probleeme, kui "sobitada" varundamisprotsess olemasolevasse infrastruktuuri.
Tasub märkida, et mittestandardsed pordid (välja arvatud veebiliides) tööks, mittestandardsete meetodite rakendamine krüpteerimiseks ja andmete vahetamine mittestandardse protokolliga on ebahariliku lahenduse tunnused. Enamik kandidaate omab neid märke mingil moel ilmselgele põhjusel: lihtsus ja universaalsus on tavaliselt kokkusobimatud. Erandiks on burp ja on ka teisi.
Üks tunnus on võimalus töötada kasutades tavalist ssh-d.
Töökiirus
Kõige vaieldavam ja vastuoluline punkt. Ühest küljest — käivitati protsess, see töötas maksimaalselt kiiresti ega seganud peamisi ülesandeid. Teisest küljest — liikluse ja protsessori koormuse tõus varundamise ajal. Tuleb märkida ka, et kõige kiirem varukoopia loomise programm on tavaliselt kõige vaesem funktsioonide poolest, mis on kasutajatele olulised. Kui tuleb välja võtta üks närune tekstifail, mille suurus on vaid paar kümnet bait, ja selle pärast peatub kogu teenus (jah, ma mõistan, et varundamisprotsess ei ole sageli süüdi), ning tuleb järjestikku lugeda kõiki faile hoidlas või lahti tõsta kogu arhiiv — siis varundamissüsteem ei ole sugugi kiire. Veel üks punkt, mis sageli tõukab vastuoludele — varukoopia taastamise kiirus arhiivist. Selgelt on eeliseid neil, kes saavad lihtsalt faile vajalikku kohta kopeerida või liigutada ilma eriliste manööverdusteta (näiteks rsync), kuid enamasti peab probleemi lahendama organisatoriliselt, empiirilise meetodiga: mõõta varukoopia taastamise aega ja sellest lahti kirjutada kasutajatele.
Stabiilsus
Peab mõistma nii: ühelt poolt peab olema võimalus varukoopia taastamiseks igal juhul, teiselt poolt - vastupidavus erinevatele probleemidele: võrgu katkestused, kõvaketta riknemine, osa hoidla kustutamine.
Varundustööriistade võrdlemine
Kopeerimise loomise aeg
Kopeerimise taastamise aeg
Lihtne paigaldamine
Lihtne seadistamine
Lihtne kasutamine
Lihtne automatiseerimine
Kas on vaja kliendiserverit?
Repository integrity check
Differential backups
Pipe processing
Universaalsus
Iseseisvus
Repository transparency
Krüpteerimine
Kompressioon
Dedupleerimine
Veebiliides
Cloud upload
Windowsi tugi
Score
Rsync
4m15s
4m28s
jah
ei
ei
ei
jah
ei
ei
jah
ei
jah
jah
ei
ei
ei
ei
ei
jah
6
Tar
pure
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
Table legend:
- Green, uptime less than five minutes, or response 'Yes' (except the 'Client-server needed?' column), 1 point
- Yellow, uptime five to ten minutes, 0.5 points
- Red, uptime over ten minutes, or response 'No' (except the 'Client-server needed?' column), 0 points
According to the table above, the simplest, fastest, and at the same time convenient and powerful backup tool is BorgBackup. Second place went to Restic, while the other candidates scored roughly the same with a spread of one to two points at the end.
Thanks to everyone who read the series to the end, I invite you to discuss options, and suggest your own if you have any. As the discussion progresses, the table may be updated.
The result of the series will be a final article attempting to introduce the ideal, fast, and manageable backup solution that allows for quick restoration and at the same time provides convenience and simplicity in setup and maintenance.
Teade
Varundamine, osa 6: Varundamise tööriistade võrdlus
Varundamine, osa 7: Järeldused
Allikas: habr.com
