Tento článek se bude zabývat zálohovacím softwarem, který rozdělením datového toku na samostatné komponenty (kusy) tvoří úložiště.
Komponenty úložiště lze dále komprimovat a šifrovat, a co je nejdůležitější – během opakovaných procesů zálohování – znovu použít.
Záložní kopie v takovém úložišti je pojmenovaný řetězec komponent vzájemně propojených, například na základě různých hashovacích funkcí.
Podobných řešení je několik, já se zaměřím na 3: zbackup, borgbackup a restic.
Očekávané výsledky
Protože všichni žadatelé požadují vytvoření úložiště tak či onak, bude jedním z nejdůležitějších faktorů odhad velikosti úložiště. V ideálním případě by jeho velikost neměla být větší než 13 GB podle přijaté metodiky nebo dokonce méně - za předpokladu dobré optimalizace.
Je také velmi žádoucí mít možnost vytvářet záložní kopie souborů přímo, bez použití archivátorů, jako je tar, a také pracovat s ssh/sftp bez dalších nástrojů, jako je rsync a sshfs.
Chování při vytváření záloh:
- Velikost úložiště bude rovna velikosti změn nebo menší.
- Při použití komprese a/nebo šifrování se očekává velké zatížení CPU a poměrně vysoké zatížení sítě a disku je pravděpodobné, pokud proces archivace a/nebo šifrování běží na záložním úložném serveru.
- Pokud je úložiště poškozeno, pravděpodobně dojde k opožděné chybě jak při vytváření nových záloh, tak při pokusu o obnovení. Je nutné naplánovat další opatření k zajištění integrity úložiště nebo použít vestavěné nástroje pro kontrolu jeho integrity.
Práce s dehtem je brána jako referenční hodnota, jak bylo ukázáno v jednom z předchozích článků.
Testování zbackup
Obecný mechanismus zbackup spočívá v tom, že program najde ve vstupním datovém toku oblasti obsahující stejná data, poté je volitelně zkomprimuje a zašifruje, přičemž každou oblast uloží pouze jednou.
Deduplikace používá 64bitovou kruhovou hashovací funkci s posuvným oknem pro kontrolu shody bajtu po bajtu s existujícími datovými bloky (podobně jako to implementuje rsync).
Vícevláknové lzma a lzo se používají pro kompresi a aes pro šifrování. Nejnovější verze mají 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 unixovou cestou, takže program při vytváření záloh přijímá data na stdin a při obnově produkuje podobný datový tok na stdout. Zbackup tedy může být použit jako velmi dobrý „stavební kámen“ při psaní vlastních zálohovacích řešení. Například autor článku používá tento program jako hlavní zálohovací nástroj pro domácí stroje přibližně od roku 2014.
Datový tok bude běžný tar, pokud není uvedeno jinak.
Podívejme se, jaké jsou výsledky:
Práce byla zkontrolována ve 2 možnostech:
- vytvoří se úložiště a na serveru se se zdrojovými daty spustí zbackup, poté se obsah úložiště přenese na server úložiště záloh.
- na serveru úložiště záloh se vytvoří úložiště, na serveru úložiště záloh se spustí zbackup přes ssh a data se do něj odesílají potrubím.
Výsledky první možnosti 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.
Zatížení serveru původními daty bylo následující (je uveden příklad s lzma; s lzo byl přibližně stejný obrázek, ale podíl rsync byl přibližně čtvrtinový):
Je jasné, že takový proces zálohování je vhodný pouze pro relativně vzácné a malé změny. Je také velmi vhodné omezit zbackup na 1 vlákno, jinak bude velmi vysoké zatížení CPU, protože Program je velmi dobrý v práci ve více vláknech. Zatížení disku bylo malé, což by obecně u moderního diskového subsystému založeného na ssd nebylo patrné. Jasně je také vidět začátek procesu synchronizace dat úložiště na vzdálený server, rychlost provozu je srovnatelná s běžným rsync a závisí na výkonu diskového subsystému serveru úložiště záloh. Nevýhodou tohoto přístupu je uložení lokálního úložiště a v důsledku toho duplikace dat.
Zajímavější a v praxi použitelná je druhá možnost, spuštění zbackup přímo na serveru úložiště záloh.
Nejprve otestujeme provoz bez použití šifrování pomocí kompresoru lzma:
Doba trvání každého zkušebního běhu:
Spuštění 1
Spuštění 2
Spuštění 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Pokud povolíte šifrování pomocí aes, výsledky jsou docela blízko:
Provozní doba 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 je šifrování kombinováno s kompresí pomocí lzo, vypadá to takto:
Provozní doba:
Spuštění 1
Spuštění 2
Spuštění 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Velikost výsledného úložiště byla relativně stejná, a to 13 GB. To znamená, že deduplikace funguje správně. Také na již komprimovaných datech dává použití lzo znatelný efekt; pokud jde o celkovou provozní dobu, zbackup se blíží duplicitě/duplicitě, ale zaostává za těmi založenými na librsync 2-5krát.
Výhody jsou zřejmé – úspora místa na disku na serveru úložiště záloh. Pokud jde o nástroje pro kontrolu úložiště, autor zbackup je neposkytuje, doporučuje se použít diskové pole odolné proti chybám nebo poskytovatel cloudu.
Celkově velmi dobrý dojem i přes to, že projekt cca 3 roky stojí na místě (poslední požadavek na funkci byl asi před rokem, ale bez odezvy).
Testování borgbackup
Borgbackup je fork of attic, další systém podobný zbackupu. Napsaný v pythonu má seznam schopností podobný zbackup, ale navíc může:
- Namontujte zálohy přes pojistku
- Zkontrolujte obsah úložiště
- Pracujte v režimu klient-server
- Pro data používejte různé kompresory a také heuristické určení typu souboru při jeho komprimaci.
- 2 možnosti šifrování, aes a blake
- Vestavěný nástroj pro
kontroly výkonu
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Výsledky byly následující:
CZ-BIG 96.51 MB/s (10 100.00 MB úplné nulové soubory: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB úplné nulové soubory: 17.48 s)
UZ-BIG 253.63 MB/s (10 100.00 MB úplné nulové soubory: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB úplné nulové soubory: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB náhodné soubory: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB náhodné soubory: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB náhodné soubory: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB náhodné soubory: 13.77 s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB úplné nulové soubory: 9.21 s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB úplné nulové soubory: 13.13 s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB úplné nulové soubory: 3.02 s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB úplné nulové soubory: 2.58 s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB náhodné soubory: 26.45 s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB náhodné soubory: 14.51 s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB náhodné soubory: 2.88 s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB náhodné soubory: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 XNUMX 10.00 kB všechny nulové soubory: 8.53 s)
RZ-SMALL 32.57 MB/s (10000 XNUMX 10.00 kB všechny nulové soubory: 3.07 s)
UZ-SMALL 19.37 MB/s (10000 XNUMX 10.00 kB všechny nulové soubory: 5.16 s)
DZ-SMALL 33.71 MB/s (10000 XNUMX 10.00 kB všechny nulové soubory: 2.97 s)
CR-SMALL 6.85 MB/s (10000 XNUMX 10.00 kB náhodné soubory: 14.60 s)
RR-SMALL 31.27 MB/s (10000 XNUMX 10.00 kB náhodné soubory: 3.20 s)
UR-SMALL 12.28 MB/s (10000 XNUMX 10.00 kB náhodné soubory: 8.14 s)
DR-SMALL 18.78 MB/s (10000 XNUMX 10.00 kB náhodné soubory: 5.32 s)
Při testování se k určení typu souboru použije heuristika komprese (automatická komprese) a výsledky budou následující:
Nejprve se podívejme, jak to funguje bez šifrování:
Provozní doba:
Spuštění 1
Spuštění 2
Spuštění 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Pokud povolíte autorizaci úložiště (autentizovaný režim), výsledky budou blízko:
Provozní doba:
Spuštění 1
Spuštění 2
Spuštění 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Když bylo aktivováno šifrování aes, výsledky se 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íte aes na blake, situace se úplně zlepší:
Provozní doba:
Spuštění 1
Spuštění 2
Spuštění 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Stejně jako v případě zbackupu byla velikost úložiště 13GB a ještě o něco méně, což se obecně očekává. S dobou běhu jsem byl velmi spokojen, je srovnatelná s řešeními založenými na librsync, poskytuje mnohem širší možnosti. Potěšila mě také možnost nastavení různých parametrů prostřednictvím proměnných prostředí, což dává velmi vážnou výhodu při použití borgbackup v automatickém režimu. Potěšila mě i zátěž při zálohování: soudě podle zátěže procesoru borgbackup funguje v 1 vláknu.
Při používání nebyly žádné zvláštní nevýhody.
restické testování
Navzdory skutečnosti, že restic je poměrně nové řešení (první 2 kandidáti byli známi již v roce 2013 a starší), má docela dobré vlastnosti. Napsáno v Go.
Ve srovnání se zbackup navíc poskytuje:
- Kontrola integrity úložiště (včetně kontroly dílů).
- Obrovský seznam podporovaných protokolů a poskytovatelů pro ukládání záloh a také podpora rclone - rsync pro cloudová řešení.
- Porovnání 2 záloh mezi sebou.
- Montáž úložiště přes pojistku.
Obecně se výčet funkcí blíží borgbackupu, někde více, jinde méně. Jednou z funkcí je, že neexistuje způsob, jak zakázat šifrování, a proto budou zálohy vždy šifrovány. Podívejme se v praxi, co lze z tohoto softwaru vymáčknout:
Výsledky byly následující:
Provozní doba:
Spuštění 1
Spuštění 2
Spuštění 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Výsledky výkonu jsou také srovnatelné s řešeními založenými na rsync a obecně velmi blízké borgbackup, ale zatížení CPU je vyšší (běží více vláken) a pilovité.
Program je s největší pravděpodobností omezen výkonem diskového subsystému na serveru pro ukládání dat, jak tomu již bylo u rsync. Velikost úložiště byla 13 GB, stejně jako zbackup nebo borgbackup, při použití tohoto řešení nebyly žádné zjevné nevýhody.
výsledky
Ve skutečnosti všichni kandidáti dosáhli podobných výsledků, ale za různé ceny. Borgbackup fungoval nejlépe ze všech, restic byl trochu pomalejší, zbackup se pravděpodobně nevyplatí používat,
a pokud se již používá, zkuste jej změnit na borgbackup nebo restic.
Závěry
Nejslibnější řešení se zdá být restické, protože... je to on, kdo má nejlepší poměr schopností k provozní rychlosti, ale neukvapujme se zatím k obecným závěrům.
Borgbackup v podstatě není horší, ale zbackup je asi lepší nahradit. Je pravda, že zbackup lze stále použít k zajištění fungování pravidla 3-2-1. Například kromě zálohovacích zařízení na bázi (lib)rsync.
Oznámení
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