Tento článek porovná zálohovací nástroje, ale nejprve byste měli zjistit, jak rychle a dobře si poradí s obnovou dat ze záloh.
Pro snadné srovnání zvážíme obnovení z úplné zálohy, zejména proto, že všichni kandidáti podporují tento režim provozu. Pro jednoduchost jsou čísla již zprůměrována (aritmetický průměr několika běhů). Výsledky budou shrnuty v tabulce, která bude obsahovat také informace o možnostech: přítomnost webového rozhraní, snadné nastavení a ovládání, možnost automatizace, přítomnost různých doplňkových funkcí (například kontrola integrity dat) , atd. V grafech bude znázorněno zatížení serveru, kde budou data použita (nikoli serveru pro ukládání záložních kopií).
Obnova dat
rsync a tar budou od té doby používány jako referenční bod jednoduché skripty pro vytváření záložních kopií.
Rsync se vypořádal se souborem testovacích dat za 4 minuty a 28 sekund, ukazuje
takovou zátěž
Proces obnovy narazil na omezení diskového subsystému serveru zálohování (pilové grafy). Také můžete bez problémů jasně vidět načítání jednoho jádra (nízký iowait a softirq - žádné problémy s diskem a sítí). Vzhledem k tomu, že další dva programy, konkrétně rdiff-backup a rsnapshot, jsou založeny na rsync a nabízejí také běžný rsync jako nástroj pro obnovu, budou mít přibližně stejný profil zatížení a dobu obnovy zálohy.
Dehet udělal to trochu rychleji
2 minuty a 43 sekund:
Celková zátěž systému byla vyšší v průměru o 20 % díky zvýšenému softirq - zvýšily se režijní náklady při provozu síťového subsystému.
Pokud je archiv dále komprimován, doba obnovy se zvýší na 3 minuty 19 sekund.
s takovým zatížením na hlavním serveru (rozbalení na straně hlavního serveru):
Proces dekomprese zabírá obě jádra procesoru, protože běží dva procesy. Obecně se jedná o očekávaný výsledek. Rovněž srovnatelný výsledek (3 minuty a 20 sekund) byl získán při spuštění gzip na straně serveru se zálohami; profil zatížení na hlavním serveru byl velmi podobný běhu tar bez kompresoru gzip (viz předchozí graf).
В rdiff-backup můžete synchronizovat poslední zálohu, kterou jste vytvořili pomocí běžného rsync (výsledky budou podobné), ale starší zálohy je stále třeba obnovit pomocí programu rdiff-backup, který dokončil obnovu za 17 minut a 17 sekund, ukazuje
tento náklad:
Snad to bylo zamýšleno, alespoň omezit rychlost autorů . Samotný proces obnovy záložní kopie zabere o něco méně než polovinu jednoho jádra, s proporcionálně srovnatelným výkonem (tj. 2-5x pomalejším) na disku a síti s rsync.
Rsnapshot Pro obnovu navrhuje použít běžný rsync, takže jeho výsledky budou podobné. Obecně to dopadlo takto.
Říhnutí Úkol obnovení zálohy jsem dokončil za 7 minut a 2 sekund s
s tímto nákladem:
Fungovalo to docela rychle a přinejmenším je to mnohem pohodlnější než čistý rsync: nemusíte si pamatovat žádné příznaky, jednoduché a intuitivní rozhraní cli, vestavěná podpora pro více kopií – i když je to dvakrát pomalejší. Pokud potřebujete obnovit data z poslední zálohy, kterou jste vytvořili, můžete použít rsync s několika výhradami.
Program ukazoval přibližně stejnou rychlost a zatížení BackupPC při povolení režimu přenosu rsync nasazení zálohy pro
7 minut a 42 sekund:
V režimu přenosu dat se však BackupPC s dehtem vypořádal pomaleji: za 12 minut a 15 sekund bylo zatížení procesoru obecně nižší.
jeden a půl krát:
Neupřímnost bez šifrování vykazoval o něco lepší výsledky, obnovení zálohy za 10 minut a 58 sekund. Pokud aktivujete šifrování pomocí gpg, doba obnovy se zvýší na 15 minut a 3 sekund. Při vytváření úložiště pro ukládání kopií můžete také určit velikost archivu, která bude použita při rozdělování příchozího datového toku. Obecně na běžných pevných discích, také kvůli jednovláknovému provoznímu režimu, není velký rozdíl. Při použití hybridního úložiště se může objevit v různých velikostech bloků. Zatížení hlavního serveru během obnovy bylo následující:
žádné šifrování
se šifrováním
Duplikát vykázala srovnatelnou míru zotavení a dokončila ji za 13 minut a 45 sekund. Kontrola správnosti obnovených dat trvala zhruba dalších 5 minut (celkem cca 19 minut). Náklad byl
docela vysoko:
Když bylo interně povoleno šifrování aes, doba obnovy byla 21 minut 40 sekund, s maximálním využitím CPU (obě jádra!) během obnovy; Při kontrole dat bylo aktivní pouze jedno vlákno, které zabíralo jedno jádro procesoru. Kontrola dat po obnově trvala stejných 5 minut (celkem téměř 27 minut).
Výsledek
duplicati bylo s obnovou o něco rychlejší při použití externího programu gpg pro šifrování, ale obecně jsou rozdíly oproti předchozímu režimu minimální. Doba provozu byla 16 minut 30 sekund, s ověřením dat za 6 minut. Náklad byl
takový:
AMANDA, s použitím dehtu, to dokončil za 2 minuty 49 sekund, což je v zásadě velmi blízké běžnému dehtu. Zatížení systému v principu
stejný:
Při obnově zálohy pomocí zbackup byly získány následující výsledky:
šifrování, komprese lzma
Délka představení 11 minut a 8 sekund
Šifrování AES, komprese lzma
Pracovní doba 14 minut
AES šifrování, lzo komprese
Délka představení 6 minut, 19 sekund
Celkově to není špatné. Vše závisí na rychlosti procesoru na záložním serveru, což je dobře vidět na době běhu programu s různými kompresory. Na straně záložního serveru byl spuštěn běžný tar, takže pokud to srovnáte s ním, obnova je 3krát pomalejší. Možná by stálo za to zkontrolovat operaci ve vícevláknovém režimu s více než dvěma vlákny.
Zálohování Borg v nešifrovaném režimu to bylo o něco pomalejší než tar, za 2 minuty 45 sekund, ale na rozdíl od taru bylo možné úložiště deduplikovat. Náklad se ukázal být
další:
Pokud povolíte šifrování založené na blake, bude rychlost obnovy zálohy o něco nižší. Doba zotavení v tomto režimu je 3 minuty 19 sekund a zátěž je pryč
takhle:
Šifrování AES je o něco pomalejší, doba obnovy je 3 minuty 23 sekund, zátěž je obzvlášť
se nezměnilo:
Vzhledem k tomu, že Borg může pracovat ve vícevláknovém režimu, je zatížení procesoru maximální a při aktivaci dalších funkcí se provozní doba jednoduše prodlouží. Zjevně stojí za to prozkoumat multithreading podobným způsobem jako zbackup.
Venkovský se s obnovou vypořádal o něco pomaleji, provozní doba byla 4 minuty 28 sekund. Náklad vypadal
následovně:
Proces obnovy zřejmě funguje v několika vláknech, ale efektivita není tak vysoká jako u BorgBackup, ale časově srovnatelná s běžným rsync.
S urBackup Obnovit data bylo možné za 8 minut a 19 sekund, zátěž byla
takový:
Zátěž stále není příliš vysoká, dokonce nižší než u dehtu. Místy jsou praskliny, ale ne více než zatížení jednoho jádra.
Výběr a zdůvodnění kritérií pro srovnání
Jak bylo uvedeno v jednom z předchozích článků, zálohovací systém musí splňovat následující kritéria:
- Snadnost použití
- všestrannost
- Stabilita
- Rychle
Stojí za to zvážit každý bod samostatně podrobněji.
Snadné ovládání
Nejlepší je, když existuje jedno tlačítko „Udělejte všechno dobře“, ale pokud se vrátíte ke skutečným programům, bude nejpohodlnější nějaký známý a standardní provozní princip.
Většina uživatelů bude s největší pravděpodobností na tom lépe, když si nebudou muset pamatovat spoustu klíčů pro cli, konfigurovat spoustu různých, často nejasných možností přes web nebo tui, nebo nastavovat upozornění na neúspěšnou operaci. To také zahrnuje schopnost snadno „zasadit“ řešení zálohování do stávající infrastruktury a také automatizaci procesu zálohování. Existuje také možnost instalace pomocí správce balíčků nebo jedním nebo dvěma příkazy jako „stáhnout a rozbalit“. curl ссылка | sudo bash - složitá metoda, protože musíte zkontrolovat, co přichází přes odkaz.
Například z uvažovaných kandidátů je jednoduchým řešením burp, rdiff-backup a restic, které mají mnemotechnické klávesy pro různé provozní režimy. O něco složitější jsou borg a duplicita. Nejtěžší byla AMANDA. Zbytek je z hlediska jednoduchosti použití někde uprostřed. V každém případě, pokud na přečtení uživatelské příručky potřebujete více než 30 sekund, nebo potřebujete přejít na Google či jiný vyhledávač a navíc prolistovat dlouhý list nápovědy, je rozhodování tak či onak těžké.
Někteří z uvažovaných kandidátů jsou schopni automaticky odeslat zprávu přes e-mailjabber, zatímco jiní se spoléhají na nakonfigurovaná upozornění v systému. Navíc většinou složitá řešení mají ne zcela zřejmé nastavení výstrah. V každém případě, pokud zálohovací program vygeneruje nenulový návratový kód, který systémová služba správně pochopí pro periodické úkoly (bude zaslána zpráva správci systému nebo přímo na monitoring) - situace je jednoduchá. Pokud však zálohovací systém, který neběží na záložním serveru, nelze nakonfigurovat, je zřejmé, že o problému lze říci, že složitost je již příliš vysoká. V každém případě je vydávání varování a dalších zpráv pouze do webového rozhraní nebo do protokolu špatným postupem, protože nejčastěji budou ignorovány.
Pokud jde o automatizaci, jednoduchý program umí číst proměnné prostředí, které nastavují jeho provozní režim, nebo má vyvinuté cli, které dokáže zcela duplikovat chování například při práci přes webové rozhraní. Patří sem i možnost nepřetržitého provozu, dostupnost možností rozšíření atp.
všestrannost
V částečném opakování předchozího pododdílu o automatizaci by neměl být zvláštní problém „napasovat“ proces zálohování do stávající infrastruktury.
Za zmínku stojí, že používání nestandardních portů (dobře, kromě webového rozhraní) pro práci, implementace šifrování nestandardním způsobem, výměna dat pomocí nestandardního protokolu jsou znaky nestandardního - univerzální řešení. Většinou je mají všichni kandidáti tak či onak z pochopitelného důvodu: jednoduchost a všestrannost většinou nejdou dohromady. Jako výjimka - říhnutí, existují i další.
Jako znamení - schopnost pracovat pomocí běžného ssh.
Pracovní rychlost
Nejkontroverznější a nejkontroverznější bod. Na jednu stranu jsme proces spustili, fungoval co nejrychleji a nezasahoval do hlavních úkolů. Na druhou stranu během zálohování dochází k prudkému nárůstu provozu a zatížení procesoru. Za zmínku také stojí, že nejrychlejší programy na vytváření kopií jsou většinou ty nejchudší, co se týče funkcí, které jsou pro uživatele důležité. Opět: pokud za účelem získání jednoho nešťastného textového souboru o velikosti několika desítek bajtů s heslem a kvůli tomu stojí celá služba (ano, ano, chápu, že proces zálohování zde většinou není na vině), a musíte znovu sekvenčně přečíst všechny soubory v úložišti nebo rozšířit celý archiv – systém zálohování není nikdy rychlý. Dalším bodem, který se často stává kamenem úrazu, je rychlost nasazení zálohy z archivu. Zde je jasná výhoda pro ty, kteří mohou jednoduše zkopírovat nebo přesunout soubory na požadované místo bez velké manipulace (například rsync), ale nejčastěji je nutné problém vyřešit organizačně, empiricky: měřením doby obnovy zálohy a otevřeně o tom informovat uživatele.
Stabilita
Je třeba to chápat takto: na jedné straně musí být možné záložní kopii jakýmkoliv způsobem nasadit zpět, na straně druhé musí být odolná vůči různým problémům: přerušení sítě, selhání disku, smazání části úložiště.
Porovnání zálohovacích nástrojů
Čas vytvoření kopie
Zkopírujte čas obnovení
Lehká instalace
Snadné nastavení
Jednoduché použití
Jednoduchá automatizace
Potřebujete klientský server?
Kontrola integrity úložiště
Diferenciální kopie
Práce přes potrubí
všestrannost
Nezávislost
Transparentnost úložiště
Šifrování
Komprese
Deduplikace
webové rozhraní
Plnění do cloudu
podpora Windows
Skóre
Rsync
4m15s
4m28s
ano
ne
ne
ne
ano
ne
ne
ano
ne
ano
ano
ne
ne
ne
ne
ne
ano
6
Dehet
čistý
3m12s
2m43s
ano
ne
ne
ne
ne
ne
ano
ano
ne
ano
ne
ne
ne
ne
ne
ne
ano
8,5
gzip
9m37s
3m19s
ano
Rdiff-záloha
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
Říhnutí
11m9s
7m2s
ano
ne
ano
ano
ano
ano
ano
ne
ano
ano
ne
ne
ano
ne
ano
ne
ano
10,5
Neupřímnost
žá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
Duplikát
žá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
Zálohování Borg
žá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
Venkovský
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
dehet
12m34s
12m15s
Legenda tabulky:
- Zelená, provozní doba kratší než pět minut nebo odpověď „Ano“ (kromě sloupce „Potřebujete klientský server?“), 1 bod
- Žlutá, doba provozu pět až deset minut, 0.5 bodu
- Červená, pracovní doba je více než deset minut nebo odpověď je „Ne“ (kromě sloupce „Potřebujete klientský server?“), 0 bodů
Podle výše uvedené tabulky je nejjednodušším, nejrychlejším a zároveň pohodlným a výkonným zálohovacím nástrojem BorgBackup. Restic obsadil druhé místo, zbytek zvažovaných kandidátů se umístil přibližně stejně s odstupem jednoho nebo dvou bodů na konci.
Děkuji všem, kteří dočetli sérii až do konce, zvu vás k diskuzi o možnostech a nabídnutí vlastních, pokud nějaké jsou. V průběhu diskuse může být tabulka rozšířena.
Výsledkem série bude závěrečný článek, ve kterém bude pokus vyvinout ideální, rychlý a ovladatelný zálohovací nástroj, který vám umožní nasadit kopii zpět v co nejkratším čase a zároveň bude pohodlný a snadný konfigurovat a udržovat.
Oznámení
Zálohování Část 6: Porovnání nástrojů pro zálohování
Záloha Část 7: Závěry
Zdroj: www.habr.com