Tento článok porovná zálohovacie nástroje, ale najprv by ste mali zistiť, ako rýchlo a dobre si poradia s obnovou dát zo záloh.
Pre jednoduchšie porovnanie zvážime obnovenie z úplnej zálohy, najmä preto, že všetci kandidáti podporujú tento režim prevádzky. Pre jednoduchosť sú čísla už spriemerované (aritmetický priemer niekoľkých cyklov). Výsledky budú zhrnuté v tabuľke, ktorá bude obsahovať aj informácie o možnostiach: prítomnosť webového rozhrania, jednoduchosť nastavenia a prevádzky, možnosť automatizácie, prítomnosť rôznych doplnkových funkcií (napríklad kontrola integrity údajov) , atď. V grafoch je znázornené zaťaženie servera, na ktorom sa budú dáta používať (nie servera na ukladanie záložných kópií).
Obnova dát
rsync a tar sa budú používať ako referenčný bod jednoduché skripty na vytváranie záložných kópií.
rsync zvládol testovacie údaje za 4 minúty a 28 sekúnd, ukazuje
taký náklad
Proces obnovy narazil na obmedzenie diskového subsystému servera zálohovania (pilové grafy). Môžete tiež jasne vidieť načítanie jedného jadra bez akýchkoľvek problémov (nízky iowait a softirq - žiadne problémy s diskom a sieťou). Keďže ďalšie dva programy, menovite rdiff-backup a rsnapshot, sú založené na rsync a ponúkajú aj bežný rsync ako nástroj obnovy, budú mať približne rovnaký profil zaťaženia a čas obnovy zálohy.
Decht podarilo sa to trochu rýchlejšie
2 minúty a 43 sekúnd:
Celková záťaž systému bola vyššia v priemere o 20% v dôsledku zvýšeného softirq - vzrástli režijné náklady počas prevádzky sieťového subsystému.
Ak je archív ďalej komprimovaný, čas obnovy sa zvýši na 3 minúty 19 sekúnd.
s takouto záťažou na hlavnom serveri (rozbalenie na strane hlavného servera):
Proces dekompresie zaberá obe jadrá procesora, pretože bežia dva procesy. Vo všeobecnosti je to očakávaný výsledok. Porovnateľný výsledok (3 minúty a 20 sekúnd) sa dosiahol aj pri spustení gzip na strane servera so zálohami; profil zaťaženia na hlavnom serveri bol veľmi podobný spusteniu tar bez kompresora gzip (pozri predchádzajúci graf).
В rdiff-backup môžete synchronizovať poslednú zálohu, ktorú ste urobili pomocou bežného rsync (výsledky budú podobné), ale staršie zálohy je stále potrebné obnoviť pomocou programu rdiff-backup, ktorý dokončil obnovu za 17 minút a 17 sekúnd, pričom zobrazuje
tento náklad:
Snáď to malo za cieľ aspoň obmedziť rýchlosť autorov . Samotný proces obnovy záložnej kópie zaberie o niečo menej ako polovicu jedného jadra, s proporcionálne porovnateľným výkonom (t.j. 2-5x pomalším) na disku a sieti s rsync.
Rsnímka Na obnovu navrhuje použiť bežný rsync, takže jeho výsledky budú podobné. Vo všeobecnosti to takto dopadlo.
Grgnutie Úlohu obnovenia zálohy som dokončil za 7 minút a 2 sekundy s
s týmto nákladom:
Fungovalo to pomerne rýchlo a prinajmenšom je to oveľa pohodlnejšie ako čistý rsync: nemusíte si pamätať žiadne príznaky, jednoduché a intuitívne rozhranie cli, vstavaná podpora viacerých kópií – hoci je to dvakrát pomalšie. Ak potrebujete obnoviť údaje z poslednej zálohy, ktorú ste vytvorili, môžete použiť rsync s niekoľkými upozorneniami.
Program ukázal približne rovnakú rýchlosť a zaťaženie BackupPC pri povolení režimu prenosu rsync nasadenie zálohy pre
7 minút a 42 sekúnd:
V režime prenosu dát sa však BackupPC vyrovnával s dechtom pomalšie: za 12 minút a 15 sekúnd bolo zaťaženie procesora vo všeobecnosti nižšie.
jeden a pol krát:
neúprimnosť bez šifrovania ukázal o niečo lepšie výsledky, obnovil zálohu za 10 minút a 58 sekúnd. Ak aktivujete šifrovanie pomocou gpg, čas obnovy sa zvýši na 15 minút a 3 sekundy. Pri vytváraní úložiska na ukladanie kópií môžete tiež určiť veľkosť archívu, ktorá sa použije pri rozdeľovaní prichádzajúceho dátového toku. Vo všeobecnosti na bežných pevných diskoch, aj vďaka jednovláknovému prevádzkovému režimu, nie je veľký rozdiel. Pri použití hybridného úložiska sa môže objaviť v rôznych veľkostiach blokov. Zaťaženie hlavného servera počas obnovy bolo nasledovné:
žiadne šifrovanie
so šifrovaním
Duplikát vykazovali porovnateľnú mieru zotavenia, dokončili ho za 13 minút a 45 sekúnd. Kontrola správnosti obnovených údajov trvala asi ďalších 5 minút (spolu asi 19 minút). Náklad bol
celkom vysoko:
Keď bolo interne povolené šifrovanie aes, čas obnovy bol 21 minút 40 sekúnd, s maximálnym využitím CPU (obe jadrá!) počas obnovy; Pri kontrole údajov bolo aktívne iba jedno vlákno, ktoré zaberalo jedno jadro procesora. Kontrola údajov po obnovení trvala rovnakých 5 minút (spolu takmer 27 minút).
Výsledok
duplicati bolo s obnovou trochu rýchlejšie pri použití externého programu gpg na šifrovanie, ale vo všeobecnosti sú rozdiely oproti predchádzajúcemu režimu minimálne. Prevádzkový čas bol 16 minút 30 sekúnd s overením údajov za 6 minút. Náklad bol
takéto:
AMANDA, s použitím dechtu, to dokončil za 2 minúty 49 sekúnd, čo je v princípe veľmi blízke bežnému dechtu. Záťaž na systém v princípe
rovnaký:
Pri obnove zálohy pomocou zbackup boli získané tieto výsledky:
šifrovanie, kompresia lzma
Dĺžka trvania 11 minút a 8 sekúnd
Šifrovanie AES, kompresia lzma
Prevádzková doba 14 minút
AES šifrovanie, lzo kompresia
Dĺžka trvania 6 minút, 19 sekúnd
Celkovo to nie je zlé. Všetko závisí od rýchlosti procesora na záložnom serveri, čo je jasne vidieť z doby chodu programu s rôznymi kompresormi. Na strane záložného servera bol spustený bežný tar, takže ak ho porovnáte s ním, obnova je 3-krát pomalšia. Možno stojí za to skontrolovať operáciu vo viacvláknovom režime s viac ako dvoma vláknami.
Zálohovanie Borg v nešifrovanom režime to bolo o niečo pomalšie ako tar, za 2 minúty 45 sekúnd, na rozdiel od tar však bolo možné deduplikovať úložisko. Zaťaženie sa ukázalo byť
nasledujúci:
Ak povolíte šifrovanie založené na blake, rýchlosť obnovy zálohy bude o niečo nižšia. Čas zotavenia v tomto režime je 3 minúty 19 sekúnd a záťaž je preč
Páči sa ti to:
Šifrovanie AES je o niečo pomalšie, čas obnovy je 3 minúty 23 sekúnd, najmä záťaž
sa nezmenilo:
Keďže Borg môže pracovať vo viacvláknovom režime, zaťaženie procesora je maximálne a pri aktivácii ďalších funkcií sa prevádzkový čas jednoducho zvyšuje. Zrejme stojí za to preskúmať multithreading podobným spôsobom ako zbackup.
Vidiecky zvládal s obnovou trochu pomalšie, prevádzkový čas bol 4 minúty 28 sekúnd. Náklad vyzeral
nasledovne:
Proces obnovy zrejme funguje vo viacerých vláknach, ale efektivita nie je taká vysoká ako pri BorgBackup, ale časovo porovnateľná s bežným rsync.
S urBackup Dáta bolo možné obnoviť za 8 minút a 19 sekúnd, záťaž bola
takéto:
Záťaž stále nie je príliš vysoká, dokonca nižšia ako pri dechte. Na niektorých miestach sú praskliny, ale nie viac ako zaťaženie jedného jadra.
Výber a zdôvodnenie kritérií na porovnanie
Ako bolo uvedené v jednom z predchádzajúcich článkov, zálohovací systém musí spĺňať nasledujúce kritériá:
- Jednoduchosť použitia
- všestrannosť
- stabilita
- Rýchlosť
Stojí za to zvážiť každý bod samostatne podrobnejšie.
Jednoduchosť obsluhy
Najlepšie je, keď existuje jedno tlačidlo „Robte všetko dobre“, ale ak sa vrátite k skutočným programom, najpohodlnejší bude nejaký známy a štandardný princíp fungovania.
Väčšina používateľov bude s najväčšou pravdepodobnosťou na tom lepšie, ak si nebudú musieť pamätať veľa kľúčov pre cli, konfigurovať veľa rôznych, často nejasných možností cez web alebo tui, alebo nastavovať upozornenia na neúspešnú operáciu. To zahŕňa aj možnosť jednoduchého „zapadnutia“ zálohovacieho riešenia do existujúcej infraštruktúry, ako aj automatizáciu procesu zálohovania. Existuje tiež možnosť inštalácie pomocou správcu balíkov alebo jedným alebo dvoma príkazmi ako „stiahnuť a rozbaliť“. curl ссылка | sudo bash - komplexná metóda, pretože musíte skontrolovať, čo prichádza cez odkaz.
Napríklad z uvažovaných kandidátov je jednoduchým riešením burp, rdiff-backup a restic, ktoré majú mnemotechnické klávesy pre rôzne prevádzkové režimy. O niečo zložitejšie sú borg a duplicita. Najťažšia bola AMANDA. Zvyšok je z hľadiska jednoduchosti používania niekde uprostred. V každom prípade, ak potrebujete na prečítanie používateľskej príručky viac ako 30 sekúnd, alebo potrebujete prejsť na Google či iný vyhľadávač a tiež si prelistovať dlhý hárok pomocníka, rozhodovanie je ťažké, tak či onak.
Niektorí z uvažovaných kandidátov sú schopní automaticky poslať správu cez e-mailjabber, zatiaľ čo iní sa spoliehajú na nakonfigurované upozornenia v systéme. Navyše, väčšinou zložité riešenia majú nie celkom zrejmé nastavenia výstrah. V každom prípade, ak zálohovací program vygeneruje nenulový návratový kód, ktorý systémová služba správne pochopí pre periodické úlohy (správa bude zaslaná správcovi systému alebo priamo monitorovaniu) - situácia je jednoduchá. Ak však zálohovací systém, ktorý nebeží na záložnom serveri, nie je možné nakonfigurovať, je zrejmé, že o probléme sa dá povedať, že zložitosť je už nadmerná. V každom prípade je vydávanie upozornení a iných správ len do webového rozhrania alebo do denníka zlým zvykom, pretože najčastejšie budú ignorované.
Čo sa týka automatizácie, jednoduchý program dokáže čítať premenné prostredia, ktoré nastavujú jeho prevádzkový režim, alebo má vyvinuté cli, ktoré dokáže úplne duplikovať správanie napríklad pri práci cez webové rozhranie. Patrí sem aj možnosť nepretržitej prevádzky, dostupnosť možností rozšírenia a pod.
všestrannosť
Čiastočne v súlade s predchádzajúcou podkapitolou týkajúcou sa automatizácie by nemalo byť problémom „napasovať“ proces zálohovania do existujúcej infraštruktúry.
Stojí za zmienku, že používanie neštandardných portov (okrem webového rozhrania) na prácu, implementácia šifrovania neštandardným spôsobom, výmena údajov pomocou neštandardného protokolu sú znakmi neštandardného protokolu. - univerzálne riešenie. Väčšinou ich tak či onak majú všetci kandidáti z jasného dôvodu: jednoduchosť a všestrannosť väčšinou nejdú dokopy. Ako výnimka - grgnutie, existujú aj iné.
Ako znamenie - schopnosť pracovať pomocou bežného ssh.
Rýchlosť práce
Najkontroverznejší a najkontroverznejší bod. Na jednej strane sme proces spustili, fungoval čo najrýchlejšie a nezasahoval do hlavných úloh. Na druhej strane počas zálohovania dochádza k prudkému nárastu prevádzky a zaťaženia procesora. Za zmienku tiež stojí, že najrýchlejšie programy na vytváranie kópií sú zvyčajne najchudobnejšie z hľadiska funkcií, ktoré sú pre používateľov dôležité. Opäť: ak s cieľom získať jeden nešťastný textový súbor o veľkosti niekoľkých desiatok bajtov s heslom a kvôli tomu stojí celá služba (áno, áno, chápem, že proces zálohovania tu najčastejšie nie je na vine), a musíte znova sekvenčne prečítať všetky súbory v úložisku alebo rozšíriť celý archív - systém zálohovania nie je nikdy rýchly. Ďalším bodom, ktorý sa často stáva kameňom úrazu, je rýchlosť nasadenia zálohy z archívu. Je tu jasná výhoda pre tých, ktorí môžu jednoducho skopírovať alebo presunúť súbory na požadované miesto bez veľkej manipulácie (napríklad rsync), ale najčastejšie sa problém musí vyriešiť organizačne, empiricky: meraním času obnovy zálohy. a otvorene o tom informovať používateľov.
stabilita
Treba to chápať takto: na jednej strane musí byť možné záložnú kópiu akýmkoľvek spôsobom nasadiť späť, na druhej strane musí byť odolná voči rôznym problémom: prerušeniu siete, výpadku disku, vymazaniu časti Úložisko.
Porovnanie zálohovacích nástrojov
Čas vytvorenia kópie
Skopírovať čas obnovenia
Ľahká inštalácia
Jednoduché nastavenie
Jednoduché použitie
Jednoduchá automatizácia
Potrebujete klientsky server?
Kontrola integrity úložiska
Diferenciálne kópie
Práca cez potrubie
všestrannosť
Nezávislosť
Transparentnosť úložiska
šifrovanie
kompresia
Deduplikácia
webové rozhranie
Plnenie do oblaku
podpora Windows
značka
rsync
4m15s
4m28s
áno
nie
nie
nie
áno
nie
nie
áno
nie
áno
áno
nie
nie
nie
nie
nie
áno
6
Decht
čistý
3m12s
2m43s
áno
nie
nie
nie
nie
nie
áno
áno
nie
áno
nie
nie
nie
nie
nie
nie
áno
8,5
gzip
9m37s
3m19s
áno
Rdiff-záloha
16m26s
17m17s
áno
áno
áno
áno
áno
nie
áno
nie
áno
nie
áno
nie
áno
áno
áno
nie
áno
11
Rsnímka
4m19s
4m28s
áno
áno
áno
áno
nie
nie
áno
nie
áno
nie
áno
nie
nie
áno
áno
nie
áno
12,5
Grgnutie
11m9s
7m2s
áno
nie
áno
áno
áno
áno
áno
nie
áno
áno
nie
nie
áno
nie
áno
nie
áno
10,5
neúprimnosť
žiadne šifrovanie
16m48s
10m58s
áno
áno
nie
áno
nie
áno
áno
nie
nie
áno
nie
áno
áno
nie
áno
nie
áno
11
gpg
17m27s
15m3s
Duplikát
žiadne šifrovanie
20m28s
13m45s
nie
áno
nie
nie
nie
áno
áno
nie
nie
áno
nie
áno
áno
áno
áno
áno
áno
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
zbackup
žiadne šifrovanie
40m3s
11m8s
áno
áno
nie
nie
nie
áno
áno
áno
nie
áno
nie
áno
áno
áno
nie
nie
nie
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
Zálohovanie Borg
žiadne šifrovanie
4m7s
2m45s
áno
áno
áno
áno
áno
áno
áno
áno
áno
áno
nie
áno
áno
áno
áno
nie
áno
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Vidiecky
5m38s
4m28s
áno
áno
áno
áno
nie
áno
áno
áno
áno
áno
nie
áno
nie
áno
nie
áno
áno
15,5
urBackup
8m21s
8m19s
áno
áno
áno
nie
áno
nie
áno
nie
áno
áno
nie
áno
áno
áno
áno
nie
áno
12
Amanda
9m3s
2m49s
áno
nie
nie
áno
áno
áno
áno
nie
áno
áno
áno
áno
áno
nie
áno
áno
áno
13
BackupPC
rsync
12m22s
7m42s
áno
nie
áno
áno
áno
áno
áno
nie
áno
nie
nie
áno
áno
nie
áno
nie
áno
10,5
decht
12m34s
12m15s
Legenda tabuľky:
- Zelená, prevádzkový čas kratší ako päť minút alebo odpoveď „Áno“ (okrem stĺpca „Potrebujete klientsky server?“), 1 bod
- Žltá, doba prevádzky päť až desať minút, 0.5 bodu
- Červená, pracovný čas je viac ako desať minút alebo odpoveď je „Nie“ (okrem stĺpca „Potrebujete klientsky server?“), 0 bodov
Podľa tabuľky vyššie je najjednoduchším, najrýchlejším a zároveň pohodlným a výkonným nástrojom na zálohovanie BorgBackup. Restic obsadil druhé miesto, ostatní zvažovaní kandidáti sa umiestnili približne rovnako s odstupom jedného alebo dvoch bodov na konci.
Ďakujem všetkým, ktorí si sériu prečítali až do konca, pozývam vás diskutovať o možnostiach a ponúknuť svoje vlastné, ak nejaké existujú. V priebehu diskusie môže byť tabuľka rozšírená.
Výsledkom série bude záverečný článok, v ktorom bude pokus o vývoj ideálneho, rýchleho a spravovateľného zálohovacieho nástroja, ktorý vám umožní nasadiť kópiu späť v čo najkratšom čase a zároveň bude pohodlný a jednoduchý. konfigurovať a udržiavať.
Oznámenie
Zálohovanie Časť 6: Porovnanie nástrojov zálohovania
Zálohovanie Časť 7: Závery
Zdroj: hab.com