Existuje ideální zálohování dat v on-premise prostředí?
Navážu na tématiku zálohování, po hardwarové stránce diskutovanou v jednom z předchozích článků, a podíváme se na otázku softwaru. Využijeme na to dva příklady konkurenčních řešení (Arcserve a Veeam Backup&Replication), Nicméně, stejné otázky jako u těchto dvou řešení se (ne)řeší i u dalších konkurentů, kde v rámci objektivity za všechny zmíním alespoň Symantec, Commvault, HPE či Acronis. Klást tedy stejné otázky na dodavatele zálohovacího softwaru se tedy rozhodně vyplatí, byť ho tím ne vždy potěšíte ;)
Co lze zálohovat? Zdánlivě nevinná otázka – ale skutečně je potřeba začít už na této úrovni, tj. podporou všech zdrojových systémů, ZE kterých chcete data zálohovat. Samozřejmě, že dnes asi už nenajdete žádný slušný software, který by neuměl zálohovat virtuální prostředí VMware vSphere, resp. Microsoft HyperV. Stejně tak provádění těchto záloh bezagentově, tj. na úrovni image virtuálního stroje je elementární funkčnost a možnosti jsou velmi široké. Ovšem, co když máte i další nevirtualizované zdrojové systémy? Tady už pak přituhne, zvláště když půjde nejen o Windows či Linux, ale i stále se vyskytující platformy jako je AIX, HP-UX, AS/400, VMS atp. Tam už většině vč. Veaam-u dojde dech a to je i jeden z důvodů, proč stále žije Arcserve, kde jen těžko naleznete platformu, pro kterou by nebyl příslušný agent. Veeam tímto směrem vyvíjí snahu „dohnat dějiny“ a minimálně už lze zálohovat i fyzické Windows (desktop i server) a několik Linuxů. Rovněž pozor na sice deklarovanou podporu zálohování fyzického Windows či Linux prostředí, která ale není integrovaná se zálohováním virtuálního clusteru – de facto tak máte 2 aplikace, ale nemáte centrální management celého systému zálohování, což je přinejmenším nešikovné. To se přitom může týkat i integrace záloh desktopových systémů. Zde má opět Arcserve svou přidanou hodnotu v tom, že vše – od fyzických serverových i desktopových platforem po virtuální prostředí vSphere, HyperV, XEN č KVM – je v jediném konsolidovaném dohledu! A aby toho nebylo málo – když už tedy máte zálohy fyzického či virtuálního prostředí, je dobré se optat na možnost křížové obnovy. Pro inspiraci může posloužit opět Arcserve, kde lze udělat libovolnou crossplatformní konverzi V2V a P2V, takže např. obnovit zálohu VM z vSphere do HyperV a naopak, obnovit fyzický server do virtuálního prostředí atp. - moc sexy funkčnost, nemyslíte? Lze pak např. mít na pobočkách firmy HyperV a na centrále vSphere. Zde často narazíte anebo je funkčnost velmi omezená – např. v VBR9.5 je první vlaštovkou možnost obnovit zálohu fyzického Windows prostředí do HyperV.
Kam zálohovat? Možnost volby cílového repository je dalším významným faktorem – celkem běžná je podpora diskových úložišt blokových (DAS, SAN) i souborových (NAS, NFS) a „chleba se začne lámat“ u podpory pásek a cloudů. Zálohování na pásku vč. páskových knihoven a jejich virtuálních ekvivalentů VTL je doménou zálohovacích softwarů s tradicí ala Arcserve, kde prakticky nenajdete pásku či knihovnu, která by nebyla podporována a to jak v lokálně (k backup serveru) připojené verzi, tak přes SAN - což překvapivě opět není obecná vlastnost! Veeam na podpoře pásek (které dlouho neměl vůbec) postupně zapracoval a dotahuje, nově ve v9.5. třeba přidal správu čistících pásek, jinak standardní historická funkčnost konkurence... A co třeba se zeptat na průběžné testování čitelnosti záznamu na páskách v knihovně s jejich automatickou náhradou, pokud se začne objevovat problém? Pokud se týká zálohování do cloudu, nabízí naopak Veeam daleko širší funkčnost a to jak díky podpoře více providerů, tak vlastním řešením Cloud Connect. Jeho cloudovou část si mohou poskytovatelé služby BaaS instalovat a poté je přímo prezentováno jako cílové úložiště pro vaše on-premise backup řešení, funguje optimalizace a zabezpečení přenosů. Velmi dobré a snadné. Samozřejmě, i ostatní vč. Arcserve podporují nějaké cloudové operátory buď napřímo anebo lze (v případě Arcserve) v cloudu instalovat RPS instanci (o tom dále u deduplikace) a zálohovat na ní. Ale je to poněkud víc konfigurační práce než Veeam Cloud Connect.
Konzistence záloh je zásadní téma, protože řešení vzniklé nekonzistence dat je opravdu pracná věc. Nejprve přehled možností: Inconsistent Backup – jde o prostou kopii souborů a změny dat v průběhu prováděné zálohy nejsou zachyceny vůbec, stejně tak on-line aplikace nejsou konzistentní. Postupné provádění zálohy složitějšího prostředí znamená, že soubory jsou ve verzích z různých časů = nejsou vzájemně vůbec konzistentní. Crash Consistent Backup – provede se snímek (snapshot) na úrovni souborů, tzn. že jsou zachycené navzájem ve stejném okamžiku = jakžtakž konzistentní. Odpovídá to stavu okamžitého vypnutí/zapnutí napájení serveru. Co bylo v paměti plus nedokončené on-line transakce s databázemi jsou pryč. Při obnově online aplikací se pak musí provést ručně náprava (integrace log filů, roll back u databáze atp.) File-Level Consistent Backup – všechny soubory v systému jsou v konzistentním stavu vč. neuložených změn – to je rozdíl proti CCB, kde to, co bylo v paměti, je pryč ... Konzistenci transakcí na databázi to ale neřeší. Na vSphere toto zajišťuje funkce quiescence ve VMware Tools. Transaction-Consistent Backup – ten při požadavku na zálohování prostředí použije VSS služby, které zajistí konzistentní snapshot aplikací (transakcí) a poté se provede záloha. Pro zajištění funkčnosti VSS procesu je potřeba 3 komponenty: 1. VSS Requestor = zálohovací aplikace, která spouští VSS proces a spolupracuje ev. při obnově dat (pokud není nahrazena specifickou implementací, která tuto funkčnost při obnově dat obchází). 2. VSS Writer = shromažďuje data do snapshotu – je součástí příslušné aplikace tj. SQL, Exchange, ... To je ta služba, která „vidí do prostředí aplikace“ a zajistí konzistenci. 3. VSS provider = vytvoří snapshot a ev. ho klonuje. VSS provider může být: a) hardwarový = součástí firmwaru primárního diskového pole jako je HPE 3PAR; b) softwarový = v aplikaci, která běží v rámci Windows.
Posledním rozlišením funkčnosti konzistentního zálohování pak je otázka, zda k jeho realizaci musíme instalovat agenta (zálohovacího softwaru) „dovnitř OS“ anebo je agentless, kdy se data zálohují prostřednictvím služeb hypervizoru virtuálního prostředí. Agent je nezbytný samozřejmě vždy, když jde o fyzický server, ale často musí být přítomen i ve virtuálním clusteru pro zajištění konzistence aplikačního prostředí sestávajícího z více VM. Pak bude zajímavé minimálně to, aby implementace agenta nevyžadovala restart VM, tzn. agent byl bootless. A tím se dostáváme k další otázce, a tou je:
Jak rychle lze zálohovat? Jakmile od zálohování chcete výkon (velké objemy dat, krátké časové okno, velký počet souborů) zjistíte, jak velký rozdíl je mezi různými softwary (ohledně vlivu hardwaru odkazuji na předešlý článek). Co mi je totiž platné, že je zde funkčnost (“lze to udělat“), když provedení trvá neúměrně dlouho, resp. proces zálohování příliš ovlivňuje produkční prostředí. To je v době neustále se snižujících hodnot RPO problém, chcete dělat zálohy např. každou hodinu i v pracovní době, co pak? Doporučuji zaměřit pozornost zejména na 2 oblasti: Paralelismus - tj. kolik současných datových toků (streamů) software umí pbsloužit při zálohování a obnově? Zde Arcserve má až 32 streamů, zatímco Veeam jen 4, naproti tomu ale ve verzi 9.5. významně optimalizoval práci s diskovým prostorem a snížil počet nezbytných I/O operací. Ale nejlepší je to zkusit na vašich datech nebo srovnatelné referenci. Image zálohování - tj. (jak jsem zmínil výše) základní funkčností stejně, jako zajištění konzistence přes VSS. V praxi ale narazíte na skutečnost, že pokud budete požadovat provedení konzistentní zálohy v pracovní době (ideálně s aplikační konzistencí VSS), dojde k „zadrhnutí“ celého prostředí na sekundy i minuty, za což vás uživatelé příliš nepochválí. A Vám, jako adminovi nezbyde než opustit správnou myšlenku aplikační konzistence a risknout crash-consistent zálohy, raději než si nechat nadávat. Z této situace vedou 2 cesty:
Nechat provedení snapshotu na diskovém poli, tzn. že analýzu změn datových bloků a jejich zkopírování nechá provést (na tuto činnost optimalizovaném) kontroléru diskového pole. Provedení snímku může být i řádově rychlejší než v případě softwarové verze! Samozřejmě k provedení potřebujete odpovídající kombinaci diskového pole a zálohovací software, který s ním umí apolupracovat. Mě velmi těší, že můj favorit - disková pole HPE 3PAR jsou podporována jako řešením Veeam tak Arcserve a možnosti implementace hardwarových snapshotpů jsou tím otevřené.
Pokud ani hardwarové snapshoty nestačí, je zde úniková cesta zařazená v řešení Veeam VBR od verze 9 a tou je možnost kombinace snapshotů SQL databáze (prováděné v méně exponovaném čase např. 1x denně v noci), doplněná o průběžné zálohy transakčního logu (TL) s časem až 15´. Protože TL nejsou příliš objemné, zásadně se tím sníží vliv na produkční prostředí. A kombinací aplikačně konzistentního snímku + TL lze mít k dispozici konzistentní databázová data kdykoliv v nastavených krocích. Velmi luxusní záležitost ... zde má konkurence ještě co dohánět!
Granulární obnova dat (alias GRT) Máme tedy (snad) konzistentní data, chceme něco obnovit a co teď? Pokud jde o obnovu celé VM, není problém – spustíme jí buď po vykopírování zálohy na primární úložiště anebo (funkce Instant Recovery) přímo ze zálohy, což může ušetřit čas i místo. Co když ale chci obnovit jen něco? Např. omylem smazaný mail, účet z AD, databázi nebo jen její část, dokument z portálu SharePoint? Zde pak mají výrobci backup softwarů k dispozici službu „application-aware“, která z uloženého image umí vypreparovat konzistentní data, ev. dílčí položky v rámci granulární obnovy. Nebo se alespoň tváří, že Vám práci obnovy usnadňují. Je ovšem zásadní rozdíl mezi tím, že:
můžete (či spíše musíte) zálohu nejprve někam obnovit (zpravidla do nějakého chráněného umístění, tzv. sandboxu) a z něj manuálně daný požadavek uspokojit (vykopírovat), anebo
máte nástroj, kterým přímo vidíte do obsahu zálohy až na úroveň položek či tabulek databáze, vyberete co chcete, a obnovíte do původního nebo alternativního umístění. V případě obnovy mailu lze i zvolit přeposlání obnoveného mailu. Tato přímo snová funkčnost je podstatou Veeam Explorerů v řešení VBR a opravdu funguje! Najít stejně způsobilou konkurenční funkčnost je nadlidský úkol, a pokud je GRT něco, co hodně chcete, řešení VBR je to pravé!
(Ne)hydratujeme a deduplikujeme Samozřejmě je ideálem, aby se po síti nepřenášela stejná data opakovaně (odstranily se duplicity už na zdrojovém úložišti v případě, že na cíli už shodná data jsou), resp. se na cílovém repository se odstranily duplicity. A to vše pokud možno v rámci celého řešení a všech dat (= dat ze všech zálohovacích jobů, všech zálohovaných systémů a platforem). Zde se ovšem opět dostanete k velkým rozdílům mezi aplikacemi, jak si ukážeme na našich dvou modelových řešeních:
Arcserve má otázku deduplikací vyřešenou autonomně (v rámci zakoupeného softwaru) a využívá pro tuto funkčnost speciální typ úložiště RPS (Recovery Point Server). Jde o virtuální stroj, fungující jako gateway/proxy, ke kterému se namapují fyzické zdroje úložišť (lhostejno jakého konkrétního typu vč. SAN, CIFS, NFS). Mezi RPS lze nastavovat libovolné vazby (1:1, 1:n), mohou být v různých lokalitách a vytvářet tak hierarchickou strukturu pro zajištění vysoké dostupnosti a rovněž globální deduplikaci. V rámci celého implementačního prostředí (fyzických i virtuálních serverů + stanic) jsou pak data ukládána pouze jednou a to v rámci skutečně všech zdrojů a zálohovacích jobů. Např. tak část souboru z lokální stanice je deduplikována s daty virtuálního serveru; deduplikace funguje i mezi různými sítěmi a lokalitami a to vč. cloudu. Všechna jednou deduplikovaná data se již nepřenášejí a jediný okamžik, kdy se znova rehydratují (= obnovují do plné, nededuplikované verze), je jejich záznam na pásku a obnova recovery pointů – jinak by to samozřejmě nedávalo smysl. Deduplikace je navíc velmi efektivní (používá velikost bloků 8 - 32 kB), byť tedy vyžaduje slušný výkon – vytváření hash databáze v paměti RAM nebo na SSD. Reálné zkušenosti s výkonem RPS deduplikace ukazují úspory kolem 60 - 80% původního objemu.
Veeam Backup&Recovery v otázce deduplikace šel zcela jinou cestou a sám o sobě deduplikuje pouze data v rámci jednoho jobu, čímž dosahuje úspory max. 10 - 20%. Ale připojuje další dvě možnosti, jak se s deduplikací poprat - jako cílové úložiště totiž podporuje:
backup appliance jako je EMC DataDomain či HPE StoreOnce Catalyst, které provádějí deduplikaci v rámci své funkčnosti velmi účinně a to i v řešení s více appliance v různých lokalitách. Ovšem – pořízení těchto appliancí stojí nemalé peníze navíc;
od verze VBR9.5. podporuje nový souborový systém ReFS, zavedený ve Windows 2016, který obsahuje podporu deduplikace. Lze tak vytvořit jakýsi „quazi RPS“ tím, že jako cílové repository použiju Windows 2016 s ReFS lokálním nebo sdíleným prostorem. Teoreticky tedy lze takto v budoucnu vytvořit i systém úložišť navzájem provázaných ... ale upřímně, i toto vyžaduje náklady navíc ve srovnání s Arcserve RPS a funkčnost zatím není srovnatelná (vyžaduje totiž záznam pomocí jobu, nestačí data jen zkopírovat).
Jsou samozřejmě desítky dalších diferenciátorů, na kterých se v konkrétním případě může ukázat (ne)efektivita konkrétního softwarového řešení a není zde prostor pro jejich další analýzu.
