RPO popisuje okno ztráty dat, které jste ochotni přijmout; RTO popisuje přerušení, které se snažíte udržet v určitých mezích. Definujte oba pro užitečnou obchodní funkci a poté ověřte průběh obnovy v rámci cvičení. Plán zálohování ani specifikace serveru samy o sobě nestanovují ani jeden z těchto cílů.
Začněte službou, kterou lidé mohou používat
Cíle obnovy se stanou užitečnými, když popisují obchodní funkci, nikoli izolovaný stroj. Server může naběhnout, zatímco zákazníci se stále nemohou přihlásit, načíst soubory nebo dokončit požadavek. Konečný stav popište běžným jazykem: autorizovaní uživatelé mohou přistupovat k aplikaci a požadovaná data jsou konzistentní. Díky tomu je cíl testovatelný někým mimo infrastrukturní tým.
Zeptejte se vlastníka aplikace, čemu by přerušení zabránilo a co by znamenala chybějící data. Týdenní publikace a aplikace pro zpracování transakcí mohou mít různé odpovědi. Výsledné cíle berte jako plánovací cíle, nikoli jako sliby vymyšlené z katalogu hardwaru. Zaznamenejte, kdo je schválil a které scénáře selhání plán pokrývá.
Oddělte oba časy
RPO se týká toho, jak daleko zpět mohou obnovená data být ve vztahu k výpadku. RTO se týká toho, jak dlouho může funkce zůstat nedostupná. Nedávná záloha může zlepšit okno ztráty dat, zatímco pomalá obnova stále nesplní cíl doby obnovy. Naopak rychlý restart může obnovit přístup k aplikaci, jejíž nejnovější data se nezachovala.
Upřesněte referenční body. Rozhodněte, kdy začíná čas incidentu, co se počítá za obnovený provoz a jak bude identifikován použitelný datový bod. Cíle udržujte oddělené od naměřených výsledků: cíl je to, o co usilujete; cvičení ukazuje, čeho dosáhl současný proces. Obojí znovu zvažte, když se aplikace nebo datová sada změní.
Naplánujte rozpočet na každý krok obnovy
Praktický rozpočet RTO zahrnuje detekci, posouzení, schválení, přístup k prostředí obnovy, obnovu, ověření aplikace a znovuotevření. Doba kopírování souborů je jen jednou složkou. Pokud osoba, která drží klíč pro obnovu, není k dispozici, teoreticky rychlá záloha může být stále nepoužitelná. Uveďte závislosti a zajistěte, aby k nim tým obnovy mohl během uvažovaného selhání získat přístup.
Každému kroku přiřaďte předběžný čas a poté odhady nahraďte pozorováními. V tomto ilustrativním dvouhodinovém rozpočtu dostává obnova největší příděl, ale ověření má stále vyhrazený čas. Čísla popisují plánovací příklad, nikoli poskytování služeb SwissOctet. Pokud součet nemá rezervu, návrh je třeba před tím, než bude cíl věrohodný, vylepšit.
| Krok obnovy | Ilustrativní příděl | Důkazy ke shromáždění |
|---|---|---|
| Detekce a posouzení | 15 minut | Příchod upozornění a rozhodnutí o incidentu |
| Příprava prostředí obnovy | 20 minut | Přístup a konfigurace k dispozici |
| Obnova dat a služby | 50 minut | Dokončená obnova s konzistentními daty |
| Ověření a znovuotevření | 25 minut | Cesta uživatele je úspěšná |
| Rezerva pro nepředvídané události | 10 minut | Zaznamenaná neočekávaná práce |
Zkontrolujte skutečné okno ztráty dat
Úloha naplánovaná každou hodinu automaticky neposkytuje jednohodinové RPO. Neúspěšná úloha, zpožděné nahrání nebo nepoužitelná kopie mohou poslední obnovitelný bod výrazně posunout do minulosti. Sledujte úspěšné dokončení a stav, který lze skutečně obnovit. U aplikace s několika datovými úložišti ověřte, že jejich body obnovy jsou vzájemně kompatibilní, místo abyste každý časový údaj četli izolovaně.
Během cvičení zvolte referenční událost, například autorizovaný testovací záznam vytvořený ve známém čase. Po obnově identifikujte nejnovější platný záznam a změřte mezeru. Použijte neškodná testovací data. Získáte tak praktický výsledek a odhalíte předpoklady, které by dashboard zobrazující pouze úspěch úlohy mohl skrývat.
Zvolte strategii v rámci rozpočtu
Zálohování a obnova, připravená pohotovostní prostředí a replikované návrhy aplikací vyměňují náklady a složitost za rychlost obnovy. Replikace může snížit některá zpoždění, ale může také reprodukovat náhodné smazání nebo chybu aplikace. Pohotovostní systém, který se odchýlil od pracovní konfigurace, vytváří vlastní riziko. Zvolte strategii podle scénářů selhání a cílů, které jste zdokumentovali.
Zvažte malou službu s čtyřhodinovým cílem a větší datovou sadu, jejíž samotná obnova při cvičení trvá šest hodin. Koupě rychlejšího síťového portu je jen hypotéza: čtení z úložiště, zápisy při příjmu a obnova aplikace mohou dominovat. Vylepšete naměřený omezující krok, zmenšete sadu pro obnovu nebo změňte strategii a poté cvičení zopakujte.
Cvičte, aniž byste ohrozili produkci
Použijte izolované prostředí obnovy a definované okno cvičení. Zajistěte, aby obnovené úlohy nemohly odesílat skutečná oznámení, přijímat veřejné platby ani zapisovat do produkčních integrací. Před dokončením cvičení otestujte přístup, integritu dat a reprezentativní cesty uživatelů. Zapojte osobu, která původní postup nepsala, aby odhalila chybějící pokyny.
Veďte časovou osu cvičení, dosaženého bodu obnovy a každého přerušení způsobeného nedostupnými informacemi. Užitečná zpráva uvádí naměřený výsledek, mezeru vůči cíli a konkrétní nápravné opatření. Opakujte po významných změnách a v intervalu odpovídajícím důležitosti projektu.
Udržujte plán použitelný během výpadku
Postup obnovy ukládejte tam, kde k němu tým má přístup, aniž by se spoléhal výhradně na selhanou aplikaci. Pověření a šifrovací klíče uchovávejte na chráněném místě s otestovaným procesem přístupu. Jak projekt roste, aktualizujte kontakty, velikosti datových sad a závislosti. Zastaralý plán může spotřebovat časovou rezervu ještě předtím, než obnova vůbec začne.
Při porovnávání konfigurací SwissOctet oddělte svou architekturu obnovy od volitelných možností zálohování v katalogu. Ověřte, co která možnost pokrývá, kde jsou data pro obnovu uložena a kdo provádí obnovu. Katalog nestanovuje RPO ani RTO aplikace. Základem pro toto rozhodnutí je váš naměřený proces a skutečné podmínky služby.
Váš praktický kontrolní seznam.
- Definujte obnovenou obchodní funkci.
- Schvalte oddělené cíle RPO a RTO.
- Naplánujte rozpočet na detekci, přístup, obnovu a ověření.
- Změřte nejnovější použitelný datový bod.
- Cvičte v izolovaném prostředí.
- Zaznamenejte mezery a opakujte po příslušných změnách.
Podrobnosti, na kterých záleží.
Je RTO totéž jako dostupnost?+
Ne. RTO je cíl obnovy pro scénář přerušení. Dostupnost měří dostupnost za určité období; jedno nestanovuje druhé.
Zaručuje hodinová záloha jednohodinové RPO?+
Ne. Zkontrolujte dokončené, použitelné kopie a požadavky aplikace na konzistenci. Neúspěšné úlohy a zpožděné přenosy mohou zvětšit mezeru v obnovitelných datech.
Musí každý projekt používat pohotovostní server?+
Zvolte strategii podle cílů obnovy projektu a naměřeného procesu obnovy. Pohotovostní systém přidává náklady a provozní složitost a není automaticky nutný.
Jděte ke zdroji.
Tyto zdroje podporují technické koncepty v tomto průvodci. Před změnou produkčního systému se řiďte aktuální dokumentací.
- NIST SP 800-34 Rev. 1: Příručka plánování kontinuity nvlpubs.nist.gov
- AWS Well-Architected: Definujte cíle obnovy docs.aws.amazon.com
- Microsoft Learn: Kontinuita podnikání, vysoká dostupnost a zotavení po havárii learn.microsoft.com
Redakční vedení od SwissOctet. Příklady jsou ilustrativní. Specifikace služeb, dostupné možnosti a smluvní podmínky je nutné ověřit samostatně.