Pokud pracujete s virtuální infrastrukturou, je jen otázkou času, než si položíte stejnou otázku: co mám dělat se všemi těmi snapshoty, které se na počítačích hromadí? Některé IT týmy upřednostňují jejich uchovávání „pro jistotu“, zatímco jiné je upřednostňují smazání co nejdříve. Realita je taková, že nesprávné použití snapshotů nejenže nezlepší zabezpečení, ale může také drasticky zvýšit spotřebu úložiště, snížit výkon a dokonce poškodit virtuální počítač.
Abyste se mohli dobře rozhodovat, musíte plně pochopit, co snapshot je, co není, jak funguje „pod kapotou“ a jaké jsou osvědčené postupy, jak zabránit poškození počítačů nebo diskového pole . Podívejme se na to klidně, ale s technickým přístupem a praktickým pohledem, stejně jako to dělají ve skutečných datových centrech.
Co je to vlastně snímek (a co není)
Snímek, ať už ve VMware, Hyper-V nebo úložných systémech, je snímek stavu virtuálního počítače nebo svazku v určitém časovém bodě . Zmrazí situaci – stav disku a volitelně paměti a aplikací – abyste se v případě problému mohli vrátit k danému bodu.
Klíčem je, že se nejedná o úplnou, nezávislou kopii dat . Snímek funguje jako „logická fotografie“ základního disku a poté zaznamenává změny, ke kterým od tohoto okamžiku dochází. To umožňuje velmi rychlou obnovu, protože vyžaduje pouze přesměrování ukazatelů, aniž by se musely přesouvat terabajty dat.
V mnoha prostředích byly snapshoty mylně považovány za záložní systémy. Tato záměna je nebezpečná : snapshot závisí na původním disku, úložném poli a celém řetězci diferenciálních disků. Pokud v tomto řetězci něco selže, může se stát, že se ani snapshot, ani virtuální počítač nespustí.
Na platformách, jako je VMware, se rozlišuje mezi snapshoty paměti (které také ukládají obsah paměti RAM a přesný stav provádění) a umlčenými nebo aplikačně konzistentními snapshoty, které pomocí nástrojů, jako jsou VMware Tools, zajišťují konzistentní stav souborového systému a určitých aplikací .
Jak funguje snapshot na úrovni bloku a disku
Abychom pochopili, proč nadměrné používání snapshotů může poškodit počítače nebo snížit výkon, je užitečné si představit, co se děje s bloky na disku. Představte si virtuální počítač s jedním virtuálním diskem složeným z bloků A, B, C, D a E. Dokud neexistují žádné snapshoty, veškerá změna se zapíše přímo na tento disk : pokud je blok A upraven, stane se A', a pokud přidáme nový blok F, disk se zvětší.
Při vytvoření prvního snapshotu se původní disk „zmrazí“ a bude pouze pro čtení. Od tohoto okamžiku se všechny změny přesměrují na nový diff disk (například další VMDK ve VMware). Snapshot neduplikuje všechna data; pouze začne ukládat upravené bloky na daný podřízený disk.
Pokud po prvním snímku změníte A' a B a přidáte nový blok G, základní disk stále obsahuje A, B, C, D, E a F, zatímco diferenciální disk ukládá A'' (nový A), B' a G. Skutečná logická velikost virtuálního počítače by nyní byla 7 bloků, ale v datovém úložišti mezi základním a diferenciálním diskem již zabíráte 9 bloků . Tam začíná tichý růst.
Pokud vytvoříte další snapshot, aktuální diferenciální disk se také zmrazí a vytvoří se druhý diferenciální disk, na který budou uloženy nové změny (A''', D', E', H atd.). Výsledkem je řetězec propojených disků, kde každý z nich závisí na předchozím . V příkladu původního obsahu zabírá základní disk 6 bloků a diferenciály nyní činí celkem 7, což znamená, že virtuální počítač spotřebuje v datovém úložišti celkem 13 bloků – více místa ve snapshotech, než je původní velikost disku.
Tato architektura má i nevýhodu: výkon. Když systém potřebuje přečíst blok, například C, nejprve se podívá na naposledy přístupný diferenciální disk ; pokud tam není, přesune se na další v řetězci a tak dále, dokud nedosáhne základního disku. U dlouhých řetězců zahrnuje každé čtení více kroků, což má za následek vyšší latenci a pomalejší operace, zejména u mechanických disků a velmi aktivních virtuálních počítačů.
Copy-on-Write, Redirect-on-Write a jejich dopad
Implementace snapshotů se obvykle spoléhají na dvě hlavní techniky: Copy-On-Write (COW) a Redirect-On-Write (ROW) . Obě se zaměřují na stejný cíl (zachování předchozího stavu), ale s různými kompromisy mezi výkonem a fragmentací.
V systémech Copy-On-Write systém při úpravě existujícího bloku nejprve zkopíruje starý blok do oblasti snapshotů a poté zapíše nová data na jejich původní pozici. Tím se zachová předchozí verze, ale každá operace zápisu je penalizována, protože se stává sekvencí čtení-kopírování-zápisu.
Přístup Redirect-On-Write, používaný v mnoha moderních systémech a některých pokročilých NAS a souborových systémech, funguje obráceně: stará data zůstanou tam, kde jsou, a nová data se zapíší na jiné fyzické místo . Snímky ukazují na „staré“ bloky a aktivní svazek aktualizuje své ukazatele na nové. Výkon zápisu je mnohem lepší, ale to je za cenu zvýšené fragmentace.
Tato fragmentace obvykle nepředstavuje u all-flash úložišť zásadní problém, ale u tradičních nebo hybridních pevných disků může velký počet snímků a trvalých změn snížit rychlost čtení . Proto mnoho výrobců doporučuje kombinovat tyto technologie s automatickými systémy reorganizace nebo se zcela rozhodnout pro flash úložiště, pokud plánujete v průběhu času pracovat s mnoha datovými body.
Proč snapshoty NEJSOU zálohy
Jedním z nejdůležitějších sdělení je, že ať jsou snapshoty jakkoli pohodlné, nenahrazují tradiční zálohy . Technicky vzato neslouží stejnému účelu ani nenabízejí stejnou úroveň ochrany před katastrofami.
Úplná záloha vytvoří repliku dat na jiném úložném médiu: jiném úložném poli, jiném datovém úložišti, pásce, cloudu atd. Pro minimalizaci rizik lze použít pravidlo 3-2-1 (tři kopie, dvě různá úložná média, jedno mimo pracoviště). Pokud datové centrum vyhoří, úložné pole selže nebo někdo smaže svazek, kopie tam stále zůstane, protože se nachází jinde.
Snímek na druhou stranu závisí na stejném hardwaru a stejném úložném fondu. Pokud dojde k selhání úložného pole, poškození datového úložiště nebo k vymazání svazku útokem, všechny snímky se s ním ztratí . Navíc, jak jsme již viděli, v mnoha implementacích závisí všechny snímky na řetězci disků; pokud se jeden článek v tomto řetězci poškodí, můžete ztratit všechny související verze.
Také nejsou ekvivalentní, pokud jde o obnovu jednotlivých položek. Snímek je obvykle navržen tak, aby obnovil celý virtuální počítač do určitého časového bodu , nikoliv k podrobné obnově jednoho souboru, databázové tabulky nebo poštovní schránky. Tuto možnost nabízejí zálohovací řešení, která spolupracují s agenty, integracemi aplikací nebo zálohovacími prohlížeči.
V náročných prostředích je nutné kombinovat oba přístupy: snímky pro rychlé a krátkodobé body obnovy a zálohy pro historii, dlouhodobé uchovávání, ochranu mimo pásmo a granulární obnovu.
Nejlepší postupy pro používání snapshotů, aby se zabránilo poškození počítačů
Vzhledem k tomu, že snapshot není záloha, další otázkou je, jak je bezpečně používat. Existuje řada doporučení sdílených výrobci jako VMware, Microsoft a poskytovateli úložišť, která pomáhají předcházet problémům, jako je poškození, nekontrolovaný úložný prostor a pokles výkonu.
Prvním pravidlem je selský rozum: neshromažďujte staré snapshoty, pokud se k nim nehodláte vrátit . Pokud víte, že byste neobnovili kritický virtuální počítač do bodu v čase před měsíci (protože by jeho datový stav již nebyl relevantní), je tento snapshot zbytečný a pouze zvyšuje riziko. Rozumné je ho smazat.
Výrobci obvykle doporučují uchovávat každý snímek po omezenou dobu. Například ve VMware se výslovně nedoporučuje uchovávat jeden snímek déle než 72 hodin, protože soubor diff se s tím, jak virtuální počítač provádí změny, zvětšuje. Čím déle zůstane, tím větší se stane a tím dražší bude jeho konsolidace.
Dalším jasným osvědčeným postupem je omezit počet simultánních snapshotů na počítač . Ačkoli technicky vzato jich můžete vytvořit desítky (ve VMware je teoretické maximum kolem 32), v praxi je nejlepší držet se maximálně 2 nebo 3. Více snapshotů znamená delší řetězce, vyšší latenci čtení a složitější konsolidaci.
Důrazně se doporučuje vytvářet snapshoty, když virtuální počítač nezaznamenává vysoké špičky I/O. Generování snapshotu přímo uprostřed nárůstu zápisů může způsobit selhání při vytváření snapshotů nebo systém uvést do nekonzistentního stavu. U kritických databází nebo aplikací je nejlepší koordinovat s obdobími nižší aktivity nebo používat snapshoty konzistentní na úrovni aplikací.
Jak dlouho je uchovávat, kolik jich používat a jak s nimi zacházet
Správa snapshotů nespočívá jen v kliknutí na tlačítko „pořídit snímek“ a zapomenutí na něj. Vyžaduje jasné zásady pro vytváření, používání a mazání snapshotů , zejména v prostředích s desítkami nebo stovkami virtuálních počítačů.
V produkčním prostředí je nejrozumnějším přístupem vytvářet snapshoty těsně před konkrétními operacemi: změnami konfigurace, aktualizacemi systému, opravami aplikací, interními migracemi atd. Jakmile se ověří, že vše funguje správně, doporučuje se snapshot okamžitě smazat . Čím méně snapshotů je, tím nižší je pravděpodobnost vzniku problémů.
Je také vhodné doplnit ruční správu automatizovanými mechanismy čištění. Ve správcích vCenter nebo Hyper-V je možné pravidelně kontrolovat strom snímků, zjistit, které snímky jsou aktivní, jejich velikost a stáří, a odstranit ty, které překročily maximální časový limit stanovený interní politikou.
Je nezbytné vždy mazat snapshoty pomocí oficiálních nástrojů (vSphere, Hyper-V Manager, CLI výrobce úložného pole atd.) a nechat systém, aby konsolidaci zvládl. Jejich smazání jakýmkoli jiným způsobem nebo přerušení procesu konsolidace v průběhu může způsobit nekonzistentní stav disků a dokonce i poškození virtuálního počítače.
Pokud jde o kvantitu, vyvážený přístup spočívá v práci s maximálně jedním nebo dvěma aktivními body v citlivých prostředích a uvolněnější přístup (tři nebo čtyři) v laboratorních prostředích, kde je riziko nižší a flexibilita je ceněna více než extrémní výkon.
Dopad na výkon, prostor a konsolidaci disků
Kromě rizika poškození je nejčastějším vedlejším účinkem zneužití snapshotů nízký výkon. Pokaždé, když přidáte nový diferenční disk, přidáte také další krok v řetězci čtení . To je obzvláště patrné u virtuálních počítačů s mnoha náhodnými operacemi s disky, jako jsou databáze nebo souborové servery.
Během operací čtení musí hypervizor nebo úložné pole vyhledat požadovaný blok, počínaje nejnovějším snímkem a postupně zpět k základnímu disku. U dvou snímků může být dopad malý, ale u dlouhých řetězců a vysoce fragmentovaných disků může být uživatelská zkušenost frustrující.
V oblasti úložišť jsou ilustrativní příklady z reálného světa. Je poměrně běžné najít virtuální počítače s logickým diskem například o velikosti 2 TB, které však v datovém úložišti zabírají 4 nebo 5 TB kvůli snapshotům zapomenutým po léta. Každá denní změna v databázi, každý soubor, který do ní vstoupí nebo ji opustí, zahlcuje disky nesrovnalostmi, aniž by si toho kdokoli všiml, dokud v úložném poli nedojde místo.
Když je čas smazat staré snímky, proces konsolidace může být zdlouhavý a delikátní. Konsolidace zahrnuje sloučení všech změn uložených na rozdílových discích do jejich nadřazeného disku , jednu po druhé, dokud není celý řetězec integrován do základního disku. Na virtuálních počítačích s velkými objemy dat a roky změn se to promítá do hodin intenzivních operací čtení/zápisu.
Tato prodloužená konsolidace nejen ovlivňuje výkon, ale jakékoli přerušení nebo chyba během procesu může způsobit, že se stroj dostane do nekonzistentního stavu . Proto je důležité nenechat snímky narůstat donekonečna a plánovat konsolidační úlohy v obdobích nižšího zatížení s řádným monitorováním.
Snímky, ransomware a kybernetická odolnost
V posledních letech ransomware přidal k problému další vrstvu složitosti. Útočníci se již nespokojí s pouhým šifrováním uživatelských souborů: vyhledávají přihlašovací údaje správce, nacházejí zálohy, mažou snímky a snaží se vám zanechat žádný čistý bod, ke kterému byste se mohli vrátit.
To zdůrazňuje omezení modelů založených výhradně na tradičních zálohách bez dodatečné ochrany. Pokud jsou zálohy přístupné pomocí stejných kompromitovaných přihlašovacích údajů nebo pokud lze snímky snadno smazat z administračního panelu, může útočník opustit prostředí bez bezpečnostní sítě během několika minut.
V této souvislosti se mnoho výrobců úložišť rozhoduje pro neměnné snapshoty integrované přímo do úložného pole. Tyto časové body, jakmile jsou vytvořeny a uzamčeny, nelze během doby jejich uchování upravovat ani mazat, a to ani účty s nejvyššími oprávněními . Jde o druh WORM (Write Once, Read Many) aplikovaného na snapshoty.
Neměnnost poskytuje velmi silnou obranu: i když útočník získá administrátorský přístup, nemůže chráněné snímky smazat, dokud nevyprší jeho uzamykatelné okno . Díky tomu máte k dispozici alespoň jednu sadu čistých bodů obnovy pro obnovení systémů po útoku.
Kromě neměnnosti některé pokročilé systémy používají analýzu entropie a umělou inteligenci u zapsaných bloků k detekci typických vzorců hromadného šifrování . Když detekují anomální nárůst náhodného zápisu a náhlé změny entropie, mohou automaticky spustit vytváření chráněných snapshotů nebo dokonce podezřelému klientovi zakázat přístup k zápisu.
Snímky úložiště vs. snímky operačního systému
Snímek spravovaný na hypervisoru nebo úložném poli není totéž co stínové kopie svazků operačního systému (například VSS ve Windows). Toto rozlišení je důležité i v případech ransomwaru.
Mnoho moderních malwarových programů po vstupu na server Windows provede příkazy k odstranění všech stínových kopií a zabrání obnovení systému do předchozího stavu pomocí jeho nativních nástrojů. Uživatel tak nemá snadnou možnost „obnovit předchozí verzi“.
Snapshoty spravované na NAS nebo SAN jsou však obvykle nezávislé na operačním systému. Jejich správa probíhá mimo pásmo, přímo ze samotného úložiště. I když útočník smaže VSS v systému Windows, tyto snapshoty úložného pole zůstanou nedotčené a s dobře definovaným postupem obnovy se můžeme vrátit do předchozího stavu.
Proto mají moderní architektury dvojí úroveň ochrany: snapshoty v úložišti pro odolnost proti útokům na operační systém a externí zálohy s neměnností a logickým oddělením pro pokrytí scénáře fyzické katastrofy nebo hlubokého ohrožení.
V každém případě je důležité zdůraznit, že i ty nejsofistikovanější snapshoty úložiště stále závisí na systému, ve kterém se nacházejí. Pokud dojde ke ztrátě nebo úplnému poškození úložného pole, ztratí se i jeho snapshoty . To posiluje potřebu udržovat zásady zálohování, které dodržují princip 3-2-1, a v kritických prostředích dokonce používat zálohy s oddělenou mezerou.
Snímky v testovacím, vývojovém a produkčním prostředí
Ne všechna prostředí těží ze snapshotů stejným způsobem a neměly by být spravovány stejným způsobem. V laboratořích a vývojových prostředích jsou snapshoty neocenitelné, protože umožňují testovat agresivní změny, nasazovat experimentální verze softwaru nebo simulovat selhání a během několika sekund se vrátit do výchozího bodu.
V těchto scénářích je obvykle menší tlak na výkon a větší tolerance k riziku. I tak je však moudré omezit příliš dlouhé řetězce a vyčistit staré snapshoty , aby se zabránilo zahlcení úložného pole technickým harampádím, jehož účel si nikdo nepamatuje.
V produkčním prostředí by měl být přístup mnohem konzervativnější. Zde by se snapshoty měly používat jako dočasná pojistka před kontrolovanými změnami : před velkou záplatou, aktualizací databáze, citlivou změnou konfigurace atd. Jakmile je ověřena stabilita, snapshot se smaže a ochrana je ponechána na záložním systému.
Aplikační servery s více závislostmi (externí databáze, webové front-endy, LDAP atd.) vyžadují zvláštní péči. Návrat pouze jednoho uzlu ke starému snapshotu může vést k nekonzistentnímu stavu celého systému . Před použitím snapshotů v těchto typech architektur je nezbytné posoudit, zda aplikace podporuje tento typ částečného vrácení zpět, nebo zda jsou vhodnější jemnější obnovy.
A konečně, v kritických systémech s vysokou dostupností a velmi přísnými požadavky na RTO mnoho organizací kombinuje neměnné snapshoty ve flash úložišti s mechanismy okamžité obnovy ze záloh . Tím se dosahuje rovnováhy mezi velmi nízkými dobami návratu a robustní ochranou proti rozsáhlým katastrofám.
Efektivní správa snapshotů vyžaduje pochopení toho, že jsou to mocné nástroje, ale s jedním háčkem: pokud jsou zneužity, mohou drasticky zvýšit spotřebu místa na disku, snížit výkon a nechat vás bez funkčního virtuálního počítače přesně ve chvíli, kdy ho nejvíce potřebujete . S moudrým použitím, s krátkými politikami uchovávání, krátkými řetězci snapshotů, plánovanými konsolidacemi a vždy podporovaným robustním zálohovacím systémem (ideálně s neměnností a logickým oddělením) se stávají klíčovým spojencem v boji proti lidským chybám, rizikovým změnám a útokům ransomwaru, aniž by poškozovaly počítače nebo ohrožovaly stabilitu prostředí.
