Ova napomena govori o alatima za pravljenje rezervnih kopija koji izvode rezervne kopije kreiranjem arhiva na serveru za rezervne kopije.
Među onima koji ispunjavaju uslove su dupličnost (koja ima lep interfejs u obliku deja dupa) i duplikati.
Još jedan veoma izvanredan alat za pravljenje rezervnih kopija je dar, ali pošto ima veoma široku listu opcija - metodologija testiranja pokriva jedva 10% onoga za šta je sposobna - ne testiramo ga kao deo trenutnog ciklusa.
Očekivani rezultati
Pošto oba kandidata kreiraju arhive na ovaj ili onaj način, običan tar se može koristiti kao vodič.
Osim toga, procijenit ćemo koliko je dobro pohranjivanje podataka na serveru za pohranu optimizirano stvaranjem rezervnih kopija koje sadrže samo razliku između pune kopije i trenutnog stanja datoteka, ili između prethodne i trenutne arhive (inkrementalne, dekrementalne, itd.) .
Ponašanje prilikom kreiranja sigurnosne kopije:
- Relativno mali broj datoteka na serveru za pohranu rezervnih kopija (uporedivo sa brojem rezervnih kopija ili veličinom podataka u GB), ali je njihova veličina prilično velika (desetine do stotine megabajta).
- Veličina spremišta će uključivati samo promjene - neće biti pohranjeni duplikati, tako da će veličina spremišta biti manja nego kod softvera baziranog na rsync.
- Očekujte veliko opterećenje CPU-a kada koristite kompresiju i/ili enkripciju, i vjerovatno prilično veliko opterećenje mreže i diska ako se proces arhiviranja i/ili šifriranja izvodi na serveru za pohranu rezervnih kopija.
Pokrenimo sljedeću naredbu kao referentnu vrijednost:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Rezultati izvršenja su bili sljedeći:
Vrijeme izvršenja 3m12s. Može se vidjeti da je brzina ograničena diskovnim podsistemom servera za pohranu rezervnih kopija, kao u primjeru sa . Samo malo brže, jer... snimak ide u jedan fajl.
Također, da bismo procijenili kompresiju, pokrenimo istu opciju, ali omogućimo kompresiju na strani backup servera:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Rezultati su:
Vrijeme izvršenja 10m11s. Najvjerovatnije je usko grlo jednoprotočni kompresor na prijemnoj strani.
Ista komanda, ali sa kompresijom koja se prenosi na server sa originalnim podacima kako bi se testirala hipoteza da je usko grlo jednonitni kompresor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Ispalo je ovako:
Vrijeme izvršenja je bilo 9m37s. Opterećenje jedne jezgre kompresorom je jasno vidljivo, jer Brzina mrežnog prijenosa i opterećenje podsistema izvornog diska su slični.
Za procjenu šifriranja, možete koristiti openssl ili gpg povezivanjem dodatne naredbe openssl ili gpg u cijevi. Za referencu biće naredba poput ove:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Rezultati su ispali ovako:
Ispostavilo se da je vrijeme izvršenja 10 m30 s, budući da su 2 procesa bila pokrenuta na prijemnoj strani - usko grlo je opet jednonitni kompresor, plus mala enkripcija.
UPS: Na zahtjev bliznezz-a dodajem testove sa pigz-om. Ako koristite samo kompresor, trebalo bi 6m30s, ako dodate i enkripciju, bilo bi oko 7m. Pad u donjem grafikonu je neisprana predmemorija diska:
Duplicirano testiranje
Duplicity je python softver za izradu sigurnosnih kopija kreiranjem šifriranih arhiva u tar formatu.
Za inkrementalne arhive se koristi librsync, tako da možete očekivati ponašanje opisano u .
Sigurnosne kopije mogu biti šifrirane i potpisane pomoću gnupg-a, što je važno kada se koriste različiti provajderi za pohranjivanje sigurnosnih kopija (s3, backblaze, gdrive, itd.)
Da vidimo kakvi su rezultati:
Ovo su rezultati koje smo dobili kada smo radili bez enkripcije
spojler
Vrijeme rada svakog probnog rada:
Lansiranje 1
Lansiranje 2
Lansiranje 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
A evo i rezultata kada je omogućena gnupg enkripcija, s veličinom ključa od 2048 bita:
Vrijeme rada na istim podacima, sa enkripcijom:
Lansiranje 1
Lansiranje 2
Lansiranje 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Naznačena je veličina bloka - 512 megabajta, što je jasno vidljivo na grafikonima; Opterećenje procesora je zapravo ostalo na 50%, što znači da program ne koristi više od jednog jezgra procesora.
Prilično je jasno vidljiv i princip rada programa: uzeli su dio podataka, komprimirali ga i poslali na backup server za pohranu, što može biti prilično sporo.
Još jedna karakteristika je predvidljivo vrijeme rada programa, koje ovisi samo o veličini promijenjenih podataka.
Omogućavanje enkripcije nije značajno povećalo vrijeme rada programa, ali je povećalo opterećenje procesora za oko 10%, što može biti prilično lijep bonus.
Nažalost, ovaj program nije mogao ispravno otkriti situaciju s preimenovanjem direktorija, a rezultirajuća veličina spremišta se pokazala jednakom veličini promjena (tj. svih 18 GB), ali mogućnost korištenja nepouzdanog servera za sigurnosnu kopiju jasno je pokriva ovo ponašanje.
Duplicirano testiranje
Ovaj softver je napisan u C# i radi pomoću skupa biblioteka iz Mono-a. Postoji GUI kao i CLI verzija.
Približna lista glavnih karakteristika je slična dupličnosti, uključujući razne dobavljače rezervnih kopija, međutim, za razliku od dupličnosti, većina funkcija je dostupna bez alata treće strane. Da li je ovo plus ili minus zavisi od konkretnog slučaja, ali za početnike je najverovatnije lakše da imaju listu svih funkcija ispred sebe odjednom, umesto da moraju da instaliraju dodatne pakete za python, kao što je slučaj sa dvoličnošću.
Još jedna mala nijansa - program aktivno piše lokalnu sqlite bazu podataka u ime korisnika koji pokreće sigurnosnu kopiju, tako da je potrebno dodatno osigurati da je potrebna baza podataka ispravno specificirana svaki put kada se proces pokrene pomoću cli-a. Kada radite kroz GUI ili WEBGUI, detalji će biti skriveni od korisnika.
Pogledajmo koje pokazatelje ovo rješenje može proizvesti:
Ako isključite enkripciju (a WEBGUI ne preporučuje da to radite), rezultati su sljedeći:
Radno vrijeme:
Lansiranje 1
Lansiranje 2
Lansiranje 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Sa omogućenom enkripcijom, koristeći aes, to izgleda ovako:
Radno vrijeme:
Lansiranje 1
Lansiranje 2
Lansiranje 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
A ako koristite vanjski program gnupg, dolazi do sljedećih rezultata:
Lansiranje 1
Lansiranje 2
Lansiranje 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Kao što vidite, program može raditi u nekoliko niti, ali to ga ne čini produktivnijim rješenjem, a ako uporedite rad enkripcije, to je pokretanje vanjskog programa
pokazalo se bržim od korištenja biblioteke iz Mono seta. To može biti zbog činjenice da je vanjski program optimiziraniji.
Još jedna lijepa stvar bila je činjenica da veličina spremišta zauzima točno onoliko koliko su stvarno promijenjeni podaci, tj. duplicati je otkrio preimenovanje direktorija i ispravno riješio ovu situaciju. To se može vidjeti prilikom pokretanja drugog testa.
Sve u svemu, prilično pozitivni utisci o programu, uključujući i prilično prijateljski raspoložen prema početnicima.
Rezulʹtaty
Oba kandidata su radila prilično sporo, ali generalno, u poređenju sa redovnim katranom, ima pomaka, barem kod duplikata. Jasna je i cijena takvog napretka – primjetan teret
procesor. Generalno, nema posebnih odstupanja u predviđanju rezultata.
nalazi
Ako ne morate nigdje žuriti, a imate i rezervni procesor, bilo koje od razmatranih rješenja će učiniti, u svakom slučaju, urađeno je dosta posla koji se ne bi trebao ponavljati pisanjem omotača na tar. . Prisustvo enkripcije je vrlo neophodno svojstvo ako se serveru za pohranjivanje rezervnih kopija ne može u potpunosti vjerovati.
U poređenju sa rešenjima zasnovanim na - performanse mogu biti nekoliko puta lošije, uprkos činjenici da je u svom čistom obliku tar radio 20-30% brže od rsync-a.
Postoje uštede na veličini spremišta, ali samo sa duplikatima.
Najava
Backup Dio 3: Pregled i testiranje dupličnosti, duplikati, deja dup
Backup Dio 4: Pregled i testiranje zbackup, restic, borgbackup
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