Disaster recovery (obnova po havárii)

Příklady z praxe

1. 01

   Obnova databáze po chybné migraci

   Tým nasadí migraci, která omylem smaže část zákaznických nastavení. Produkce se zastaví pro zápis, poslední konzistentní dump se obnoví do izolované databáze a porovná se s produkcí. Po ověření integrity se chybějící záznamy vrátí řízeným skriptem a incident končí bez úplného návratu celé aplikace v čase.

   # Obnova PostgreSQL dumpu do izolované databáze pro kontrolu
   createdb app_restore
   pg_restore --clean --if-exists -d app_restore latest.dump

2. 02

   Failover webové aplikace do druhého regionu

   Webová aplikace běží v jednom cloudovém regionu a druhý region má připravenou infrastrukturu ze šablon. Primární region přestane odpovídat, tým podle runbooku povýší repliku databáze, spustí aplikační služby v náhradním regionu a přepne DNS. Zákazníci vidí dočasné omezení, ale objednávky pokračují bez čekání na opravu původního regionu.

Časté omyly

MýtusMáme zálohy, takže disaster recovery máme vyřešené.

Ve skutečnostiZálohy samy neřeší pořadí obnovy, přístupy, síť, DNS, tajemství, test integrity ani rozhodnutí během incidentu. Disaster recovery začíná být důvěryhodné až tehdy, když je obnova opakovaně vyzkoušená.

MýtusDisaster recovery je potřeba jen pro velké firmy.

Ve skutečnostiMenší organizace mívají méně rezerv, takže dlouhý výpadek je může zasáhnout tvrději. Rozsah plánu může být jednoduchý, ale základní postup obnovy, odpovědnosti a test záloh potřebuje i malý tým.

Časté dotazy

Kdy má smysl psát disaster recovery plán?

Disaster recovery plán se vyplatí vytvořit pro každou službu, u které výpadek znamená ztrátu peněz, porušení smlouvy, právní problém nebo zásadní reputační škodu. Malý projekt nepotřebuje složitý dokument, ale potřebuje vědět, kde jsou zálohy, kdo má přístupy, jak se ověří obnova a co se vypne jako první. Rozsah plánu má odpovídat dopadu výpadku, ne velikosti týmu.

Co má obsahovat test disaster recovery?

Disaster recovery test by měl ověřit skutečnou obnovitelnost, ne jen existenci souboru se zálohou. Praktický test obnoví data do odděleného prostředí, spustí závislé služby, provede základní aplikační scénáře a změří, zda se výsledek blíží cílům RTO a RPO. Test má také ověřit, že potřební lidé mají přístupy, runbook je srozumitelný a kontakty na dodavatele jsou aktuální.

Proč disaster recovery nestačí nahradit vysokou dostupností?

Disaster recovery není totéž co vysoká dostupnost, i když se oba přístupy doplňují. Vysoká dostupnost se snaží udržet službu v provozu při běžných poruchách komponent, například při pádu jednoho serveru. Disaster recovery řeší rozsáhlejší události, kdy je potřeba obnovit službu v jiném prostředí, z datových kopií nebo podle krizového postupu.

Jak disaster recovery souvisí s ransomwarem?

Disaster recovery pro ransomware musí počítat s tím, že útočník mohl poškodit i zálohy, získat administrátorská oprávnění nebo dlouho čekat v síti. Plán proto potřebuje neměnné nebo oddělené zálohy, vícefaktorové ověření, kontrolu čistoty obnoveného prostředí a postup pro obnovu identit. Rychlé spuštění z napadené kopie může vrátit do provozu i malware.

Zdroje

1. What is Disaster Recovery?(otevře se v novém okně)Amazon Web Services
2. Disaster recovery planning guide(otevře se v novém okně)Google Cloud
3. Disaster recovery overview(otevře se v novém okně)Microsoft Learn
4. Continuous Archiving and Point-in-Time Recovery (PITR)(otevře se v novém okně)PostgreSQL Global Development Group

Související pojmy

• Incident responseIncident response je organizovaný postup, kterým firma detekuje bezpečnostní incident, omezí jeho dopad, odstraní příčinu, obnoví provoz a vyhodnotí, co selhalo. Zahrnuje předem připravený plán, definované role, komunikaci se zákazníky i regulátorem a sběr důkazů. Cílem není jen zastavit útok, ale zkrátit dobu, po kterou útočník zůstává v systému nepovšimnut.
• Záloha databázeZáloha databáze je samostatně uložená kopie databázových dat a potřebných metadat, ze které lze databázi po chybě obnovit. V praxi chrání před smazáním, poškozením, selháním infrastruktury i ransomwarem, ale smysl má jen tehdy, když je pravidelně vytvářená, bezpečně uložená a ověřená obnovou.
• Vysoká dostupnostVysoká dostupnost je vlastnost systému, který zůstává použitelný i při výpadku jednotlivých součástí, protože je navržený bez jediného kritického místa selhání. Měří se podílem času, kdy služba funguje podle dohodnutých parametrů, typicky v procentech za měsíc nebo rok, a dosahuje se redundancí, automatickým přepnutím a průběžným monitoringem.
• 3-D Secure3-D Secure je protokol, který u online platby kartou ověří, že platí skutečně její držitel, typicky potvrzením v bankovní aplikaci. Při úspěšném ověření se zároveň přenáší odpovědnost za podvodnou transakci z obchodníka na vydavatele karty.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• API GatewayAPI Gateway je vstupní vrstva mezi klientem a sadou backendových služeb, která přijímá požadavky, směruje je na správné API, vynucuje bezpečnostní pravidla a často řeší limity, logování nebo transformace odpovědí. Pomáhá skrýt vnitřní strukturu systému a sjednotit chování pro web, mobilní aplikaci i partnery.
• Archivace dokumentůArchivace dokumentů je řízené ukládání dokumentů, které už nejsou běžně používány, ale musí zůstat čitelné, dohledatelné a prokazatelné po určenou dobu. V praxi spojuje pravidla retence, metadata, oprávnění, ochranu před změnou a postup pro bezpečné vyřazení po skončení právního nebo obchodního důvodu.
• Automatické škálováníAutomatické škálování je řízení výpočetní kapacity služby podle aktuální nebo očekávané zátěže bez ručního zásahu operátora. Systém přidává či odebírá instance, kontejnery, vlákna nebo jiné prostředky podle metrik a pravidel, aby aplikace zvládla špičky, neplatila zbytečnou rezervu a zůstala stabilní.