Moderní metody zálohování

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

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ů.

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.