Táto poznámka sa zaoberá nástrojmi na zálohovanie, ktoré vykonávajú zálohy vytváraním archívov na serveri záloh.
Medzi tie, ktoré spĺňajú požiadavky patrí duplicita (ktorá má pekné rozhranie v podobe deja dup) a duplicati.
Ďalším veľmi pozoruhodným zálohovacím nástrojom je dar, ale keďže má veľmi rozsiahly zoznam možností – metodika testovania pokrýva sotva 10 % toho, čoho je schopná – v rámci aktuálneho cyklu ho netestujeme.
Očakávané výsledky
Keďže obaja kandidáti vytvárajú archívy tak či onak, ako pomôcku možno použiť bežný tar.
Okrem toho vyhodnotíme, ako dobre je optimalizované ukladanie údajov na úložnom serveri vytvorením záložných kópií obsahujúcich iba rozdiel medzi úplnou kópiou a aktuálnym stavom súborov alebo medzi predchádzajúcimi a aktuálnymi archívmi (prírastkové, dekrementálne atď.) .
Správanie pri vytváraní záloh:
- Relatívne malý počet súborov na serveri zálohovania (porovnateľný s počtom záložných kópií alebo veľkosťou dát v GB), ale ich veľkosť je pomerne veľká (desiatky až stovky megabajtov).
- Veľkosť úložiska bude zahŕňať iba zmeny – nebudú sa ukladať žiadne duplikáty, takže veľkosť úložiska bude menšia ako pri softvéri založenom na rsync.
- Očakávajte veľké zaťaženie procesora pri použití kompresie a/alebo šifrovania a pravdepodobne aj pomerne vysoké zaťaženie siete a disku, ak proces archivácie a/alebo šifrovania beží na serveri zálohovania.
Ako referenčnú hodnotu spustíme nasledujúci príkaz:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Výsledky realizácie boli nasledovné:
Čas vykonania 3m12s. Je vidieť, že rýchlosť je obmedzená diskovým subsystémom servera zálohovania, ako v príklade s . Len trochu rýchlejšie, pretože... záznam prejde do jedného súboru.
Ak chcete vyhodnotiť kompresiu, spustite rovnakú možnosť, ale povoľte kompresiu na strane záložného servera:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Výsledky sú:
Čas vykonania 10m11s. S najväčšou pravdepodobnosťou je prekážkou jednoprúdový kompresor na prijímacej strane.
Rovnaký príkaz, ale s kompresiou prenesenou na server s pôvodnými údajmi na testovanie hypotézy, že prekážkou je jednovláknový kompresor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Dopadlo to takto:
Čas vykonania bol 9 m 37 s. Zaťaženie jedného jadra kompresorom je jasne viditeľné, pretože Rýchlosť sieťového prenosu a zaťaženie subsystému zdrojového disku sú podobné.
Na vyhodnotenie šifrovania môžete použiť openssl alebo gpg pripojením ďalšieho príkazu openssl alebo gpg v potrubí. Pre referenciu bude príkaz ako tento:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Výsledky vyšli takto:
Čas vykonania sa ukázal byť 10m30s, keďže na prijímacej strane bežali 2 procesy – úzkym miestom je opäť jednovláknový kompresor plus malá réžia šifrovania.
UPS: Na žiadosť bliznezz pridávam testy s pigz. Ak by ste použili len kompresor, trvalo by to 6m30s, ak by ste pridali aj šifrovanie, bolo by to cca 7m. Pokles v spodnom grafe je nevyprázdnená disková vyrovnávacia pamäť:
Duplicitné testovanie
Duplicity je python softvér na zálohovanie vytváraním šifrovaných archívov vo formáte tar.
Pre prírastkové archívy sa používa librsync, takže môžete očakávať správanie opísané v .
Zálohy môžu byť šifrované a podpísané pomocou gnupg, čo je dôležité pri používaní rôznych poskytovateľov na ukladanie záloh (s3, backblaze, gdrive atď.)
Pozrime sa, aké sú výsledky:
Toto sú výsledky, ktoré sme dosiahli pri spustení bez šifrovania
spojler
Doba trvania každého testovacieho chodu:
Spustenie 1
Spustenie 2
Spustenie 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
A tu sú výsledky, keď je povolené šifrovanie gnupg s veľkosťou kľúča 2048 bitov:
Prevádzkový čas na rovnakých údajoch so šifrovaním:
Spustenie 1
Spustenie 2
Spustenie 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Veľkosť bloku bola uvedená - 512 megabajtov, čo je jasne viditeľné v grafoch; Zaťaženie procesora v skutočnosti zostalo na 50 %, čo znamená, že program nevyužíva viac ako jedno jadro procesora.
Princíp fungovania programu je tiež celkom jasne viditeľný: vzali kus údajov, skomprimovali ich a poslali na server zálohovania, čo môže byť dosť pomalé.
Ďalšou vlastnosťou je predvídateľná doba chodu programu, ktorá závisí len od veľkosti zmenených dát.
Povolenie šifrovania výrazne nezvýšilo čas chodu programu, no zvýšilo zaťaženie procesora asi o 10 %, čo môže byť celkom príjemný bonus.
Žiaľ, tento program nedokázal správne rozpoznať situáciu s premenovaním adresára a výsledná veľkosť úložiska sa ukázala byť rovná veľkosti zmien (t.j. všetkých 18 GB), ale možnosť použiť na zálohovanie nedôveryhodný server jednoznačne pokrýva toto správanie.
Duplicitné testovanie
Tento softvér je napísaný v C# a beží pomocou sady knižníc od Mono. K dispozícii je GUI aj verzia CLI.
Približný zoznam hlavných funkcií je podobný duplicite, vrátane rôznych poskytovateľov zálohovania, avšak na rozdiel od duplicity je väčšina funkcií dostupná bez nástrojov tretích strán. Či je to plus alebo mínus, závisí od konkrétneho prípadu, ale pre začiatočníkov je s najväčšou pravdepodobnosťou jednoduchšie mať pred sebou zoznam všetkých funkcií naraz, namiesto toho, aby museli dodatočne inštalovať balíčky pre python, ako je prípad s duplicitou.
Ďalšia malá nuansa - program aktívne zapisuje lokálnu databázu sqlite v mene používateľa, ktorý spúšťa zálohovanie, takže musíte dodatočne zabezpečiť, aby bola požadovaná databáza správne špecifikovaná pri každom spustení procesu pomocou cli. Pri práci cez GUI alebo WEBGUI budú detaily pred používateľom skryté.
Pozrime sa, aké ukazovatele môže toto riešenie produkovať:
Ak vypnete šifrovanie (a WEBGUI to neodporúča), výsledky budú nasledovné:
Prevádzkové hodiny:
Spustenie 1
Spustenie 2
Spustenie 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
S povoleným šifrovaním pomocou aes to vyzerá takto:
Prevádzkové hodiny:
Spustenie 1
Spustenie 2
Spustenie 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
A ak použijete externý program gnupg, objavia sa nasledujúce výsledky:
Spustenie 1
Spustenie 2
Spustenie 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Ako vidíte, program môže pracovať vo viacerých vláknach, ale to z neho nerobí produktívnejšie riešenie a ak porovnáte prácu so šifrovaním, spúšťa externý program
sa ukázalo rýchlejšie ako použitie knižnice zo sady Mono. Môže to byť spôsobené tým, že externý program je viac optimalizovaný.
Ďalšou príjemnou vecou bol fakt, že veľkosť úložiska zaberá presne toľko, koľko skutočne zmenených dát, t.j. duplicati zistil premenovanie adresára a vyriešil túto situáciu správne. To možno vidieť pri spustení druhého testu.
Celkovo celkom pozitívne dojmy z programu, vrátane toho, že je celkom priateľský k nováčikom.
výsledky
Obaja kandidáti pracovali dosť pomaly, ale vo všeobecnosti je v porovnaní s bežným dechtom pokrok, aspoň s duplikátmi. Cena takéhoto pokroku je tiež jasná – citeľná záťaž
procesor. Vo všeobecnosti neexistujú žiadne špeciálne odchýlky pri predpovedaní výsledkov.
Závery
Ak sa nemusíte nikam ponáhľať a máte aj náhradný procesor, urobí vám ktorékoľvek zo zvažovaných riešení, v každom prípade sa urobilo dosť veľa práce, ktorá by sa nemala opakovať písaním obalových skriptov na vrch tar. . Prítomnosť šifrovania je veľmi potrebná vlastnosť, ak server na ukladanie záložných kópií nemôže byť plne dôveryhodný.
V porovnaní s riešeniami založenými - výkon môže byť niekoľkonásobne horší, napriek tomu, že vo svojej čistej forme decht fungoval o 20-30% rýchlejšie ako rsync.
Dochádza k úsporám na veľkosti úložiska, ale iba pri duplikáciách.
Oznámenie
Zálohovanie, časť 3: Kontrola a testovanie duplicity, duplicati, deja dup
Zálohovanie Časť 4: Kontrola a testovanie zbackup, restic, borgbackup
Zálohovanie, časť 5: Testovanie zálohovania bacula a veeam pre linux
Zálohovanie Časť 6: Porovnanie nástrojov zálohovania
Zálohovanie Časť 7: Závery
Pridané: Pavla Demkoviča
Zdroj: hab.com