Zálohování a obnova firemní aplikace: co znamená RPO a RTO v praxi

„Zálohu máme" je jedna z nejčastěji vyslovených a nejméně ověřených vět ve firemním IT. Záloha, která běží podle plánu, ale nikdy se nezkoušelo, jestli se z ní dají data reálně obnovit, je jen předpoklad. A předpoklady o zálohách se nejčastěji ukážou jako nesprávné přesně tehdy, když je nejpozději na nápravu.

Dvě zkratky, které se v tomto tématu objevují, znějí jako technický žargon, ale odpovídají na dvě velmi konkrétní obchodní otázky.

Recovery Point Objective (RPO) říká, jak velký časový úsek dat je firma ochotná ztratit při výpadku. Pokud se záloha dělá jednou denně o půlnoci a systém spadne v jedenáct dopoledne, RPO je jedenáct hodin — přesně tolik dat, kolik vzniklo od poslední zálohy, se nenávratně ztratí.

Pro e-shop to znamená jedenáct hodin objednávek, které nikdo nezapsal nikam jinam. Pro systém, kde se data zapisují ručně nebo generují z jiné evidence, může být tato ztráta obnovitelná zpětně — pracně, ale obnovitelná. Rozdíl mezi těmito dvěma situacemi je přesně to, co určuje, jaké RPO je pro danou aplikaci přijatelné.

Recovery Time Objective (RTO) říká, jak dlouho smí trvat, než je systém po výpadku znovu funkční. Není to totéž co RPO — dá se mít výborné RPO (ztratíte jen pár sekund dat) a hrozné RTO (obnova trvá dva dny), i naopak.

RTO určuje, jaký typ zálohovací infrastruktury firma potřebuje. Obnovit systém z jednoho souboru zálohy na nový server může trvat hodiny, než se všechno nainstaluje a nakonfiguruje. Mít připravené záložní prostředí, které se dá spustit přepnutím, zkrátí to na minuty — za cenu, že to prostředí je třeba udržovat běžet i tehdy, když se nepoužívá.

Denní záloha databáze je běžný standard a pro spoustu aplikací dostatečný — pokud je přijatelné RPO měřené v hodinách. Pro aplikace, kde se data mění průběžně a ztráta byť hodin dat je nepřijatelná (platební systémy, objednávkové toky s vysokým objemem), se nastavuje jiný mechanismus: průběžné zálohování transakčního logu, které umožňuje obnovit stav databáze k přesnému okamžiku těsně před výpadkem, ne jen k poslední půlnoční snímce.

Záloha na stejném serveru. Pokud záloha leží na stejném disku nebo ve stejném datovém centru jako produkční data, chrání před smazáním záznamu nebo chybou v aplikaci, ale ne před výpadkem celého serveru, požárem nebo útokem, který zasáhne i zálohu. Pravidlo, které se vyplatí dodržet, je alespoň jedna kopie mimo primární infrastrukturu.

Záloha, která se nikdy neobnovila. Firmy zálohují roky a poprvé se pokusí data obnovit až při skutečném výpadku. Tehdy se zjistí, že záloha je poškozená, že chybí část konfigurace potřebná ke spuštění, nebo že proces obnovy nikdo v týmu nikdy nedělal a improvizuje se naživo.

Šifrovací klíče a hesla mimo zálohu. Pokud jsou data šifrovaná a klíč se nezálohuje stejně důsledně jako data, obnovená záloha je nepoužitelná hromada šifrovaného textu.

Funkčnost zálohy se nedá ověřit kontrolou, že „proces zálohování proběhl bez chyby". Jediný způsob je pravidelně skutečně obnovit data do testovacího prostředí a ověřit, že aplikace s nimi běží. To odhalí věci, které se jinak nezjistí — chybějící část konfigurace, nekompatibilní verzi, poškozený soubor, zapomenutý krok v postupu.

Tento test je zároveň jediný způsob, jak reálně změřit RTO — ne odhadem, ale stopkami. Firma, která si myslí, že obnova trvá dvě hodiny, a nikdy to nezkusila, se při skutečném výpadku může dozvědět, že to trvá den.

Tato disciplína úzce souvisí s bezpečným nasazováním softwaru obecně — stejný princip „otestované předem, ne předpokládané" platí i u rollbacku po nasazení, kterému jsme se věnovali v článku o CI/CD a bezpečném nasazování.

Správná hodnota není univerzální, je to obchodní rozhodnutí s technickými důsledky:

1. Kolik stojí ztráta hodiny dat — v obratu, důvěře zákazníků, právních povinnostech.
2. Kolik stojí hodina výpadku — nejen přímo, ale i v reputaci a smluvních pokutách, pokud existují.
3. Jaká data se reálně mění průběžně a která jsou téměř statická — ne každá tabulka potřebuje stejnou úroveň ochrany.
4. Jaký rozpočet je firma ochotná dát na infrastrukturu, která většinu času jen čeká na to, aby nikdy nebyla potřeba.

RPO odpovídá na to, kolik dat je firma ochotná ztratit; RTO na to, jak dlouho může být mimo provoz. Denní záloha stačí pro většinu aplikací, ale ne pro ty, kde ztráta hodin dat není přijatelná. Záloha, která se nikdy zkušebně neobnovila, není ověřená záloha — a právě test obnovy je jediný způsob, jak zjistit skutečné RTO.

Správné nastavení závisí na konkrétní aplikaci a na tom, co si firma může dovolit ztratit. Pokud řešíte zálohovací strategii pro vlastní systém, projdeme si ji na nezávazné konzultaci.