Ovaj članak će razmotriti softver za sigurnosno kopiranje koji, razbijanjem toka podataka u zasebne komponente (dijelove), tvori spremište.
Komponente repozitorija mogu se dodatno komprimirati i šifrirati, i što je najvažnije - tijekom ponovljenih procesa sigurnosnog kopiranja - ponovno koristiti.
Sigurnosna kopija u takvom repozitoriju je imenovani lanac komponenti međusobno povezanih, na primjer, na temelju različitih hash funkcija.
Postoji nekoliko sličnih rješenja, a ja ću se usredotočiti na 3: zbackup, borgbackup i restic.
Očekivani rezultati
Budući da svi podnositelji zahtjeva na ovaj ili onaj način zahtijevaju stvaranje repozitorija, jedan od najvažnijih čimbenika bit će procjena veličine repozitorija. U idealnom slučaju, njegova veličina ne bi trebala biti veća od 13 GB prema prihvaćenoj metodologiji, ili čak manje - uz dobru optimizaciju.
Također je vrlo poželjno imati mogućnost izravnog stvaranja sigurnosnih kopija datoteka, bez korištenja arhivara poput tar-a, kao i rad s ssh/sftp-om bez dodatnih alata poput rsync i sshfs.
Ponašanje prilikom izrade sigurnosnih kopija:
- Veličina repozitorija bit će jednaka veličini promjena ili manja.
- Očekuje se veliko opterećenje CPU-a kada se koristi kompresija i/ili enkripcija, a vrlo veliko opterećenje mreže i diska vjerojatno je ako se proces arhiviranja i/ili enkripcije izvodi na poslužitelju za pohranu pričuvnih kopija.
- Ako je spremište oštećeno, vjerojatno će doći do odgođene pogreške i prilikom stvaranja novih sigurnosnih kopija i prilikom pokušaja vraćanja. Potrebno je planirati dodatne mjere za osiguranje integriteta repozitorija ili koristiti ugrađene alate za provjeru njegovog integriteta.
Kao referentna vrijednost uzima se rad s tarom, kao što je prikazano u jednom od prethodnih članaka.
Testiranje zbackupa
Opći mehanizam zbackupa je da program u ulaznom toku podataka pronalazi područja koja sadrže iste podatke, zatim ih po želji sažima i šifrira, spremajući svako područje samo jednom.
Deduplikacija koristi 64-bitnu prstenastu hash funkciju s kliznim prozorom za provjeru podudaranja bajt po bajt s postojećim blokovima podataka (slično kako to implementira rsync).
Višenitni lzma i lzo koriste se za kompresiju, a aes za enkripciju. Najnovije verzije imaju mogućnost brisanja starih podataka iz repozitorija u budućnosti.
Program je napisan u C++ s minimalnim ovisnostima. Autor je očito bio inspiriran unix-načinom, tako da program prihvaća podatke na stdin prilikom stvaranja sigurnosnih kopija, proizvodeći sličan tok podataka na stdout prilikom vraćanja. Stoga se zbackup može koristiti kao vrlo dobar "građevni blok" pri pisanju vlastitih rješenja za sigurnosno kopiranje. Na primjer, autor članka koristi ovaj program kao glavni backup alat za kućne strojeve od otprilike 2014. godine.
Tok podataka bit će običan tar osim ako nije drugačije navedeno.
Pogledajmo kakvi su rezultati:
Rad je provjeren u 2 opcije:
- stvara se repozitorij i na poslužitelju se pokreće zbackup s izvornim podacima, zatim se sadržaj repozitorija prenosi na poslužitelj za sigurnosnu pohranu.
- kreira se repozitorij na poslužitelju za pričuvnu pohranu, zbackup se pokreće putem ssh-a na poslužitelju za pričuvnu pohranu, a podaci mu se šalju putem cijevi.
Rezultati prve opcije bili su sljedeći: 43m11s - pri korištenju nešifriranog repozitorija i kompresora lzma, 19m13s - pri zamjeni kompresora s lzo.
Opterećenje poslužitelja s izvornim podacima bilo je sljedeće (prikazan je primjer s lzma; s lzo je bila približno ista slika, ali je udio rsync bio otprilike četvrtina vremena):
Jasno je da je takav proces sigurnosne kopije prikladan samo za relativno rijetke i male promjene. Također je vrlo preporučljivo ograničiti zbackup na 1 nit, inače će doći do vrlo velikog opterećenja procesora, jer Program je vrlo dobar u radu u više niti. Opterećenje diska bilo je malo, što općenito ne bi bilo vidljivo s modernim diskovnim podsustavom temeljenim na ssd-u. Također možete jasno vidjeti početak procesa sinkronizacije podataka repozitorija na udaljeni poslužitelj, brzina rada je usporediva s običnim rsync-om i ovisi o performansama diskovnog podsustava poslužitelja za pričuvnu pohranu. Nedostatak ovog pristupa je pohranjivanje lokalnog repozitorija i, kao rezultat, dupliciranje podataka.
Zanimljivija i u praksi primjenjivija je druga opcija, pokretanje zbackupa izravno na poslužitelju za pohranu rezervnih kopija.
Prvo ćemo testirati rad bez korištenja enkripcije s lzma kompresorom:
Vrijeme izvođenja svakog testnog izvođenja:
Pokreni 1
Pokreni 2
Pokreni 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
Ako omogućite enkripciju koristeći aes, rezultati su prilično blizu:
Vrijeme rada na istim podacima, uz enkripciju:
Pokreni 1
Pokreni 2
Pokreni 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
Ako se šifriranje kombinira s kompresijom pomoću lzo-a, to izgleda ovako:
Radno vrijeme:
Pokreni 1
Pokreni 2
Pokreni 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
Veličina dobivenog repozitorija bila je relativno ista i iznosila je 13 GB. To znači da deduplikacija radi ispravno. Također, na već komprimiranim podacima korištenje lzo daje zamjetan učinak, po ukupnom vremenu rada zbackup se približava duplicity/duplicati, ali zaostaje za onima koji se temelje na librsyncu 2-5 puta.
Prednosti su očite - ušteda prostora na disku na poslužitelju za sigurnosnu pohranu. Što se tiče alata za provjeru repozitorija, autor zbackupa ih ne nudi; preporuča se korištenje diskovnog polja otpornog na greške ili cloud providera.
Sve u svemu, vrlo dobar dojam, unatoč činjenici da je projekt stajao oko 3 godine (posljednji zahtjev za značajkom bio je prije otprilike godinu dana, ali bez odgovora).
Testiranje borgbackupa
Borgbackup je fork of attic, još jedan sustav sličan zbackupu. Napisan u pythonu, ima popis mogućnosti sličnih zbackupu, ali dodatno može:
- Montirajte sigurnosne kopije putem osigurača
- Provjerite sadržaj repozitorija
- Rad u načinu klijent-poslužitelj
- Koristiti različite kompresore za podatke, kao i heurističko određivanje tipa datoteke prilikom kompresije.
- 2 opcije šifriranja, aes i blake
- Ugrađeni alat za
provjere performansi
borgbackup benchmark crud ssh://backup_server/repo/path lokalni_dir
Rezultati su bili sljedeći:
CZ-BIG 96.51 MB/s (10 100.00 MB datoteka sve nula: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB datoteka sve nula: 17.48 s)
UZ-BIG 253.63 MB/s (10 100.00 MB datoteka sve nula: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB datoteka sve nula: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB nasumične datoteke: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB nasumične datoteke: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB nasumične datoteke: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB nasumične datoteke: 13.77 s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB datoteka sve nula: 9.21 s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB datoteka sve nula: 13.13 s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB datoteka sve nula: 3.02 s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB datoteka sve nula: 2.58 s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB nasumične datoteke: 26.45 s)
RR-SREDNJI 68.90 MB/s (1000 1.00 MB nasumične datoteke: 14.51 s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB nasumične datoteke: 2.88 s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB nasumične datoteke: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB sve nulte datoteke: 8.53 s)
RZ-MALI 32.57 MB/s (10000 10.00 kB sve nulte datoteke: 3.07 s)
UZ-MALI 19.37 MB/s (10000 10.00 kB sve nulte datoteke: 5.16 s)
DZ-MALI 33.71 MB/s (10000 10.00 kB sve nulte datoteke: 2.97 s)
CR-SMALL 6.85 MB/s (10000 10.00 kB nasumične datoteke: 14.60 s)
RR-MALI 31.27 MB/s (10000 10.00 kB nasumične datoteke: 3.20 s)
UR-SMALL 12.28 MB/s (10000 10.00 kB nasumične datoteke: 8.14 s)
DR-SMALL 18.78 MB/s (10000 10.00 kB nasumične datoteke: 5.32 s)
Prilikom testiranja koristit će se heuristika kompresije za određivanje vrste datoteke (automatska kompresija), a rezultati će biti sljedeći:
Prvo provjerimo kako radi bez enkripcije:
Radno vrijeme:
Pokreni 1
Pokreni 2
Pokreni 3
4 m6 s
4 m10 s
4 m5 s
56s
58s
54s
1 m26 s
1 m34 s
1 m30 s
Ako omogućite autorizaciju repozitorija (provjereni način rada), rezultati će biti bliski:
Radno vrijeme:
Pokreni 1
Pokreni 2
Pokreni 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
Kada je aktivirana aes enkripcija, rezultati se nisu mnogo pogoršali:
Pokreni 1
Pokreni 2
Pokreni 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
A ako promijenite aes u blake, situacija će se potpuno popraviti:
Radno vrijeme:
Pokreni 1
Pokreni 2
Pokreni 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
Kao iu slučaju zbackup-a, veličina repozitorija bila je 13 GB pa čak i malo manje, što je općenito očekivano. Bio sam vrlo zadovoljan vremenom izvođenja; usporedivo je s rješenjima koja se temelje na librsyncu, pružajući puno šire mogućnosti. Također sam bio zadovoljan mogućnošću postavljanja raznih parametara kroz varijable okoline, što daje vrlo ozbiljnu prednost pri korištenju borgbackupa u automatskom načinu rada. Također sam bio zadovoljan opterećenjem tijekom sigurnosnog kopiranja: sudeći po opterećenju procesora, borgbackup radi u 1 niti.
Nije bilo posebnih nedostataka prilikom korištenja.
restic testiranje
Unatoč činjenici da je restic prilično novo rješenje (prva 2 kandidata bila su poznata još 2013. i starije), ima prilično dobre karakteristike. Napisano u Go.
U usporedbi sa zbackupom, dodatno daje:
- Provjera integriteta repozitorija (uključujući provjeru dijelova).
- Ogroman popis podržanih protokola i pružatelja usluga za pohranu sigurnosnih kopija, kao i podrška za rclone - rsync za rješenja u oblaku.
- Usporedba 2 sigurnosne kopije jedna s drugom.
- Montaža spremišta preko osigurača.
Općenito, popis značajki prilično je blizak borgbackupu, na nekim mjestima više, na drugim manje. Jedna od značajki je da ne postoji način da se onemogući enkripcija, pa će sigurnosne kopije uvijek biti šifrirane. Pogledajmo u praksi što se može izvući iz ovog softvera:
Rezultati su bili sljedeći:
Radno vrijeme:
Pokreni 1
Pokreni 2
Pokreni 3
5 m25 s
5 m50 s
5 m38 s
35s
38s
36s
1 m54 s
2 m2 s
1 m58 s
Rezultati performansi također su usporedivi s rješenjima temeljenim na rsync-u i, općenito, vrlo blizu borgbackupa, ali opterećenje CPU-a je veće (pokretanje više niti) i pilasto.
Najvjerojatnije je program ograničen performansama diskovnog podsustava na poslužitelju za pohranu podataka, kao što je već bio slučaj s rsync-om. Veličina repozitorija bila je 13 GB, baš kao i zbackup ili borgbackup, nije bilo očitih nedostataka pri korištenju ovog rješenja.
Nalazi
Zapravo, svi su kandidati postigli slične rezultate, ali po različitim cijenama. Borgbackup je bio najbolji od svih, restic je bio malo sporiji, zbackup se vjerojatno ne isplati početi koristiti,
a ako je već u upotrebi, pokušajte ga promijeniti u borgbackup ili restic.
Zaključci
Rješenje koje najviše obećava čini se restično, jer... upravo on ima najbolji omjer mogućnosti i brzine rada, ali za sada nemojmo brzati s generalnim zaključcima.
Borgbackup u osnovi nije ništa lošiji, ali zbackup je vjerojatno bolje zamijeniti. Istina, zbackup se još uvijek može koristiti kako bi se osiguralo da pravilo 3-2-1 radi. Na primjer, uz mogućnosti sigurnosnog kopiranja temeljene na (lib)rsync.
Obavijest
Sigurnosna kopija 5. dio: Testiranje bacula i veeam sigurnosne kopije za linux
Sigurnosno kopiranje, 6. dio: Usporedba alata za sigurnosno kopiranje
Rezervni dio 7: Zaključci
Objavio: Pavel Demkovich
Izvor: www.habr.com