Selles artiklis käsitletakse varundustarkvara, mis jagades andmevoo eraldi komponentideks (tükkideks), moodustab hoidla.
Hoidla komponente saab veelgi tihendada ja krüpteerida ning mis kõige tähtsam – korduvate varundusprotsesside käigus – taaskasutada.
Varukoopia sellises hoidlas on omavahel ühendatud komponentide nimeline ahel, mis põhineb näiteks erinevatel räsifunktsioonidel.
Sarnaseid lahendusi on mitu, keskendun kolmele: zbackup, borgbackup ja restic.
Oodatud tulemused
Kuna kõik taotlejad nõuavad hoidla loomist ühel või teisel viisil, on üheks olulisemaks teguriks hoidla suuruse hindamine. Ideaalis ei tohiks selle suurus vastavalt aktsepteeritud metoodikale olla suurem kui 13 GB või isegi vähem - hea optimeerimise korral.
Samuti on väga soovitav võimalus luua failidest varukoopiaid otse, ilma arhiive (nt tar) kasutamata, samuti töötada ssh/sftp-ga ilma lisatööriistadeta, nagu rsync ja sshfs.
Käitumine varukoopiate loomisel:
- Hoidla suurus on võrdne muudatuste suurusega või väiksem.
- Tihendamise ja/või krüptimise kasutamisel on oodata suurt protsessori koormust ning üsna suur võrgu- ja kettakoormus on tõenäoline, kui arhiveerimis- ja/või krüpteerimisprotsess töötab varusalvestusserveris.
- Kui hoidla on kahjustatud, on tõenäoline viivitusega viga nii uute varukoopiate loomisel kui ka taastamise katsel. Hoidla terviklikkuse tagamiseks on vaja kavandada lisameetmed või kasutada selle terviklikkuse kontrollimiseks sisseehitatud tööriistu.
Tõrvaga töötamist võetakse võrdlusväärtusena, nagu oli näidatud ühes eelmises artiklis.
zbackupi testimine
Zbackupi üldine mehhanism seisneb selles, et programm leiab sisendandmevoost samu andmeid sisaldavad alad, seejärel valikuliselt tihendab ja krüpteerib need, salvestades iga ala ainult ühe korra.
Deduplikatsioon kasutab 64-bitist rõngaräsifunktsiooni koos libiseva aknaga, et kontrollida bait-baidi vasteid olemasolevate andmeplokkidega (sarnaselt sellele, kuidas rsync seda rakendab).
Tihendamiseks kasutatakse mitme lõimega lzma ja lzo ning krüptimiseks aes. Uusimatel versioonidel on tulevikus võimalus hoidlast vanu andmeid kustutada.
Programm on kirjutatud C++ keeles minimaalsete sõltuvustega. Autor oli ilmselt inspireeritud unix-viisist, nii et programm aktsepteerib varukoopiate loomisel stdini andmeid, taastades stdoutis sarnase andmevoo. Seega saab zbackupi kasutada väga hea “ehituskivina” enda varunduslahenduste kirjutamisel. Näiteks on artikli autor kasutanud seda programmi kodumasinate peamise varundustööriistana alates ligikaudu 2014. aastast.
Andmevoog on tavaline tõrv, kui pole öeldud teisiti.
Vaatame, millised on tulemused:
Tööd kontrolliti kahe variandi vahel:
- luuakse hoidla ja lähteandmetega käivitatakse serveris zbackup, seejärel kantakse hoidla sisu varusalvestusserverisse.
- varusalvestusserverisse luuakse hoidla, zbackup käivitatakse ssh kaudu varusalvestusserveris ja andmed saadetakse sinna toru kaudu.
Esimese variandi tulemused olid järgmised: 43m11s - krüpteerimata hoidla ja lzma kompressori kasutamisel, 19m13s - kompressori asendamisel lzo vastu.
Algandmetega oli serveri koormus järgmine (näide on toodud lzma-ga; lzo-ga oli umbes sama pilt, aga rsynci osakaal oli umbes veerand ajast):
On selge, et selline varundusprotsess sobib ainult suhteliselt harvade ja väikeste muudatuste jaoks. Samuti on väga soovitatav piirata zbackupi 1 lõimega, vastasel juhul on protsessori koormus väga suur, kuna Programm on väga hea mitme lõimega töötamiseks. Plaadi koormus oli väike, mida üldiselt kaasaegse ssd-põhise ketta alamsüsteemi puhul märgata ei oleks. Samuti näete selgelt hoidla andmete kaugserverisse sünkroonimise protsessi algust; töökiirus on võrreldav tavalise rsynciga ja sõltub varusalvestusserveri ketta alamsüsteemi jõudlusest. Selle lähenemisviisi puuduseks on kohaliku hoidla salvestamine ja sellest tulenevalt andmete dubleerimine.
Huvitavam ja praktikas rakendatavam on teine võimalus, zbackupi käivitamine otse varundussalvestusserveris.
Esiteks testime toimingut ilma lzma kompressoriga krüptimist kasutamata:
Iga katsesõidu kestus:
Käivitage 1
Käivitage 2
Käivitage 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Kui lubate krüptimise AES abil, on tulemused üsna lähedased:
Tööaeg samadel andmetel krüptimisega:
Käivitage 1
Käivitage 2
Käivitage 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Kui krüpteerimine kombineeritakse lzo abil tihendamisega, näeb see välja järgmine:
tundi:
Käivitage 1
Käivitage 2
Käivitage 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Saadud hoidla suurus oli suhteliselt sama, 13 GB. See tähendab, et dubleerimine töötab õigesti. Samuti annab juba tihendatud andmetel lzo kasutamine märgatava efekti, kogu tööaja poolest jõuab zbackup duplicity/duplicati lähedale, kuid jääb librsyncil põhinevatest maha 2-5 korda.
Eelised on ilmsed – kettaruumi säästmine varusalvestusserveris. Mis puutub hoidlate kontrollimise tööriistu, siis zbackupi autor neid ei paku, soovitatav on kasutada tõrketaluvat kettamassiivi või pilvepakkujat.
Üldiselt väga hea mulje, vaatamata sellele, et projekt on seisnud umbes 3 aastat (viimane funktsioonisoov oli umbes aasta tagasi, kuid vastuseta).
Borgbackupi testimine
Borgbackup on pööninguhark, teine süsteem, mis sarnaneb zbackupiga. Pythonis kirjutatud, sellel on zbackupiga sarnane võimaluste loend, kuid lisaks saab:
- Paigaldage varukoopiad kaitsme kaudu
- Kontrollige hoidla sisu
- Töötage klient-serveri režiimis
- Kasutage andmete jaoks erinevaid kompressoreid, samuti failitüübi heuristlikku määramist selle tihendamisel.
- 2 krüpteerimisvalikut, aes ja blake
- Sisseehitatud tööriist
jõudluskontrollid
borgbackupi võrdlusnäitaja crud ssh://backup_server/repo/path local_dir
Tulemused olid järgmised:
CZ-BIG 96.51 MB/s (10 100.00 MB null-failid: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB null-failid: 17.48 s)
UZ-BIG 253.63 MB/s (10 100.00 MB null-failid: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB null-failid: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB juhuslikud failid: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB juhuslikud failid: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB juhuslikud failid: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB juhuslikud failid: 13.77 s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB null-failid: 9.21 s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB null-failid: 13.13 s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB null-failid: 3.02 s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB null-failid: 2.58 s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB juhuslikud failid: 26.45 s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB juhuslikud failid: 14.51 s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB juhuslikud failid: 2.88 s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB juhuslikud failid: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB null-failid: 8.53 s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB null-failid: 3.07 s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB null-failid: 5.16 s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB null-failid: 2.97 s)
CR-SMALL 6.85 MB/s (10000 10.00 kB juhuslikud failid: 14.60 s)
RR-VÄIKE 31.27 MB/s (10000 10.00 kB juhuslikud failid: 3.20 s)
UR-SMALL 12.28 MB/s (10000 10.00 kB juhuslikud failid: 8.14 s)
DR-SMALL 18.78 MB/s (10000 10.00 kB juhuslikud failid: 5.32 s)
Testimisel kasutatakse failitüübi määramiseks tihendusheuristikat (automaatne tihendus) ja tulemused on järgmised:
Kõigepealt kontrollime, kuidas see ilma krüptimiseta töötab:
tundi:
Käivitage 1
Käivitage 2
Käivitage 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Kui lubate hoidla autoriseerimise (autentitud režiim), on tulemused lähedal:
tundi:
Käivitage 1
Käivitage 2
Käivitage 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Kui AES-krüptimine aktiveeriti, ei halvenenud tulemused palju:
Käivitage 1
Käivitage 2
Käivitage 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Ja kui muudate aes blake'iks, paraneb olukord täielikult:
tundi:
Käivitage 1
Käivitage 2
Käivitage 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Nagu zbackupi puhul, oli hoidla suurus 13 GB ja isegi veidi vähem, mida üldiselt oodatakse. Tööajaga jäin väga rahule, see on võrreldav librsyncil põhinevate lahendustega, pakkudes palju laiemaid võimalusi. Rõõmustas ka võimalus seada erinevaid parameetreid läbi keskkonnamuutujate, mis annab väga tõsise eelise borgbackupi kasutamisel automaatrežiimis. Jäin rahule ka varundamise ajal oleva koormusega: protsessori koormuse järgi otsustades töötab borgbackup 1 lõimes.
Kasutamisel erilisi miinuseid ei olnud.
restic testimine
Vaatamata sellele, et restic on üsna uus lahendus (esimesed 2 kandidaati olid teada juba 2013. aastal ja vanemad), on sellel üsna head omadused. Kirjutatud Go.
Võrreldes zbackupiga annab see lisaks:
- Hoidla terviklikkuse kontrollimine (sh osade kontrollimine).
- Tohutu loend toetatud protokollidest ja pakkujatest varukoopiate salvestamiseks, samuti rclone - rsynci tugi pilvelahenduste jaoks.
- Kahe varukoopia võrdlemine omavahel.
- Hoidla paigaldamine kaitsme kaudu.
Üldiselt on funktsioonide nimekiri üsna lähedal borgbackupile, mõnes kohas rohkem, teises vähem. Üks omadusi on see, et krüptimist pole võimalik keelata ja seetõttu krüpteeritakse varukoopiad alati. Vaatame praktikas, mida sellest tarkvarast välja pigistada saab:
Tulemused olid järgmised:
tundi:
Käivitage 1
Käivitage 2
Käivitage 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Samuti on jõudlustulemused võrreldavad rsync-põhiste lahendustega ja üldiselt väga lähedal borgbackupile, kuid protsessori koormus on suurem (mitu lõime töötab) ja saehambaline.
Tõenäoliselt piirab programmi ketta alamsüsteemi jõudlus andmesalvestusserveris, nagu see oli juba rsynci puhul. Hoidla suurus oli 13 GB, nagu ka zbackupi või borgbackupi puhul, ei ilmnenud selle lahenduse kasutamisel ilmseid miinuseid.
Järeldused
Tegelikult saavutasid kõik kandidaadid sarnaseid tulemusi, kuid erinevate hindadega. Borgbackup toimis kõige paremini, restic oli veidi aeglasem, zbackupi ei tasu ilmselt kasutama hakata,
ja kui see on juba kasutusel, proovige muuta see borgbackupiks või resticuks.
Järeldused
Kõige lootustandvam lahendus näib olevat rahulik, sest... just temal on parim võimete ja töökiiruse suhe, kuid ärgem kiirustagem praegu üldiste järeldustega.
Borgbackup pole põhimõtteliselt halvem, kuid zbackup on ilmselt parem asendada. Tõsi, 3-2-1 reegli toimimise tagamiseks saab siiski kasutada zbackupi. Näiteks lisaks (lib)rsynci-põhistele varundusvõimalustele.
Kuulutus
Varukoopia 5. osa: bacula ja veeam varukoopia testimine Linuxi jaoks
Varundamine 6. osa: varundustööriistade võrdlemine
Varukoopia 7. osa: Järeldused
Postitas: Pavel Demkovitš
Allikas: www.habr.com