Zálohování, část 3: Kontrola a testování duplicit, duplicity

Tato poznámka popisuje zálohovací nástroje, které provádějí zálohování vytvářením archivů na serveru záloh.

Mezi ty, které splňují požadavky, patří duplicity (které mají pěkné rozhraní ve formě deja dup) a duplicati.

Dalším velmi pozoruhodným zálohovacím nástrojem je dar, ale protože má velmi rozsáhlý seznam možností – metodika testování pokrývá sotva 10 % toho, čeho je schopna – v rámci aktuálního cyklu jej netestujeme.

Očekávané výsledky

Protože oba kandidáti vytvářejí archivy tak či onak, lze jako vodítko použít běžný tar.

Kromě toho vyhodnotíme, jak dobře je optimalizováno ukládání dat na úložném serveru vytvořením záložních kopií obsahujících pouze rozdíl mezi plnou kopií a aktuálním stavem souborů nebo mezi předchozími a aktuálními archivy (přírůstkové, dekrementální atd.) .

Chování při vytváření záloh:

1. Relativně malý počet souborů na serveru úložiště záloh (srovnatelný s počtem záložních kopií nebo velikostí dat v GB), ale jejich velikost je poměrně velká (desítky až stovky megabajtů).
2. Velikost úložiště bude zahrnovat pouze změny – nebudou se ukládat žádné duplikáty, takže velikost úložiště bude menší než u softwaru založeného na rsync.
3. Očekávejte velké zatížení procesoru při použití komprese a/nebo šifrování a pravděpodobně poměrně vysoké zatížení sítě a disku, pokud proces archivace a/nebo šifrování běží na serveru úložiště záloh.

Spusťte následující příkaz jako referenční hodnotu:

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

Výsledky provedení byly následující:

Doba provedení 3m12s. Je vidět, že rychlost je omezena diskovým subsystémem serveru úložiště záloh, jako v příkladu s rsync. Jen trochu rychleji, protože... záznam přejde do jednoho souboru.

Chcete-li také vyhodnotit kompresi, spusťte stejnou možnost, ale povolte kompresi na straně záložního serveru:

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

Výsledky jsou:

Doba provedení 10m11s. Nejpravděpodobnějším úzkým hrdlem je jednoproudový kompresor na přijímací straně.

Stejný příkaz, ale s kompresí přenesenou na server s původními daty, aby se ověřila hypotéza, že úzkým místem je jednovláknový kompresor.

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

Dopadlo to takto:

Doba provedení byla 9m37s. Zatížení jednoho jádra kompresorem je dobře viditelné, protože Rychlost síťového přenosu a zatížení subsystému zdrojového disku jsou podobné.

Chcete-li vyhodnotit šifrování, můžete použít openssl nebo gpg připojením dalšího příkazu openssl nebo gpg v potrubí. Pro referenci bude příkaz jako 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 dopadly takto:

Doba provádění se ukázala být 10m30s, protože na přijímací straně běžely 2 procesy - úzkým hrdlem je opět jednovláknový kompresor plus malá režie šifrování.

UPD: Na žádost bliznezz přidávám testy s pigz. Při použití pouze kompresoru by to trvalo 6m30s, pokud k tomu přidáte i šifrování, bylo by to cca 7m. Pokles ve spodním grafu je nevyprázdněná disková mezipaměť:

Duplicitní testování

Duplicity je pythonový software pro zálohování vytvářením šifrovaných archivů ve formátu tar.

Pro přírůstkové archivy se používá librsync, takže můžete očekávat chování popsané v předchozí příspěvek v seriálu.

Zálohy lze šifrovat a podepisovat pomocí gnupg, což je důležité při používání různých poskytovatelů pro ukládání záloh (s3, backblaze, gdrive atd.)

Podívejme se, jaké jsou výsledky:

Toto jsou výsledky, kterých jsme dosáhli při běhu bez šifrování

rušič vztlaku

Doba trvání každého zkušebního běhu:

Spuštění 1
Spuštění 2
Spuštění 3

16m33s
17m20s
16m30s

8m29s
9m3s
8m45s

5m21s
6m04s
5m53s

A zde jsou výsledky, když je povoleno šifrování gnupg s velikostí klíče 2048 bitů:

Provozní doba na stejných datech, se šifrováním:

Spuštění 1
Spuštění 2
Spuštění 3

17m22s
17m32s
17m28s

8m52s
9m13s
9m3s

5m48s
5m40s
5m30s

Byla uvedena velikost bloku - 512 megabajtů, což je jasně vidět v grafech; Zatížení procesoru ve skutečnosti zůstalo na 50 %, což znamená, že program nevyužívá více než jedno jádro procesoru.

Princip fungování programu je také zcela jasně viditelný: vzali kus dat, zkomprimovali je a poslali na server zálohování, což může být docela pomalé.
Další vlastností je předvídatelná doba běhu programu, která závisí pouze na velikosti změněných dat.

Povolení šifrování sice výrazně nezvýšilo běh programu, ale zvýšilo zatížení procesoru asi o 10 %, což může být docela příjemný bonus.

Bohužel tento program nedokázal správně detekovat situaci s přejmenováním adresáře a výsledná velikost úložiště se ukázala být rovna velikosti změn (tj. všech 18 GB), ale možnost použít nedůvěryhodný server pro zálohování jasně pokrývá toto chování.

Duplicitní testování

Tento software je napsán v C# a běží pomocí sady knihoven od Mono. K dispozici je GUI i CLI verze.

Přibližný seznam hlavních funkcí je podobný duplicitě, včetně různých poskytovatelů zálohovacích úložišť, nicméně na rozdíl od duplicity je většina funkcí dostupná bez nástrojů třetích stran. Zda je to plus nebo mínus, závisí na konkrétním případě, ale pro začátečníky je pravděpodobně snazší mít před sebou seznam všech funkcí najednou, než muset dodatečně instalovat balíčky pro python, jako je případ s duplicitou.

Další malá nuance - program aktivně zapisuje místní databázi sqlite jménem uživatele, který spouští zálohování, takže musíte dodatečně zajistit, aby byla požadovaná databáze správně zadána při každém spuštění procesu pomocí cli. Při práci přes GUI nebo WEBGUI budou detaily před uživatelem skryty.

Podívejme se, jaké indikátory může toto řešení produkovat:

Pokud vypnete šifrování (a WEBGUI to nedoporučuje), výsledky jsou následující:

Provozní doba:

Spuštění 1
Spuštění 2
Spuštění 3

20m43s
20m13s
20m28s

5m21s
5m40s
5m35s

7m36s
7m54s
7m49s

S povoleným šifrováním pomocí aes to vypadá takto:

Provozní doba:

Spuštění 1
Spuštění 2
Spuštění 3

29m9s
30m1s
29m54s

5m29s
6m2s
5m54s

8m44s
9m12s
9m1s

A pokud použijete externí program gnupg, objeví se následující výsledky:

Spuštění 1
Spuštění 2
Spuštění 3

26m6s
26m35s
26m17s

5m20s
5m48s
5m40s

8m12s
8m42s
8m15s

Jak vidíte, program může pracovat v několika vláknech, ale to z něj nedělá produktivnější řešení, a pokud porovnáte práci šifrování, spouští externí program
se ukázalo být rychlejší než použití knihovny ze sady Mono. To může být způsobeno tím, že externí program je více optimalizovaný.

Další vychytávkou byl fakt, že velikost úložiště zabírá přesně tolik, co skutečná změněná data, tzn. duplicati detekoval přejmenování adresáře a vyřešil tuto situaci správně. To lze vidět při spuštění druhého testu.

Celkově docela pozitivní dojmy z programu, včetně toho, že byl docela přátelský k nováčkům.

výsledky

Oba kandidáti pracovali dost pomalu, ale obecně oproti běžnému dehtu je pokrok, alespoň u duplikátů. Cena takového pokroku je také jasná – citelná zátěž
procesor. Obecně neexistují žádné zvláštní odchylky v predikci výsledků.

Závěry

Pokud nemusíte nikam spěchat a navíc máte náhradní procesor, udělá vám kterékoli z uvažovaných řešení, v každém případě bylo vykonáno poměrně hodně práce, která by se neměla opakovat psaním obalových skriptů na tar. . Přítomnost šifrování je velmi nezbytná vlastnost, pokud serveru pro ukládání záložních kopií nelze plně důvěřovat.

Ve srovnání s řešeními založenými rsync - výkon může být několikanásobně horší, přestože ve své čisté formě dehet fungoval o 20-30% rychleji než rsync.
Dochází k úsporám na velikosti úložiště, ale pouze s duplikacemi.

Oznámení

Zálohování, část 1: Proč je zálohování potřeba, přehled metod, technologií
Zálohování, část 2: Kontrola a testování nástrojů zálohování založených na rsync
Zálohování, část 3: Kontrola a testování duplicit, duplicity, deja dup
Zálohování Část 4: Kontrola a testování zbackup, restic, borgbackup
Zálohování, část 5: Testování zálohování bacula a veeam pro linux
Zálohování Část 6: Porovnání nástrojů pro zálohování
Záloha Část 7: Závěry

Autor: Pavel Demkovič

Zdroj: www.habr.com