Dnes znovu s potěšením představuji užitečné rady od mého kolegy Evgenije Ivanova, team leada technické podpory Veeam. Tentokrát se Ženja podělil o doporučení pro práci s zálohami a replikami. Doufám, že vám pomohou vyhnout se typickým chybám, a vaše repliky a zálohy nikdy nebudou 'slabým článkem' v procesu obnovy, pokud to bude potřeba.

Takže, vítejte pod článkem.

V předchozím článku článku jsme se zabývali tím, jak optimalizovat zátěž na komponenty infrastruktury zálohování a zvažovali jsme typické chyby konfigurace. Přecházíme k další důležitému tématu – správné přípravě a provedení obnovy. To také probereme na skutečných příkladech, se kterými měla naše technická podpora příležitost pracovat.

Záloha bez restaurace – peníze vyhozené oknem

Často se na nás obracejí uživatelé, kteří se ocitli v podobných obtížných situacích: je třeba provést obnovu ze zálohy, ale při pokusu o to narazí na pro ně neřešitelný problém. A tímto problémem není vůbec nedostatek záložní kopie, činnost CryptoLocker nebo něco podobného. Je to 'pouze' nedostatečná pozornost věnovaná kontrole záloh a replik na možnost obnovy. Mnozí se často soustředí výhradně na proces vytváření zálohy, zapomínají na to, že prosté existování záložní kopie není zázračné řešení proti možným problémům. Je třeba chápat, že obnova je zcela jiný proces, který má své specifické vlastnosti a který je nutné monitorovat a testovat před uvedením do produkce. Zde je několik ukázkových příkladů:

U uživatele došlo k selhání kritické virtuálního stroje o velikosti 20 TB. Výpadky, jak jinak, jsou nepřijatelné a administrátor spouští proces okamžité obnovy (VM instant recovery) – za 5 minut je stroj opět v chodu. Ale pamatujeme si, že takový stav stroje může být využit pouze dočasně – je nutné jej migrovat do produkčního datastoru (datastore). A v tomto případě se ukázalo, že možnosti infrastruktury nedovolily zkopírovat 20 TB dat v rozumném čase. V nastavení procesu okamžité obnovy bylo zvoleno uchovávat změny na disku. Z: servery Veeam Backup & Replication (na rozdíl od snapshotu vSphere) – v důsledku toho se samozřejmě volné místo na disku rychle zaplnilo. Do doby, než se uživatel obrátil na podporu, se na VM objevily změny, které nebylo možné ignorovat. To znamená, že jsme měli situaci, kdy nebylo možné rychle finalizovat proces okamžité obnovy kritického zařízení – jak tedy zachránit data?
Musím přiznat, že si už příliš nepamatuji detaily finále, ale pamatuji si, že jsme nakonec nevymysleli nic geniálního. Klienti na své straně tak nějak vyřešili tento problém rozšířením disku C: z rezerv, zkopírovali ty nejdůležitější soubory a pak vypnuli VM a tímto způsobem migrovali. Zkrátka, zázrak se nekonal.
V infrastruktuře uživatele pracoval jeden řadič domény a všechny komponenty Veeam Backup & Replication byly nakonfigurovány pomocí DNS. Ano, ano, určitě jste slyšeli správně. Možností, jak by se situace mohla vyvinout, byla stovka, ne méně, ale realita vypadala takto: lidé naplánovali údržbu a rozhodli se přepnout na repliku svého doménového řadiče. Použili plánované přepnutí, což je v podobných případech doporučeno. V prvním kroku vše probíhalo v pořádku, ale ve druhém byla původní VM na chvíli vypnuta, aby se přenesly zbývající data. Samozřejmě, úloha přepnutí okamžitě selhala, protože DNS přestalo fungovat.
Naštěstí se nám podařilo vyřešit situaci tím, že jsme manuálně aktivovali repliku z vSphere (tuto operaci byste měli provádět sami na vlastní nebezpečí, jak uvidíte v následujícím příkladu). Ale, jak chápete, proces údržby byl přerušen a odložen. Navíc jsme museli manuálně přidat jména hostitelů do souboru C:WindowsSystem32driversetchosts na serveru Veeam Backup & Replication, abychom zajistili správnost při zpětném přepnutí.
U jednoho klienta byla celá infrastruktura zálohování postavena na magnetických pásech, přičemž na pevných discích byly uloženy pouze krátké řetězce souborů. Když bylo třeba obnovit několik souborů z velkého souborového serveru, zjistilo se, že žádný stroj nelze použít jako pomocný repozitář pro obnovu z pásu, protože na žádném z nich nebylo dostatek volného místa. (O obnově přímo z magnetického pásku a s využitím pomocného repozitáře si můžete přečíst zde (zatím jen v angličtině)).

Myslím, že ve všech třech případech byli uživatelé, tak říkajíc, v zajetí iluzí – předpokládali, že pokud záloha proběhla úspěšně, s obnovou nebude problém. Ale, jak víte, to zdaleka není vždy pravda, a proto je třeba se na obnovu připravit stejně pečlivě jako na zálohování. Nejprve byste měli prozkoumat uživatelská příručka, kde je uvedena poměrně podrobná informace o různých typech obnovy. Na začátku každého odstavce jsou uvedeny požadavky, přípravné kroky a možná omezení. Popis obnovy z magnetických pásek nebo z hardwarových snímků úložišť lze najít v sekcích dokumentace a v našich článcích na Habru. Kromě toho jsou akce k přípravě obnovy objektů aplikací pomocí nástrojů Veeam Explorers popsány v sekci „Planning and preparation“ (plánování a příprava) návody pro každý z těchto nástrojů. Doporučuji se s nimi důkladně seznámit – pomůže vám to správně připravit systém k obnově v případě potřeby. V ruštině jsou instrukce pro obnovu databáze SQL Server uvedeny zde.

Proč byste neměli pracovat s replikami z konzole vSphere?

Teoreticky jsou repliky Veeam běžné virtuální stroje, se kterými by mělo smysl pracovat pomocí nástrojí vSphere, zejména klienta vSphere. Avšak nedoporučujeme to a zde je důvod: přepnutí na repliku v Veeam Backup & Replication je poměrně složitý proces, který vyžaduje striktní a sekvenční provádění kroků (aby bylo možné se v případě potřeby vrátit zpět) a správné závěrečné akce – podívejte se na obrázek ilustrující proces:

Pokud se rozhodnete zapnout replikaci ze vSphere klienta, pravděpodobně vás čeká řada problémů:

Mechanismus přepnutí na replikaci z Veeam Backup & replication (znázorněný na schématu) už pro tento server nebude fungovat.
Data v databázi Veeam Backup nebudou odpovídat skutečnému stavu VM. V nejhorším případě bude třeba upravit databázi.
Dokonce může dojít k ztrátě dat, jako v tomto příkladu: uživatel ručně zapnul replikaci v vSphere klientu a rozhodl se s ní pokračovat v práci. Po nějaké době si všiml, že replikace se stále zobrazuje v konzoli Veeam Backup & Replication, a rozhodl se ji odstranit, protože byla zbytečná. Klikl na ni pravým tlačítkem a dal příkaz „Smazat z disku“. Veeam Backup & Replication okamžitě smazal z disku replikaci, která byla mezitím využívána jako běžná VM a obsahovala potřebná a užitečná data.

Samozřejmě existují situace, kdy je třeba přesto zapnout replikaci ze vSphere klienta – zpravidla to bývá, když je server Veeam vypnutý a replikaci je třeba zapnout se zpožděním. Ale pokud je server Veeam v pořádku, měly by se replikace používat výhradně z jeho konzole.

Také byste neměli odstraňovat replikace pomocí vSphere klienta. Veeam Backup & Replication si nebude vědom této změny, což může vést k chybám a zastaralým datům. Pokud replikaci již nepotřebujete, odstraňte ji pomocí konzole Veeam, a ne jako VM z vSphere klienta. Tak budete mít vždy aktuální seznam replik.

„O“ — pozor, aktualizace!

Zde máme na mysli samozřejmě aktualizace pro hypervisory a různé aplikace, které jsou zálohovány pomocí Veeam. Z pohledu práce s Veeam Backup & Replication lze aktualizace zhruba rozdělit do 2 kategorií: velké, vážné, přinášející řadu změn – a malé.

Nejprve se podíváme na první kategorii.

Nejdůležitější aktualizace jsou ty, které jsou určeny pro hypervizor. Před instalací takové aktualizace je nezbytné ověřit, že je podporována aplikací Veeam Backup & Replication. Tyto aktualizace přinášejí mnoho změn v knihovnách a rozhraních API, které Veeam Backup & Replication používá, takže pro oficiální potvrzení jejich podpory je třeba aktualizovat kód Veeam Backup & Replication a provést důkladné testování.

Je třeba mít na paměti, že například VMware neposkytuje předběžný přístup k nejnovějším verzím vSphere výrobcům software, takže vývojáři a testeři Veeam dostávají novou verzi současně se zbytkem pokrokové společnosti – proto mezi vydáním VMware a oficiálně vyhlášenou podporou obvykle uběhne určitý čas. Počet a rozmanitost potřebných změn je takové, že je málo pravděpodobné, že by se je podařilo vtěsnat do jednoduchého hotfixu – a oficiální podpora je obvykle oznámena spolu s vydáním verze Veeam Backup & Replication.

V důsledku toho nastává ten nepříjemný moment, kdy po vydání nové verze vSphere dramaticky vzrůstá počet požadavků na technickou podporu, protože uživatelé se neúnavně snaží nainstalovat novou verzi, a jejich zálohy samozřejmě okamžitě přestávají fungovat. Nám – technické podpoře Veeam – nezbývá nic jiného, než vysvětlovat uživatelům, co přesně udělali špatně, nebo je prosit, aby se vrátili zpět (pokud je to možné) nebo vymýšlet složité cesty, jak se dostat z této situace. Proto před instalací důležité aktualizace vždy zkontrolujte její kompatibilitu s již běžícím softwarem, velmi vás prosím!

Všechny výše uvedené informace se vztahují také na aplikace, které zálohujete a plánujete obnovit pomocí Veeam. Nástrojová řada Veeam Explorers má také seznam podporovaných verzí příslušných aplikací, který se s každým vydáním Veeam Backup & Replication aktualizuje. Proto před instalací nové verze vaší aplikace – ať už jde o Exchange, Oracle nebo SharePoint – vždy přečtěte příslušnou část dokumentace Veeam Explorers.

Do druhé kategorie, tj. k menším aktualizacím, řadím například nové verze VMware Tools, kumulativní aktualizace Exchange, bezpečnostní aktualizace vSphere atd. Obvykle nepřinášejí žádné zásadní změny a ve většině případů Veeam Backup & Replication s nimi nemá problémy. (Proto pro ně neexistují veřejná oznámení o oficiální podpoře v produktu.) Nicméně, v naší praxi jsme se setkali se situacemi, kdy i takové aktualizace natolik měnily obvyklý chod věcí, že vedly k chybám v provozu Veeam Backup & Replication. V takových situacích se inženýři Veeam snaží po potvrzení problému co nejdříve vydat hotfix.

Těm, kteří ovládají technickou angličtinuPokud chcete být v obraze o tom, na čem pracují inženýři a s čím se setkávají systémoví architekti a specialisté technické podpory, doporučuji se přihlásit k odběru našich fór. Každý týden pro ně vychází zpravodaj "Word from Gostev" od autora TheRealGostev. V něm Anton Gostev, vedoucí oddělení produktového managementu, informuje o nedávno nalezených problémech (a nejen na straně Veeam), plánech na nové verze a novinkách ze světa IT. Pokud potřebujete více informací, můžete prozkoumat témata fóra - pokud někdo z klientů zjistí problém s provozem produktu po nějaké aktualizaci, pravděpodobně o tom již napsal na fóru.

Jak chápete, patche a aktualizace mohou způsobit problémy nejen se zálohami, ale také s aplikacemi, pro které se tyto zálohy vytvářejí. A zde vám pomohou virtuální laboratoře - Veeam DataLabs. Určitě jste slyšeli o funkčnosti SureBackup, určené k ověřování záloh. Ta se zakládá na využití DataLabs, s vytvořením izolovaného prostředí, ve kterém můžete mimo jiné testovat aktualizace před jejich nasazením do produkce. Velmi doporučuji to udělat – ušetříte si spoustu nervových buněk. A pokud někdo ještě neví o SureBackup, doporučuji si přečíst dokumentaci.

Asi je vše, co mám pro dnešek, děkuji za pozornost!