V tem članku bomo obravnavali programska sredstva za varnostno kopiranje, ki z razbitjem toka podatkov na posamezne komponente (chunks) oblikujejo repozitorij.
Komponente repozitorija se lahko dodatno stisnejo in šifrirajo, najpomembnejše pa je, da se lahko pri ponovnih procesih varnostnega kopiranja ponovno uporabijo.
Varnostna kopija v takem repozitoriju je poimenovana veriga povezanih komponent, na primer, na osnovi različnih hash-funkcij.
Obstaja več takšnih rešitev, osredotočil se bom na 3: zbackup, borgbackup in restic.
Pričakovani rezultati
Ker vsi kandidati na tak ali drugačen način zahtevajo ustvarjanje repozitorija, bo eden najpomembnejših dejavnikov ocena velikosti repozitorija. V idealnem primeru ne sme biti večji od 13 GB v skladu s sprejeto metodologijo, lahko pa je tudi manj — ob dobri optimizaciji.
Prav tako je zelo zaželeno imeti možnost ustvarjati varnostne kopije datotek neposredno, brez uporabe arhivatorjev, kot je tar, ter delovati z ssh/sftp brez dodatnih sredstev, kot sta rsync in sshfs.
Obnašanje pri ustvarjanju varnostnih kopij:
- Velikost repozitorija bo enaka velikosti sprememb ali manjša.
- Pričakuje se velika obremenitev procesorja pri uporabi stiskanja in/ali šifriranja, prav tako je verjetna precejšnja obremenitev omrežja in diska, če bo postopek arhiviranja in/ali šifriranja potekal na strežniku za shranjevanje varnostnih kopij.
- Če se repozitorij poškoduje, obstaja verjetnost zamudne napake tako pri ustvarjanju novih varnostnih kopij kot pri poskusu obnovitve. Treba je načrtovati dodatne ukrepe za zagotavljanje celovitosti repozitorija ali uporabiti vgrajena orodja za preverjanje njegove celovitosti.
Kot referenčna vrednost je bila sprejeta uporaba tar, kot je bilo prikazano v enem od prejšnjih člankov.
Testiranje zbackup
Splošni mehanizem delovanja zbackup je, da program v toku podatkov, ki se dovaja na vhodu, najde področja z enakimi podatki, jih po potrebi stisne, šifrira in shranjuje vsako področje le enkrat.
Za deduplikacijo se uporablja 64-bitna krožna hash-funkcija s pomičnim oknom za byte-po-byte preverjanje ujemanja z že obstoječimi bloki podatkov (podobno, kot je to izvedeno v rsync).
Za stiskanje se uporablja lzma in lzo v večnitnem izvajanja, za šifriranje pa aes. V zadnjih različicah je prisotna možnost v prihodnosti odstraniti stare podatke iz repozitorija.
Program je napisan v C++ z minimalnimi odvisnostmi. Avtor se očitno navdihuje z unix-way, zato program sprejema podatke na stdin pri ustvarjanju varnostnih kopij in izda podoben podatkovni tok v stdout pri obnovitvi. Tako se lahko zbackup uporablja kot zelo dober 'gradnik' pri pisanju lastnih rešitev za varnostno kopiranje. Na primer, avtor članka ta program uporablja kot glavno sredstvo za varnostno kopiranje domačih računalnikov od leta 2014.
Kot podatkovni tok se bo uporabil običajen tar, če ne bo drugače navedeno.
Poglejmo, kakšni bodo rezultati:
Preverjanje delovanja je potekalo v 2 različicah:
- ustvari se repozitorij in zažene zbackup na strežniku s prvotnimi podatki, nato se vsebina repozitorija prenese na strežnik za shranjevanje varnostnih kopij.
- ustvari se repozitorij na strežniku za shranjevanje varnostnih kopij, zbackup se zažene preko ssh na strežniku za shranjevanje varnostnih kopij, podatki pa se mu posredujejo preko pipe.
Rezultati prve različice so bili takšni: 43m11s — pri uporabi nešifriranega repozitorija in stiskalnika lzma, 19m13s — pri zamenjavi stiskalnika z lzo.
Obremenitev na strežniku s prvotnimi podatki je bila naslednja (prikazan je primer z lzma, z lzo je bila slika približno enaka, vendar je delež rsync znašal približno četrtino časa):
Jasno je da je takav proces izrade sigurnosnih kopija koristan samo pri relativno rijetkim i malim promjenama. Također, vrlo je poželjno ograničiti rad zbackup-a na 1 nit, inače će opterećenje CPU-a biti vrlo visoko, jer program vrlo dobro radi s više niti. Opterećenje diska je bilo malo, što će u cijelosti biti neprimjetno uz moderni diskski sustav temeljen na SSD-u. Također je jasno pokrenut proces sinkronizacije podataka repozitorija na udaljeni server, brzina rada usporediva je s običnim rsync-om i ograničena je performansama diskskog sustava servera za pohranu sigurnosnih kopija. Nedostatak pristupa je pohranjivanje lokalnog repozitorija i, kao posljedica, - dupliciranje podataka.
Zanimljivija i primjenjivija opcija u praksi je druga varijanta s pokretanjem zbackup-a odmah na serveru za pohranu sigurnosnih kopija.
Za početak će biti provjerena funkcionalnost bez korištenja šifriranja s kompresorom lzma:
Vrijeme rada svakog testnog pokretanja:
Pokretanje 1
Pokretanje 2
Pokretanje 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Ako aktivirate šifriranje pomoću aes, rezultati su prilično bliski:
Vrijeme rada na istim podacima, s šifriranjem:
Pokretanje 1
Pokretanje 2
Pokretanje 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Ako šifriranje spojite s kompresijom na lzo, ispadne ovako:
Vrijeme rada:
Pokretanje 1
Pokretanje 2
Pokretanje 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Veličina rezultantnog repozitorija bila je relativno ista i iznosila je 13GB. To znači da deduplikacija radi ispravno. Također, na već komprimiranim podacima primjena lzo daje značajan učinak, ukupno vrijeme rada zbackup-a približava se duplicity/duplicati, ali zaostaje za onima temeljenima na librsync-u 2-5 puta.
Prednosti su očigledne - ušteda prostora na disku na serveru za pohranu sigurnosnih kopija. Što se tiče alata za provjeru repozitorija - autor zbackup-a ih nije predvidio, preporučuje se korištenje otpornog diskskog niza ili cloud provajdera.
U cjelini vrlo dobar dojam, unatoč tome što projekt otprilike 3 godine stagnira (posljednji zahtjev za funkcionalnošću je bio prije otprilike godinu dana, ali bez odgovora).
Testiranje borgbackup-a
Borgbackup je fork attic-a, još jednog sustava sličnog zbackup-u. Napisan je na pythonu, ima sličan popis mogućnosti kao zbackup, ali dodatno zna:
- Prikaži varnostne kopije preko fuse
- Preveri vsebino repozitorija
- Delaj v odjemalsko-strežni načinu
- Uporabi različne kompresorje za podatke, pa tudi heuristično določanje vrste datoteke pri njeni kompresiji.
- 2 možnosti šifriranja, aes in blake
- Vgrajeno orodje za
preverjanje zmogljivosti
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Rezultati so bili naslednji:
C-Z-BIG 96.51 MB/s (10 100.00 MB all-zero datoteke: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB all-zero datoteke: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB all-zero datoteke: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB all-zero datoteke: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB naključne datoteke: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB naključne datoteke: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB naključne datoteke: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB naključne datoteke: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB all-zero datoteke: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB all-zero datoteke: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB all-zero datoteke: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB all-zero datoteke: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB naključne datoteke: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB naključne datoteke: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB naključne datoteke: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB naključne datoteke: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB all-zero datoteke: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB all-zero datoteke: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB all-zero datoteke: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB all-zero datoteke: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB naključne datoteke: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB naključne datoteke: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB naključne datoteke: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB naključne datoteke: 5.32s)
Med testiranjem bo uporabljena heuristika pri kompresiji z določanjem vrste datoteke (compression auto), rezultati pa bodo naslednji:
Za začetek preverimo delovanje brez šifriranja:
Vrijeme rada:
Pokretanje 1
Pokretanje 2
Pokretanje 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Če aktiviramo avtentikacijo repozitorija (mode authenticated), bodo rezultati podobni:
Vrijeme rada:
Pokretanje 1
Pokretanje 2
Pokretanje 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Ko je aktivirana šifriranje aes, rezultati niso bistveno slabši:
Pokretanje 1
Pokretanje 2
Pokretanje 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Če blake zamenjamo z aes, se situacija močno izboljša:
Vrijeme rada:
Pokretanje 1
Pokretanje 2
Pokretanje 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Kot v primeru z zbackupom je velikost repozitorija znašala 13gb in celo malo manj, kar je v splošnem pričakovano. Čas delovanja je zelo pohvalen, primerljiv z rešitvami, temelječimi na librsync, in ponuja veliko širše možnosti. Prav tako je bila dobrodošla možnost nastavitve različnih parametrov preko okoljskih spremenljivk, kar daje precejšnjo prednost pri avtomatski uporabi borgbackup. Prav tako je bila dobrodošla obremenitev pri varnostnem kopiranju: glede na obremenitev procesorja — borgbackup deluje v 1 toku.
Pri uporabi ni bilo zaznanih posebnih pomanjkljivosti.
Testiranje restic
Čeprav je restic razmeroma novo rešitev (prva 2 kandidata sta bila znana že od leta 2013 in starejša), ima dovolj dobre lastnosti. Napisana je v jeziku Go.
Če primerjam z zbackup, dodatno ponuja:
- Preverjanje celovitosti repozitorija (vključno s preverjanjem po delih).
- Ogromni seznam podprtih protokolov in ponudnikov za shranjevanje varnostnih kopij, prav tako podporo rclone — rsync za ‘oblačna’ rešitev.
- Primerjava 2 varnostnih kopij med seboj.
- Montiranje repozitorija preko fuse.
Na splošno je seznam možnosti dovolj blizu borgbackup, občasno več, občasno manj. Med značilnostmi — odsotnost možnosti izklopa šifriranja, zato bodo varnostne kopije vedno šifrirane. Poglejmo praktično, kaj lahko pridobimo iz te programske opreme:
Rezultati so bili takšni:
Vrijeme rada:
Pokretanje 1
Pokretanje 2
Pokretanje 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Rezultati dela so prav tako primerljivi z rešitvami, ki temeljijo na rsync, in so na splošno precej blizu borgbackup, vendar je obremenitev procesorja višja (deluje več niti) in je pulzno naravnana.
Verjetno se program sooča z zmogljivostjo disčnega sistema na strežniku za shranjevanje podatkov, kot je že bilo pri rsync. Velikost repozitorija je bila 13 GB, enako kot pri zbackup ali borgbackup, pri tem rešitvi niso bili ugotovljeni očitni minusi.
Rezultati
Dejansko so vsi kandidati dosegli podobne rezultate, vendar po različnih cenah. Najbolj se je izkazal borgbackup, nekoliko počasneje restic, zbackup z verjetnostjo ne bi smeli začeti uporabljati,
če pa se že uporablja — poskusiti zamenjati z borgbackup ali restic.
Zaključki
Najbolj obetavna rešitev se zdi restic, saj ima najboljšo razmerje možnosti in hitrosti delovanja, vendar zaenkrat ne hitimo s splošnimi zaključki.
Borgbackup načeloma ni slabši, zbackup pa bi verjetno bilo bolje zamenjati. Vendar pa se za zagotavljanje delovanja pravila 3-2-1 zbackup še vedno lahko uporabi. Na primer, poleg orodij za varnostno kopiranje, ki temeljijo na (lib)rsync.
Najava
Varnostno kopiranje, del 5: Testiranje bacula in veeam backup for linux
Varnostno kopiranje, del 6: Primerjava orodij za varnostno kopiranje
Varnostno kopiranje, del 7: Sklepi
Avtor objave: Pavel Demkovič
Izvor: habr.com
