V tomto článku se zaměříme na softwarové nástroje pro zálohování, které rozdělením datového toku na jednotlivé komponenty (chunks) vytvářejí repozitář.
Komponenty repozitáře mohou být také dále komprimovány a šifrovány, a co je nejdůležitější — při opakovaných procesech zálohování mohou být znovu použity.
Záloha v takovém repozitáři je pojmenovaný řetězec vzájemně propojených komponent, například na základě různých hash funkcí.
Existuje několik takových řešení, zaměřím se na 3: zbackup, borgbackup a restic.
Očekávané výsledky
Jelikož všichni kandidáti vyžadují vytvoření repozitáře, jedním z nejdůležitějších faktorů bude hodnocení velikosti repozitáře. Ideálně by jeho velikost neměla překročit 13 GB podle přijaté metodiky, a to ani méně — za podmínky dobré optimalizace.
Také je velmi žádoucí mít možnost vytvářet zálohy souborů přímo, bez použití archivačních nástrojů jako tar, a také pracovat s ssh/sftp bez dodatečných prostředků jako rsync a sshfs.
Chování při vytváření záloh:
- Velikost repozitáře se rovná velikosti změn, nebo je menší.
- Očekává se vysoké zatížení procesoru při použití komprese a/nebo šifrování, a také pravděpodobně značné zatížení sítě a diskového subsystému, pokud proces archivace a/nebo šifrování bude probíhat na serveru pro ukládání záloh.
- Pokud dojde k poškození repozitáře — je pravděpodobná zpožděná chyba jak při vytváření nových záloh, tak při pokusu o obnovení. Je třeba plánovat další opatření k zajištění integrity repozitáře nebo použít integrované prostředky pro kontrolu jeho integrity.
Jako referenční hodnota byla přijata práce s tar, jak bylo ukázáno v jednom z minulých článků.
Testování zbackup
Celkový mechanismus fungování zbackup spočívá v tom, že program nalézá v datovém toku na vstupu oblasti obsahující stejná data, poté je volitelně komprimuje, šifruje a ukládá každou oblast pouze jednou.
Pro deduplikaci se používá 64bitová kruhová hash funkce se skluzybraným oknem pro byte-by-byte porovnání s již existujícími bloky dat (podobně jako je to realizováno v rsync).
Pro kompresi se používá lzma a lzo v multi-threadovém provedení a pro šifrování — aes. V posledních verzích je také možnost v budoucnu odstranit stará data z úložiště.
Program je napsán v C++ s minimálními závislostmi. Autor se zřejmě inspiroval unixovým způsobem, takže program přijímá data na stdin při vytváření záloh a vydává podobný datový tok na stdout při obnově. Zároveň lze zbackup využít jako velmi dobrou "kamenou" součást při vytváření vlastních řešení zálohování. Například autor článku tuto aplikaci používá jako hlavní prostředek zálohování pro domácí počítače přibližně od roku 2014.
Jako datový tok bude použit běžný tar, pokud nebude uvedeno jinak.
Podívejme se, jaké budou výsledky:
Testování probíhalo ve 2 variantách:
- vytvoří se úložiště a spustí se zbackup na serveru s původními daty, poté se obsah úložiště přenáší na server pro ukládání záloh.
- vytvoří se úložiště na serveru pro ukládání záloh, spustí se zbackup přes ssh na serveru pro ukládání záloh, kterému se přes pipe předávají data.
Výsledky první varianty byly následující: 43m11s — při použití nešifrovaného úložiště a kompresoru lzma, 19m13s — při výměně kompresoru za lzo.
Zátěž na serveru s původními daty byla následující (ukázka s lzma, s lzo byla zhruba stejná situace, ale podíl rsync byl přibližně čtvrtina času):
Je jasně vidět, že takový proces zálohování je vhodný pouze při relativně vzácných a malých změnách. Také je velmi žádoucí omezit práci zbackup na 1 vlákno, jinak bude zátěž na procesor velmi vysoká, protože program umí velmi dobře pracovat ve více vláknech. Zátěž na disk byla malá, což v současnosti s diskovými subsystémy na bázi SSD nebude viditelné. Také je jasně vidět spuštění procesu synchronizace dat úložiště na vzdálený server, rychlost práce je srovnatelná s běžným rsync a uvízla v výkonu diskového subsystému serveru pro ukládání záloh. Nevýhodou tohoto přístupu je uchovávání místního úložiště a tím pádem — duplicita dat.
Druhý variant, kdy se zbackup spustí přímo na serveru pro ukládání záloh, je zajímavější a praktičtější.
Nejprve bude zkontrolována funkčnost bez použití šifrování s kompresorem lzma:
Doba běhu každého testovacího spuštění:
Spuštění 1
Spuštění 2
Spuštění 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Pokud se aktivuje šifrování pomocí aes, výsledky jsou dost podobné:
Doba provozu na stejných datech se šifrováním:
Spuštění 1
Spuštění 2
Spuštění 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Pokud se šifrování spojí se zpracováním na lzo, výsledek je následující:
Doba trvání:
Spuštění 1
Spuštění 2
Spuštění 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
Velikost výsledného repozitáře byla relativně stejná a činila 13 GB. To znamená, že deduplikace funguje správně. Také aplikace lzo na již komprimovaných datech má značný efekt; celkový čas práce zbackup se přibližuje duplicity/duplicati, avšak zaostává za systémy založenými na librsync o 2-5 krát.
Výhody jsou zřejmé – úspora diskového prostoru na serveru pro zálohování. Co se týče nástrojů pro kontrolu repozitáře – autorem zbackup nejsou předpokládány, doporučuje se používat odolný diskový pole nebo cloudového poskytovatele.
Celkově zanechává velmi dobrý dojem, i přesto, že projekt už asi 3 roky stagnuje (poslední požadavek na nové funkce byl před rokem, ale bez odpovědi).
Testování borgbackup
Borgbackup je fork attic, další podobný systém k zbackup. Napsán v pythonu, má podobný seznam funkcí jako zbackup, ale navíc umí:
Zmountovat zálohy přes fuse
- Kontrolovat obsah repozitáře
- Pracovat v klient-server režimu
- Použít různé kompresory pro data a také heuristicky určovat typ souboru při jeho kompresi.
- 2 varianty šifrování, aes a blake
- Vestavěný nástroj pro
- kontrolu výkonu
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Výsledky dopadly takto:
C-Z-BIG 96.51 MB/s (10
100.00 MB all-zero files: 10.36s) R-Z-BIG 57.22 MB/s (10
100.00 MB all-zero files: 17.48s) U-Z-BIG 253.63 MB/s (10
100.00 MB all-zero files: 3.94s) D-Z-BIG 351.06 MB/s (10
100.00 MB all-zero files: 2.85s) C-R-BIG 34.30 MB/s (10
100.00 MB random files: 29.15s) R-R-BIG 60.69 MB/s (10
100.00 MB random files: 16.48s) U-R-BIG 311.06 MB/s (10
100.00 MB random files: 3.21s) D-R-BIG 72.63 MB/s (10
100.00 MB random files: 13.77s) C-Z-MEDIUM 108.59 MB/s (1000
1.00 MB all-zero files: 9.21s) R-Z-MEDIUM 76.16 MB/s (1000
1.00 MB all-zero files: 13.13s) U-Z-MEDIUM 331.27 MB/s (1000
1.00 MB all-zero files: 3.02s) D-Z-MEDIUM 387.36 MB/s (1000
1.00 MB all-zero files: 2.58s) C-R-MEDIUM 37.80 MB/s (1000
1.00 MB random files: 26.45s) 1.00 MB random files: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB náhodné soubory: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB náhodné soubory: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB náhodné soubory: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB všechny nuly: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB všechny nuly: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB všechny nuly: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB všechny nuly: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB náhodné soubory: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB náhodné soubory: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB náhodné soubory: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB náhodné soubory: 5.32s)
Při testování bude použita heuristika při kompresi s určením typu souboru (compression auto) a výsledky budou následující:
Nejprve zkontrolujme funkci bez šifrování:
Doba trvání:
Spuštění 1
Spuštění 2
Spuštění 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Pokud povolíme autorizaci repozitáře (režim authenticated), výsledky budou podobné:
Doba trvání:
Spuštění 1
Spuštění 2
Spuštění 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Při aktivaci šifrování aes se výsledky příliš nezhoršily:
Spuštění 1
Spuštění 2
Spuštění 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
A pokud změníme aes na blake, situace se dokonce zlepší:
Doba trvání:
Spuštění 1
Spuštění 2
Spuštění 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Jak je tomu u zbackup, velikost repozitáře byla 13 GB a dokonce o něco méně, což je celkem očekávané. Velmi potěšilo časové vyhodnocení, které je srovnatelné s řešeními na bázi librsync, poskytující mnohem širší možnosti. Také potěšila možnost zadání různých parametrů prostřednictvím proměnných prostředí, což poskytuje vážnou výhodu při používání borgbackup v automatickém režimu. Také potěšila zátěž při zálohování: podle zátěže procesoru — borgbackup funguje v 1 vláknu.
Při používání nebyly zjištěny žádné zvláštní nevýhody.
Testování restic
I když je restic poměrně nové řešení (první 2 kandidáti byli známí už od roku 2013 a starší), má velmi dobré vlastnosti. Napsáno v Go.
Pokud to srovnáme se zbackup, navíc poskytuje:
- Kontrolu integrity repozitáře (včetně kontroly po částech).
- Obrovský seznam podporovaných protokolů a poskytovatelů pro uložení záloh, stejně jako podporu rclone — rsync pro "cloudové" řešení.
- Srovnání 2 záloh mezi sebou.
- Přimontování repozitáře přes fuse.
Celkově je seznam možností dost blízký k borgbackup, někde více, někde méně. Z rysů — absence možnosti vypnutí šifrování, a tudíž, zálohy budou vždy zašifrované. Pojďme se podívat na praktické využití tohoto SW:
Výsledky jsou následující:
Doba trvání:
Spuštění 1
Spuštění 2
Spuštění 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Výsledky práce jsou také srovnatelné s řešeními založenými na rsync a celkově jsou velmi blízké borgbackup, avšak zátěž na procesor je vyšší (pracuje několik vláken) a podobá se pílovému vzoru.
Pravděpodobně program naráží na výkon diskového subsystému na serveru pro ukládání dat, stejně jako tomu bylo u rsync. Velikost repozitáře byla 13 GB, stejně jako u zbackup nebo borgbackup, výrazné nevýhody používání tohoto řešení nejsou zjištěny.
Výsledky
Všichni kandidáti mají v zásadě podobné výsledky, avšak s různými cenami. Nejlépe se ukázal borgbackup, trochu pomalejší byl restic, zbackup pravděpodobně nemá smysl začínat používat,
a pokud již je používán — zkusit přejít na borgbackup nebo restic.
Závěry
Nejperspektivnějším řešením se zdá být restic, protože má nejlepší poměr možností k rychlosti práce, ale nebudeme spěchat s obecným zhodnocením.
Borgbackup v zásadě není horší, ale zbackup je pravděpodobně lepší nahradit. Přesto pro zajištění fungování pravidla 3-2-1 lze zbackup stále použít. Například jako doplněk k zálohovacím nástrojům založeným na (lib)rsync.
Oznámení
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
