DRP a BCP

Jak často testovat DRP?

Automaticky kontrolujte, že kopie stále nabíhají, alespoň jednou měsíčně, a alespoň jednou ročně proveďte skutečné přepnutí s pracovním úkonem. Test zopakujte pokaždé, když se změní server, síť, dodavatel nebo osoba, která drží klíč.

Aktualizováno v říjnu 20263 min čtení6 citovaných zdrojů

To hlavní

Každý den: projít neúspěšné zálohy. Každý měsíc: technické spuštění záložního prostředí.
Každé čtvrtletí: obnova s měřením času. Každý rok: skutečné přepnutí s návratem zpět.
NIST počítá s ročním testem schopností obnovy; GDPR a ANSSI (Francie) požadují pravidelné testy.
Každá významná změna (server, hlavní verze, správce, dodavatel, internetové připojení) vyžaduje test.
Nejdůležitější je zapsané datum posledního testu a opravené odchylky.

Co říkají referenční rámce

NIST. Průvodce SP 800-34, určený pro federální systémy USA, počítá s každoročním testováním schopností obnovy a týmů s cílem odhalit jejich slabá místa. Samotný plán se má aktualizovat v četnosti stanovené organizací, například jednou ročně, a po každé významné změně.
GDPR. Jeho článek 32 vyžaduje prostředky, které umožní v přiměřené lhůtě obnovit dostupnost osobních údajů, a proces pravidelného testování a hodnocení účinnosti bezpečnostních opatření.
ANSSI (Francie). Podle francouzské národní agentury pro kybernetickou bezpečnost se zálohy mají pravidelně testovat a postup obnovy informačního systému má být sepsán a pravidelně prováděn. U krizových cvičení agentura doporučuje uvažovat víceleté strategii s formáty, které postupně nabudí na náročnosti.

Žádný z těchto textů nevyžaduje „každý měsíc v reálných podmínkách“. Všechny se shodují na častých kontrolách a úplném testu alespoň jednou ročně.

Proč ne „každý měsíc v reálných podmínkách“

Skutečné přepnutí přeruší produkci, nebo ji přinejmenším ohrozí. Provádět ho každý měsíc stojí mnoho hodin i úsilí a týmy jej nakonec začnou odbyt. Lepší je jeden důkladný test ročně než měsíční rituál, při kterém nikdo neotevře aplikaci.

Na druhou stranu čekat rok, než zjistíte, že záloha už nenaběhne, je příliš dlouho. Proto častá a nenáročná technická kontrola a vzácný, ale úplný provozní test.

Udržitelný harmonogram pro malou a střední firmu

Kdy	Co
Každý den	Projít neúspěšné zálohy. DRP napájený poškozenou kopií je poškozený DRP
Každý měsíc	Technické spuštění záložního prostředí bez vypnutí produkce
Každé čtvrtletí	Obnova souboru nebo databáze s měřením času
Každý rok	Skutečné přepnutí nebo jeho ekvivalent, s uživatelem z provozu a návratem zpět
Při každé změně	Nový server, nová hlavní verze, odchod správce, změna dodavatele nebo internetového připojení

Silně regulované obory nebo životně důležité systémy (zdravotní péče, nepřetržitá výroba) řádek „každý rok“ zkracují, někdy až na pololetí. To však není minimální standard pro firmu poskytující služby. Podrobnosti o jednotlivých úrovních najdete v článku Jak otestovat DRP?.

Co je důležitější než četnost

Zapsané datum posledního testu a opravené odchylky. DRP otestovaný před jedenácti měsíci a doložený zápisem je na tom lépe než DRP „testovaný nepřetržitě“, o němž žádný záznam neříká, co bylo ověřeno. NIST požaduje, aby z každého cvičení vzešla zpráva se zjištěními a doporučeními ke zlepšení.

Pokud je poslední test starší než dvanáct měsíců, řekněte to vedení na rovinu. Je to informace, ne ostuda. Chybou je tvrdit zákazníkovi nebo pojišťovně, že plán je funkční.

Po skutečném incidentu

Skutečná havárie je testem, pokud o ní do týdne vznikne zápis: co trvalo déle, než se čekalo, co chybělo, co se v plánu změní. Bez toho se stejná situace zopakuje stejně. Viz také Můj server vypadl: co dělat?.

Jak to řeší WeDoBack

Kontrola spuštění probíhá měsíčně, je zahrnuta v DRP a do produkce nezasahuje: pokrývá řádek „každý měsíc“ v tabulce, a to pro image, nikoli pro pracovní úkon. Test v reálných podmínkách se plánuje, v rozsahu až deseti hodin, na základě cenové nabídky: je přirozeným kandidátem na roční řádek. Nic v nabídce za vás neotestuje lidský postup (kdo rozhoduje, kde je klíč, jak se informuje tým). Tato část se řídí tempem odchodů a nástupů lidí, nikoli tempem softwaru.

Seznamte se s DRP Vyžádat cenovou nabídku

Časté dotazy

Existuje zákonná povinnost určité četnosti testů?

Obecné pravidlo pro všechny malé a střední firmy neexistuje. GDPR (článek 32) i ANSSI, francouzská agentura pro kybernetickou bezpečnost, požadují testovat „pravidelně“, aniž by stanovily četnost. NIST pro federální systémy USA počítá s ročním testem. Některé regulované obory, případně vaše smlouvy a pojišťovna, mohou vyžadovat častější testy.

Počítá se skutečná havárie jako test?

Ano, pokud o ní do týdne vznikne zápis: co trvalo déle, než se čekalo, co chybělo, co se v plánu mění. Bez tohoto záznamu incident ke zlepšení plánu neposlouží.

Co říct zákazníkovi nebo pojišťovně, pokud je poslední test starší než rok?

Pravdu, včetně data. Prohlásit plán za funkční bez nedávného testu znamená riziko rozporu mezi slibem a skutečností v den havárie. Lepší je uvést plánované datum příštího testu.

Další čtení

Zdroje

Dokumenty ověřeny v říjnu 2026.

SP 800-34 Rev. 1, Průvodce plánováním pro nepředvídané situace u federálních informačních systémů (v angličtině) — NIST
Nařízení (EU) 2016/679 (GDPR), článek 32 — EUR-Lex
Zálohování informačních systémů – Základy (ANSSI-BP-100, v1.1, 27. listopadu 2025) — ANSSI (francouzská agentura)
Jak zorganizovat cvičení řízení kybernetické krize (Organiser un exercice de gestion de crise cyber) — ANSSI (francouzská agentura)
SP 800-84, Průvodce programy testů, školení a cvičení pro plány a schopnosti IT (září 2006, v angličtině) — NIST
Nabídka DRP: obnova provozu po havárii — WeDoBack

Plánujete projekt zálohování, DRP nebo BCP?

Více než 20 let zkušeností s ochranou firemních dat.

Vyžádat cenovou nabídku +33 9 72 50 78 28

Chraňte svá data s WeDoBack

Šifrované zálohování mimo pracoviště, neměnné úložiště, DRP a BCP: popište nám své servery a my vám navrhneme vhodnou kombinaci.

Vyžádat cenovou nabídku Zobrazit nabídky a ceny