V tomto článku se zabýváme zálohovacími nástroji, které provádějí zálohu vytvářením archivu na záložním serveru.
Z těch, které splňují požadavky, jsou duplicity (k němuž existuje příjemné 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 % z toho, co dokáže — v rámci aktuálního cyklu ho netestujeme.
Očekávané výsledky
Protože oba kandidáti nějakým způsobem vytvářejí archivy, lze jako orientační bod použít běžný tar.
Dále zhodnotíme, jak dobře se optimalizuje ukládání dat na serveru zálohování tím, že vytvoříme zálohy obsahující pouze rozdíl mezi plnou kopií a aktuálním stavem souborů, nebo mezi minulými a současnými archivy (inkrementální, dekrementální atd.).
Chování při vytváření záloh:
- Relativně malé množství souborů na serveru zálohování (srovnatelné s počtem záloh nebo velikostí dat v GB), ale jejich velikost je dostatečně velká (desítky až stovky megabajtů).
- Velikost repozitáře bude zahrnovat pouze změny — duplicity nebudou ukládány, takže velikost repozitáře bude menší, než při práci softwaru založeného na rsync.
- Očekává se vysoké zatížení procesoru při používání komprese a/nebo šifrování, stejně jako pravděpodobně dost velké zatížení sítě a diskového subsystému, pokud bude proces archivace a/nebo šifrování probíhat na serveru zálohování.
Jako referenční hodnotu spustíme následující příkaz:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Výsledky provedení byly následující:
Doba provádění 3m12s. Je zřejmé, že rychlost narazila na diskový subsystém serveru zálohování, stejně jako v příkladu s . Jen o něco rychleji, protože zápis jde do jednoho souboru.
Také pro posouzení komprese spustíme stejnou variantu, ale zahrneme kompresi na straně serveru zálohování:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Výsledky jsou následující:
Doba provádění 10m11s. Pravděpodobně největší slabinou je jednovláknový kompresor na přijímající straně.
Stejný příkaz, ale s přenosem komprese na server s původními daty pro ověření hypotézy, že úzkým hrdlem je jednoúčelový komprektor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Vyšlo to takto:
Doba provedení byla 9m37s. Jasně je vidět zatížení jednoho jádra kompresorem, protože rychlost přenosu přes síť a zatížení diskového subsystému zdroje jsou podobné.
Pro vyhodnocení šifrování můžete použít openssl nebo gpg, připojením dalšího příkazu openssl nebo gpg do pipe. Pro orientaci bude takový příkaz:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Výsledky byly následující:
Doba provedení byla 10m30s, protože běžely 2 procesy na přijímací straně — úzkým hrdlem opět byl jednoúčelový komprektor, plus malé režijní náklady na šifrování.
UPD: Na žádost bliznezz přidávám testy s pigz. Pokud se použije pouze komprektor — trvalo to 6m30s, pokud přidáme také šifrování — přibližně 7m. Propad na dolním grafu — nesmazaný diskový cache:
Testování duplicity
Duplicity je software v pythonu pro zálohování pomocí vytváření šifrovaných archivů ve formátu tar.
Pro inkrementální archivy se používá librsync, což znamená, že lze očekávat chování popsané v .
Zálohy mohou být šifrovány a podepisovány pomocí gnupg, což je důležité při používání různých poskytovatelů pro uložení záloh (s3, backblaze, gdrive atd.)
Podívejme se, jaké budou výsledky:
Takovéto výsledky byly získány při spuštění bez šifrování
spoiler
Doba běhu každého testovacího spuštění:
Spuštění 1
Spuštění 2
Spuštění 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
A tady jsou výsledky při zapnutí šifrování gnupg, s velikostí klíče 2048 bitů:
Doba provozu 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 na grafech; zatížení procesoru se vlastně drželo na úrovni 50%, což znamená, že program využívá méně než jedno procesorové jádro.
Také je dobře vidět princip činnosti programu: vzali jsme kousek dat, zkomprimovali ho, poslali na server pro ukládání záloh, který může být dost pomalý.
Další zvláštností je předvídatelný čas práce programu, který závisí pouze na velikosti změněných dat.
Zapnutí šifrování nezvýšilo dobu běhu programu příliš, ale zatížení procesoru se zvýšilo přibližně o 10 %, což může být velmi příjemný bonus.
Bohužel, tento program nedokázal správně detekovat situaci s přejmenováním adresáře, a tak výsledná velikost repozitáře byla rovna velikosti změn (tj. všech 18 GB), avšak možnost používání nedůvěryhodného serveru pro zálohování určitě převažuje nad takovým chováním.
Testování duplicati
Tento software je napsán v C#, běží s využitím knihoven Mono. Disponuje GUI i CLI verzí.
Předběžný seznam hlavních funkcí je podobný jako u duplicity, včetně různých poskytovatelů pro ukládání záloh, avšak na rozdíl od duplicity, většina funkcí je dostupná bez dalších prostředků. To může být plus nebo minus — závisí na konkrétní situaci, ale pro nováčky je pravděpodobně jednodušší mít před očima seznam všech funkcí hned, než instalovat balíčky pro Python, jak je tomu u duplicity.
Další malý detail — program aktivně zapisuje lokální databázi SQLite jménem toho uživatele, který spouští zálohování, takže je třeba dodatečně dbát na správné určení požadované databáze při každém spuštění procesu pomocí CLI. Při práci přes GUI nebo WEBGUI budou detaily uživateli skryty.
Podívejme se, jaké ukazatele může toto řešení poskytnout:
Pokud vypnete šifrování (což WEBGUI nedoporučuje), výsledky jsou následující:
Doba trvání:
Spuštění 1
Spuštění 2
Spuštění 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Se zapnutým šifrováním, používající AES, vypadá to takto:
Doba trvání:
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, vyjdou takovéto výsledky:
Spuštění 1
Spuštění 2
Spuštění 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Jak je vidět, program umí pracovat ve více vláknech, ale z toho důvodu se nestává výkonnějším řešením, a pokud porovnáme práci šifrování — spuštění externího programu
bylo rychlejší než použití knihovny z balíčku Mono. Možná je to způsobeno tím, že externí program je lépe optimalizovaný.
Příjemným momentem bylo také to, že velikost úložiště zabírá přesně tolik, kolik bylo skutečně změněných dat, tzn. duplicati rozpoznal přejmenování složky a správně tuto situaci zpracoval. To lze vidět při provedení druhého testu.
Celkově mám z programu velmi pozitivní dojem, včetně dostatečné přívětivosti pro začátečníky.
Výsledky
Oba kandidáti pracovaly dost pomalu, ale celkově, ve srovnání s běžným tar, je pokrok patrný, alespoň u duplicati. Cena takového pokroku je také jasná - znatelná zátěž
procesoru. Celkově neexistují žádné zvláštní odchylky při předpovídání výsledků.
Závěry
Pokud není potřeba spěchat a je dostatek výkonu procesoru - vyhovuje jakékoli z prozkoumaných řešení, v každém případě byla odvedena dost velká práce, kterou není třeba opakovat psaním skriptů na vrstvu nad tar. Přítomnost šifrování je velmi užitečná vlastnost, pokud server pro ukládání záloh není plně důvěryhodný.
Pokud porovnáme s řešeními na bázi výkon může být horší několikrát, i když v čisté verzi tar fungoval rychleji než rsync o 20-30%.
Úspora na velikosti úložiště je, ale pouze u duplicati.
Oznámení
Zálohování, část 3: Přehled a testování duplicity, duplicati, deja dup
Zálohování, část 4: Přehled a testování zbackup, restic, borgbackup
Zálohování, část 5: Testování Bacula a Veeam Backup pro Linux
Zálohování, část 6: Srovnání nástrojů pro zálohování
Zálohování, část 7: Závěry
Autor publikace: Pavel Demkovič
Zdroj: habr.com
