Ta opomba obravnava orodja za varnostno kopiranje, ki izvajajo varnostno kopiranje z ustvarjanjem arhivov na strežniku za varnostno kopiranje.
Med tistimi, ki izpolnjujejo zahteve, sta duplicity (ki ima lep vmesnik v obliki deja dup) in duplicati.
Drugo zelo izjemno orodje za varnostno kopiranje je dar, a ker ima zelo obsežen seznam možnosti - metodologija testiranja pokriva komaj 10 % tega, kar je zmožno - ga ne testiramo kot del trenutnega cikla.
Pričakovani rezultati
Ker oba kandidata na tak ali drugačen način ustvarjata arhive, lahko kot vodilo uporabimo običajni tar.
Poleg tega bomo ocenili, kako dobro je shranjevanje podatkov na strežniku za shranjevanje optimizirano z ustvarjanjem varnostnih kopij, ki vsebujejo samo razliko med celotno kopijo in trenutnim stanjem datotek ali med prejšnjim in trenutnim arhivom (inkrementalni, dekrementalni itd.) .
Obnašanje pri ustvarjanju varnostnih kopij:
- Relativno majhno število datotek na strežniku za shranjevanje varnostnih kopij (primerljivo s številom varnostnih kopij ali velikostjo podatkov v GB), vendar je njihova velikost precej velika (deset do sto megabajtov).
- Velikost repozitorija bo vključevala le spremembe - dvojniki ne bodo shranjeni, zato bo velikost repozitorija manjša kot pri programski opremi, ki temelji na rsync.
- Pričakujte veliko obremenitev procesorja pri uporabi stiskanja in/ali šifriranja ter verjetno precej visoko obremenitev omrežja in diska, če se proces arhiviranja in/ali šifriranja izvaja na strežniku za rezervno shranjevanje.
Zaženimo naslednji ukaz kot referenčno vrednost:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Rezultati izvedbe so bili naslednji:
Čas izvedbe 3m12s. Vidimo, da je hitrost omejena z diskovnim podsistemom strežnika za rezervno shranjevanje, kot v primeru z . Le malo hitreje, ker... posnetek gre v eno datoteko.
Za ovrednotenje stiskanja zaženimo isto možnost, vendar omogočimo stiskanje na strani rezervnega strežnika:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Rezultati so:
Čas izvedbe 10m11s. Najverjetneje je ozko grlo kompresor z enim tokom na sprejemnem koncu.
Isti ukaz, vendar s stiskanjem, prenesenim na strežnik z izvirnimi podatki, da se preizkusi hipoteza, da je ozko grlo enonitni kompresor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Izkazalo se je takole:
Čas izvedbe je bil 9m37s. Obremenitev enega jedra s strani kompresorja je jasno vidna, ker Hitrost omrežnega prenosa in obremenitev izvornega diskovnega podsistema sta podobni.
Za ovrednotenje šifriranja lahko uporabite openssl ali gpg s povezavo dodatnega ukaza openssl ali gpg v cevi. Za referenco bo na voljo ukaz, kot je ta:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Rezultati so prišli takole:
Izkazalo se je, da je čas izvajanja 10 m30 s, saj sta se na sprejemni strani izvajala 2 procesa - ozko grlo je spet enonitni kompresor in majhna šifrirna obremenitev.
UPS: Na željo bliznezza dodajam teste s pigz. Če bi uporabili samo kompresor, bi trajalo 6m30s, če bi dodali še enkripcijo, bi bilo približno 7m. Padec na spodnjem grafu je neizpran diskovni predpomnilnik:
Podvojeno testiranje
Duplicity je programska oprema python za varnostno kopiranje z ustvarjanjem šifriranih arhivov v formatu tar.
Za inkrementalne arhive se uporablja librsync, tako da lahko pričakujete vedenje, opisano v .
Varnostne kopije lahko šifriramo in podpišemo z gnupg, kar je pomembno pri uporabi različnih ponudnikov za shranjevanje varnostnih kopij (s3, backblaze, gdrive itd.)
Poglejmo, kakšni so rezultati:
To so rezultati, ki smo jih dobili pri izvajanju brez šifriranja
spojler
Čas delovanja vsake preskusne vožnje:
Zagon 1
Zagon 2
Zagon 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
In tukaj so rezultati, ko je omogočeno šifriranje gnupg, z velikostjo ključa 2048 bitov:
Čas delovanja na istih podatkih, s šifriranjem:
Zagon 1
Zagon 2
Zagon 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
Navedena je bila velikost bloka - 512 megabajtov, kar je jasno vidno na grafih; Obremenitev procesorja je dejansko ostala 50 %, kar pomeni, da program ne uporablja več kot eno procesorsko jedro.
Dokaj jasno je viden tudi princip delovanja programa: vzeli so delček podatka, ga stisnili in poslali na strežnik za rezervno shranjevanje, kar je lahko precej počasno.
Druga lastnost je predvidljiv čas delovanja programa, ki je odvisen le od velikosti spremenjenih podatkov.
Omogočanje šifriranja ni bistveno povečalo časa delovanja programa, je pa povečalo obremenitev procesorja za približno 10%, kar je lahko kar lep bonus.
Na žalost ta program ni mogel pravilno zaznati situacije s preimenovanjem imenika in nastala velikost repozitorija se je izkazala za enako velikosti sprememb (tj. vseh 18 GB), vendar možnost uporabe nezaupljivega strežnika za varnostno kopiranje jasno pokriva to vedenje.
Podvojeno testiranje
Ta programska oprema je napisana v C# in deluje z uporabo niza knjižnic iz Mono. Obstaja različica GUI in CLI.
Približen seznam glavnih funkcij je podoben dvojniku, vključno z različnimi ponudniki shranjevanja varnostnih kopij, vendar je za razliko od dvojnika večina funkcij na voljo brez orodij tretjih oseb. Ali je to plus ali minus, je odvisno od konkretnega primera, za začetnike pa je najverjetneje lažje imeti pred seboj seznam vseh funkcij naenkrat, kot da bi morali dodatno nameščati pakete za python, kot je npr. primer z dvojnostjo.
Še en majhen odtenek - program aktivno piše lokalno bazo podatkov sqlite v imenu uporabnika, ki zažene varnostno kopiranje, zato morate dodatno zagotoviti, da je zahtevana baza podatkov pravilno določena vsakič, ko se postopek zažene s cli. Ko delate prek GUI ali WEBGUI, bodo podrobnosti skrite pred uporabnikom.
Poglejmo, katere kazalnike lahko ustvari ta rešitev:
Če izklopite šifriranje (in WEBGUI tega ne priporoča), so rezultati naslednji:
Delovni čas:
Zagon 1
Zagon 2
Zagon 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
Z omogočenim šifriranjem z uporabo aes je videti takole:
Delovni čas:
Zagon 1
Zagon 2
Zagon 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
In če uporabite zunanji program gnupg, pridejo naslednji rezultati:
Zagon 1
Zagon 2
Zagon 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
Kot lahko vidite, lahko program deluje v več nitih, vendar to ne pomeni, da je bolj produktivna rešitev, in če primerjate delo šifriranja, je zagon zunanjega programa
se je izkazalo za hitrejše od uporabe knjižnice iz nabora Mono. To je lahko posledica dejstva, da je zunanji program bolj optimiziran.
Lepo je bilo tudi dejstvo, da velikost repozitorija zavzame natanko toliko, kot dejansko spremenjeni podatki, tj. duplicati je zaznal preimenovanje imenika in to situacijo pravilno obravnaval. To je mogoče videti pri izvajanju drugega testa.
Na splošno dokaj pozitivni vtisi o programu, vključno s tem, da je dokaj prijazen do novincev.
Ugotovitve
Oba kandidata sta delala precej počasi, a na splošno je v primerjavi z navadnim tar-om napredek, vsaj pri duplikatih. Tudi cena takšnega napredka je jasna – opazno breme
procesor. Na splošno pri napovedovanju rezultatov ni posebnih odstopanj.
Ugotovitve
Če se vam ni treba nikamor muditi in imate tudi rezervni procesor, bo katera od obravnavanih rešitev zadostovala, v vsakem primeru je bilo opravljenega kar nekaj dela, ki ga ne bi smeli ponavljati s pisanjem ovojnih skriptov na tar. . Prisotnost šifriranja je zelo potrebna lastnost, če strežniku za shranjevanje varnostnih kopij ni mogoče popolnoma zaupati.
V primerjavi z rešitvami, ki temeljijo - zmogljivost je lahko nekajkrat slabša, kljub dejstvu, da je v svoji čisti obliki tar deloval 20-30% hitreje kot rsync.
Obstajajo prihranki pri velikosti repozitorija, vendar le z dvojniki.
Obvestilo
Varnostno kopiranje, 3. del: Pregled in testiranje dvojnosti, duplicati, deja dup
Varnostno kopiranje, 4. del: Pregled in testiranje zbackup, restic, borgbackup
Varnostno kopiranje, 5. del: Testiranje varnostnega kopiranja bacula in veeam za linux
Varnostno kopiranje, 6. del: Primerjava orodij za varnostno kopiranje
Varnostno kopiranje, 7. del: Zaključki
Objavil: Pavel Demkovič
Vir: www.habr.com