Disaster Recovery — plánování obnovy po havárii

Co je Disaster Recovery

Disaster Recovery (DR) je soubor politik, nástrojů a postupů, které umožňují obnovu nebo pokračování kritických technologických systémů a infrastruktury po přírodní nebo člověkem způsobené katastrofě. Na rozdíl od běžného zálohování, které se zaměřuje na ochranu dat, DR řeší komplexní obnovu celého IT prostředí — serverů, sítí, aplikací, databází a procesů — tak, aby firma mohla co nejrychleji obnovit provoz.

DR je součástí širšího konceptu Business Continuity Planning (BCP) — plánování kontinuity podnikání. Zatímco BCP pokrývá všechny aspekty firemního provozu (lidé, procesy, prostory, dodavatelé), DR se specificky zaměřuje na IT systémy a data.

RPO a RTO — klíčové metriky

Dva nejdůležitější parametry disaster recovery plánu jsou RPO a RTO. Správné pochopení a nastavení těchto metrik je základem každého DR plánu.

RPO — Recovery Point Objective

RPO (Recovery Point Objective) definuje maximální přijatelnou dobu, za kterou mohou být data ztracena při havárii. Jinými slovy: kolik dat si můžete dovolit ztratit? Pokud je RPO 4 hodiny, znamená to, že zálohy musí probíhat minimálně každé 4 hodiny. V případě havárie ztratíte maximálně 4 hodiny dat.

• RPO = 0 — žádná ztráta dat. Vyžaduje synchronní replikaci. Nejdražší a nejnáročnější.
• RPO = 15 minut — téměř real-time ochrana. CDP (Continuous Data Protection) nebo velmi časté snapshoty.
• RPO = 1 hodina — přijatelné pro většinu firemních aplikací. Hodinové zálohy nebo replikace.
• RPO = 24 hodin — standardní pro méně kritické systémy. Denní zálohy.
• RPO = 7 dní — jen pro archivní nebo méně důležitá data. Týdenní zálohy.

RTO — Recovery Time Objective

RTO (Recovery Time Objective) definuje maximální přijatelnou dobu od havárie do plné obnovy provozu. Jinými slovy: jak rychle musíte být zpět v provozu? RTO zahrnuje celý proces — detekci problému, rozhodování, obnovu dat, konfiguraci systémů, testování a předání do provozu.

• RTO = 0 — žádný výpadek (zero downtime). Vyžaduje hot standby s automatickým failoverem. Typicky pro kritickou infrastrukturu.
• RTO = 1 hodina — rychlá obnova. Předpřipravené DR prostředí, automatizované skripty.
• RTO = 4 hodiny — standard pro důležité firemní systémy. Virtualizace a rychlý restore.
• RTO = 24 hodin — přijatelné pro podpůrné systémy. Obnova ze zálohy na náhradní hardware.
• RTO = 72 hodin — pro nekritické systémy. Manuální obnova, případně nákup náhradního hardware.

Klasifikace systémů podle kritičnosti

Šablona DR plánu

DR plán je dokumentovaný, strukturovaný postup pro obnovu IT systémů po havárii. Dobrý DR plán je dostatečně podrobný, aby ho mohl následovat i člověk, který se s prostředím setkává poprvé, a přitom dostatečně přehledný pro rychlé rozhodování v krizové situaci.

1. Kontaktní informace a eskalační matice

Seznam klíčových osob s jejich rolemi, telefonními čísly, e-maily a záložními kontakty. Definice eskalačního řetězce — kdo rozhoduje o vyhlášení DR situace, kdo koordinuje obnovu, kdo komunikuje se zainteresovanými stranami (management, zákazníci, média).

2. Inventář systémů a závislostí

Kompletní seznam všech IT systémů včetně: názvu a účelu systému, klasifikace kritičnosti (Tier 1–4), RPO/RTO, závislostí na jiných systémech, technických parametrů (OS, databáze, síťová konfigurace), umístění záloh a přístupových údajů, vlastníka systému (business owner) a technického správce.

3. Scénáře havárií

Pro každý realistický scénář havárie definujte konkrétní postup obnovy:

• Selhání jednotlivého serveru: Obnova z poslední zálohy na záložní hardware nebo VM
• Ransomware útok: Izolace, forenzní analýza, obnova z immutable zálohy
• Ztráta datacentra: Aktivace DR lokality, obnova z offsite záloh
• Výpadek cloudu: Přechod na záložní poskytovatele nebo lokální provoz
• Selhání databáze: Point-in-time recovery z WAL logů nebo replik
• Kompromitace účtů: Reset přístupů, obnova z čisté zálohy, bezpečnostní audit

4. Postupy obnovy (runbooky)

Detailní, krok-za-krokem návody pro obnovu každého kritického systému. Runbook by měl obsahovat: předpoklady (co musí být k dispozici), přesné příkazy a postupy, očekávané výstupy a kontrolní body, postup při chybě, ověření úspěšné obnovy.

5. Komunikační plán

Kdo, kdy a jak informuje: vedení firmy, zaměstnance, zákazníky, dodavatele, regulátory (NÚKIB v případě povinných subjektů), média. Šablony komunikačních zpráv pro různé scénáře.

DR strategie

Cold site

Prázdný prostor s připravenou infrastrukturou (elektrická síť, chlazení, síťové připojení), ale bez serverů a dat. V případě havárie se doručí a nainstaluje náhradní hardware a obnoví ze záloh. Nejlevnější varianta, ale s nejdelším RTO (dny až týdny).

Warm site

Záložní lokalita s předinstalovaným hardware, ale bez aktuálních dat. Data se obnovují ze záloh při aktivaci DR plánu. RTO v řádu hodin. Přijatelný kompromis mezi cenou a rychlostí obnovy pro většinu firem.

Hot site

Plně funkční kopie produkčního prostředí se synchronizovanými nebo téměř synchronizovanými daty. Při havárii se přepne provoz na DR lokalitu s minimálním výpadkem (minuty). Nejdražší varianta, ale nutná pro Tier 1 systémy s RPO/RTO blízkým nule.

Cloud DR (DRaaS)

Disaster Recovery as a Service využívá cloudovou infrastrukturu jako DR lokalitu. Zálohy nebo repliky se průběžně ukládají do cloudu (AWS, Azure, Google Cloud) a v případě havárie se virtuální stroje spustí přímo v cloudu. Výhody: žádné investice do hardware, platba za skutečné využití (pay-as-you-go), globální dostupnost. Služby jako Veeam Cloud Connect, Zerto, Azure Site Recovery nebo AWS Elastic Disaster Recovery nabízejí automatizovaný failover.

Business Continuity

Business Continuity Planning (BCP) je nadřazený koncept, který zahrnuje DR, ale jde dále. Zatímco DR řeší technickou obnovu IT systémů, BCP pokrývá celý firemní provoz:

• Lidské zdroje: Kdo nahradí klíčové zaměstnance? Mohou zaměstnanci pracovat z domova?
• Prostory: Kde bude firma fungovat, pokud přijde o kancelář?
• Dodavatelský řetězec: Co když klíčový dodavatel nemůže dodávat?
• Finance: Má firma dostatek prostředků na překlenutí výpadku příjmů?
• Komunikace: Jak bude firma komunikovat se zaměstnanci, zákazníky, partnery?

Business Impact Analysis (BIA)

BIA je první krok při tvorbě BCP i DR plánu. Jedná se o systematickou analýzu dopadů výpadku jednotlivých firemních procesů a IT systémů. Pro každý proces/systém se stanoví: finanční dopad výpadku za hodinu/den/týden, regulatorní dopady (pokuty, ztráta licencí), reputační dopady, provozní závislosti. Na základě BIA se určí priorita obnovy a přidělí odpovídající RPO/RTO.

Cloud DR v praxi

AWS Elastic Disaster Recovery (AWS DRS)

Služba automaticky replikuje zdrojové servery (fyzické, virtuální, cloudové) do AWS. Při havárii lze spustit servery v AWS během minut. Agentní software na zdrojových serverech průběžně replikuje blokové změny do staging area v AWS. Cena: přibližně 0,028 USD/hod za replikovaný server plus náklady na compute a storage při skutečném failoveru.

Azure Site Recovery

Podobná služba od Microsoftu pro replikaci do Azure. Podporuje VMware, Hyper-V i fyzické servery. Automatizovaný failover s recovery plans, které definují pořadí spuštění serverů a síťovou konfiguraci. Integrace s Azure Backup pro dlouhodobou retenci.

Veeam + Cloud Connect

Veeam Backup & Replication ve spojení s Cloud Connect partnerem umožňuje replikaci záloh nebo VM replik do datacentra poskytovatele. V ČR nabízí Cloud Connect služby několik poskytovatelů. Výhodou je, že firma nemusí spravovat cloudovou infrastrukturu — tu zajišťuje partner.

Testování DR plánu

DR plán, který nebyl otestován, je jen teorie. Testování ověřuje, že plán je realistický, dokumentace je aktuální, lidé znají své role a technické postupy fungují v praxi.

Úrovně testování

1. Tabletop exercise (stolní cvičení): Klíčoví pracovníci sedí u stolu a procházejí DR scénář verbálně. Nejlevnější a nejrychlejší forma testování. Odhalí mezery v plánu a komunikaci, ale neověří technické postupy.
2. Walkthrough test: Tým prochází DR plán krok za krokem a ověřuje, že každý krok je proveditelný. Kontroluje se dostupnost záloh, funkčnost nástrojů, platnost přístupových údajů, ale skutečná obnova se neprovádí.
3. Simulation test: Simulace konkrétního scénáře havárie s technickou obnovou do testovacího prostředí. Měří se skutečné RPO/RTO. Nejblíže skutečné havárii bez ovlivnění produkce.
4. Full interruption test: Skutečné přepnutí produkčního provozu na DR lokalitu. Nejvěrohodnější test, ale nejrizikovější. Obvykle se provádí mimo pracovní dobu nebo v údržbovém okně.

Frekvence testování

• Tabletop exercise: 2x ročně
• Walkthrough: 1x ročně
• Simulation test: 1x ročně pro Tier 1 systémy, 1x za 2 roky pro Tier 2
• Full interruption: 1x za 2–3 roky (pokud je to proveditelné)

DR a ransomware

Ransomware útoky jsou dnes nejčastějším důvodem aktivace DR plánu. Na rozdíl od technického selhání je ransomware útok záměrný a cílí na zálohy. DR plán pro ransomware scénář musí počítat se specifickými aspekty:

• Detekce a izolace: Okamžité odpojení napadených systémů od sítě. Identifikace rozsahu kompromitace.
• Forenzní analýza: Určení vektoru útoku, doby kompromitace, rozsahu škod. Nutné pro rozhodnutí, z jak staré zálohy obnovit.
• Čistá obnova: Obnova ze zálohy, o které máte jistotu, že nebyla kompromitována. Immutable zálohy jsou klíčové.
• Bezpečnostní hardening: Před obnovením přístupu uživatelů zabezpečte systémy — reset hesel, aktualizace patchů, uzavření zneužitých zranitelností.
• Regulatorní povinnosti: Nahlášení incidentu NÚKIB (pokud spadáte pod zákon o kybernetické bezpečnosti), notifikace ÚOOÚ dle GDPR (pokud došlo k úniku osobních údajů).

Shrnutí

Disaster Recovery plánování je investice do přežití firmy. Začněte kategorizací systémů podle kritičnosti, definujte RPO/RTO pro každou kategorii, vytvořte dokumentovaný DR plán s podrobnými runbooky a pravidelně jej testujte. Využijte cloudové DR služby pro cenově dostupnou offsite ochranu. Pamatujte: katastrofa nepřijde v pracovní době a nerespektuje vaše plány — připravte se, dokud můžete.

Klíčové zásady disaster recovery:

• Dokumentujte vše — v krizové situaci není čas hledat informace
• Automatizujte co nejvíce — ruční postupy jsou pomalé a chybové
• Testujte pravidelně — netestovaný plán je jen papír
• Počítejte s ransomwarem — immutable zálohy a air-gapped kopie
• Aktualizujte plán při každé změně infrastruktury
• Zajistěte, aby klíčové osoby znaly své role bez nahlížení do dokumentace