Ta članek obravnava programsko opremo za varnostno kopiranje, ki z razdelitvijo podatkovnega toka na ločene komponente (kose) tvori repozitorij.
Komponente repozitorija je mogoče dodatno stisniti in šifrirati, in kar je najpomembnejše – med ponavljajočimi se procesi varnostnega kopiranja – ponovno uporabiti.
Varnostna kopija v takem repozitoriju je poimenovana veriga komponent, povezanih med seboj, na primer na podlagi različnih zgoščevalnih funkcij.
Obstaja več podobnih rešitev, jaz se bom osredotočil na 3: zbackup, borgbackup in restic.
Pričakovani rezultati
Ker vsi prijavitelji na tak ali drugačen način zahtevajo izdelavo repozitorija, bo eden najpomembnejših dejavnikov ocena velikosti repozitorija. V idealnem primeru njegova velikost ne sme biti večja od 13 GB v skladu s sprejeto metodologijo ali celo manj - ob dobri optimizaciji.
Zelo zaželena je tudi možnost ustvarjanja varnostnih kopij datotek neposredno, brez uporabe arhivarjev, kot je tar, kot tudi delo s ssh/sftp brez dodatnih orodij, kot sta rsync in sshfs.
Obnašanje pri ustvarjanju varnostnih kopij:
- Velikost repozitorija bo enaka velikosti sprememb ali manj.
- Pri uporabi stiskanja in/ali šifriranja je pričakovana velika obremenitev procesorja, precej velika obremenitev omrežja in diska pa je verjetna, če se postopek arhiviranja in/ali šifriranja izvaja na strežniku za shranjevanje rezervnih kopij.
- Če je repozitorij poškodovan, je verjetna napaka z zakasnitvijo tako pri ustvarjanju novih varnostnih kopij kot pri poskusu obnovitve. Načrtovati je treba dodatne ukrepe za zagotovitev celovitosti repozitorija ali uporabiti vgrajena orodja za preverjanje njegove celovitosti.
Delo s tar je vzeto kot referenčna vrednost, kot je bilo prikazano v enem od prejšnjih člankov.
Testiranje zbackup
Splošni mehanizem zbackupa je, da program v toku vhodnih podatkov najde področja, ki vsebujejo iste podatke, nato jih po želji stisne in šifrira, pri čemer vsako področje shrani samo enkrat.
Deduplikacija uporablja 64-bitno obročno zgoščevalno funkcijo z drsečim oknom za preverjanje ujemanja bajt za bajtom z obstoječimi podatkovnimi bloki (podobno kot to izvaja rsync).
Večnitna lzma in lzo se uporabljata za stiskanje, aes pa za šifriranje. Zadnje različice imajo možnost brisanja starih podatkov iz repozitorija v prihodnosti.
Program je napisan v C++ z minimalnimi odvisnostmi. Avtorja je očitno navdihnil način unix, zato program pri ustvarjanju varnostnih kopij sprejema podatke na stdin, pri obnavljanju pa ustvari podoben tok podatkov na stdout. Tako lahko zbackup uporabite kot zelo dober "gradnik" pri pisanju lastnih rešitev za varnostno kopiranje. Na primer, avtor članka uporablja ta program kot glavno orodje za varnostno kopiranje domačih strojev od približno leta 2014.
Podatkovni tok bo običajni tar, razen če ni navedeno drugače.
Poglejmo, kakšni so rezultati:
Delo je bilo preverjeno v dveh možnostih:
- ustvari se repozitorij in zbackup se zažene na strežniku z izvornimi podatki, nato pa se vsebina repozitorija prenese na strežnik za shranjevanje rezervnih kopij.
- repozitorij se ustvari na strežniku za rezervno shranjevanje, zbackup se zažene prek ssh na strežniku za varnostno shranjevanje, podatki pa se vanj pošljejo po cevi.
Rezultati prve možnosti so bili naslednji: 43m11s - pri uporabi nešifriranega repozitorija in kompresorja lzma, 19m13s - pri zamenjavi kompresorja z lzo.
Obremenitev strežnika z izvirnimi podatki je bila naslednja (prikazan je primer z lzma; z lzo je bila približno enaka slika, vendar je bil delež rsync približno četrtina časa):
Jasno je, da je tak postopek varnostnega kopiranja primeren le za relativno redke in majhne spremembe. Prav tako je zelo priporočljivo omejiti zbackup na 1 nit, sicer bo CPE zelo obremenjen, ker Program je zelo dober pri delu v več nitih. Obremenitev diska je bila majhna, kar na splošno pri sodobnem diskovnem podsistemu na osnovi ssd ne bi bilo opazno. Prav tako je jasno viden začetek procesa sinhronizacije podatkov repozitorija z oddaljenim strežnikom, hitrost delovanja je primerljiva z običajnim rsync in je odvisna od zmogljivosti diskovnega podsistema strežnika za rezervno shranjevanje. Slabost tega pristopa je shranjevanje lokalnega repozitorija in posledično podvajanje podatkov.
Bolj zanimiva in v praksi uporabna je druga možnost, ki izvaja zbackup neposredno na strežniku za shranjevanje varnostnih kopij.
Najprej bomo preizkusili delovanje brez uporabe šifriranja s kompresorjem lzma:
Čas delovanja vsake preskusne vožnje:
Zagon 1
Zagon 2
Zagon 3
39 m45 s
40 m20 s
40 m3 s
7 m36 s
8 m3 s
7 m48 s
15 m35 s
15 m48 s
15 m38 s
Če omogočite šifriranje z uporabo aes, so rezultati precej blizu:
Čas delovanja na istih podatkih, s šifriranjem:
Zagon 1
Zagon 2
Zagon 3
43 m40 s
44 m12 s
44 m3 s
8 m3 s
8 m15 s
8 m12 s
15 m0 s
15 m40 s
15 m25 s
Če je šifriranje kombinirano s stiskanjem z uporabo lzo, je videti takole:
Delovni čas:
Zagon 1
Zagon 2
Zagon 3
18 m2 s
18 m15 s
18 m12 s
5 m13 s
5 m24 s
5 m20 s
8 m48 s
9 m3 s
8 m51 s
Velikost nastalega repozitorija je bila relativno enaka pri 13 GB. To pomeni, da deduplikacija deluje pravilno. Tudi na že stisnjenih podatkih uporaba lzo daje opazen učinek, po skupnem času delovanja se zbackup približa duplicity/duplicati, vendar zaostaja za tistimi, ki temeljijo na librsync 2-5 krat.
Prednosti so očitne - prihranek prostora na disku na strežniku za varnostno shranjevanje. Kar zadeva orodja za preverjanje repozitorija, jih avtor zbackupa ne ponuja; priporočljiva je uporaba diskovnega polja, odpornega na napake, ali ponudnika oblaka.
Na splošno zelo dober vtis, kljub dejstvu, da projekt miruje že približno 3 leta (zadnja zahteva po funkciji je bila pred približno letom dni, vendar brez odgovora).
Testiranje borgbackupa
Borgbackup je fork of attic, še en sistem, podoben zbackupu. Napisan v pythonu ima seznam zmožnosti, ki je podoben zbackupu, poleg tega pa lahko:
- Namestite varnostne kopije prek varovalke
- Preverite vsebino skladišča
- Delajte v načinu odjemalec-strežnik
- Uporabite različne kompresorje za podatke, kot tudi hevristično določanje vrste datoteke pri stiskanju.
- 2 možnosti šifriranja, aes in blake
- Vgrajeno orodje za
preverjanje uspešnosti
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Rezultati so bili naslednji:
CZ-BIG 96.51 MB/s (10 100.00 MB datotek vse nič: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB datotek vse nič: 17.48 s)
UZ-VELIKI 253.63 MB/s (10 100.00 MB datotek vse nič: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB datotek vse nič: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB naključne datoteke: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB naključne datoteke: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB naključne datoteke: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB naključne datoteke: 13.77 s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB datotek vse nič: 9.21 s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB datotek vse nič: 13.13 s)
UZ-SREDNJI 331.27 MB/s (1000 1.00 MB datotek vse nič: 3.02 s)
DZ-SREDNJI 387.36 MB/s (1000 1.00 MB datotek vse nič: 2.58 s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB naključne datoteke: 26.45 s)
RR-SREDNJI 68.90 MB/s (1000 1.00 MB naključne datoteke: 14.51 s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB naključne datoteke: 2.88 s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB naključne datoteke: 20.49 s)
CZ-MALE 11.72 MB/s (10000 10.00 kB datoteke vse nič: 8.53 s)
RZ-MAJHEN 32.57 MB/s (10000 10.00 kB datoteke vse nič: 3.07 s)
UZ-MAJH 19.37 MB/s (10000 10.00 kB datoteke vse nič: 5.16 s)
DZ-MAJH 33.71 MB/s (10000 10.00 kB datoteke vse nič: 2.97 s)
CR-SMALL 6.85 MB/s (10000 10.00 kB naključne datoteke: 14.60 s)
RR-MAJH 31.27 MB/s (10000 10.00 kB naključne datoteke: 3.20 s)
UR-MAJH 12.28 MB/s (10000 10.00 kB naključne datoteke: 8.14 s)
DR-SMALL 18.78 MB/s (10000 10.00 kB naključne datoteke: 5.32 s)
Pri testiranju bo za določitev vrste datoteke uporabljena hevristika stiskanja (samodejno stiskanje), rezultati pa bodo naslednji:
Najprej preverimo, kako deluje brez šifriranja:
Delovni čas:
Zagon 1
Zagon 2
Zagon 3
4 m6 s
4 m10 s
4 m5 s
56s
58s
54s
1 m26 s
1 m34 s
1 m30 s
Če omogočite avtorizacijo repozitorija (preverjen način), bodo rezultati blizu:
Delovni čas:
Zagon 1
Zagon 2
Zagon 3
4 m11 s
4 m20 s
4 m12 s
1 m0 s
1 m3 s
1 m2 s
1 m30 s
1 m34 s
1 m31 s
Ko je bilo aktivirano šifriranje aes, se rezultati niso bistveno poslabšali:
Zagon 1
Zagon 2
Zagon 3
4 m55 s
5 m2 s
4 m58 s
1 m0 s
1 m2 s
1 m0 s
1 m49 s
1 m50 s
1 m50 s
In če spremenite a v blake, se bo situacija popolnoma izboljšala:
Delovni čas:
Zagon 1
Zagon 2
Zagon 3
4 m33 s
4 m43 s
4 m40 s
59s
1 m0 s
1 m0 s
1 m38 s
1 m43 s
1 m40 s
Tako kot v primeru zbackup je bila velikost repozitorija 13 GB in celo malo manj, kar je na splošno pričakovano. S časom delovanja sem bil zelo zadovoljen, primerljiv je z rešitvami, ki temeljijo na librsync, saj ponuja veliko širše zmožnosti. Zadovoljen sem bil tudi z možnostjo nastavljanja različnih parametrov prek spremenljivk okolja, kar daje zelo resno prednost pri uporabi borgbackupa v samodejnem načinu. Zadovoljen sem bil tudi z obremenitvijo med varnostnim kopiranjem: sodeč po obremenitvi procesorja borgbackup deluje v 1 niti.
Pri uporabi ni bilo posebnih slabosti.
restično testiranje
Kljub temu, da je restic dokaj nova rešitev (prva 2 kandidata sta bila znana že leta 2013 in starejše), ima kar dobre lastnosti. Napisano v Go.
V primerjavi z zbackupom dodatno daje:
- Preverjanje celovitosti repozitorija (vključno s preverjanjem po delih).
- Ogromen seznam podprtih protokolov in ponudnikov za shranjevanje varnostnih kopij ter podpora za rclone - rsync za rešitve v oblaku.
- Primerjava dveh varnostnih kopij med seboj.
- Montaža repozitorija preko varovalke.
Na splošno je seznam funkcij precej blizu borgbackupu, ponekod več, drugje manj. Ena od funkcij je, da šifriranja ni mogoče onemogočiti, zato bodo varnostne kopije vedno šifrirane. Poglejmo v praksi, kaj je mogoče iztisniti iz te programske opreme:
Rezultati so bili naslednji:
Delovni čas:
Zagon 1
Zagon 2
Zagon 3
5 m25 s
5 m50 s
5 m38 s
35s
38s
36s
1 m54 s
2 m2 s
1 m58 s
Tudi rezultati zmogljivosti so primerljivi z rešitvami, ki temeljijo na rsync, in na splošno zelo blizu borgbackupu, vendar je obremenitev CPE večja (več niti deluje) in žagasta.
Najverjetneje je program omejen z delovanjem diskovnega podsistema na strežniku za shranjevanje podatkov, kot je bilo že pri rsync. Velikost repozitorija je bila 13 GB, tako kot zbackup ali borgbackup pri uporabi te rešitve ni bilo očitnih pomanjkljivosti.
Ugotovitve
Pravzaprav so vsi kandidati dosegli podobne rezultate, vendar po različnih cenah. Borgbackup se je odrezal najbolje, restic je bil nekoliko počasnejši, zbackup se verjetno ne splača začeti uporabljati,
in če je že v uporabi, ga poskusite spremeniti v borgbackup ali restic.
Ugotovitve
Najbolj obetavna rešitev se zdi restična, ker... prav on ima najboljše razmerje med zmogljivostmi in hitrostjo delovanja, a zaenkrat ne hitimo s splošnimi sklepi.
Borgbackup v bistvu ni nič slabši, zbackup pa je verjetno bolje zamenjati. Res je, zbackup je še vedno mogoče uporabiti za zagotovitev delovanja pravila 3-2-1. Na primer, poleg zmogljivosti za varnostno kopiranje, ki temeljijo na (lib)rsync.
Obvestilo
Varnostno kopiranje, 5. del: Testiranje varnostnega kopiranja bacula in veeam za linux
Varnostno kopiranje, 6. del: Primerjava orodij za varnostno kopiranje
Varnostno kopiranje, 7. del: Zaključki
Objavil: Pavel Demkovič
Vir: www.habr.com