Ovaj članak će razmotriti softver za pravljenje rezervnih kopija koji, razbijanjem toka podataka u zasebne komponente (komponente), formira spremište.
Komponente spremišta mogu se dalje komprimirati i šifrirati, i što je najvažnije - tokom ponovljenih procesa sigurnosne kopije - ponovo koristiti.
Rezervna kopija u takvom spremištu je imenovani lanac komponenti povezanih jedna s drugom, na primjer, na osnovu različitih hash funkcija.
Postoji nekoliko sličnih rješenja, fokusiraću se na 3: zbackup, borgbackup i restic.
Očekivani rezultati
Budući da svi podnosioci zahtjeva na ovaj ili onaj način zahtijevaju kreiranje repozitorija, jedan od najvažnijih faktora će biti procjena veličine spremišta. 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đe je veoma poželjno imati mogućnost kreiranja rezervnih kopija fajlova direktno, bez korišćenja arhivatora kao što je tar, kao i rad sa ssh/sftp bez dodatnih alata kao što su rsync i sshfs.
Ponašanje prilikom kreiranja sigurnosne kopije:
- Veličina spremišta će biti jednaka veličini izmjena ili manja.
- Očekuje se veliko opterećenje CPU-a kada se koristi kompresija i/ili enkripcija, a prilično je veliko opterećenje mreže i diska vjerovatno ako se proces arhiviranja i/ili šifriranja izvodi na serveru za pohranu rezervnih kopija.
- Ako je spremište oštećeno, odgođena greška je vjerovatno i pri kreiranju novih rezervnih kopija i prilikom pokušaja vraćanja. Potrebno je planirati dodatne mjere za osiguranje integriteta spremišta ili koristiti ugrađene alate za provjeru njegovog integriteta.
Rad sa katranom uzima se kao referentna vrijednost, kao što je prikazano u jednom od prethodnih članaka.
Testiranje zbackup-a
Opšti mehanizam zbackup-a je da program pronalazi u ulaznom toku podataka područja koja sadrže iste podatke, a zatim ih opciono komprimuje i šifrira, čuvajući svako područje samo jednom.
Deduplikacija koristi 64-bitnu prstenastu hash funkciju s kliznim prozorom za provjeru poklapanja bajt po bajt sa postojećim blokovima podataka (slično kako to rsync implementira).
Višenitni lzma i lzo se koriste za kompresiju, a aes za enkripciju. Najnovije verzije imaju mogućnost brisanja starih podataka iz spremišta u budućnosti.
Program je napisan na C++ sa minimalnim zavisnostima. Autor je očigledno bio inspirisan unix-načinom, tako da program prihvata podatke na stdin prilikom kreiranja rezervnih kopija, proizvodeći sličan tok podataka na stdout-u prilikom vraćanja. Dakle, zbackup se može koristiti kao vrlo dobar "građevinski blok" prilikom pisanja vlastitih rješenja za sigurnosnu kopiju. Na primjer, autor članka koristi ovaj program kao glavni alat za pravljenje rezervnih kopija za kućne mašine od otprilike 2014.
Tok podataka će biti običan tar osim ako nije drugačije navedeno.
Da vidimo kakvi su rezultati:
Rad je provjeren u 2 opcije:
- kreira se spremište i zbackup se pokreće na serveru sa izvornim podacima, zatim se sadržaj spremišta prenosi na server za pohranu rezervnih kopija.
- kreira se spremište na serveru za pohranu rezervnih kopija, zbackup se pokreće preko ssh-a na backup serveru za pohranu, a podaci mu se šalju putem cijevi.
Rezultati prve opcije su bili sljedeći: 43m11s - kada se koristi nešifrirano spremište i lzma kompresor, 19m13s - kada se kompresor zamijeni sa lzo.
Opterećenje servera sa originalnim podacima je bilo sljedeće (prikazano je primjer sa lzma; sa lzo je bila približno ista slika, ali je udio rsync bio približno četvrtinu vremena):
Jasno je da je takav proces sigurnosne kopije prikladan samo za relativno rijetke i male promjene. Također je preporučljivo ograničiti zbackup na 1 nit, inače će doći do vrlo velikog opterećenja CPU-a, jer Program je veoma dobar u radu u više niti. Opterećenje diska je bilo malo, što općenito ne bi bilo primjetno sa modernim diskovnim podsistemom baziranim na ssd-u. Također možete jasno vidjeti početak procesa sinhronizacije podataka spremišta na udaljeni server; brzina rada je uporediva sa uobičajenim rsync-om i zavisi od performansi diskovnog podsistema servera za pohranu rezervnih kopija. Nedostatak ovog pristupa je skladištenje lokalnog spremišta i, kao rezultat, dupliciranje podataka.
Zanimljivija i primenljivija u praksi je druga opcija, pokretanje zbackup-a direktno na serveru za skladištenje rezervnih kopija.
Prvo ćemo testirati rad bez korištenja enkripcije sa lzma kompresorom:
Vrijeme rada svakog probnog rada:
Lansiranje 1
Lansiranje 2
Lansiranje 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Ako omogućite enkripciju koristeći aes, rezultati su prilično blizu:
Vrijeme rada na istim podacima, sa enkripcijom:
Lansiranje 1
Lansiranje 2
Lansiranje 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Ako se enkripcija kombinira sa kompresijom pomoću lzo-a, to izgleda ovako:
Radno vrijeme:
Lansiranje 1
Lansiranje 2
Lansiranje 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Veličina rezultirajućeg spremišta bila je relativno ista na 13 GB. To znači da deduplikacija radi ispravno. Takođe, na već kompresovanim podacima, korišćenje lzo-a daje primetan efekat; u smislu ukupnog vremena rada, zbackup je blizu duplikata/duplicata, ali zaostaje za onima baziranim na librsync-u 2-5 puta.
Prednosti su očigledne - ušteda prostora na disku na serveru za pohranu rezervnih kopija. Što se tiče alata za provjeru spremišta, autor zbackup-a ih ne daje, preporučuje se korištenje diskovnog niza otpornog na greške ili provajdera u oblaku.
Sve u svemu, veoma dobar utisak, uprkos činjenici da projekat stoji oko 3 godine (zadnji zahtev za funkciju bio je pre godinu dana, ali bez odgovora).
Testiranje borgbackup-a
Borgbackup je fork of attic, još jedan sistem sličan zbackup-u. Napisan na python-u, ima listu mogućnosti sličnih zbackup-u, ali dodatno može:
- Montirajte rezervne kopije preko osigurača
- Provjerite sadržaj spremišta
- Rad u režimu klijent-server
- Koristite različite kompresore za podatke, kao i heurističko određivanje tipa datoteke prilikom komprimiranja.
- 2 opcije šifriranja, aes i blake
- Ugrađeni alat za
provjere performansi
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Rezultati su bili sljedeći:
CZ-BIG 96.51 MB/s (10 100.00 MB sve-nula fajlova: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB sve-nula fajlova: 17.48 s)
UZ-BIG 253.63 MB/s (10 100.00 MB sve-nula fajlova: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB sve-nula fajlova: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB nasumičnih fajlova: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB nasumičnih fajlova: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB nasumičnih fajlova: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB nasumičnih fajlova: 13.77 s)
CZ-SREDNJA 108.59 MB/s (1000 1.00 MB sve-nula fajlova: 9.21 s)
RZ-SREDNJA 76.16 MB/s (1000 1.00 MB sve-nula fajlova: 13.13 s)
UZ-SREDNJA 331.27 MB/s (1000 1.00 MB sve-nula fajlova: 3.02 s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB sve-nula fajlova: 2.58 s)
CR-SREDNJA 37.80 MB/s (1000 1.00 MB nasumičnih fajlova: 26.45 s)
RR-SREDNJA 68.90 MB/s (1000 1.00 MB nasumičnih fajlova: 14.51 s)
UR-SREDNJA 347.24 MB/s (1000 1.00 MB nasumičnih fajlova: 2.88 s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB nasumičnih fajlova: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB sve-nula fajlova: 8.53 s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB sve-nula fajlova: 3.07 s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB sve-nula fajlova: 5.16 s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB sve-nula fajlova: 2.97 s)
CR-SMALL 6.85 MB/s (10000 10.00 kB nasumičnih fajlova: 14.60 s)
RR-SMALL 31.27 MB/s (10000 10.00 kB nasumičnih fajlova: 3.20 s)
UR-SMALL 12.28 MB/s (10000 10.00 kB nasumičnih fajlova: 8.14 s)
DR-SMALL 18.78 MB/s (10000 10.00 kB nasumičnih fajlova: 5.32 s)
Prilikom testiranja, heuristika kompresije će se koristiti za određivanje tipa datoteke (automatska kompresija), a rezultati će biti sljedeći:
Prvo, provjerimo kako funkcionira bez enkripcije:
Radno vrijeme:
Lansiranje 1
Lansiranje 2
Lansiranje 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Ako omogućite autorizaciju spremišta (provjereni način), rezultati će biti bliski:
Radno vrijeme:
Lansiranje 1
Lansiranje 2
Lansiranje 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Kada je aktivirana aes enkripcija, rezultati se nisu mnogo pogoršali:
Lansiranje 1
Lansiranje 2
Lansiranje 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
A ako promijenite aes u blake, situacija će se potpuno popraviti:
Radno vrijeme:
Lansiranje 1
Lansiranje 2
Lansiranje 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Kao iu slučaju zbackup-a, veličina spremišta je bila 13GB pa čak i nešto manje, što je općenito očekivano. Bio sam veoma zadovoljan vremenom rada; uporedivo je sa rešenjima zasnovanim na librsync-u, pružajući mnogo šire mogućnosti. Također sam bio zadovoljan mogućnošću postavljanja različitih parametara kroz varijable okruženja, što daje vrlo ozbiljnu prednost pri korištenju borgbackup-a u automatskom načinu rada. Takođe sam bio zadovoljan opterećenjem tokom backup-a: 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. godine i stariji), ima prilično dobre karakteristike. Napisano u Go.
U poređenju sa zbackupom, dodatno daje:
- Provjera integriteta spremišta (uključujući provjeru u dijelovima).
- Ogromna lista podržanih protokola i provajdera za čuvanje rezervnih kopija, kao i podrška za rclone - rsync za cloud rešenja.
- Poređenje 2 sigurnosne kopije jedna s drugom.
- Montaža spremišta preko osigurača.
Općenito, lista funkcija je prilično bliska borgbackup-u, na nekim mjestima više, na drugim manje. Jedna od karakteristika je da ne postoji način da se onemogući enkripcija, pa će stoga rezervne kopije uvijek biti šifrirane. Pogledajmo u praksi šta se može istisnuti iz ovog softvera:
Rezultati su bili sljedeći:
Radno vrijeme:
Lansiranje 1
Lansiranje 2
Lansiranje 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Rezultati performansi su takođe uporedivi sa rešenjima zasnovanim na rsync-u i, generalno, veoma bliski borgbackup-u, ali je opterećenje CPU-a veće (pokreće se više niti) i testerasto.
Najvjerovatnije je program ograničen performansama podsistema diska na serveru za pohranu podataka, kao što je već bio slučaj sa rsync-om. Veličina spremišta je bila 13GB, baš kao zbackup ili borgbackup, nije bilo očiglednih nedostataka pri korištenju ovog rješenja.
Rezulʹtaty
Zapravo, svi kandidati su postigli slične rezultate, ali po različitim cijenama. Borgbackup je bio najbolji od svih, restic je bio malo sporiji, zbackup vjerovatno nije vrijedan početka korištenja,
a ako je već u upotrebi, pokušajte ga promijeniti u borgbackup ili restic.
nalazi
Čini se da je rješenje koje najviše obećava restično, jer... upravo on ima najbolji omjer mogućnosti i brzine rada, ali nemojmo za sada žuriti s općim zaključcima.
Borgbackup u osnovi nije ništa lošiji, ali zbackup je vjerovatno bolje zamijeniti. Istina, zbackup se i dalje može koristiti kako bi se osiguralo da pravilo 3-2-1 funkcionira. Na primjer, pored (lib)rsync baziranih rezervnih kopija.
Najava
Backup Dio 5: Testiranje backup-a bacula i veeam za linux
Backup Dio 6: Poređenje alata za pravljenje rezervnih kopija
Rezervni dio 7: Zaključci
Objavio: Pavel Demkovich
izvor: www.habr.com