„Zálohu máme" je jedna z najčastejšie vyslovených a najmenej overených viet vo firemnom IT. Záloha, ktorá beží podľa plánu, ale nikdy sa neskúšalo, či sa z nej dá dáta reálne obnoviť, je len predpoklad. A predpoklady o zálohách sa najčastejšie ukážu ako nesprávne presne vtedy, keď je najneskôr na nápravu.
Dve skratky, ktoré sa v tejto téme objavujú, znejú ako technický žargón, ale odpovedajú na dve veľmi konkrétne obchodné otázky.
RPO: koľko dát smiete stratiť
Recovery Point Objective (RPO) hovorí, aký veľký časový úsek dát je firma ochotná stratiť pri výpadku. Ak sa záloha robí raz denne o polnoci a systém spadne o jedenástej dopoludnia, RPO je jedenásť hodín — presne toľko dát, koľko vzniklo od poslednej zálohy, sa nenávratne stratí.
Pre e-shop to znamená jedenásť hodín objednávok, ktoré nikto nezapísal nikam inam. Pre systém, kde sa dáta zapisujú ručne alebo generujú z inej evidencie, môže byť táto strata obnoviteľná spätne — pracne, ale obnoviteľná. Rozdiel medzi týmito dvoma situáciami je presne to, čo určuje, aké RPO je pre danú aplikáciu prijateľné.
RTO: ako dlho môžete byť mimo prevádzky
Recovery Time Objective (RTO) hovorí, ako dlho smie trvať, kým je systém po výpadku znova funkčný. Nie je to to isté ako RPO — dá sa mať výborné RPO (stratíte len pár sekúnd dát) a hrozné RTO (obnova trvá dva dni), aj naopak.
RTO určuje, aký typ zálohovacej infraštruktúry firma potrebuje. Obnoviť systém z jedného súboru zálohy na nový server môže trvať hodiny, kým sa všetko nainštaluje a nakonfiguruje. Mať pripravené záložné prostredie, ktoré sa dá spustiť prepnutím, skráti to na minúty — za cenu, že to prostredie treba udržiavať bežať aj vtedy, keď sa nepoužíva.
Prečo denná záloha nestačí na všetko
Denná záloha databázy je bežný štandard a pre veľa aplikácií dostatočný — ak je prijateľné RPO merané v hodinách. Pre aplikácie, kde sa dáta menia priebežne a strata čo aj hodiny dát je neprijateľná (platobné systémy, objednávkové toky s vysokým objemom), sa nastavuje iný mechanizmus: priebežné zálohovanie transakčného logu, ktoré umožňuje obnoviť stav databázy k presnému okamihu tesne pred výpadkom, nie len k poslednej polnočnej snímke.
| Typ zálohy | Typické RPO | Kedy stačí |
|---|---|---|
| Denná snímka databázy | až 24 hodín | nízky objem zmien, dáta sa dajú rekonštruovať |
| Snímka niekoľkokrát denne | jednotky hodín | stredný objem, čiastočná tolerancia straty |
| Priebežné zálohovanie transakčného logu | sekundy až minúty | platby, objednávky, kritické toky |
Kde sa záloha najčastejšie pokazí
Záloha na tom istom serveri. Ak záloha leží na rovnakom disku alebo v tom istom dátovom centre ako produkčné dáta, chráni pred zmazaním záznamu alebo chybou v aplikácii, ale nie pred výpadkom celého servera, požiarom alebo útokom, ktorý zasiahne aj zálohu. Pravidlo, ktoré sa oplatí dodržať, je aspoň jedna kópia mimo primárnej infraštruktúry.
Záloha, ktorá sa nikdy neobnovila. Firmy zálohujú roky a prvýkrát sa pokúsia dáta obnoviť až pri skutočnom výpadku. Vtedy sa zistí, že záloha je poškodená, že chýba časť konfigurácie potrebnej na spustenie, alebo že proces obnovy nikto v tíme nikdy nerobil a improvizuje sa naživo.
Šifrovacie kľúče a heslá mimo zálohy. Ak sú dáta šifrované a kľúč sa nezálohuje rovnako dôsledne ako dáta, obnovená záloha je nepoužiteľná hromada šifrovaného textu.
Test obnovy: jediný spôsob, ako to overiť
Funkčnosť zálohy sa nedá overiť kontrolou, že „proces zálohovania prebehol bez chyby". Jediný spôsob je pravidelne skutočne obnoviť dáta do testovacieho prostredia a overiť, že aplikácia s nimi beží. Toto odhalí veci, ktoré sa inak nezistia — chýbajúcu časť konfigurácie, nekompatibilnú verziu, poškodený súbor, zabudnutý krok v postupe.
Tento test je zároveň jediný spôsob, ako reálne zmerať RTO — nie odhadom, ale stopkami. Firma, ktorá si myslí, že obnova trvá dve hodiny, a nikdy to neskúsila, sa pri skutočnom výpadku môže dozvedieť, že to trvá deň.
Táto disciplína úzko súvisí s bezpečným nasadzovaním softvéru vo všeobecnosti — rovnaký princíp „otestované predtým, nie predpokladané" platí aj pri rollbacku po nasadení, ktorému sme sa venovali v článku o CI/CD a bezpečnom nasadzovaní.
Ako nastaviť RPO a RTO pre konkrétnu aplikáciu
Správna hodnota nie je univerzálna, je to obchodné rozhodnutie s technickými dôsledkami:
- Koľko stojí strata hodiny dát — v obrátkach, dôvere zákazníkov, právnych povinnostiach.
- Koľko stojí hodina výpadku — nie len priamo, ale aj v reputácii a zmluvných pokutách, ak existujú.
- Aké dáta sa reálne menia priebežne a ktoré sú takmer statické — nie každá tabuľka potrebuje rovnakú úroveň ochrany.
- Aký rozpočet je firma ochotná dať na infraštruktúru, ktorá sa väčšinu času len čaká na to, aby nikdy nebola potrebná.
Zhrnutie
RPO odpovedá na to, koľko dát je firma ochotná stratiť; RTO na to, ako dlho môže byť mimo prevádzky. Denná záloha stačí pre väčšinu aplikácií, ale nie pre tie, kde strata hodín dát nie je prijateľná. Záloha, ktorá sa nikdy neobnovila skúšobne, nie je overená záloha — a práve test obnovy je jediný spôsob, ako zistiť skutočné RTO.
Správne nastavenie závisí od konkrétnej aplikácie a od toho, čo si firma môže dovoliť stratiť. Ak riešite zálohovaciu stratégiu pre vlastný systém, prejdeme si ju na nezáväznej konzultácii.