Přidat článek mezi oblíbenéZasílat nové komentáře e-mailem Moderní metody zálohování

Každý, kdo spravuje nějakou síť nebo firemní data, již zcela určitě řešil otázku jak a kam zálohovat data. Dnes bych se rád věnoval této často ignorované a podceňované problematice. Nerudovská otázka „Kam s nimi?“ transformovaná pro 21. století dojde částečného rozřešení právě v tomto článku.

Trocha historie nikoho nezabije

V dřevních dobách se zálohovalo všelijak. Dělaly se duplikáty děrných štítků a pásek, data se nahrávala na zálohovací pásky (tato technologie v podobě karuselových páskových mechanik přežívá dodnes), na Amize se používalo mj. zálohování na pásky VHS :-)

[87311-diavolomain-png]

a v neposlední řadě se zálohovalo na diskety, později Bernoulli disky, ZIPky, JAZy apod. A už v těchto dobách to byl problém z několika hledisek:

1. Jak zajistit spolehlivost takové zálohy?
2. Rychlost (spíše však pomalost) zálohy
3. Malá kapacita záložních médií
4. Fyzické rozměry zálohovacích médií
5. Možnost off-site uložení záložních médií

Popravdě, všechny tyto problémy řešíme dodnes. Navíc se z jednoho problému (vlastně dvou a přeneseně tří) uvedeného výše stal doslova strašák – ano, je to kapacita záložních médií, potažmo velikost zálohovaných dat, a z nich plynoucí problém ceny, rychlosti a možnosti off-site uložení takové zálohy. Další kapitola popíše přístupy k zálohování.

Zálohovací strategie

Nejprve si nastíníme nějakou tu výchozí situaci: Mějme malou firmičku o několika desítkách počítačů a s nějakým tím serverem nebo dvěma. Uživatelé si kutí na svých počítačích, data nahrávají sem-tam na server, ale spolehnutí na to není. Ještě před několika lety bylo běžné, že se systematicky zálohovaly pouze servery a počítače si zálohovali samotní uživatelé svépomocně (pokud vůbec). V takovém prostředí se vyvinula většina známých zálohovacích softwarů, ať se jedná o serverové, nebo desktopové produkty, mezi které můžeme zahrnout např. Veritas/Symantec Backup Exec, Veaam backup, apod., případně Acronis TrueImage apod. pro desktop. V průběhu času se tyto systémy prolnuly a nabízejí jednotné prostředí pro servery i desktopy.
Daleko podstatnější je, že pro zálohování musíte koupit nejen software, ale i hardware, a hlavně si určit, co a jak budete zálohovat – jak taková záloha má vypadat a co má všechno obsahovat. Pojďme si nyní projít jednotlivé obecné možnosti, jak takové zálohování řešit:

Prostá kopie dat na záložní médium

Takové řešení vypadá jako nejjednodušší a realizovatelné s nejmenšími náklady. V dávných dobách tomu tak i bylo, stačilo nakoupit balíček disket a postupně na ně v časových intervalech kopírovat data, týden co týden jednu disketu. V jedenáctém týdnu pak stačilo vzít první disketu, smazat ji a začít nové kolo. Měli jste zálohu 10 týdnů zpátky a bylo to jednoduché a celkem i spolehlivé – pokud jste nezapomněli, nebo pokud byla disketa spolehlivě čitelná. V dnešní době se takové zálohování už skoro nepoužívá, a pokud ano, je spojeno s několika obtížemi. V první řadě jde o objem a rychlost záloh, zálohovat např. stovky megabajtů ještě jde, ale stovky gigabajtů už bude problém. Částečně se rychlost zálohování dá vyřešit inteligentním kopírováním a rotací záložních složek - stará záloha se nemaže, ale „synchronizuje“ nástrojem jako je rsync, robocopy nebo unison, což je daleko rychlejší, než otrocké kopírování dat. Takovým způsobem ale nijak nevyřešíte problém celkového objemu takových záloh. Zálohujete-li např. 500GB dat, pak 4 zálohy nevyhnutelně budou zabírat 2TB na záložním médiu. A 500GB, to je v dnešní době informační exploze tzv. „nic.“ Na off-site zálohu můžete prakticky zapomenout. Naopak výhodou je poměrně snadná obnova prakticky kdekoli, kde lze připojit záložní médium. Do tohoto schématu si dovolím zařadit i zálohování pomocí kompresních nástrojů (7-zip, tar/gzip, RAR apod.), protože princip je prakticky stejný. Automatizace je možná na straně serveru, ale u uživatelů a jejich PC velmi pravděpodobně narazíte.

Aplikační řešení záloh souborového systému, rozdílová a inkrementální záloha

Dostáváme se k nejběžnějšímu způsobu řešení záloh. Jde o řešení, které je vlastní většině zálohovacích aplikací a systémů, a které zavedlo rozšířená zálohovací schémata. Jde o to, že při zálohování se do zálohy dostávají i soubory a data, která nebyla od poslední zálohy změněna. Při zálohování kopírováním jsme takový soubor mohli maximálně nekopírovat znova, protože v dané záloze, určené k přepsání, již byl. Žádné místo na záložním médiu jsme však neušetřili. Tento problém řeší aplikační způsob zálohy, kdy se o zálohování stará „chytrý“ program, který si vyhodnotí, že daný soubor v některé předešlé záloze již je, a proto je možné jej v aktuální záloze nezahrnout. Tato data o souborech se nacházejí v tzv. metadatech zálohy, typicky jde o databázi, ve které jsou uloženy všechny záznamy o provedených zálohách. Samotný soubor zálohy (typicky jde opravdu o jeden velký soubor) pak obsahuje data o samotných zálohovaných souborech – umístění, jméno, apod.)
Vždy tak existuje prvotní plná záloha (tedy ekvivalent kopie dat z předešlé kapitoly) a na ni navazující rozdílové a inkrementální zálohy. V obou případech platí, že bez prvotní zálohy nelze obnovit jakýkoli soubor, ale maximálně soubory, které byly součástí následných záloh.
Rozdíl mezi rozdílovou a inkrementální zálohou je ten, že každá rozdílová záloha se vztahuje pouze na rozdíly oproti prvotní záloze, kdežto inkrementální zálohy se řetězí a zálohuje se rozdíl jen vůči poslední záloze. Výhody i nevýhody jsou tedy zřejmé. Rozdílová záloha závisí pouze na jedné předešlé záloze (a její případná obnova je poměrně rychlá), zato je jednoznačně větší. U inkrementální zálohy je to opačně – postupné zálohy jsou menší, ale obnova předpokládá postupný průchod všemi historickými instancemi záložních souborů.

[87345-diff-increment-png]

Tento způsob záloh reálně umožnil tvorbu tzv. zálohovacích schémat. Smysl schématu je prodloužit historickou dobu a časovou dosažitelnost záloh, tedy např. možnost obnovit data nejen 4 týdny stará, ale (v rámci omezených možností) stará třeba rok. Jednotlivé zálohy tak dostávají tzv. „tag“ – označení, o jaký typ zálohy se jedná. Nejčastější princip je styl denní – týdenní – měsíční – roční. Zatím co každá záloha je označena jako denní, jako týdenní je označena pouze jedna z týdne (např. první nebo poslední v daném týdnu), podobně pak měsíční (první/poslední v měsíci) a roční. V schématu je dále nastaveno jakou trvanlivost má ta která záloha. Denní např. 14 dní, týdenní 2 měsíce, měsíční půl roku a roční třeba 5 let. V takovém případě má správce k dispozici obnovu dat za každý den 14 dní zpět, pondělní zálohy pak 2 měsíce zpátky, zálohy z prvního dne v měsíci pak půl roku zpět a roční zálohy z ledna 5 let zpátky. To zohledňuje pravděpodobnost odhalení chyby a nutnost vrátit se k historickým datům – že jste si něco smazali, zjistíte většinou velmi brzy; kouknout se na starý soubor, který jste měli někde v archivu a on ho někdo v průběhu roku přepsal, stačí z roční lednové zálohy rok staré.
Jak už bylo řečeno, tento způsob je dnes nejrozšířenější, ovšem i on naráží na problémy. Tím největším je, jako obvykle, velikost zálohovaných dat. Problém tkví v jedné malé, zato podstatné věci – kterýkoli změněný soubor, byť pranepatrně, se při další záloze ocitne v aktivní záloze. V dobách, kdy typický průměrný soubor měl velikost maximálně pár set kB, v nejhorším případě MB, to nebyl takový problém. Dnes má průměrný soubor (fotka, video, dokument) velikost značně větší, protože digitální média jsou čím dál tím více detailnější, popřípadě toho umí více (jsou naprogramovány bez ohledu na výslednou efektivitu vygenerovaných dat), a proto mají i větší velikost – desítky MB jsou standardem. Takový 10MB soubor, v němž změníte pár bajtů, se pak celý znova musí znova zálohovat.
Další zcela zásadní problém pro tento systém je přejmenování nebo přesunutí dat. Stačí přejmenovat složku „Dovolená“ obsahující 300GB fotek z dovolené na „Dovolená 2019“, případně tuto složku přesunout do podsložky „Fotky 2019,“ a celých 300MB se zálohuje znova, byť se v datech nezměnil ani bajt. Podobně neefektivní je tento systém, pokud si data zkopírujete na jiné místo disku. Jeho výhoda tkví v možnosti instalace zálohovacích agentů jak na server, tak na počítače uživatelů. Bohužel velmi často uživatelé zálohy torpédují, protože trvají dlouho a vytěžují počítač.
Z takového příkladu je poměrně dobře vidět, že ani tento systém záloh není příliš efektivní. Vyřešit tento problém se podařilo poměrně nedávno, ačkoli principiálně jde o řešení známé už z dob sálových počítačů v 70. letech minulého století. Více v následující podkapitole.

Deduplikace dat

Problém opakujících se dat a jejich deduplikace je znám a popsán velmi dobře. Typickým příkladem, kde se této techniky používá, je relační databáze (SQL), kde můžete (správněji musíte, měli byste) deduplikovat (v terminologii relačních databází se používá termín „normalizace dat“), abyste zamezili chybám opakovaného zadávání stejných dat, zmenšili databázi a zrychlili procházení a vyhledávání.
Revolucí bylo nasazení této techniky do zálohování souborů, k čemuž vedla poměrně složitá cesta. Zásadní problém pro deduplikaci souborů byl, a je, odlišit jednotlivé soubory tak, abyste je byli schopni poznat vždy – i když je jen přejmenujete, nebo přesunete či zkopírujete. Cestou k této identifikaci je takzvané hashování – jde o kryptografickou metodu, pomocí níž se z každého souboru vypočítává tzv. hash – krátký textový řetězec, který soubor zcela jednoznačně identifikuje – tedy jeden konkrétní soubor (ať se jmenuje jak chce a je umístěn kde chce) má vždy STEJNÝ hash. Naopak, dva rozdílné soubory musí mít hash ODLIŠNÝ, a to i kdyby se lišily sebeméně (i jedním bitem) nebo sebevíce. Pak stačí zálohovat pouze soubory, jejichž hash ještě nemám zaveden v databázi záloh.
To ale není ještě konec, celé se to dá vylepšit – ano, modří již vědí – celý proces lze aplikovat nejen na celé soubory, ale i jejich části. Tyto části se nazývají chunky [čanky] a proces rozřezání souboru na tyto části není úplně triviální. Zprvu se používala metoda pevné velikosti chunku, ale nejsofistikovanější zálohovací algoritmy jej mají proměnný – některé začínají na 4kB, špička v oboru, EMC, umí i 1 byte (!), horní hranice bývá někde u 64kB. Jde o to, rozřezat soubor tak, aby se jednotlivé chunky měly šanci co nejvíce opakovat v rámci souboru, nebo zálohy, případně všech záloh. Princip je následně stejný – pro chunk je spočten hash a je porovnán s databází známých hashů. Pokud je nalezen nový, je hash i chunk uložen na zálohovací médium, pokud není, chunk se nikam neuloží. Celá záloha pak sestává ze seznamu souborů, které jsou zase definovány řetězci hashů (které zase odpovídají uloženým chunkům). V případě že budete provádět obnovu dat, bude proces opačný, a bude připomínat stavbu LEGO hračky – k dispozici bude seznam stavebních prvků a postup jejich skládání.
Abyste měli rámcovou možnost srovnat si jak to vypadá v běžné praxi, níže je ukázka jak to vypadá při zálohování cca 900GB živých dat (tedy data, se kterými se běžně pracuje):

Sun 30 Jun 2019 04:39:07 PM CEST Starting backup
------------------------------------------------------------------------------
Archive name: matrix-2019-06-30T16:39:07
Archive fingerprint: 2f297bbf63186ae71628fe48e0a434c45d5f2214592aed68afbbec4c57886d60
Time (start): Sun, 2019-06-30 16:39:07
Time (end):   Sun, 2019-06-30 16:43:22
Duration: 4 minutes 14.53 seconds
Number of files: 447872
Utilization of max. archive size: 0%

Jak vidíte, běžná záloha již zálohovaného systému trvala pouhé 4 minuty (viz výše) a samotná záloha zabrala pouhé necelé 3 GB. Celkem jsou v systému 4 zálohy o celkovém objemu 4,34 TB, přičemž na médiu je reálně uloženo pouhých 507 GB dat

------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:              874.98 GB            744.03 GB              2.97 GB
All archives:                4.34 TB              3.69 TB            507.02 GB
                       Unique chunks         Total chunks
Chunk index:                  480527              3713855
------------------------------------------------------------------------------

Sun 30 Jun 2019 04:43:24 PM CEST Pruning repository

Keeping archive: matrix-2019-06-30T16:39:07           Sun, 2019-06-30 16:39:07 [2f297bbf63186ae71628fe48e0a434c45d5f2214592aed68afbbec4c57886d60]
Keeping archive: matrix-2019-06-15T22:00:02           Sat, 2019-06-15 22:00:08 [7ef73c315080e4462940d29da4dc7d42ead79aac5efbb3ef67efff97399af69a]
Keeping archive: matrix-2019-06-08T22:00:01           Sat, 2019-06-08 22:00:07 [5bf919108c863834dbd11803d5ded7b5058ca31d02d1e2c6da0005fd5c29801c]
Keeping archive: matrix-2019-06-01T22:00:01           Sat, 2019-06-01 22:00:07 [baf674d9a2bae59ce848dea214254a7fa32e7f89b3c40b8174ca5c865ce4c3bc]
Pruning archive: matrix-2019-06-01T17:00:08           Sat, 2019-06-01 17:00:08 [51eee1f8c275bd59c23ea73091a7e4f168dd409e7ef4829202c6814ccd44441f] (1/1)
terminating with success status, rc 0
Sun 30 Jun 2019 04:43:32 PM CEST Backup and Prune finished successfully
borg info /mnt/backup/borgs
Repository ID: 0025d834d48961dceff2331864d97313e009ac3a61b541aafdf2b26621913d75
Location: /mnt/backup/borgs
Encrypted: No
Cache: /root/.cache/borg/0025d834d48961dceff2331864d97313e009ac3a61b541aafdf2b26621913d75
Security dir: /root/.config/borg/security/0025d834d48961dceff2331864d97313e009ac3a61b541aafdf2b26621913d75
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:                3.48 TB              2.96 TB            507.02 GB
                       Unique chunks         Total chunks
Chunk index:                  480391              2973126
borg list /mnt/backup/borgs
matrix-2019-06-01T22:00:01           Sat, 2019-06-01 22:00:07 [baf674d9a2bae59ce848dea214254a7fa32e7f89b3c40b8174ca5c865ce4c3bc]
matrix-2019-06-08T22:00:01           Sat, 2019-06-08 22:00:07 [5bf919108c863834dbd11803d5ded7b5058ca31d02d1e2c6da0005fd5c29801c]
matrix-2019-06-15T22:00:02           Sat, 2019-06-15 22:00:08 [7ef73c315080e4462940d29da4dc7d42ead79aac5efbb3ef67efff97399af69a]
matrix-2019-06-30T16:39:07           Sun, 2019-06-30 16:39:07 [2f297bbf63186ae71628fe48e0a434c45d5f2214592aed68afbbec4c57886d60]

Poměr deduplikace je tedy přibližně 7:1 pro všechny zálohy (včetně komprese), bez komprese pak stále velmi výborných 6,8:1. Jistě nemusím napovídat, že takovou zálohu je možné ukládat i off-site, protože její velikost je více než přijatelná pro téměř jakoukoli intranetovou/internetovou linku.
Výše uvedený příklad bych rád popsal v dalším článku z pohledu použitého řešení a srovnal s dalšími řešeními z pohledu funkčního.
A jaké jsou nevýhody? V podstatě jsou jen dvě, obě však poměrně podstatné. V první řadě musíte mít zálohující stroj stoprocentně spolehlivý. Jakékoli chyby v paměti nebo při výpočtu hashe znamenají průšvih. Druhý problém není tak viditelný, ale o to je nebezpečnější: celé řešení spoléhá na unikátnost funkce hash. Pokud by se stalo, že dojde k takzvanému narozeninovému paradoxu, je celý systém ohrožen – pro jeden hash pak budou existovat dva rozdílné chunky, což logicky celý systém hashování daným hashovacím algoritmem zcela pohřbí. Teoreticky je taková věc s danými velikostmi chunků poměrně nepravděpodobná, nicméně kryptografové už z principu nikdy nic nevylučují.

Zálohy systému vs. zálohy dat

Tato kapitola je tu trochu navíc, nicméně je vhodné ji zmínit. Správce by si vždy měl uvědomit, CO a PROČ zálohuje. Někdo řeší rychlou obnovu systému při fatálním selhání, jiný potřebuje zálohovat pouze uživatelská data. V obou případech je na místě adekvátní a spolehlivá metoda zálohování. Pokud spravujete doménu, vždy by její stav a minimálně jeden server (ideálně ten, který drží FSMO role) byste měli zálohovat tak, abyste mohli obnovit její funkci, tj. mít kompletní zálohu systému. Naopak, pro souborový server můžete nastavit pouze zálohování dat, popřípadě zálohu systému plánovat jen jednou měsíčně. Vždy byste si měli obnovu vyzkoušet, vždy byste měli vědět, co dělat pro obnovu dat.

Závěr

Z teoretického hlediska jsme probrali metody zálohování, popsali jejich principy, výhody a nevýhody. Dovolí-li to čas, pokusím se napsat další díl, věnující se deduplikaci, jakožto progresivní metodě zálohování, a dostupným řešením. A pamatujte: existují jen dva typy lidí – ti co zálohují, a ti, co ještě nepřišli o data.

Předmět Autor Datum
Dam plusko, ked sa nalogujem, a mam milion otazok, pretoze tento clanok je urceny pre mna...pre IT p… nový
fleg-sk 03.07.2019 09:42
fleg-sk
ten článek není určen mudlům. Je pro mírně pokročilé a pokročilé, kteří už chápou cenu dat a mají na… nový
touchwood 03.07.2019 12:11
touchwood
Prave riesim u zakaznika problem co s datami, ich IT oddelenie chce kupit 2 QNAP polia za cca 13k, c… nový
fleg 03.07.2019 19:33
fleg
rsync ti ale vytvoří zrcadlo, a když budeš chtít časové rozpětí záloh, tak jsi už na násobcích záloh… nový
touchwood 03.07.2019 20:50
touchwood
Nejsem expert, takže jen co mě tak po přečtení napadá... K čemu bude "sofistikovanému" zálohovacímu… nový
kacikac 05.07.2019 18:02
kacikac
ad chunk velký 1B: co když ten jeden bajt odděluje chunky větší, které mají potom shodný obsah? ad 6… nový
touchwood 06.07.2019 11:37
touchwood
add chunk velký 1B: No tak se z toho 1 B neudělá chunk, ale nechá se tam prostě ten 1 B dat :-) add… nový
kacikac 06.07.2019 14:27
kacikac
budu psát jen k tomu důležitému: - deduplikační poměr a malá firmička: ten samozřejmě není garantov… nový
touchwood 06.07.2019 16:45
touchwood
Deduplikovaných dat bylo 3 GB. Nededuplikovaných bylo ale 900 GB. Jde o to, že jako jsou mé dva přík… nový
kacikac 06.07.2019 17:46
kacikac
Budeš se divit, ale většina firem, kde jsem zálohování nasadil, skončila u deduplikace jako nejefekt… nový
touchwood 06.07.2019 21:01
touchwood
Bych ze zvědavosti chtěl vidět ty data na zálohování co ty firmy měly. :-) A bude ve druhém díle i n… nový
kacikac 06.07.2019 22:57
kacikac
Jj tiez by sa mi nieco take hodilo, zrovna v pondelok mam meeting u zakaznika a bude sa preberat aj… nový
fleg 06.07.2019 23:45
fleg
Něco málo tam v tomto ohledu je. Nechcete-li čekat, můžu doporučit free verzi datadomain a duo borgb… poslední
touchwood 07.07.2019 07:05
touchwood
Jestli tomu dobře rozumím (jestli ne, prosím o opravu) , pak záloha pomocí deduplikace dat je záloha… nový
hynajs 06.07.2019 17:01
hynajs
Já popisuju nejběžnější zálohy - souborové. Integrita otevřených souborů samozřejmě řešena není. Nic… nový
touchwood 06.07.2019 21:07
touchwood

Dam plusko, ked sa nalogujem, a mam milion otazok, pretoze tento clanok je urceny pre mna...pre IT profika.
Ale mam otazku ako uzivatel...myslis, ze si okrem mna (a par dalsich ludi) niekto este tento clanok uzije?
Otazky ohladom zalohovania doplnim, ja pouzivam trosku iny system, ale rad sa naucim nieco nove.

Prave riesim u zakaznika problem co s datami, ich IT oddelenie chce kupit 2 QNAP polia za cca 13k, co je imho blbost, ale neviem ich presvedcit.
Inak ja pouzivam rsync na linuxoch, cobian na win a pripadne vstavane nastroje na FreeNASoch (push, pull).
Pre beznych klientov som daval Always sync, ale ten mal obcas problem bezat ako sluzba a ako freeware nesmie byt pusteny prilis casto inak brble, ze si ho mas kupit.

rsync ti ale vytvoří zrcadlo, a když budeš chtít časové rozpětí záloh, tak jsi už na násobcích zálohovaného úložiště. Si to klidně zkus s tím Borgem, je to otázka hodinky a půl včetně instalace. :-) Prostě rsync je spíše kopie dat, ne záloha...

edit: tohle je myslím zásadní:

                       Unique chunks         Total chunks
Chunk index:                  480391              2973126

jen půl milionu unikátních chunků z celkového počtu necelých 3 milionů. A to jde o klasické úložiště všemožných dat...

Nejsem expert, takže jen co mě tak po přečtení napadá...
K čemu bude "sofistikovanému" zálohovacímu nástroji chunk o velikosti 1 B, když k němu bude muset udělat třeba 64 B hash a zapsat ho i jeho použití v databázi? :-D
Pokud horní hranice u chunku bývá 64 kB, tak to pak nechápu co za odpadní program na deduplikaci používáš, když jen průměrná velikost chunku v tvém příkladě je 1 284 886 B, tedy přes 1 MB.
Je sice hezké, že deduplikační poměr je u tebe 7:1, ale ten vždy bude záležet na tom, co se zálohuje a co nového tam přibývá. V tvém případě se jedná jen o hodně málo modifikované soubory, protože ten deduplikační poměr u nových dat je 294.6:1 a to je poměr na základě chunků, v souborech to může dýt doslova otázka B.
Jo a ja bych to, že takový nástroj musí být 100% spolehlivý viděl jako docela hodně podstatný nedostatek, tam se toho může pokazit tolik :-) Stačí třeba bug v algoritmu při zapisování do databáze a je po záloze :-) A taky bych chtěl vidět jak taková deduplikační databáze vypadá, když bych vzal tebou uváděný údaj horní meze 64 kB na chunk, tak to máš při 64 B hashi velikost při 4 TB databázi 4 294 967 296 B a to je jen velikost chunků...
Co se týče ještě deduplikace tak si ji myslím každý může přidat (nevím teda jako jestli ofiko) i do win 10 jako myslím normálně origo balíček od Microsoftu co je třeba v serverových edicích s názvem Microsoft-Windows-Dedup-Package, balíček má necelé 4 MB, nezkoušel jsem ale.
A dalších pár poznámek:
- co se týče zálohování a velikosti, on třeba takový 7z pokud se něco komprimuje snadno tak udělá malinký soubor (příklad soubor.7z) a i pokud je hromada hodně podobných souborů tak vpodstatě ten komprimační algoritmus umí používat data z těch předchozích (příklad soubory.7z).
- na netu se třeba na zálohování windows iso na uložiště používá utilitka smv:
https://www.smartversion.com/cmdline.htm
která vytváří rozdílové svf soubory a nemusí se uploadovat celé iso (lze použít na cokoliv).
- Windows obsahuje knihovny na práci s patchováním konkrétně na to, co se používá v aktualizacích (neposílají se celé soubory, pouze rozdílové soubory na vytvoření novější verze ze staré a původní verze z novější), knihovny jsou to mspatchc.dll (vytvoření patche) a mspatcha.dll (aplikování patche) (obě knihovny obsahuje přímo Windows), ty taky myslím používá na zálohování systémových souborů ve složce WinSxS. Do Win 7 SDK k těm knihovnám byla přikládaná i exe utilitka (jde použít i ve win 10), pokud někdo nechce přistupovat k těm knihovnám přímo.

ad chunk velký 1B: co když ten jeden bajt odděluje chunky větší, které mají potom shodný obsah?
ad 64kB: je to OpenSource, takže efekt zřejmě nebude tak dobrý, jako u 10+ let vyvíjeného komerčního řešení. Celé kouzlo je totiž v umění "správně" určit velikost chunku na základě dodaných dat.
ad deduplikační poměr: jenže to je právě to, k čemu je deduplikace určena - k zálohám opakujících se dat. Je to nástroj, kterým dokážeš odzálohovat data celé firmy a nezaplatíš za to těžké peníze za úložiště.
ad spolehlivost: je samozřejmě důležitá. Nicméně když se dnes koukneš na moderní SANy, tak tam je taky základem nějaký dual-blade s Linuxem - těch chyb se dá nasekat spousta a různě, i mimo proces zálohování.
ad Windows: o tom píšu v druhém díle článku. Deduplikaci nad FS podporuje i Linux a BSD.
ad 7zip: OK, zkus si takhle zabalit těch 900GB - třeba každou sobotu. :-) Pojede to celý víkend a ještě si budeš muset poradit s tím, jak takové zálohy držet alespoň 2-3 zpátky, protože na méně než 500GB se téměř jistě nedostaneš.

add chunk velký 1B: No tak se z toho 1 B neudělá chunk, ale nechá se tam prostě ten 1 B dat :-)
add 64kB: Stále mi není jasné co ta 64 kB hodnota znamená, já ji pochopil tak, že je to horní hranice velikosti chunků. Chápat se to možná ale dá i tak, že je to horní hranice na jaké velikost chunků u některých programů může začínat. A nějak jsem nedomyslel to, že zjišťovat průměrnou velikost chunků nemůžu tak, že vydělím celou velikost počtem chunků, všechna data nemusí být rozsekaná na chunky.
add deduplikační poměr: to ano, já to ale zmiňoval kvůli tomu, že ten deduplikační poměr může být naprosto jakýkoliv a aby si někdo nemyslel, že když nasadí deduplikaci, že bude mít deduplikační poměr kolem 7:1 a u nových dat kolem 294:1, ono to klidně může být třeba 1.2:1 a 1.3:1 :-)
add 7z: Na začátku jsi zmínil 7z. Já to uvedl jen jako příklad co mě napadlo na co by se mohl 7z hodit. A těmi hodně podobnými soubory jsem myslel třeba jednotlivé verze souborů v čase, v archivu jich mám 20. Já nemyslel, že by to mohlo být určené na nějaké obrovské kvanta dat.
add "Mějme malou firmičku" (jen poznámka): Nemyslím si, že úplně všechny malé firmičky vyprodukují třeba 900 GB důležitých dat týdně. :-)

budu psát jen k tomu důležitému:

- deduplikační poměr a malá firmička: ten samozřejmě není garantovaný. Jsou data, která jdou deduplikovat poměrně špatně, ale smysl deduplikace je právě v zálohách "živých" velkých dat (minimum jsou ty stovky GB), ideálně od více uživatelů, ve kterých se tento efekt jednoznačně projeví. Nejde o to, že vyprodukuješ týdně 900GB dat, ale že s nimi nějakým způsobem pracuješ. I ten můj příklad ukazuje, že zcela nových dat byly za týden jen cca 3GB - jenže deduplikovaných! Kdybys to řešil na úrovni souborů, klidně to mohlo být těch 21GB v inkrementální záloze, protože změna v souboru mohla být jen minoritní.

Deduplikovaných dat bylo 3 GB. Nededuplikovaných bylo ale 900 GB. Jde o to, že jako jsou mé dva příklady se 7z dejme tomu ideální pro 7z, tak ten tvůj příklad je ideální pro deduplikaci, protože tam máš prakticky skoro všechno vhodné na deduplikaci (přesně 99.66 % velikosti dat). A je jasné, že vhodnější řešení nebude. Jenže ony ty data asi tak ideální za normálních okolností nebudou...

Jestli tomu dobře rozumím (jestli ne, prosím o opravu) , pak záloha pomocí deduplikace dat je záloha souborů .
Pak ale nemohu ze zálohy obnovit jenom jednu databázovou tabulku.
Nebo ano?

S tím souvisí:

cca 900GB živých dat (tedy data, se kterými se běžně pracuje)

Pak ale musí být po dobu zálohy databáze pozastaveny všechny transakce, které přijdou po zahájení zálohy (přičemž předchozí musí být řádně ukončeny). Nedovedu si totiž představit chunkování a hashování souboru, který se neustále mění.
Nebo mi něco uniká?
Děkuji.

Já popisuju nejběžnější zálohy - souborové. Integrita otevřených souborů samozřejmě řešena není. Nicméně, zálohy probíhají většinou v noci (a díky tomuto mechanismu jsou rychlé) a SQL databáze je možné zálohovat jako dumpy, popřípadě jako volume snapshot. Nicméně deduplikaci lze aplikovat na libovolný datový stream.

Třeba ten Avamar má pluginy pro prakticky všechny aplikační databáze a umožnuje, v případě např. MSSQL, obnovu i konkrétní tabulky - zde to je ovšem o featurách samotné zálohovací aplikace, nikoli zálohovacího algoritmu.

Zpět na články Přidat komentář k článku Nahoru