Pri kvartálnom audite spravovaných serverov u jedného klienta sme popri káve položili otázku, ktorú odvtedy kladieme všade: kedy ste poslednýkrát skutočne obnovili niečo zo zálohy? Otázka znie nevinne. Odpoveď znela ešte nevinnejšie — „nikdy sa nič nestratilo, takže nebolo treba”. Zálohovanie bežalo. Cron logy mali zelené hlášky. Tým sa to malo skončiť.
Skončilo sa to víkendom disaster-recovery cvičení. Niečo z toho fungovalo. Veľa z toho nie.
Otázka, ktorá to celé spustila
Klient mal zálohovanie dvojakého typu: nočný `rsync` súborov na NAS, ktorý sa potom raz denne zrkadlil do S3 Glacieru; a `pg_dump` databázy do toho istého bucketu. Schéma vyzerala čisto. CTO mal Datadog screenshoty s rovnou zelenou linkou „backup OK” za osemnásť mesiacov bez prerušenia. Riadne dokumentované zálohovanie. Riadne ho nikto nikdy nevyskúšal obnoviť.
V piatok popoludní sme navrhli neformálne cvičenie. Štyri scenáre: obnovenie jedného súboru, obnovenie jednej databázy do staging-u, obnovenie kompletného image-u servera do izolovaného VM, a — ten posledný — krížový test, kde si poznámky robí niekto iný ako ten, kto zálohu pôvodne nastavoval.
Čo sme zistili za 14 hodín
- IAM kľúč, cez ktorý S3 lifecycle politika sťahovala objekty späť z Glacieru pre obnovu, bol pred deviatimi mesiacmi rotovaný. Nový sa nikdy nezapojil do restore skriptu. Zálohovanie ukladalo. Obnova by nedokázala stiahnuť ani jeden súbor.
- Mount NAS-u fungoval. Z milióna súborov sa 94 % obnovilo bez problémov. Zvyšných 6 % bolo poškodených: `rsync --inplace` cez sieťovo pripojený NAS prepisoval polovičné súbory a občas zomrel uprostred.
- `pg_dump` produkoval súbory. Obnovenie do staging Postgresu padlo na konflikte rolí — `pg_dump` bežal pod iným používateľom ako ten, ktorý vlastnil tabuľky. Postgres to pri obnove kontroluje. Nikto to nikdy nevedel, lebo nikto nikdy nerobil obnovu.
- Image kompletného servera sa dal obnoviť. Trvalo to 11 hodín cez Glacier expedited retrieval, čo stálo viac, ako klient čakal. A na obnovenom serveri sa nedal aktivovať licenčný kľúč k OS — bol viazaný na MAC adresu starého hardvéru.
Pondelok ráno mali zálohovanie, ktoré technicky bežalo, ale v jednom zo štyroch dôležitých scenárov by neobnovilo nič. To je 25-percentná šanca na úplnú katastrofu v deň, keď ju naozaj potrebujú.
Záloha, ktorú si nikdy neotestoval, je iba dúfanie na disku. Niekedy ani to.
Štyri kontroly, ktoré dnes robíme každý kvartál
- Obnovenie náhodného súboru cez celý reťazec, presne tak ako by to robil junior o tretej ráno. Z S3 cez Glacier expedited retrieval cez IAM kľúč, ktorý skutočne odpovedá. Cieľ: úspech do 30 minút.
- Obnovenie najnovšieho `pg_dump`-u do izolovaného staging Postgresu. Cieľ: kompletná schéma + indexy + cudzie kľúče naložené bez chyby do 60 minút.
- Plná obnova disk image-u do dočasného VM bez sieťového pripojenia. Cieľ: bootovateľný systém s prístupnou aplikačnou vrstvou do 4 hodín. (Toto trvalo najdlhšie, ale rozdiel medzi 4 a 24 hodinami sa ráta.)
- Kalendárový zápis nasledujúceho kvartálu. Žiadna kontrola neexistuje, kým nemá dátum.
Po tom víkende sme klientovi vyfakturovali dva pracovné dni. Zachránili sme im jeden — možno dva — produkčné výpadky, ktoré by za rovnaký mesiac inak mohli prísť. To je najlepší pomer cena/výkon, aký v IT poznáme. K bežnej praxi to patrí v rámci našej spravovanej IT služby — ale s nastavením pomôžeme aj klientom, ktorí si infraštruktúru spravujú sami.
