Atsarginė kopija 3 dalis: Dvigubumo peržiūra ir testavimas, dublikatai

Šioje pastaboje aptariami atsarginių kopijų kūrimo įrankiai, kurie atlieka atsargines kopijas kurdami archyvus atsarginių kopijų serveryje.

Tarp tų, kurie atitinka reikalavimus, yra duplicity (kuris turi gražią sąsają deja dup forma) ir duplicati.

Kitas labai puikus atsarginių kopijų kūrimo įrankis yra dar, bet kadangi jis turi labai platų parinkčių sąrašą – testavimo metodika apima vos 10% to, ką ji gali – mes jo netestuojame kaip dabartinio ciklo dalį.

Laukiami rezultatai

Kadangi abu kandidatai vienaip ar kitaip kuria archyvus, įprasta tara gali būti naudojama kaip vadovas.

Be to, įvertinsime, kaip optimizuotas duomenų saugojimas saugyklos serveryje, sukuriant atsargines kopijas, kuriose yra tik skirtumas tarp visos kopijos ir dabartinės failų būsenos arba tarp ankstesnio ir dabartinio archyvo (prieauginio, mažėjimo ir kt.) .

Elgesys kuriant atsargines kopijas:

1. Atsarginės kopijos saugojimo serveryje yra palyginti mažas failų skaičius (palyginti su atsarginių kopijų skaičiumi arba duomenų dydžiu GB), tačiau jų dydis yra gana didelis (nuo kelių dešimčių iki šimtų megabaitų).
2. Į saugyklos dydį bus įtraukti tik pakeitimai – dublikatai nebus saugomi, todėl saugyklos dydis bus mažesnis nei naudojant rsync pagrįstą programinę įrangą.
3. Tikėtis didelės procesoriaus apkrovos, kai naudojamas glaudinimas ir (arba) šifravimas, ir, tikėtina, gana didelė tinklo ir disko apkrova, jei archyvavimo ir (arba) šifravimo procesas vykdomas atsarginės kopijos saugojimo serveryje.

Vykdykime šią komandą kaip atskaitos reikšmę:

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

Vykdymo rezultatai buvo tokie:

Vykdymo laikas 3m12s. Galima pastebėti, kad greitį riboja atsarginės kopijos saugojimo serverio disko posistemis, kaip pavyzdyje rsync. Tik šiek tiek greičiau, nes... įrašymas vyksta į vieną failą.

Be to, norėdami įvertinti glaudinimą, paleiskite tą pačią parinktį, bet įgalinkite glaudinimą atsarginio serverio pusėje:

cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"

Rezultatai:

Vykdymo laikas 10m11s. Labiausiai tikėtina, kad kliūtis yra vieno srauto kompresorius priėmimo gale.

Ta pati komanda, bet su glaudinimu, perduodama į serverį su pradiniais duomenimis, siekiant patikrinti hipotezę, kad kliūtis yra vienos gijos kompresorius.

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

Tai pasirodė taip:

Vykdymo laikas buvo 9m37s. Kompresoriaus vienos šerdies apkrova yra aiškiai matoma, nes Tinklo perdavimo greitis ir šaltinio disko posistemio apkrova yra panašūs.

Norėdami įvertinti šifravimą, galite naudoti openssl arba gpg, prijungę papildomą komandą openssl arba gpg vamzdyje. Kaip nuoroda, bus tokia komanda:

cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"

Rezultatai pasirodė tokie:

Paaiškėjo, kad vykdymo laikas buvo 10 m30 s, nes priėmimo pusėje veikė 2 procesai - kliūtis vėlgi yra vienos gijos kompresorius ir nedidelė šifravimo kaina.

UPD: Bliznezz prašymu pridedu testus su pigz. Jei naudotum tik kompresorių, tai užtruktų 6m30s, jei dar pridėtum šifravimą, tai būtų apie 7m. Apatinėje diagramoje esantis kritimas yra neišvalyta disko talpykla:

Pasikartojantys bandymai

„Duplicity“ yra „python“ programinė įranga, skirta atsarginėms kopijoms kurti kuriant šifruotus archyvus tar formatu.

Papildomiems archyvams naudojama librsync, todėl galite tikėtis, kad elgsena aprašyta straipsnyje ankstesnis šios serijos įrašas.

Atsarginės kopijos gali būti užšifruotos ir pasirašytos naudojant gnupg, o tai svarbu, kai atsarginėms kopijoms saugoti naudojami skirtingi tiekėjai (s3, backblaze, gdrive ir kt.)

Pažiūrėkime, kokie rezultatai:

Tai yra rezultatai, kuriuos gavome veikdami be šifravimo

spoileris

Kiekvieno bandomojo važiavimo trukmė:

Paleisti 1
Paleisti 2
Paleisti 3

16m33s
17m20s
16m30s

8m29s
9m3s
8m45s

5m21s
6m04s
5m53s

Ir štai rezultatai, kai įjungtas gnupg šifravimas, kurio rakto dydis yra 2048 bitai:

Veikimo laikas naudojant tuos pačius duomenis su šifravimu:

Paleisti 1
Paleisti 2
Paleisti 3

17m22s
17m32s
17m28s

8m52s
9m13s
9m3s

5m48s
5m40s
5m30s

Buvo nurodytas bloko dydis – 512 megabaitų, kas aiškiai matosi grafikuose; Procesoriaus apkrova iš tikrųjų išliko 50%, o tai reiškia, kad programa naudoja ne daugiau kaip vieną procesoriaus branduolį.

Gana aiškiai matomas ir programos veikimo principas: jie paėmė dalį duomenų, suglaudino ir nusiuntė į atsarginį saugojimo serverį, kuris gali būti gana lėtas.
Dar viena savybė – nuspėjamas programos veikimo laikas, kuris priklauso tik nuo pakeistų duomenų dydžio.

Įjungus šifravimą, programos veikimo laikas žymiai nepailgėjo, tačiau procesoriaus apkrova padidėjo maždaug 10%, o tai gali būti gana maloni premija.

Deja, šiai programai nepavyko teisingai aptikti situacijos keičiant katalogą, o gautas saugyklos dydis pasirodė lygus pakeitimų dydžiui (t. y. visi 18 GB), tačiau galimybė atsarginėms kopijoms naudoti nepatikimą serverį aiškiai matosi. apima šį elgesį.

Pasikartojantys bandymai

Ši programinė įranga parašyta C# ir veikia naudojant Mono bibliotekų rinkinį. Yra GUI ir CLI versija.

Apytikslis pagrindinių funkcijų sąrašas yra panašus į duplicity, įskaitant įvairius atsarginių duomenų saugyklos teikėjus, tačiau, skirtingai nei duplicity, dauguma funkcijų yra prieinamos be trečiųjų šalių įrankių. Ar tai pliusas, ar minusas, priklauso nuo konkretaus atvejo, bet pradedantiesiems greičiausiai lengviau turėti visų funkcijų sąrašą iš karto, o ne diegti papildomus python paketus, kaip yra atvejis su dviveidiškumu.

Dar vienas nedidelis niuansas – programa aktyviai rašo vietinę sqlite duomenų bazę vartotojo, kuris pradeda atsarginę kopiją, vardu, todėl reikia papildomai pasirūpinti, kad reikiama duomenų bazė būtų teisingai nurodyta kiekvieną kartą, kai procesas pradedamas naudojant cli. Kai dirbate per GUI arba WEBGUI, informacija bus paslėpta nuo vartotojo.

Pažiūrėkime, kokius rodiklius gali sukelti šis sprendimas:

Jei išjungsite šifravimą (o WEBGUI nerekomenduoja to daryti), rezultatai bus tokie:

Darbo laikas:

Paleisti 1
Paleisti 2
Paleisti 3

20m43s
20m13s
20m28s

5m21s
5m40s
5m35s

7m36s
7m54s
7m49s

Kai įjungtas šifravimas, naudojant aes, tai atrodo taip:

Darbo laikas:

Paleisti 1
Paleisti 2
Paleisti 3

29m9s
30m1s
29m54s

5m29s
6m2s
5m54s

8m44s
9m12s
9m1s

Ir jei naudojate išorinę programą gnupg, gaunami šie rezultatai:

Paleisti 1
Paleisti 2
Paleisti 3

26m6s
26m35s
26m17s

5m20s
5m48s
5m40s

8m12s
8m42s
8m15s

Kaip matote, programa gali veikti keliose gijose, tačiau tai netampa produktyvesniu sprendimu, o jei palyginsite šifravimo darbą, tai paleidžia išorinę programą
pasirodė greičiau nei naudotis biblioteka iš Mono rinkinio. Taip gali būti dėl to, kad išorinė programa yra labiau optimizuota.

Dar vienas malonus dalykas buvo tai, kad saugyklos dydis užima lygiai tiek pat, kiek realiai pakeisti duomenys, t.y. duplicati aptiko katalogo pervadinimą ir teisingai išsprendė šią situaciją. Tai galima pamatyti atliekant antrąjį testą.

Apskritai, gana teigiami įspūdžiai apie programą, įskaitant gana draugišką naujokams.

rezultatai

Abu kandidatai dirbo gana lėtai, bet apskritai, lyginant su įprasta tara, pažanga, bent jau su dublikatais, yra. Tokio progreso kaina taip pat aiški – pastebima našta
procesorius. Apskritai prognozuojant rezultatus ypatingų nukrypimų nėra.

išvados

Jei niekur nereikia skubėti, o dar ir atsarginį procesorių, tiks bet kuris iš svarstytų sprendimų, bet kokiu atveju atlikta gana daug darbo, kurio nereikėtų kartoti rašant įvyniojimo scenarijus ant dervos . Šifravimo buvimas yra labai reikalinga savybė, jei negalima visiškai pasitikėti atsarginių kopijų saugojimo serveriu.

Palyginti su sprendimais pagrįstais rsync - našumas gali būti kelis kartus prastesnis, nepaisant to, kad gryna tara veikė 20–30% greičiau nei rsync.
Sutaupoma dėl saugyklos dydžio, bet tik naudojant dublikatus.

Skelbimas

Atsarginė kopija, 1 dalis: Kodėl reikalinga atsarginė kopija, metodų, technologijų apžvalga
Atsarginė kopija 2 dalis: rsync pagrįstų atsarginių kopijų kūrimo įrankių peržiūra ir testavimas
Atsarginė kopija 3 dalis: peržiūra ir tikrinamas dubliavimas, duplicati, deja dup
Atsarginė kopija 4 dalis: zbackup, restic, borgbackup peržiūra ir testavimas
Atsarginė kopija 5 dalis: „Bacula“ ir „veeam“ atsarginių kopijų testavimas, skirtas Linux
Atsarginė kopija 6 dalis: Atsarginės kopijos įrankių palyginimas
Atsarginė kopija 7 dalis: Išvados

Paskelbtas: Pavelas Demkovičius

Šaltinis: www.habr.com