Käesolevas artiklis käsitletakse varundustarkvara, mis jagab andmevoo eraldi komponentideks (chunks), et luua hoidla.
Hoidla komponendid võivad täiendavalt tihendada ja krüpteerida ning mis kõige tähtsam — varundamisprotsesside kordamisel — neid uuesti kasutada.
Varukoopia sellises hoidlas on nimeline ahel vastastikku seotud komponentidest, näiteks erinevate hash-funktsioonide põhjal.
On mitmeid selliseid lahendusi, peatun kolmel: zbackup, borgbackup ja restic.
Oodatavad tulemused
Kuna kõik kandidaadid vajavad hoidla loomist, on üheks oluliseks teguriks hoidla suuruse hindamine. Ideaaljuhul ei tohiks selle suurus olla üle 13 GB vastavalt kehtestatud meetodile, ja veelgi vähem — hea optimeerimise korral.
Samuti on soovitatav võimalus luua varukoopiaid faile otseselt, kasutamata selliseid arhiivereid nagu tar, ja töötada ssh/sftp-ga ilma täiendavate vahenditeta nagu rsync ja sshfs.
Varundamise käitumine:
- Hoidla suurus on võrdne muudatuste suurusega või väiksem.
- Rohke koormus on oodata protsessorile, kui kasutatakse tihendust ja/või krüptimist, samuti on tõenäoliselt suur koormus võrgule ja salvestusala süsteemile, kui arhiveerimise ja/või krüptimise protsess töötab varundusserveris.
- Kui hoidla saab kahjustatud, on oodata viivitusega vigu nii uute varukoopiate loomisel kui ka taastamiskatsetel. Tuleb planeerida täiendavaid meetmeid hoidla terviklikkuse tagamiseks või kasutada sisseehitatud vahendeid selle terviklikkuse kontrollimiseks.
Tõeväärtusena on võetud töötamine tar-iga, nagu see on näidatud ühes varasemas artiklis.
Zbackup testimine
Zbackup töö mehhanism seisneb selles, et programm leiab andmevoos, mis antakse sisendiks, piirkonnad, kus on sarnased andmed, seejärel tihendab ja krüpteerib need valikuliselt, salvestades iga ala vaid üks kord.
DeDuplicaatorina kasutatakse 64-bitist ringikujulist hash-funktsiooni libiseva akna meetodil, et kontrollida baiti-baatel kokkuvõtmist juba olemasolevate andmeplokkidega (sarnaselt sellele, kuidas see on realiseeritud rsyncis).
Kitsendamiseks kasutatakse lzma ja lzo mitme lõime täitmisel ning krüpteerimiseks aes. Viimases versioonis on tulevikus võimalik vanu andmeid hoidlast eemaldada.
Programm on kirjutatud C++ keeles minimaalsete sõltuvustega. Tundub, et autor sai inspiratsiooni unix-mudelist, seega programm võtab andmeid stdin, kui luua varukoopiaid, väljastades sarnase andmevoo stdout-is taastamisel. Seega saab zbackup'i kasutada üsna heana „detailina“ omade varukoopiate lahenduste kirjutamisel. Näiteks on autoril selle artikli programmi kasutamise peamine vahend varukoopiate tegemiseks kodumasinates alates 2014. aastast.
Andmevoona kasutatakse tavapärast tar'i, kui pole öeldud teisiti.
Vaatame, millised on tulemused:
Töö kontrollimine toimus 2 variandis:
- loodakse hoidla ja käivitatakse zbackup serveris, kus on algandmed, seejärel edastatakse hoidla sisu varukoopiate salvestamise serverisse.
- loodakse hoidla varukoopiate salvestamise serveris, zbackup käivitatakse ssh kaudu varukoopiate salvestamise serveris, andmed edastatakse talle kaudu pipe.
Esimese variandi tulemused olid järgmised: 43m11s — kui kasutati krüpteerimata hoidlat ja lzma kompressorit, 19m13s — kui kompressorit asendati lzo-ga.
Andmeserveri koormus oli järgmine (näidatud on lzma näide, lzo puhul oli pilt umbes sama, kuid rsync'i osa oli ajast umbes veerand):
On selgelt näha, et selline varukoopiate tegemise protsess sobib vaid suhteliselt harvade ja väikehulgaliste muudatuste korral. Samuti on äärmiselt soovitatav piirata zbackup'i tööd ühes lõimes, muidu on CPU koormus üsna kõrge, kuna programm oskab hästi töötada mitme lõimega. Diskikoormus oli väike, mis on tänapäevaste ssd-põhiste ketaste süsteemide puhul peaaegu märkamatud. Samuti on selgelt näha andmehoidla sünkroniseerimise protsessi käivitamine kaugserverisse, töö kiirus on võrreldav tavalise rsync-iga ja sõltub varukoopiate salvestamise serveri ketaste süsteemi tootlikkusest. Miinusena on approach'i puhul kohalik hoidla ja sellest tulenevalt - andmete dubleerimine.
Teine, huvitavam ja praktilisem variant on zbackup käivitamine otse varukoopiate salvestusserveris.
Alguses kontrollitakse tööd ilma krüpteerimist kasutamata 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 kasutamisega, on tulemused üpris sarnased:
Tööaeg samadel andmetel krüptimisega:
Käivitamine 1
Käivitamine 2
Käivitamine 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Kui krüpteerimine kombineerida lzo kokkusurutusega, tulemus on järgmine:
Runtime:
Käivitamine 1
Käivitamine 2
Käivitamine 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Lõpptulemuseks olnud hoidla suurus oli suhteliselt sama ning ulatus 13gb. See näitab, et deduplikatsioon töötab korrektselt. Samuti, juba kompressitud andmete puhul annab lzo rakendamine märkimisväärse efekti, zbackup'i töötamise üldine aeg läheneb duplicity/duplicati'le, kuid jääb librsync põhistele lahendustele 2-5 korda maha.
Eelised on ilmsed — diskiruumi säästmine varukoopiate salvestusserveris. Mis puudutab hoidlate kontrollimise tööriistu — zbackup'i autorid neid ei näe ette, soovitatakse kasutada tõrkeid taluva ketta riba või pilveteenuse pakkujat.
Kokkuvõttes on mul üsna positiivne mulje, kuigi projekt on olnud umbes 3 aastat samas kohas (viimane funktsiooni nõue oli umbes aasta tagasi, kuid ei saanud vastust).
borgbackup testi
Borgbackup on attic'i fork, samuti zbackup'ile sarnane süsteem. Kirjutatud python'is, omab zbackup'iga sarnast võimaluste loetelu, kuid lisaks oskab:
- Mountida varukoopiaid läbi fuse
- Kontrollida hoidla sisu
- Töötada kliendi-serveri režiimis
- Kasutada erinevaid andmete kompressoreid ning ka heuristilist failitüübi määramist kompressimise ajal.
- 2 krüpteerimise varianti, aes ja blake
- Sisseehitatud töötahes
töötasude kontrollimiseks
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Tulemused olid järgmised:
C-Z-BIG 96.51 MB/s (10 100.00 MB all-zero files: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB all-zero files: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB all-zero files: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB all-zero files: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB random files: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB random files: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB random files: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB random files: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB all-zero files: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB all-zero files: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB all-zero files: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB all-zero files: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB random files: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB random files: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB random files: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000) 1.00 MB juhuslikke faile: 20.49s)
C-Z-VÄIKENE 11.72 MB/s (10000 10.00 kB kõik-null faile: 8.53s)
R-Z-VÄIKENE 32.57 MB/s (10000 10.00 kB kõik-null faile: 3.07s)
U-Z-VÄIKENE 19.37 MB/s (10000 10.00 kB kõik-null faile: 5.16s)
D-Z-VÄIKENE 33.71 MB/s (10000 10.00 kB kõik-null faile: 2.97s)
C-R-VÄIKENE 6.85 MB/s (10000 10.00 kB juhuslikke faile: 14.60s)
R-R-VÄIKENE 31.27 MB/s (10000 10.00 kB juhuslikke faile: 3.20s)
U-R-VÄIKENE 12.28 MB/s (10000 10.00 kB juhuslikke faile: 8.14s)
D-R-VÄIKENE 18.78 MB/s (10000 10.00 kB juhuslikke faile: 5.32s)
Testimise käigus kasutatakse heuristikat failitüübi määramiseks (compression auto), ja tulemused on järgmised:
Alustame krüpteerimise puudumist:
Runtime:
Käivitamine 1
Käivitamine 2
Käivitamine 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Kui lubada autentimise režiimi (authenticated), saadud tulemused on sarnased:
Runtime:
Käivitamine 1
Käivitamine 2
Käivitamine 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Aes krüpteerimise kasutamisel pole tulemused oluliselt halvenenud:
Käivitamine 1
Käivitamine 2
Käivitamine 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Aga kui muuta aes blake'ks, paranevad tulemused veelgi:
Runtime:
Käivitamine 1
Käivitamine 2
Käivitamine 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Nagu zbackup'iga, oli reposti suurus 13 GB ja isegi veidi vähem, mis on üldiselt ootuspärane. Tööaeg oli üsna muljetavaldav, kuna see on võrreldav librsync'i lahendustega, pakkudes palju laiemat funktsionaalsust. Samuti oli meeldiv, et erinevate parameetrite seadmine keskkonnamuutujate kaudu annab tõsise eelise borgbackup'i automaatkäitamise puhul. Ka varundamise koormus oli rahuldav: protsessori koormuse järgi töötab borgbackup ühes niidis.
Eriti olulisi puudusi ei leitud.
Restic'i testimine
Hoolimata sellest, et restic on suhteliselt uus lahendus (esimesed kaks kandidaati on tuntud juba 2013. aastast ja vanemad), omab see üsna head omadusi. Kirjutatud Go-s.
Kui võrrelda zbackup'iga, lisab see:
- Tagamissüsteemi terviklikkuse kontrolli (sealhulgas osalise kontrolli).
- Väga pikk toetatud protokollide ja teenusepakkujate nimekiri varunduste tegemiseks, samuti rclone'i toimetamine - rsync 'pilveteenuste' lahenduste jaoks.
- Kahe varukoopia võrdlemine.
- Reposti mountimine kaudu fuse.
Üldiselt on võimalikuste loetelu üsna lähedal borgbackup'ile, mõnes kohas rohkem, mõnes vähem. Eripäraks on şifreeerimise väljalülitamise võimaluse puudumine, seega on varukoopiad alati krüpteeritud. Uurime praktikas, mida sellest tarkvarast kätte saada:
Tulemused olid järgmised:
Runtime:
Käivitamine 1
Käivitamine 2
Käivitamine 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Töötulemustes on ka võrreldavad lahendused rsynciga ning üldiselt on need borgbackupiga üsna sarnased, kuid protsessori koormus on suurem (töötavad mitu lõime) ja saagimistüüpi.
Tõenäoliselt on programm piiratud andmesalvestussüsteemi jõudlusega, nagu see oli rsynci puhul. Repositooriumi suurus oli 13GB, nagu zbackupil või borgbackupil, selle lahenduse kasutamisel ei tuvastatud selgeid puudusi.
tulemused näitasid ainult nelja ebaolulise koodibloki kattuvust, mis olid tingitud POSIX ja ANSI C nõuetest.
Kokkuvõttes on kõikidel kandidaatidel sarnased näitajad, kuid erinevad hinnad. Parim tulemus oli borgbackupil, pisut aeglasemad olid restic ja zbackup, mida tõenäoliselt ei tohiks alustada.
Ja kui see juba on kasutusel, tuleks proovida üle minna borgbackupile või resticile.
Järeldused
Kõige paljutõotavam lahendus tundub olevat restic, kuna sellel on parim suhe võimaluste ja töökiirusena, kuid hetkel ei kiirusta me üldiste järeldustega.
Borgbackup ei ole põhimõtteliselt kehvem, kuid zbackup võiks tõenäoliselt välja vahetada. Tõsi, et 3-2-1 reegli järgimiseks võib zbackupit veel kasutada. Näiteks koos (lib)rsynci põhiste varundustööriistadega.
Teade
Varundamine, osa 5: Bacula ja Veeam Backup for Linux testimine
Varundamine, osa 6: Varundamise tööriistade võrdlus
Varundamine, osa 7: Järeldused
Artikli autor: Pavel Demkovich
Allikas: habr.com
