Záloha MySQL: čo musí preveriť skúška obnovy

Úspešná úloha ešte nepreukazuje použiteľný systém

Zálohovací proces môže skončiť bez chyby a vytvoriť veľký súbor. Pri výpadku však tím zistí, že chýba šifrovací kľúč, časť príloh alebo prístup do úložiska. Ilustračný zákaznícky portál potrebuje objednávky aj ich dokumenty; obnovenie samotnej tabuľky mu funkciu nevráti. Preto skúška obnovy musí končiť kontrolou pracovnej úlohy v aplikácii.

Spíšte všetko, čo služba potrebuje: databázu, súbory, konfiguráciu, tajomstvá, potrebnú verziu aplikácie a externé závislosti. Zálohu chráňte pred rovnakou chybou či účtom, ktorý dokáže zničiť pôvodné údaje. Replika prenáša zmeny a môže preniesť aj nechcené vymazanie; jej úlohu preto odlišujte od uchovania bodu, ku ktorému sa chcete vrátiť.

RPO určuje prijateľnú stratu dát, RTO čas obnovy

Recovery Point Objective vyjadruje, ako ďaleko do minulosti môže obnovený stav zaostávať za incidentom. Recovery Time Objective stanovuje cieľový čas návratu služby. Tieto pojmy patria do plánovania kontinuity, ktoré opisuje NIST. Hodnoty musí určiť vlastník procesu podľa dôsledkov straty objednávok či nedostupnosti služby.

V ilustračnej dohode môže firma požadovať obnovu dát s odstupom najviac pätnástich minút a návrat služby do štyroch hodín. Sú to ukážkové požiadavky, nie výsledok eWorks ani univerzálne odporúčanie. Nočná záloha sama prvú požiadavku nepokryje. Druhá musí počítať s nájdením incidentu, prípravou prostredia, prenosom dát, obnovou a funkčnou kontrolou.

Obnova do bodu v čase potrebuje súvislú históriu

Dokumentácia MySQL 8.4 opisuje point-in-time recovery ako obnovenie úplnej zálohy a následné prehratie potrebných zmien z binárnych logov. Nestačí ponechať logy iba na poškodenom serveri. Retencia a ich kopírovanie musia nadväzovať na dostupné zálohy, aby sa medzi základným stavom a požadovaným bodom nevytvorila medzera.

Postup musí vedieť určiť zodpovedajúcu pozíciu logu alebo ďalší identifikátor podľa použitej metódy. Pri incidente spôsobenom chybným zápisom treba zvoliť hranicu pred nežiaducou zmenou. Časové pásmo a presnosť času patria do záznamu skúšky. Produkčný návod sa musí opierať o konkrétnu verziu, zálohovací nástroj a transakčné správanie použitých tabuliek.

Skúšku spustite v oddelenom prostredí

Obnovená aplikácia nesmie automaticky poslať staré faktúry, notifikácie alebo webhooky. Pred spustením vypnite odchádzajúce integrácie a nastavte skúšobné adresy. Prostredie má byť oddelené aj prístupmi a sieťou. Reálne údaje zo zálohy zostávajú chránené údaje aj počas testu; skúška nemá vytvoriť verejne prístupnú kópiu portálu.

Použite postup, ktorý dokáže vykonať aj zastupujúci kolega. Zaznamenajte verzie, potrebné oprávnenia a miesta uloženia kľúčov bez vloženia samotných tajomstiev do návodu. Čas začnite merať od dohodnutého bodu. Ak skúška preskočí vytvorenie servera alebo stiahnutie veľkej zálohy, výsledok musí tieto vynechané kroky jasne uviesť.

Overte dátové väzby aj stav súborov

Kontrola počtu riadkov a integrity súboru je užitočná, ale objednávka potrebuje správne položky, sumy a prílohy. Vytvorte skúšobné referenčné záznamy pred zálohou aj po nej a overte, ktoré majú v obnovenom bode existovať. Pri súboroch preverujte obsah aj väzbu na databázový záznam. Nezávislá obnova dvoch úložísk môže vytvoriť chýbajúce alebo osirelé prílohy.

Tím má vyskúšať prihlásenie, vyhľadanie objednávky a chránené stiahnutie dokumentu. Potom preverí, že zakázané odchádzajúce integrácie zostali zakázané. Pri skutočnom návrate do prevádzky sa osobitne rozhoduje o udalostiach vzniknutých po obnovenom bode, o duplicitách a o zosúladení s externými systémami. Prehratie celej fronty bez kontroly môže zopakovať obchodné účinky.

Z výsledku skúšky vytvorte konkrétne opravy

Záznam skúšky má uviesť použitú zálohu, dosiahnutý bod obnovy, nameraný čas, výsledky funkčných kontrol a prekážky. Ak chýbal prístup alebo súbor, priraďte oprave vlastníka a zopakujte príslušnú časť po náprave. Termín ďalšej skúšky určte podľa zmien systému a významu procesu; samotná pravidelnosť bez kontroly výsledku nestačí.

• Záloha a nadväzujúce logy tvoria obnoviteľnú postupnosť bez medzery.
• Kľúč a prístup do úložiska sú dostupné aj pri nedostupnom pôvodnom serveri.
• Databáza a dokumenty sa obnovia do vzájomne overeného stavu.
• Skúška zmeria celý dohodnutý rozsah RTO a uvedie vynechané kroky.

Od témy ku konkrétnemu riešeniu.