Selles artiklis käsitletakse varundustarkvara, mis jagab andmevoo eraldi komponentideks (chunks), et luua hoidla.
Hoidlate komponendid võivad lisaks tihendada ja krüptida ning mis kõige tähtsam — neid saab taaskasutada uuesti varundamisprotsesside käigus.
Sellises hoidlas olev varukoopia on nimeline seotud komponentide ahel, näiteks erinevate hash-funktsioonide põhjal.
On olemas mitu sarnast lahendust, kirjutan kolmest: zbackup, borgbackup ja restic.
Oodatavad tulemused
Kuna kõik kandidaadid nõuavad hoidla loomist, on üks olulisemaid tegureid hoidla suuruse hindamine. Ideaalis peaks selle suurus olema mitte rohkem kui 13 GB vastavalt aktsepteeritud meetodile, ja veelgi vähem — hea optimeerimise korral.
Samuti on äärmiselt soovitav, et oleks võimalik varundada faile otse, ilma arhivaatoreid nagu tar kasutamata, ning töötada ssh/sftp-ga ilma täiendavate vahenditeta nagu rsync ja sshfs.
Varukoopia loomise käitumine:
- Repositooriumi suurus vastab muudatuste suurusele või on sellest väiksem.
- Oodata on suurt koormust protsessorile, kui kasutatakse kompressiooni ja/või krüpteerimist, samuti on tõenäoliselt piisavalt suur koormus võrgu ja salvestussüsteemi puhul, kui arhiveerimise ja/või krüpteerimise protsess toimub varukoopia salvestamise serveris.
- Kui repositoorium kahjustub, võib tekkida viivitatud viga nii uute varukoopia loomisel kui ka taastamise katsetamisel. Tuleb planeerida täiendavaid meetmeid repositooriumi terviklikkuse tagamiseks või kasutada selle terviklikkuse kontrollimise sisseehitatud vahendeid.
Viiteväärtusena on valitud töö tar-iga, nagu on varem ühes artiklis näidatud.
zbackup'i testimine
zbackup'i toimimise üldine mehhanism seisneb selles, et programm tuvastab sisendsüsteemis sama teavet sisaldavad andmepiirkonnad, seejärel võimalusel kompressib ja krüpteerib need, säilitades iga piirkonna vaid üks kord.
Dedupeerimiseks kasutatakse 64-bitist ringikujulist hash-funktsiooni, millel on libisev aken, et kontrollida byte-tasandil vasteid juba olemasolevate andmepakettide vahel (sarnasel viisil nagu rsync).
Kompresseerimiseks kasutatakse lzma ja lzo mitme lõimega versioonis, ning krüpteerimiseks — aes. Viimastes versioonides on tulevikus võimalus kustutada vanu andmeid hoidlalt.
Programm on kirjutatud C++-s, minimaalsete sõltuvustega. Autor näib olevat inspireeritud unix-way'ist, seetõttu aktsepteerib programm andmeid stdin-i kaudu varukoopiate loomisel ja väljastab sarnase andmevoo stdout-is taastamisel. Nii saab zbackup'i kasutada kui head „ehitusplokki“ oma varunduslahenduste kirjutamiseks. Näiteks on selle artikli autoril see programm olnud põhiline varundusvahend kodumasinate jaoks umbes alates 2014. aastast.
Andmevoona kasutatakse tavalist tar'i, välja arvatud juhul, kui on öeldud teisiti.
Vaadakem, millised tulemused on:
Tööd kontrolliti kahes variandis:
- luuakse tugiteenus ja zbackup käivitatakse allikate serveris, seejärel edastatakse tugiteenuse sisu varundamisserverisse.
- luuakse tugiteenus varundamisserveris, zbackup käivitatakse ssh kaudu varundamisserveris ning andmed edastatakse pipe'i kaudu.
Esimese variandi tulemused olid järgmised: 43m11s — kasutades krüpteerimata tugiteenust ja lzma kompressorit, 19m13s — kompressori asendamisel lzo-ga.
Allikate serveri koormus oli järgmine (näidatud on lzma näide, lzo puhul oli pilt sarnane, kuid rsynci osakaal oli aega veidi vähem kui neljandik):
On selgelt näha, et selline varundusprotsess sobib ainult suhteliselt harvade ja väikeste muudatuste korral. Soovitatav on piirata zbackup'i töötamist ühes voos, vastasel juhul tekib protsessori kõrge koormus, kuna programm oskab väga hästi korraga mitme vooga töötada. Ketaste koormus oli väike, mis kaasaegse SSD põhiste ketassüsteemide korral on üldiselt tähelepanuta jääv. Samuti on selgelt näha, et andmebaasi andmete sünkroniseerimise protsessi käivitamine kaugserverisse, töökiirus on võrreldav tavalise rsync'iga ja sõltub varundusserveri ketassüsteemi jõudlusest. Meetodi miinuseks on kohalikku andmebaasi hoidmine ja seetõttu ka andmete dubleerimine.
Teine variant, mille korral zbackup käivitatakse kohe varundusserveril, on huvitavam ja praktilisem.
Alustuseks kontrollitakse, kuidas see töötab ilma krüpteerimiseta lzma kompressoriga:
Iga testkäivituse tööaeg:
Käivitamine 1
Käivitamine 2
Käivitamine 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Kui aktiveerida krüpteerimine aes'i rakendamisega, on tulemused piisavalt sarnased:
Aeg töödelda sama andmete, koos krüpteerimisega:
Käivitamine 1
Käivitamine 2
Käivitamine 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Kui krüpteerimist kombineeritakse lzo tihendamisega, on tulemused järgmised:
Töötamise aeg:
Käivitamine 1
Käivitamine 2
Käivitamine 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Tulemuseks saanud hoidla suurus oli suures osas sama ja oli 13GB. See näitab, et deduplikatsioon töötab korrektselt. Samuti annavad juba tihendatud andmete puhul lzo rakendamine tuntavaid tulemusi; zbackup'i üldine tööaeg on peaaegu sama nagu duplicity/duplicati, jäädes siiski librsynci põhiste lahenduste taha 2–5 korda.
Eelised on ilmne — diskiruumi säästmine varukoopiate serveris. Mis puutub hoidla kontrollimise tööriistadesse — zbackup autorid ei ole neid ette näinud, soovitatakse kasutada talitlushäirete taluvust pakkuvat ketta massiivi või pilveteenuse pakkujat.
Kokkuvõttes on muljate suhtes väga positiivne, vaatamata sellele, et projekt on olnud ligikaudu 3 aastat peatuses (viimane funktsioonitaotlus oli umbes aasta tagasi, kuid vastuseta).
Borgbackup'i testimine
Borgbackup on attic'i fork, mis on veel üks zbackup'iga sarnane süsteem. Kirjutatud python'is, sisaldab sarnast funktsioonide loetelu nagu zbackup, kuid lisaks oskab:
- Mountida varukoopiaid fuse'i kaudu
- Kontrollige reposiitori sisu
- Töötage kliendi-serveri režiimis
- Kasutage erinevaid andmete tihendajaid ja heuristilist faili tüübi määratlemist selle tihendamisel.
- 2 krüptimise varianti, aes ja blake
- Sisseehitatud vahend
tõhususe kontrollimiseks
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Tulemused on sellised:
C-Z-BIG 96.51 MB/s (10 100.00 MB kõik-null-failid: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB kõik-null-failid: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB kõik-null-failid: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB kõik-null-failid: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB juhuslikud failid: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB juhuslikud failid: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB juhuslikud failid: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB juhuslikud failid: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB kõik-null-failid: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB kõik-null-failid: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB kõik-null-failid: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB kõik-null-failid: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB juhuslikud failid: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB juhuslikud failid: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB juhuslikud failid: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB juhuslikud failid: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB kõik-null-failid: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB kõik-null-failid: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB kõik-null-failid: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB kõik-null-failid: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB juhuslikud failid: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB juhuslikud failid: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB juhuslikud failid: 8.14s)
D-R-SMALL 18.78 MB/s (10000) 10.00 kB juhuslikud failid: 5.32s)
Testimisel kasutatakse heuristikat faili tüübi kindlaksmääramiseks (automaatne kompressioon), ning tulemused on järgmised:
Alustame töötamise kontrollimist ilma krüptimiseta:
Töötamise aeg:
Käivitamine 1
Käivitamine 2
Käivitamine 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Kui lubada repo autentimist (autentimise režiim), on tulemused sarnased:
Töötamise aeg:
Käivitamine 1
Käivitamine 2
Käivitamine 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Krüpteerimise aes aktiveerimisel ei ole tulemused oluliselt halvenenud:
Käivitamine 1
Käivitamine 2
Käivitamine 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Kui aes vahetada blake'i vastu, paraneb olukord oluliselt:
Töötamise aeg:
Käivitamine 1
Käivitamine 2
Käivitamine 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Nagu zbackupiga, oli repo suurus 13GB või isegi pisut vähem, mis on enamasti ootuspärane. Tööaeg oli väga hea, võrreldav librsync-põhiste lahendustega, pakkudes palju laiemat funktsionaalsust. Samuti meeldis võimalus määrata erinevaid parameetreid keskkonnamuutujate kaudu, mis annab olulise eelise borgbackup'i automaatse kasutamise puhul. Varundamise ajal oli ka koormus hea: protsessorikoormuse järgi töötab borgbackup ühes voos.
Kasutamise käigus ei olnud mingeid erilisi puudusi.
Testimine restic
Kuigi restic on suhteliselt uus lahendus (esimesed kaks kandidaati olid tuntud juba 2013. aastast ja vanemad), omab see siiski üsna häid omadusi. See on kirjutatud Go keeles.
Kui võrrelda zbackuppiga, pakub see lisaks:
- Repo igasuguste terviklikkuse kontrolli (sealhulgas osade kaupa kontrolli).
- Suur loetelu toetatud protokollidest ja teenusepakkujatest varukoopiate säilitamiseks, samuti rclone'i tugi - rsync 'pilvelahendustele'.
- Kahe varukoopia võrdlemine omavahel.
- Repo montaaž fuse kaudu.
Üldiselt on võimaluste nimekiri üsna sarnane borgbackupile, kohati rohkem, kohati vähem. Erakordse omadusena puudub krüptimise väljalülitamise võimalus, seega on varukoopiad alati krüpteeritud. Vaatame praktikas, mida sellest tarkvarast välja pigistada:
Tulemused olid järgmised:
Töötamise aeg:
Käivitamine 1
Käivitamine 2
Käivitamine 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Töötulemused on samuti võrreldavad rsynci-põhiste lahendustega ja on üldiselt üsna lähedal borgbackupile, kuid protsessori koormus on suurem (töötavad mitmed lõimed) ja hammastega.
Tõenäoliselt on programm piiratud serveri andmesalvestuse diskisüsteemi jõudlusega, nagu juba juhtus rsynci puhul. Repositooriumi suurus oli 13 GB, nagu ka zbackupil või borgbackupil, selle lahenduse kasutamisel ei leitud tõsiseid puudusi.
Tulemused
Tegelikult olid kõigil kandidaatidel tulemused lähedased, kuid hind varieerus. Kõige paremini toimis borgbackup, veidi aeglasemad olid restic ja zbackup, tõenäoliselt ei tasu zbackupi kasutusele võtta.
Kui see on juba kasutusel, siis proovige minna üle borgbackupile või resticile.
Järeldused
Kõige perspektiivikam lahendus on restic, kuna sellel on parim vahe võimekuse ja töökiirus vahel, kuid praegu ei kiirusta üldiste järeldustega.
Borgbackup pole põhimõtteliselt halvem, kuid zbackup tuleks tõenäoliselt asendada. Siiski, et järgida 3-2-1 reeglit, saab zbackupi endiselt kasutada, näiteks lisaks (lib)rsynci põhjalistele varundamisvahenditele.
Teade
Varundamine, osa 5: Bacula ja Veeam Backup for Linux testimine
Varundamine, osa 6: Varundamisvahendite võrdlus
Varundamine, osa 7: Järeldused
Autori publikatsioon: Pavel Demkovič
Allikas: habr.com
