Co má záloha webu skutečně obnovit?

Zálohovací úloha může skončit úspěšně, i když obnova zůstává neověřená. Zpráva o úspěchu neukazuje, zda kopie vrátí části webu, které firma potřebuje. Ani obnovená úvodní stránka vám moc neřekne o tom, zda se zaměstnanci přihlásí, najdou záznamy zákazníků nebo otevřou nahrané dokumenty.

Začněte tím, co na webu děláte. Co byste po jeho ztrátě potřebovali udělat? Pak se poskytovatele zeptejte, co všechno by se muselo obnovit, aby to šlo.

Rezervace a její příloha patří k sobě

Představte si rezervační web, který ukládá termíny do databáze a dokumenty zákazníků jako nahrané soubory. Je to hypotetický příklad, ale snadno si ho představíte: obnovíte rezervaci, kliknete na její přílohu a zjistíte, že dokument chybí.

Údaje o rezervaci máte. Práci, ke které potřebujete dokument, ale dokončit nemůžete.

U typického webu na WordPressu doporučení WordPressu k zálohám vysvětluje, že záleží na databázi i souborech a že mají tvořit vzájemně odpovídající celek. Jiné weby mohou být postavené jinak. Zeptejte se, kde jsou vaše záznamy a nahrané soubory skutečně uložené. Nepředpokládejte, že záloha jedné složky pokrývá všechno.

Záleží také na samotném webovém softwaru, jeho nastavení a přístupech potřebných k obnově a používání. A také na propojených službách. Pokyny australského ředitelství pro signály ke správě systémů doporučují obnovit data, aplikace a nastavení ke stejnému okamžiku a předem určit závislosti. Pro majitele firmy to znamená zeptat se, zda budou jednotlivé části fungovat společně a kdo má přístupy potřebné k jejich obnovení.

Kolik nedávné práce by mohlo chybět?

Obnovená kopie zachycuje web v určitém okamžiku minulosti. Rezervace vytvořená později v ní může chybět, i když obnova proběhne přesně podle plánu.

Zeptejte se poskytovatele, k jakému okamžiku lze data obnovit a jak staré tyto údaje budou, až je budete potřebovat. Pak zvažte, co by chybějící práce znamenala. Dokázali by ji zaměstnanci sestavit z jiného záznamu? Museli byste kontaktovat zákazníky? Přijatelná odpověď závisí na tom, co váš web dělá.

Důležitý je také čas, než se vrátíte k práci. Samotné zkopírování dat zpět nestačí. Někdo musí obnovit i ostatní části a ověřit, že důležité úkoly fungují. Pokyny AWS k testování obnovy doporučují obnovu samostatně vyzkoušet, ověřit dostupnost a použitelnost obnovených dat a měřit jejich stáří i dobu obnovy a ověření podle potřeb firmy.

Zeptejte se, jak dlouho tyto kroky trvaly při testu. Získáte konkrétní podklad k rozhovoru. Není to příslib, jak dlouho potrvá celý případný incident, včetně odhalení problému a rozhodování o dalším postupu.

Platba mohla přesto proběhnout

Vraťme se k rezervačnímu webu. Představte si, že zákazník zaplatil zálohu přes externí platební službu. Obnova starší kopie webu tuto platbu nevrátí ani nepotvrdí, že údaje na webu souhlasí s údaji platební služby.

Pokud jsou samotné rezervace uložené v externí rezervační službě, v záloze webu vůbec být nemusí. Zeptejte se, který systém obsahuje záznam, podle kterého se mají zaměstnanci řídit, co lze obnovit v této službě a jak někdo ověří, že záznamy v obou systémech souhlasí. Obnova webu nevrátí zpět vše, co je s ním propojené.

Požádejte o bezpečnou obnovu

Užitečným dalším krokem je plánovaná obnova, kterou provedou oprávněné osoby v izolovaném prostředí. Předem si dohodněte, kdo ji provede a co zkontroluje. Obnovená kopie musí chránit osobní i firemní údaje, nesmí být veřejně přístupná a nesmí změnit živé záznamy.

Zároveň je třeba zabránit odesílání skutečných e-mailů, přijímání plateb, spouštění webhooků nebo jiných automatických požadavků na jiné služby a vytváření skutečných rezervací. Kde jsou k dispozici, mohou pomoci kontrolované testovací účty a testovací propojení. Pokud nějakou službu nelze v testu bezpečně použít, zaznamenejte toto omezení a její roli ověřte zvlášť.

V našem hypotetickém příkladu by poskytovatel obnovil vzájemně odpovídající kopii, přihlásil se s kontrolovaným přístupem, otevřel vybranou rezervaci i její přílohu a porovnal je s tím, co má k danému okamžiku obnovy existovat. To je užitečnější než snímek úvodní stránky.

Historickou připomínkou, proč na tom záleží, je popis výpadku databáze GitLabu z ledna 2017. Očekávané zálohy databáze nebyly dostupné a e-maily s upozorněním na chybu se nedoručily; obnova se opírala o jiný snímek. Ztráta se týkala databázových údajů GitLab.com, nikoli dat repozitářů ani zákazníků s vlastní instalací. Ukazuje rozdíl mezi nastaveným zálohováním a skutečně použitelnou cestou zpět.

Podle výsledku rozhodněte, co je třeba změnit

Požádejte o stručný záznam toho, co bylo obnoveno a k jakému okamžiku, které úkoly se kontrolovaly a s jakým výsledkem. Měl by uvádět také stáří obnovených údajů, dobu obnovy a kontrol, potřebné přístupy a propojené služby i to, co selhalo nebo zůstalo neověřené.

Úspěšná kontrola rezervace potvrzuje tento úkol za podmínek daného testu. Nedokazuje, že jsou neporušené všechny záznamy, fungují všechny funkce ani že každá budoucí obnova potrvá stejně dlouho. Izolovaná kopie sama o sobě také nepotvrzuje, že je obnovený web bezpečný nebo bez následků útoku.

Porovnejte výsledek s tím, co vaše firma potřebuje. Možná máte dost důkazů, že dohodnuté pokrytí vyhovuje. Možná najdete konkrétní mezeru, například chybějící nahrané soubory nebo nedostupný účet. Nebo test nezodpoví důležitou otázku a bude potřeba ho rozšířit.

Pokud s LINK-V probíráte údržbu webu, přineste seznam úkolů, které by zaměstnanci i zákazníci potřebovali po obnově zvládnout. Potřebné pokrytí a případné testování obnovy pak můžete dohodnout pro svůj web.