Zálohování v cloudu: proč, kdy, co a hlavně jak?

Se zálohováním to je jako s tabletami paracetamolu. Jste klidnější, když víte, že je někde máte, a v případě potřeby vám dovedou ulevit od zbytečného trápení. Stejně jako u tablet musíme hlídat datum expirace, tak i u záloh kontrolujeme, zda se pravidelně provádějí, a jsme schopni z nich data doopravdy obnovit v požadovaném čase. Řekněme si, jak vypadá zálohování v rámci cloudových služeb.

Proč zálohovat?

Data (nejen v cloudu) zálohujeme z mnoha důvodů a podle nich se většinou pak i rozhodujeme, jakým způsobem zálohování provádět. Hlavním cílem je nepřijít o dataspolečnosti v případě nečekané události. Takové události mohou být:

• Lidská chyba vedoucí k chybě v datech
• Selhání hardware, software
• Přírodní katastrofy
• Ransomware, malware a další viry
• Záměrné poškození zevnitř (tzv. inside job)
• Krádež a promazání
• Útoky hackerů, respektive crackerů

Schválně zde uvádím lidskou chybu na prvním místě, protože jde jednoznačně o nejčastější příčinu většiny větších i menších důvodů k obnovování dat.

V cloudovém prostředí nejsme automaticky více chráněni! Zálohování není defaultně zapnuto a datové zdroje musíme zabezpečit podle stejné logiky jako v běžném datacentru.

 

Zálohuj, zálohuj, zálohuj…

Zálohování je důležitou součástí provozu každé firmy. Ovšem každá společnost k němu přistupuje trochu jinak, neboť má své specifické požadavky vycházející z technických, obchodních, provozních nebo legislativně-politických aspektů. Proto není možné formulovat žádné univerzální doporučení, ale je třeba vnímat celkový kontext společnosti i konkrétních dat.

Na způsob zálohování mohou mít vliv například následující požadavky:

• Certifikační standardy (např. ISO)
• Legislativní regulace (např. regulace ČNB, GDPR)
• Omezení nákladů na provoz a údržbu
• Další technické a business požadavky

Jako u většiny dalších významných cloudových disciplín i v případě zálohování je vhodné si cílový koncept nejprve dobře rozmyslet a naplánovat. Tato aktivita se může nazývat definování strategie zálohování a často bývá součástí Business continuity plánu (BCP).

Tématem dnešního článku ale není BCP, data security ani disaster recovery (DR), budu se proto snažit soustředit na samotné zálohování.

Schrödingerovo zálohování

Velmi často se setkávám s tím, že na začátku si firma zálohování v cloudu nastaví, ale dále se o ně moc nestará. V lepším případě se nastaví notifikace při neprovedeném backup jobu. Takovým zálohám říkám Schrödingerovy zálohy – dokud se z nich totiž den D opravdu nepokusíte obnovit, nevíte, jestli zálohy k něčemu jsou.

Ačkoli podobné situace bývají napínavé až vzrušující, doporučuji se jim raději vyhýbat. Zálohy mají být jistotou, na kterou se můžete vždy spolehnout – je to plán B. Plán C, na který dojde v případě chybějících záloh, většinou nebývá vůbec příjemný a špatně se vysvětluje nejen vedení, ale například i auditorovi, který přišel na kontrolu od regulátora jako je ČNB.

I zálohy, které se zdají na první pohled v pořádku, mohou být nějakým způsobem poškozené, infikované (např. ransomware), nebo backup job sice proběhne, ale záloha je nulová nebo neúplná (chyba nástroje, špatné nastavení, změna konfigurace nebo práv). Případná záloha zálohy pak je rovněž nepoužitelná, a to, že leží logicky a fyzicky např. v jiné zóně, nás nezachrání.

Proto kromě notifikací ze zálohovacího nástroje o provedení (respektive neprovedení) backup jobu, je vhodné pravidelně zálohy kontrolovat a provádět testovací obnovu. Tyto testy by měly mimo jiné dokázat, že řešení splňuje požadované RTO a RPO stanovené pro daný obsah dat podle dohodnuté úrovně služby aplikace.

• RTO – Recovery Time Objective – schopnost obnovení ve stanovém čase
• RPO – Recovery Point Objective – schopnost obnovení k určitému bodu

Za zálohy by měla být odpovědná konkrétní osoba (nebo skupina osob), která dohlíží na dodržování požadavků vyplývajících ze strategie společnosti. Součástí tohoto dohledu má být i ověření obnovitelnosti kritických záloh a souvisejících procesů v pravidelných intervalech alespoň jednou za půl roku, maximálně jednou ročně.

Zálohování (nejen) v cloudu

V tomto článku se věnujeme primárně zálohování v cloudu, nicméně principy zálohování zůstávají stejné bez ohledu na to, zda se jedná o zálohování čistě cloudových dat (Azure, AWS, GCP), multi-cloudu nebo hybrid cloudu.

Ve všech případech by nároky měly být konzistentní. Potřeby zálohování by totiž měly být jasně definovány danou společností a neměly by být limitovány konkrétním prostředím. I proto většina významných zálohovacích softwarů podporuje více variant prostředí a umožňuje propojení různých zdrojů i cílů pro zálohy.

Integrace většinou probíhá buď přímo nějakým connectorem, nebo poskytovatel zálohovací služby nabízí vlastní variantu řešení pro cloud, například ve formě appliance.

Co v cloudu zálohovat?

V cloudu rozdělujeme zálohování do tří základních kategorií: IaaS, PaaS, SaaS. PaaS a SaaS služby mají většinou omezené možnosti nativního zálohování od poskytovatele, ale často je lze integrovat s externími nástroji (což bývá vzhledem ke zmíněným omezením žádoucí). V případě IaaS lze pak zálohování většinou řešit  obdobně jako na on-premise (klasická záloha virtuálního stroje).

To, že data běží v cloudu, neznamená, že jsou automaticky zálohována! Tento, všeobecně rozšířený omyl platí i v případě SaaS. Data jsou vždy v režii zákazníka (viz shared responsibility model v předchozím článku seriálu) a cloudoví poskytovatelé nechávají zálohování na něm. Výjimkou mohou být některé SaaS služby, kde někdy poskytovatel provádí částečnou zálohu nativně.

Doporučuji si vždy u SaaS řešení ověřit detaily zálohování a rozhodnout se, zda je řešení dostatečné a zda se vůbec mohu spoléhat na zálohy, které provádí někdo jiný (a nemám je tak vysloveně pod kontrolou).

Například Microsoft SharePoint Online je zálohován pouze každých 12 hodin s pouhou 14denní retencí (tzn. mám data pouze 14dní zpětně). Tyto zálohy si můžete vyžádat, ale na jejich obnovení má společnost Microsoft 30 dní. Vystačíte si s tímto schématem zálohování?

Kromě samotných dat nesmíme zapomenout ani na data infrastrukturní a obecně konfigurační. V ideálním případě bychom měli mít naši cloudovou architekturu definovanou pomocí Infrastructure as a Code (IaaC) a tyto soubory zálohovat, udržovat aktualizované a verzované. Díky tomu jsme schopni udělat nejen restore dat, ale kompletně celého provozovaného prostředí.

Jaký nástroj použít?

Většina zákazníků již vstupuje do cloudu s nějakým existujícím řešením na on-premise. Pokud existující on-premise zálohovací nástroj podporuje veřejný cloud, můžeme jej integrovat a nativní nástroje od cloud poskytovatelů využít jen na nepodporované služby (pokud takové jsou).

Mezi nativní zálohovací nástroje patří v případě Microsoft cloudu Azure Backup, Amazon zase nabízí AWS Backup. Nejznámějšími produkty třetích stran, které rovněž podporují veřejné cloudy, jsou například:

• Veeam
• Commvault
• Unitrends
• Acronis

Funkcionality jednotlivých nástrojů se liší a je třeba si je projít důkladněji. Pro startupy nebo firmy, které s cloudem teprve začínají, může být nativní nástroj cloudového poskytovatele nejsnadnější a zároveň i nejekonomičtější volba.

Jak často zálohovat a kam?

Když jsme si vybrali nástroj, je na čase rozhodnout, jak často zálohovat, kde zálohy ukládat a jak dlouho je držet (retence).

Frekvenci záloh nám určuje kritičnost dat, vyplývající z aplikační business analýzy. Určíme, jaké máme RPO a za jaký časový úsek si může společnost dovolit data postrádat. Pomineme nyní koncept vysoké dostupnosti a případné active-pasive a další nastavení pro bezvýpadkový provoz.

Zlaté pravidlo říká, že máme zálohovat na principu 3-2-1, tj. mít tři zálohy ve dvou zařízeních a jednu v jiné lokalitě. Toto naplňujeme i v cloudu s přihlédnutím k availability zónám a archivní vrstvě.

Pro produkční zálohy je asi nejběžnější provádět denní zálohy v noci. Tedy na konci dne se provede záloha nových dat (většinou inkrementální) a jednou týdně celá.

Denní zálohy nejčastěji uchováváme 30–60 dní na výkonné storage – tier hot u Azure, standard u AWS. Po této době uchováváme již pouze týdenní a měsíční zálohy, které pomocí lifecycle managementu přesouváme na levnější a méně výkonnější tier storage – cool a následně archive v případě Azure, Standard-IA, Glacier a Deep Archive u AWS.

Archive tier u Azure a Deep Archive u AWS jsou storage tiery na úrovni osvědčených páskových kazet. Bavíme se tak v tomto případě už spíše o archivaci než zálohování jako takovém. Data na archive tier jsou uložena velmi levně, jejich obnova však může trvat i několik dní.

To, zda se provádí inkrementální nebo plná záloha, můžeme ovlivnit ve vybraném zálohovacím SW, stejně tak mohou některé nástroje podporovat i deduplikaci dat. Pokud nezálohujeme na naše diskové pole mimo cloud, tyto funkce můžeme ovlivnit jen na softwarové úrovni a na úrovni storage řešíme pouze jednotlivé tiers (vrstvy).

Zálohování v Azure

Azure se velmi rychle vyvíjí, a proto se často služby mění zákazníkům doslova pod rukama. Zároveň Microsoft (MS) rád mění názvy služeb a přesouvá jejich funkcionality mezi sebou. Kvůli tomu může být celkové backup řešení roztažené přes několik služeb s často zaměnitelnými názvy, což zhoršuje už tak špatnou přehlednost.

MS si toho začínám být vědom, a proto poslední měsíce (psáno v druhé polovině 2021) podniká kroky, aby celé řešení pro zálohování zjednodušil a především zpřehlednil.

V oblasti backupu byl Azure jako celkové řešení pro zálohování u náročnějších klientů nedostatečný. Nyní vychází nová služba, která má ambice toto změnit. Jedná se o Backup Center, který má fungovat jako single pane of glass pro zálohovaní v Azure. Dokud ale nepřejde z preview do general availability (GA) může obsahovat chyby, nemá SLA a teoreticky může být z nabídky i stažen.

Pro zálohovaní v Azure je kritickou součástí Recovery Services vault. Oficiální Microsoft dokumentace jej definuje jako storage entitu v Azure, která slouží k ukládání dat. Tato data jsou typicky datové kopie, konfigurační informace pro virtuální stroje (VMs), servery, pracovní stanice a další workloady.

Pomocí Recovery Services vaultu je možné dělat zálohy pro různé Azure služby, jako je IaaS VMs (Linux i Windows) a Azure SQL databáze. Usnadňuje organizaci zálohovaných dat a snižuje náročnost na správu. Recovery Services vaults jsou založeny na ARM modelu (Azure Resource Manager), který poskytuje funkcionality jako:

• Rozšířené možnosti pro zabezpečení zálohovaných dat
• Centrální monitoring pro hybridní IT prostředí
• Azure RBAC (Role Based Access Control)
• Soft Delete
• Cross Region Restore

Zjednodušeně lze říci, že se jedná o komplexní službu poskytující zálohování, disaster recovery, migrační nástroje a další funkcionality přímo v cloudu.

Pro migraci se dnes už uvádí jako primární nástroj Azure Migrate, který dříve sloužil pouze pro měření workloadu a assesment. Nyní obsahuje nástroje i pro samotnou migraci, která se dříve prováděla zvlášť přes Azure Site recovery (ASR) v Recovery Services vaultu.

Služba Recovery Services vault je Microsoftem preferovaná varianta pro zálohování a disaster recovery, která je zabudována nativně v Azure (někdy je rovněž označována obecně jako Azure Backup).

Hlavní výhodou Recovery Services vaultu je možnost zálohovat i on-premise workload a provádět failover jak z on-premise do cloudu, tak z jednoho regionu do druhého.

Do Recovery Services vault je možné zálohovat data z Azure, Azure Stacku i OnPremise data.

Seznam podporovaných systémů i se support maticí je dostupný zde.

Zálohování v AWS

Nativní nástroj v AWS se nazývá AWS Backup. Princip je podobný jako u konkurenčního Microsoftu, rovněž podporuje lifecycle management, zálohování workloadu běžící mimo samotné AWS (například on-premise) a mnoho dalších funkcionalit, jako například:

• Centralized backup management
• Policy-based backup
• Tag-based backup
• Automated backup scheduling
• Automated retention management
• Backup activity monitoring
• AWS backup audit manager
• Lifecycle management policies
• Incremental backup

Pro zálohování on-premise dat je nutné nasazení AWS storage gateway. Pokročilé automatizační nástroje jsou rozhodně jednou ze silných předností AWS Backup.

Pokud řešíte zálohování v cloudu pouze u jednoho poskytovatele, doporučuji jít cestou nativního nástroje. V případě multi-cloudu či hybrid cloud architektury je vhodné zvážit jednotlivé nástroje a detailněji prozkoumat kombinaci, která odpovídá vašim potřebám.

Závěrem

Nečekejte, až budete mít problém – ať už lidskou vinou nebo z jakékoli jiné příčiny.

Provádějte restore testy. Cloud je úžasnou pomůckou v tom, že můžete za velmi malé náklady obnovit velkou část vašeho prostředí, ověřit správnost dat a obnovená data zase smazat.

A pak můžete klidně spát…

Předchozích 11 kapitol seriálu Encyklopedie cloudu najdete zde.