Dnes na první pohled možná z trošku jiného soudku. Uvědomte si ale, že spolehlivost a dostupnost jsou základní bezpečnostní požadavky, takže se zase až tak moc od svého obvyklého směru neodchyluju.
Dnes na věčné téma - snapshot (dnes checkpoint) - a na dnes ještě aktuálnější téma Hyper-V replikace.
Bohužel, pořád si někdo myslí, že se jedná o zálohování. Tohle nemá nic společného se zálohováním. V případě Hyper-V replikace (Hyper-V replication) se GUI dokonce tváří, že vytváří tzv. "application consistent recovery point", což je značně matoucí a přitom to taky není zálohování. Špatně to chápat může být smrtící. Když takovou "zálohu" obnovíte, buď si něco nenávratně poškodíte, nebo budete následujících x let řešit opakující se problémky a latentní bugy.
Přehled technologií
Hyper-V nabízí následující technologie, které se nějakým způsobem dotýkají pojmu "zálohování", a které nějak řeší data uložená ve VHD a VHDX souborech.
- snapshot, neboli checkpoint od Windows 2012 (pouze změna názvu, jinak se nic nemění) - prostě si uděláte v jednom okamžiku snímek virtuálního počítače. Tedy obsahu jeho VHD a VHDX disků a paměti RAM, pokud virtuálka zrovna běží. Mohli bychom to tedy nazývat offline a online snapshot, tedy buď děláte snapshot z vypnutého VM, nebo z běžícího. To stejné jako snapshot/checkpoint je i export.
- storage migration - Windows 2012 umí přesunout VHD i VHDX soubory za jízdy virtuálního počítače na jiné úložiště. V případě VHDX souborů můžete přesouvat i na sdílený SMB adresář. Prostě virtuálka jede celou dobu z původního virtuálního hard disku, jakmile je dokopírováno, virtuálka se "pausne", dokopíruje se posledních pár bajtíků a přehodí se to na nové umístění.
- live migration - virtuální disky zůstávají na stejném místě, jenom se přehodí RAM paměť mezi dvěma stroji, klidně za jízdy virtual machine.
- Hyper-V replication - Windows 2012 umí kopírovat VHD a VHDX soubory a jejich změny plynule na pozadí na jiný Hyper-V hostitelský stroj. Kopírování neprobíhá úplně plynule, dělá se v balících jednou za 30 sekund, jednou za 5 minut, nebo jednou za 15 minut. Takže na cílovém stroji budete mít několik sekund, nebo minut starou verzi VHD a VHDX souborů. Na co je replikace dobrá se dozvíte na konci.
- asynchronní mirroring na diskovém poli - relativně levnější hardware technologie, kdy se pole umí samo o sobě kopírovat na jiné diskové pole. Dělá to asynchronně, to znamená, že na druhém poli máte o něco starší stav disků.
- syncronní mirroring na diskovém poli - ultra mega drahá hardware technologie, kdy se pole miroruje synchronně hned při zápisu každého bloku, takže na druhém poli je v každém okamžiku to stejné.
Storage migration a live migration náz nezajímá, protože v těchto dvou případech se nemůžete vrátit ke staršímu obsahu VHD/VHDX souborů. Zatímco v případě snapshotu/checkpointu a Hyper-V repliky si vrátit starší verzi disků můžete.
A to je ten kámen úrazu.
Obnovit starou verzi VHD nebo VHDX může být smrtící
Už se docela ví, že není zdravé obnovovat jen tak snapshot. Ale ono je to stejné v případě Hyper-V repliky!!! Ani tam to nedělejte. Detaily zde.
Máte řekněme server. Například databázový, nebo Active Directory, nebo Exchange, nebo SMB souborový, nebo cokoliv. Co se asi stane, když ten server vrátíte datově o pár sekund/minut/hodin/dnů zpátky? Mohlo by se zdát na první pohled, že nic podstatného. Prostě přijdete o ta data, která se uložila v té "obnovovací díře" - prostě tam nebudou nějaké soubory, nebo maily, nebo třeba několik uživatelů bude mít zase staré heslo, protože si ho mezitím změnili.
Tak to by až tak nevadilo. S tím se snad počítá, že když obnovuju zálohu, že tam budou jen starší data.
Jenže je jiný problém. Replikace. Všechny tyto technologie obvykle nabízí nějakou formu své vlastní aplikační replikace. V případě Exchange máte dokonce replikací stovky nebo i tisíce. On si totiž každý Outlook ve skutečnosti replikuje obsah svého mailboxu k sobě do offline složek (OST soubor). V případě SMB serveru je tam taky podobná klientská replikace nazvaná offline files.
Obecně bych řekl, že více počítačů nějak sdílí data.
Jak fungují replikace
Představte si, že Outlook replikuje z Exchange tisíce, nebo miliony jednotlivých mailů a schůzek. Asi těžko to bude dělat tak, že by při každém spuštění projel seznam všech mailů, které jsou v Exchange a porovnal to s tím, co má u sebe, a zbytek si dostáhl. Že? Samozřejmě stahuje jen "novinky".
Na druhou stranu musí být schopen zpět do Exchange uložit všechno, co se u něho vytvořilo v průběhu doby, co byl odpojen od sítě. Na to tam přece právě máte ten offline mode.
Příklad - jste offline, vytvoříte si v Outlooku nový kontakt, a nějaký jiný si upravíte. Za hodinu se připojíte a Outlook tyto dvě modifikace nahraje zpět do Exchange. Jakmile aktualizace na nějaké položce proběhne, už nikdy se nedělá znovu. Proč taky, že? Takže položky, které už byly synchronizovány, se znovu nesynchronizují.
Co je "nové" se pozná podle nějakého celosystémového čítače, obvykle. V případě Active Directory se to nazývá universal serial number (USN). Jak se to jmenuje v Outlooku nevím.
Co se stane, když vy jednu stranu replikace natvrdo vrátít v čase zpět? Řekněme, že vrátíte zpět Exchange databázi o jeden den. Vrátíte zpět snapshot/checkpoint, nebo Hyper-V replica. Exchange se vrátí zpět, aniž by to sám věděl. Nebude mít tedy nějaké kontatky a maily, které jsou v OST souborech na klientech. Jenže Exchange neví, že byl vrácen zpět. Neví to ani Outlooky.
Znamená to, že položky, které byly synchronizovány v té "obnovovací díře" se už nikdy nebudou synchronizovat z Outlooku zpět do Exchange. V Exchange mailboxu budou tedy chybět buď úplně, nebo tam budou ve své starší verzi. To je mejhem! Každý Outlook bude nějak poškozen.
Jaký by byl rozdíl, kdybyste provedli skutečnou obnovu Exchange databáze? Provedli byste to za plného vědomí Exchange. Exchange by sám věděl, že byl vrácen o nějaký čas zpět. Tohle by řekl všem klientům. A všechny Outlooky by provedly násilnou re-synchronizaci všech položek, které byly změněny v oné "obnovovací díře".
To je důvod, proč Exchange nepodporuje obnovu ze snapshot/checkpoint/image/replica. To je důvod, proč to nepodpruje skoro nikdo. Kromě Active Directory na Windows 2012, pokud virtualizační platforma nabízí GenerationID. Ale já tomu stejně nevěřím. Je jednoduché to poškodit.
Vemte si jiný příklad WSUS a aktualizací na stanicích. Jak probíhá detekce? Myslíte, že Windows Update client pokaždé projíždí celý seznam všech nabídek? Nebo si stanice pamatuje co už všechno chtěla/nechtěla a znovu to nedetekuje? Můžete tedy ze snapshot/replica vrátit WSUS server? To já nevím.
Co vím, je že nikdy nevíte, dokud vám výrobce konkrétní aplikace nepotvrdí, že to umí. Tak jako to potvrzuje v případě Active Directory. Jak se chová DNS? Jak se chová DHCP replika? Jak se chová certifikační autorita a certifikátoví klienti? Vy to víte? A garantujete?
V ostatních případech musíte bezpodmínečně provádět korektní podporovanou aplikační obnovu ze skutečné aplikační zálohy. Takže i pro WSUS atd.
Nikdy nevíte.
To je stejné, jako když máte nějaký hardware mirroring na diskovém poli. Na to, aby to fungovalo korektně, musíte mít synchronní mirroring. Tzn. na druhém poli máte data synchronně mirorovaná ještě předtím, než pole dá vědět OS, že se data zapsala. To je drahé jako peklo.
Na co je tedy snapshot/checkpoint
Samozřejmě na pokusy. Pro obnovu to můžete také použít, jako startovní bod. Nahodíte snapshot BEZ SÍŤOVÉHO PŘIPOJENÍ a až to naběhne, provedete uvnitř korektní aplikační obnovu. Teprve potom můžete připojit do zbytku prostředí.
Na co je Hyper-V replika
Hyper-V replica může sloužit zase jako startovací bod pro manuální aplikační obnovu, stejně jako checkpoint. Na co je ale výborná je plánovaný failover (planned failover). Tedy přenos virtuálního počítače plánovaně na totálně jiný Hyper-V hostitel. Tady nenastává problém s vracením se k minulému stavu, ale plynule přecházíte z jednoho hostitele na druhého.
A samozřejmě na pokusy. Na to tam je právě ten "application consitent recovery point".
Hyper-V replika a application consistent recovery point
Co to je? Když se dělá replika, je to trošku divné. Replikuje se totiž jen storage. Tedy VHD a VHDX. Za jízdy virtuálního stroje. Pokud obnovíte nějakou repliku (tzn. neděláte planned failover), tak obnovujete vlastně stroj, který jste vytrhli z napájení. Tedy po tvrdém restartu.
V takovém případě vám nemusí už databázový systém (speciálně Exchange) naběhnout. Prostě vytrhnout Exchange, AD, nebo DHCP a certifikační autoritu, nebo i jen registry z napájení může být smrtící. Hyper-V replica umí tedy vyžádat, před odkopírováním, volume shadow copy (VSS), kdy se aplikace dozví, že bude vyrvána ze zásuvky a korektně se na to připraví.
Je tedy Hyper-V replica backup? Ne!!!
Znamená to, že pokud obnovíte starší obyčejný recovery point, tak nemusí vám ta virtuálka naběhnout vůbec. Zatímco když obnovíte starší application consistent recovery point, virtuálka vám zaručeně sama o sobě naběhne v pořádku. Ale do sítě to stejně pustit nemůžete, protože jste obnovili ve skutečnosti snapshot/checkpoint. Tak bacha!
Co z toho plyne?
Virtualizace sama vám nikdy v životě nemůže nabízet službu spolehlivého zálohování a obnovy. Obnovu musíte vždy provádět podle návodu výrobce každé jednotlivé aplikace, kterou provozujete! Musíte obvykle zálohovat "uvnitř virtuálního počítače" pomocí nějakého agenta a obnovit to opět uvnitř jedoucího a vědoucího virtuálního počítače a jeho aplikace.