V tomto článku bude provedeno srovnání zálohovacích nástrojů, ale nejprve je dobré zjistit, jak rychle a efektivně dokážou obnovit data ze záloh.
Pro zjednodušení srovnání bude posuzováno obnovení z úplné zálohy, zejména proto, že tento režim podporují všichni kandidáti. Pro přehlednost byly čísla průměrná (aritmetický průměr z několika spuštění). Výsledky budou shrnuty do tabulky, která také bude obsahovat informace o funkcích: přítomnost webového rozhraní, snadnost nastavení a používání, schopnost automatizace, různé další možnosti (například kontrola integrity dat) atd. Grafy ukáží zatížení serveru, kde budou data aplikována (nikoli serveru pro ukládání záloh).
Obnova dat
Jako základní bod budou použity rsync a tar, protože nejjednodušší skripty pro vytváření záloh.
Rsync splnil testovací datový set za 4 minuty a 28 sekund, přičemž ukázal
takové zatížení.
Proces obnovy narazil na omezení diskového subsystému serveru pro ukládání záloh (zubaté grafy). Také je jasně vidět zatížení jednoho jádra bez zvláštních problémů (nízké iowait a softirq — žádné problémy s diskem a sítí). Vzhledem k tomu, že dvě další programy, a sice rdiff-backup a rsnapshot, jsou založené na rsync a také nabízejí jako prostředek obnovy běžný rsync, budou mít přibližně stejný profil zatížení a dobu obnovy zálohy.
Tar se vypořádal o něco rychleji, za
2 minuty a 43 sekund:
Celkové zatížení systému bylo v průměru o 20% vyšší kvůli zvýšenému softirq — zvýšily se režijní náklady při práci síťového subsystému.
Pokud bude archiv navíc komprimován, pak doba obnovy naroste na 3 minuty 19 sekund s
takovým zatížením na hlavním serveru (rozbalení na straně hlavního serveru):
Proces rozbalování využívá jádra obou procesorů, protože běží dva procesy. Celkově se jedná o očekávaný výsledek. Také srovnatelný výsledek (3 minuty a 20 sekund) byl dosažen při spuštění gzip na straně serveru s zálohami, zatížení na hlavním serveru bylo velmi podobné spuštění tar bez kompresoru gzip (viz předchozí graf).
V rdiff-backup poslední vytvořenou zálohu lze synchronizovat pomocí standardního rsync (výsledky budou podobné), ale starší zálohy je nutné obnovit pomocí programu rdiff-backup, který se s obnovou vypořádal za 17 minut a 17 sekund, ukazujíc
takové zatížení:
Možná to tak bylo zamýšleno, v každém případě pro omezení rychlosti autoři . Samotný proces obnovy zálohy trvá o něco méně než polovinu jednoho jádra, s proporcionálně srovnatelným výkonem (tj. 2-5krát pomaleji) při zátěži na disku a síti ve srovnání s rsync.
Rsnapshot pro obnovu doporučuje použít standardní rsync, takže jeho výsledky budou také podobné. Celkově to tak skutečně dopadlo.
Burp se úkolu obnovy zálohy zhostil za 7 minut a 2 sekundy s
takovým zatížením:
Pracoval dostatečně rychle, a alespoň mnohem pohodlněji než čistý rsync: není třeba pamatovat žádné příznaky, jednoduché a intuitivní cli rozhraní, vestavěná podpora několika kopií — pravda, dvakrát pomalejší. Pokud je třeba obnovit data z poslední vytvořené zálohy — lze využít rsync, s menšími výhradami.
Přibližně stejnou rychlost a zátěž ukázal program BackupPC při zapnutí režimu přenosu rsync, rozbalujíc zálohu za
7 minut a 42 sekund:
Ale v režimu přenosu dat s tar se BackupPC vypořádal pomaleji: za 12 minut a 15 sekund, zatížení CPU přitom bylo celkově nižší
o půl druhého:
Duplicity bez šifrování ukázal o něco lepší výsledky, zvládl obnovení zálohy za 10 minut a 58 sekund. Pokud aktivujete šifrování pomocí gpg — čas obnovení se zvyšuje na 15 minut a 3 sekundy. Při vytváření repozitáře pro ukládání kopií můžete také uvést velikost archivu, který bude použit při rozdělování toku příchozích dat. Celkově, na běžných pevných discích, také ve spojení s jednovláknovým režimem práce, není výrazný rozdíl. Ten se možná objeví při různých velikostech bloků, když jsou použita hybridní úložiště. Zátěž na hlavním serveru při obnovení byla následující:
bez šifrování
se šifrováním
Duplicati ukázal srovnatelnou rychlost obnovení, zvládl to za 13 minut a 45 sekund. Dalších přibližně 5 minut trvalo ověření správnosti obnovených dat (celkem asi 19 minut). Zatížení bylo
dostatečně vysoké:
Když bylo šifrování aes aktivováno interními prostředky, čas obnovení činil 21 minut a 40 sekund, přičemž zatížení procesoru bylo maximální (oba jádra!) během obnovení; při kontrole dat byl aktivní pouze jeden vláknový proces, zabírající jedno procesorové jádro. Ověření dat po obnovení trvalo stejné 5 minut (celkem skoro 27 minut).
Výsledek
O něco rychleji duplicati zvládlo obnovení při použití externího programu gpg pro šifrování, ale v celku jsou rozdíly oproti předchozímu režimu minimální. Doba práce činila 16 minut a 30 sekund, s ověřením dat v 6 minutách. Zatížení bylo
takové:
AMANDA, využívající tar, zvládla to za 2 minuty a 49 sekund, což je v podstatě velmi blízko běžnému tar. Zatížení systému je v podstatě
stejné:
Při obnovení zálohy prostředky zbackup byly následující výsledky:
šifrování, komprese lzma
Doba práce 11 minut a 8 sekund
šifrování aes, komprese lzma
Doba práce 14 minut
šifrování aes, komprese lzo
Doba práce 6 minut, 19 sekund
Celkově, docela dobré. Vše závisí na rychlosti procesoru na serveru pro zálohování, což se jasně projevuje na době práce programu s různými kompresory. Na straně serveru pro zálohování běžel obvyklý tar, takže pokud to srovnáme s ním — obnova probíhá třikrát pomaleji. Možná by stálo za to zkontrolovat práci v multithreadovém režimu, s počtem vláken vyšším než dvě.
BorgBackup v režimu bez šifrování se mu podařilo o něco pomaleji než tar, za 2 minuty 45 sekund, nicméně, na rozdíl od téhož tar, se objevila možnost deduplikace repozitáře. Zátěž byla přitom
následující:
Pokud aktivujete šifrování na základě blake, rychlost obnovy zálohy se mírně zpomaluje. Doba obnovy v tomto režimu je 3 minuty 19 sekund, a zátěž byla
taková:
Šifrování aes funguje o něco pomaleji, doba obnovy je 3 minuty 23 sekund, zátěž se příliš
nezměnila:
Jelikož Borg může pracovat v multithreadovém režimu — zatížení procesoru je maximální, přičemž při aktivaci dalších funkcí se jen prodlužuje doba práce. Zjevně stojí za to prozkoumat multithreadovou práci podobně jako zbackup.
Restic se svou obnovou vypořádal o něco pomaleji, doba práce činila 4 minuty 28 sekund. Zátěž vypadala
takto:
Zřejmě proces obnovy pracuje ve více vláknech, ale efektivita není tak vysoká jako u BorgBackup, ale časově je srovnatelná s obvyklým rsync.
Pomocí UrBackup se podařilo obnovit data za 8 minut a 19 sekund, přičemž zátěž byla
takové:
Pořád je vidět, že zátěž není příliš vysoká, dokonce i nižší než u tar. Příležitostně špičky, ale ne více než zatížení jednoho jádra.
Výběr a odůvodnění kritérií pro srovnání
Jak bylo uvedeno v jednom z předchozích článků, zálohovací systém by měl splňovat následující kritéria:
- Snadnost použití
- Univerzálnost
- Stabilita
- Rychlost
Stojí za to prozkoumat každý bod podrobněji.
Jednoduchost použití
Nejlépe je, když je k dispozici jedno tlačítko „Udělaj vše správně“, ale pokud se vrátíme k reálným programům — nejpohodlnější bude nějaký obvyklý a standardní princip práce.
Většině uživatelů se pravděpodobně bude lépe, pokud nebudou muset pamatovat řadu klíčů pro CLI, nastavovat různé, často málo srozumitelné možnosti prostřednictvím webu nebo TUI, a nastavovat upozornění na neúspěšnou práci. Sem patří také možnost snadno "zapracovat" řešení pro zálohování do stávající infrastruktury, stejně jako automatizace procesu zálohování. Dále je zde možnost instalace pomocí správce balíčků, nebo pomocí jednoho či dvou příkazů typu "stáhnout a rozbalit." curl odkaz | sudo bash — složitá metoda, protože je třeba zkontrolovat, co přichází z odkazu.
Například z prozkoumaných kandidátů je jednoduchým řešením burp, rdiff-backup a restic, které mají mnemotechnicky zapamatovatelné klíče pro různé pracovní režimy. O něco složitější jsou borg a duplicity. Nejsložitější byla AMANDA. Ostatní jsou co do jednoduchosti použití někde uprostřed. V každém případě, pokud potřebujete více než 30 sekund na přečtení uživatelské příručky, nebo musíte hledat v Googlu nebo jiném vyhledávači, a také procházet dlouhý příspěvek nápovědy — řešení je složité, ať už to vezmete jakkoli.
Některé z prozkoumaných kandidátů umí automaticky posílat zprávy e-mailem/jabber, jiné se spoléhají na nastavená upozornění v systému. Ale často složité řešení má ne zcela zřejmá nastavení upozornění. V každém případě, pokud program pro zálohování vrátí nenulový kód návratu, který systémová služba periodických úloh správně pochopí (odeslat zprávu systémovému administrátorovi nebo ihned do monitorování) — situace je jednoduchá. Pokud však systém zálohování, který nefunguje na serveru pro zálohování, nemůže bez nastavení zjevným způsobem oznámit problém — složitost je už nadměrná. V každém případě je vydávání upozornění a dalších zpráv pouze do webového rozhraní nebo do protokolu — špatná praxe, protože většinou budou ignorovány.
Pokud jde o automatizaci — jednoduchý program umí číst proměnné prostředí, které určují jeho pracovní režim, nebo má rozvinuté CLI, schopné plně duplikovat chování při práci prostřednictvím webového rozhraní, například. Sem patří také možnost proudové práce, možnosti rozšíření atd.
Univerzálnost
Částečně se překrývá s předchozí sekcí týkající se automatizace, neměl by být problém "začlenit" proces zálohování do stávající infrastruktury.
Je třeba poznamenat, že používání nestandardních portů (kromě webového rozhraní) pro funkci, implementace šifrování nestandardním způsobem, výměna dat nestandardním protokolem — příznaky neuniverzálního řešení. Většina kandidátů je má z jasného důvodu: jednoduchost a univerzálnost obvykle nejsou slučitelné. Jako výjimka — burp, existují i další.
Jako znak — možnost práce pomocí běžného ssh.
Rychlost práce
Nejdiskutabilnější a nejspornější bod. Na jedné straně — spuštěný proces, který pracoval maximálně rychle a nebrání hlavním úkolům. Na druhé straně — výkyv provozu a zátěže na procesoru při zálohování. Je také třeba poznamenat, že nejrychlejší programy pro zálohování jsou obvykle nejchudší na funkce důležité pro uživatele. Opět: pokud pro to, abyste získali jeden nešťastný textový soubor velikosti několika desítek bajtů s heslem, a kvůli němu stojí celý servis (ano, chápu, že zde proces zálohování není často viníkem), a musíte projít všechny soubory v repozitáři nebo rozbalit celé archivy — systém zálohování rozhodně není rychlý. Další bod, který se často stává kamenem úrazu — rychlost obnovy zálohy z archivu. Zde mají jasnou výhodu ti, kteří mohou jednoduše zkopírovat nebo přesunout soubory na požadované místo bez zvláštních manipulací (např. rsync), ale většinou je třeba problém řešit organizačně, empiricky: měřit čas obnovy zálohy a otevřeně o tom informovat uživatele.
Stabilita
Je třeba to chápat takto: na jedné straně by měla být možnost vrátit zálohu zpět bez ohledu na okolnosti, na druhé straně — odolnost vůči různým problémům: výpadek sítě, selhání disku, odstranění části repozitáře.
Srovnání prostředků zálohování
Čas vytvoření kopie
Čas obnovy kopie
Jednoduchá instalace
Jednoduché nastavení
Jednoduché použití
Jednoduchá automatizace
Je potřeba klient-server?
Kontrola integrity úložiště
Diferenciální kopie
Práce přes pipe
Univerzálnost
Nezávislost
Průhlednost úložiště
Šifrování
Kompresce
Deduplikace
Webové rozhraní
Nahrání do cloudu
Podpora Windows
Bod
Rsync
4m15s
4m28s
ano
ne
ne
ne
ano
ne
ne
ano
ne
ano
ano
ne
ne
ne
ne
ne
ano
6
Tar
čistý
3m12s
2m43s
ano
ne
ne
ne
ne
ne
ano
ano
ne
ano
ne
ne
ne
ne
ne
ne
ano
8,5
. Verze ICU jsou – bezvýznamné.
9m37s
3m19s
ano
Rdiff-backup
16m26s
17m17s
ano
ano
ano
ano
ano
ne
ano
ne
ano
ne
ano
ne
ano
ano
ano
ne
ano
11
Rsnapshot
4m19s
4m28s
ano
ano
ano
ano
ne
ne
ano
ne
ano
ne
ano
ne
ne
ano
ano
ne
ano
12,5
Burp
11m9s
7m2s
ano
ne
ano
ano
ano
ano
ano
ne
ano
ano
ne
ne
ano
ne
ano
ne
ano
10,5
Duplicity
žádné šifrování
16m48s
10m58s
ano
ano
ne
ano
ne
ano
ano
ne
ne
ano
ne
ano
ano
ne
ano
ne
ano
11
gpg
17m27s
15m3s
Duplicati
žádné šifrování
20m28s
13m45s
ne
ano
ne
ne
ne
ano
ano
ne
ne
ano
ne
ano
ano
ano
ano
ano
ano
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
Zbackup
žádné šifrování
40m3s
11m8s
ano
ano
ne
ne
ne
ano
ano
ano
ne
ano
ne
ano
ano
ano
ne
ne
ne
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
žádné šifrování
4m7s
2m45s
ano
ano
ano
ano
ano
ano
ano
ano
ano
ano
ne
ano
ano
ano
ano
ne
ano
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
ano
ano
ano
ano
ne
ano
ano
ano
ano
ano
ne
ano
ne
ano
ne
ano
ano
15,5
UrBackup
8m21s
8m19s
ano
ano
ano
ne
ano
ne
ano
ne
ano
ano
ne
ano
ano
ano
ano
ne
ano
12
Amanda
9m3s
2m49s
ano
ne
ne
ano
ano
ano
ano
ne
ano
ano
ano
ano
ano
ne
ano
ano
ano
13
BackupPC
rsync
12m22s
7m42s
ano
ne
ano
ano
ano
ano
ano
ne
ano
ne
ne
ano
ano
ne
ano
ne
ano
10,5
tar
12m34s
12m15s
Legenda tabulky:
- Zelená, doba provozu méně než pět minut, nebo odpověď „Ano“ (kromě sloupce „Potřebuje klient/server?“), 1 bod
- Žlutá, doba provozu pět až deset minut, 0,5 bodu
- Červená, doba provozu více než deset minut, nebo odpověď „Ne“ (kromě sloupce „Potřebuje klient/server?“), 0 bodů
Podle výše uvedené tabulky je nejjednodušším, nejrychlejším a zároveň pohodlným a výkonným nástrojem pro zálohování BorgBackup. Na druhém místě skončil Restic, ostatní zvažované kandidáty se umístily přibližně stejně s rozptylem jeden-dva body na konci.
Děkuji všem, kteří dotáhli cyklus do konce, nabízím diskuzi o možnostech, navrhněte své, pokud máte. S postupem diskuse může být tabulka doplněna.
Výsledkem cyklu bude závěrečný článek, ve kterém se pokusíme vyvést ideální, rychlé a spravovatelné řešení pro zálohování, které umožňuje co nejrychlejší obnovu kopie a zároveň má pokud možno pohodlí a jednoduchost v nastavení a údržbě.
Oznámení
Zálohování, část 6: Srovnání nástrojů pro zálohování
Zálohování, část 7: Závěry
Zdroj: habr.com
