Ova bilješka govori o alatima za sigurnosno kopiranje koji izvode sigurnosno kopiranje stvaranjem arhiva na poslužitelju za sigurnosno kopiranje.
Među onima koji ispunjavaju zahtjeve su duplicity (koji ima lijepo sučelje u obliku deja dup) i duplicati.
Još jedan vrlo značajan alat za sigurnosno kopiranje je dar, ali budući da ima vrlo opsežan popis opcija - metodologija testiranja pokriva jedva 10% onoga za što je sposoban - ne testiramo ga kao dio trenutnog ciklusa.
Očekivani rezultati
Budući da oba kandidata stvaraju arhive na ovaj ili onaj način, obični tar može se koristiti kao vodič.
Osim toga, procijenit ćemo koliko je dobro pohrana podataka na poslužitelju za pohranu optimizirana stvaranjem sigurnosnih kopija koje sadrže samo razliku između potpune kopije i trenutnog stanja datoteka ili između prethodne i trenutne arhive (inkrementalne, dekrementalne, itd.) .
Ponašanje prilikom izrade sigurnosnih kopija:
- Relativno mali broj datoteka na poslužitelju za sigurnosnu pohranu (usporediv s brojem sigurnosnih kopija ili veličinom podataka u GB), ali njihova veličina je prilično velika (desetke do stotine megabajta).
- Veličina repozitorija će uključivati samo promjene - neće biti pohranjeni duplikati, tako da će veličina repozitorija biti manja nego kod softvera temeljenog na rsync.
- Očekujte veliko opterećenje CPU-a kada koristite kompresiju i/ili enkripciju, a vjerojatno i prilično veliko opterećenje mreže i diska ako se proces arhiviranja i/ili enkripcije izvodi na poslužitelju za pričuvnu pohranu.
Pokrenimo sljedeću naredbu kao referentnu vrijednost:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Rezultati izvršenja bili su sljedeći:
Vrijeme izvršenja 3m12s. Vidljivo je da je brzina ograničena diskovnim podsustavom poslužitelja pričuvne pohrane, kao u primjeru s . Samo malo brže, jer... snimanje ide u jednu datoteku.
Također, za procjenu kompresije, pokrenimo istu opciju, ali omogućimo kompresiju na strani rezervnog poslužitelja:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Rezultati su:
Vrijeme izvršenja 10m11s. Najvjerojatnije je usko grlo jednoprotočni kompresor na prijemnom kraju.
Ista naredba, ali s kompresijom prenesenom na poslužitelj s izvornim podacima za testiranje hipoteze 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 bilo je 9m37s. Opterećenje jedne jezgre od strane kompresora jasno je vidljivo, jer Brzina mrežnog prijenosa i opterećenje podsustava izvornog diska su slični.
Za procjenu enkripcije možete koristiti openssl ili gpg povezivanjem dodatne naredbe openssl ili gpg u cijevi. Za referencu će biti ovakva naredba:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Rezultati su izašli ovako:
Ispostavilo se da je vrijeme izvršenja 10 m30 s, budući da su 2 procesa bila pokrenuta na primateljskoj strani - usko grlo je opet jednonitni kompresor, plus mali troškovi šifriranja.
UPS: Na zahtjev bliznezza dodajem testove sa pigz. Ako koristite samo kompresor, to bi trajalo 6m30s, ako dodate i enkripciju, to bi bilo oko 7m. Pad na donjem grafikonu je neisprana predmemorija diska:
Dvostruko testiranje
Duplicity je python softver za backup stvaranjem šifriranih arhiva u tar formatu.
Za inkrementalne arhive koristi se librsync, tako da možete očekivati ponašanje opisano u .
Sigurnosne kopije se mogu šifrirati i potpisati pomoću gnupg-a, što je važno kada se koriste različiti pružatelji usluga za pohranu sigurnosnih kopija (s3, backblaze, gdrive, itd.)
Pogledajmo kakvi su rezultati:
Ovo su rezultati koje smo dobili kada smo radili bez enkripcije
spojler
Vrijeme izvođenja svakog testnog izvođenja:
Pokreni 1
Pokreni 2
Pokreni 3
16 m33 s
17 m20 s
16 m30 s
8 m29 s
9 m3 s
8 m45 s
5 m21 s
6 m04 s
5 m53 s
A evo rezultata kada je uključena gnupg enkripcija, s veličinom ključa od 2048 bita:
Vrijeme rada na istim podacima, uz enkripciju:
Pokreni 1
Pokreni 2
Pokreni 3
17 m22 s
17 m32 s
17 m28 s
8 m52 s
9 m13 s
9 m3 s
5 m48 s
5 m40 s
5 m30 s
Naznačena je veličina bloka - 512 megabajta, što je jasno vidljivo na grafikonima; Opterećenje procesora zapravo je ostalo na 50%, što znači da program ne koristi više od jedne jezgre procesora.
Načelo rada programa također je prilično jasno vidljivo: uzeli su dio podataka, komprimirali ga i poslali na rezervni poslužitelj za pohranu, što može biti prilično sporo.
Još jedna značajka 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 detektirati situaciju s preimenovanjem direktorija, a rezultirajuća veličina repozitorija pokazala se jednakom veličini promjena (tj. svih 18 GB), ali mogućnost korištenja nepouzdanog poslužitelja za sigurnosno kopiranje jasno pokriva ovo ponašanje.
Dvostruko testiranje
Ovaj softver je napisan u C# i radi pomoću skupa Mono biblioteka. Postoji GUI kao i CLI verzija.
Približan popis glavnih značajki sličan je duplicityju, uključujući razne pružatelje sigurnosne pohrane, međutim, za razliku od duplicityja, većina značajki dostupna je bez alata trećih strana. Je li to plus ili minus ovisi o konkretnom slučaju, no početnicima je vjerojatno lakše imati pred sobom popis svih mogućnosti odjednom, nego instalirati dodatne pakete za python, kao što je slučaj s 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 morate dodatno osigurati da je potrebna baza podataka ispravno navedena svaki put kada se proces pokrene pomoću cli. Kada radite kroz GUI ili WEBGUI, detalji će biti skriveni od korisnika.
Pogledajmo koje pokazatelje ovo rješenje može dati:
Ako isključite enkripciju (a WEBGUI to ne preporučuje), rezultati su sljedeći:
Radno vrijeme:
Pokreni 1
Pokreni 2
Pokreni 3
20 m43 s
20 m13 s
20 m28 s
5 m21 s
5 m40 s
5 m35 s
7 m36 s
7 m54 s
7 m49 s
S uključenom enkripcijom, koristeći aes, to izgleda ovako:
Radno vrijeme:
Pokreni 1
Pokreni 2
Pokreni 3
29 m9 s
30 m1 s
29 m54 s
5 m29 s
6 m2 s
5 m54 s
8 m44 s
9 m12 s
9 m1 s
A ako koristite vanjski program gnupg, pojavljuju se sljedeći rezultati:
Pokreni 1
Pokreni 2
Pokreni 3
26 m6 s
26 m35 s
26 m17 s
5 m20 s
5 m48 s
5 m40 s
8 m12 s
8 m42 s
8 m15 s
Kao što vidite, program može raditi u nekoliko niti, ali to ga ne čini produktivnijim rješenjem, a ako usporedite rad enkripcije, to je pokretanje vanjskog programa
pokazalo se bržim od korištenja knjižnice iz Mono seta. To može biti zbog činjenice da je vanjski program optimiziraniji.
Ugodna točka bila je i činjenica da veličina repozitorija 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 izvođenja drugog testa.
Sve u svemu, prilično pozitivni dojmovi o programu, uključujući prilično prijateljski odnos prema početnicima.
Nalazi
Oba kandidata su radila prilično sporo, ali općenito, u usporedbi s običnim tarom, ima napretka, barem kod duplikata. Jasna je i cijena takvog napretka – osjetan teret
procesor. Općenito, nema posebnih odstupanja u predviđanju rezultata.
Zaključci
Ako ne morate nikamo žuriti, a uz to imate i višak procesora, poslužit će bilo koje od razmatranih rješenja, u svakom slučaju obavljeno je dosta posla koji se ne bi trebao ponavljati pisanjem omotnih skripti na tar-u . Prisutnost enkripcije vrlo je neophodna osobina ako se poslužitelju za pohranu sigurnosnih kopija ne može u potpunosti vjerovati.
U usporedbi s rješenjima na temelju - performanse mogu biti nekoliko puta lošije, unatoč činjenici da je u svom čistom obliku tar radio 20-30% brže od rsync.
Postoje uštede na veličini repozitorija, ali samo s duplikatima.
Obavijest
Sigurnosna kopija 3. dio: Pregled i testiranje dvostrukosti, duplikati, deja dup
Sigurnosna kopija 4. dio: Pregled i testiranje zbackup, restic, borgbackup
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