Čo má záloha webu skutočne obnoviť?

Úloha zálohovania sa môže skončiť úspešne, aj keď obnova zostáva nevyskúšaná. Správa o úspechu neukazuje, či kópia dokáže vrátiť časti webu, ktoré firma potrebuje. Ani obnovená úvodná stránka vám veľa nepovie o tom, či sa zamestnanci dokážu prihlásiť, nájsť záznamy zákazníkov alebo otvoriť nahrané dokumenty.

Začnite tým, čo na webe robíte. Čo by ste po jeho strate potrebovali urobiť? Potom sa poskytovateľa spýtajte, čo všetko by sa muselo obnoviť, aby to bolo možné.

Rezervácia a jej príloha patria k sebe

Predstavte si rezervačný web, ktorý ukladá termíny do databázy a dokumenty zákazníkov ako nahrané súbory. Je to hypotetický príklad, no ľahko si ho predstavíte: obnovíte rezerváciu, kliknete na jej prílohu a zistíte, že dokument chýba.

Údaje o rezervácii máte. Prácu, na ktorú potrebujete dokument, však dokončiť nemôžete.

Pri typickom webe na WordPresse odporúčania WordPressu k zálohám vysvetľujú, že záleží na databáze aj súboroch a že majú tvoriť vzájomne zladený celok. Iné weby môžu byť postavené inak. Spýtajte sa, kde sa vaše záznamy a nahrané súbory skutočne nachádzajú. Nepredpokladajte, že záloha jedného priečinka pokrýva všetko.

Dôležitý je aj samotný webový softvér, jeho nastavenia a prístupy potrebné na obnovu a používanie. Rovnako aj prepojené služby. Pokyny austrálskeho riaditeľstva pre signály k správe systémov odporúčajú obnoviť dáta, aplikácie a nastavenia k rovnakému okamihu a vopred určiť závislosti. Pre majiteľa firmy to znamená spýtať sa, či budú jednotlivé časti fungovať spolu a kto má prístupy potrebné na ich obnovenie.

Koľko nedávnej práce by mohlo chýbať?

Obnovená kópia zachytáva web v určitom okamihu minulosti. Rezervácia vytvorená po tomto okamihu v nej môže chýbať, aj keď obnova prebehne presne podľa plánu.

Spýtajte sa poskytovateľa, k akému okamihu sa dajú dáta obnoviť a aké staré budú tieto údaje, keď ich budete potrebovať. Potom zvážte, čo by chýbajúca práca znamenala. Dokázali by ju zamestnanci doplniť z iného záznamu? Museli by ste kontaktovať zákazníkov? Prijateľná odpoveď závisí od toho, čo váš web robí.

Dôležitý je aj čas, kým sa vrátite k práci. Samotné skopírovanie dát späť nestačí. Niekto musí obnoviť aj ostatné časti a overiť, či dôležité úlohy fungujú. Pokyny AWS k testovaniu obnovy odporúčajú obnovu samostatne vyskúšať, overiť dostupnosť a použiteľnosť obnovených dát a merať ich vek aj čas potrebný na obnovu a overenie podľa potrieb firmy.

Spýtajte sa, ako dlho tieto kroky trvali počas testu. Získate konkrétny podklad na rozhovor. Nie je to prísľub, ako dlho potrvá celý prípadný incident vrátane odhalenia problému a rozhodovania o ďalšom postupe.

Platba sa napriek tomu mohla uskutočniť

Vráťme sa k rezervačnému webu. Predstavte si, že zákazník zaplatil zálohu cez externú platobnú službu. Obnovenie staršej kópie webu túto platbu nevráti ani nepotvrdí, že údaje na webe súhlasia s údajmi platobnej služby.

Ak sú samotné rezervácie uložené v externej rezervačnej službe, v zálohe webu nemusia byť vôbec. Spýtajte sa, ktorý systém obsahuje záznam, podľa ktorého sa majú zamestnanci riadiť, čo sa dá obnoviť v tejto službe a ako niekto overí, či záznamy v oboch systémoch súhlasia. Obnova webu nevráti všetko, čo je s ním prepojené.

Požiadajte o bezpečnú obnovu

Užitočným ďalším krokom je plánovaná obnova, ktorú vykonajú oprávnené osoby v izolovanom prostredí. Vopred sa dohodnite, kto ju vykoná a čo skontroluje. Obnovená kópia musí chrániť osobné aj firemné údaje, zostať mimo verejného prístupu a nezasiahnuť do živých záznamov.

Zároveň treba zabrániť odoslaniu skutočných e-mailov, prijatiu platieb, spusteniu webhookov alebo iných automatických požiadaviek na iné služby a vytváraniu živých rezervácií. Ak sú dostupné, môžu pomôcť kontrolované testovacie účty a testovacie prepojenia. Ak sa nejaká služba nedá v teste bezpečne použiť, zaznamenajte toto obmedzenie a jej úlohu overte osobitne.

V našom hypotetickom príklade by poskytovateľ obnovil vzájomne zladenú kópiu, prihlásil sa s kontrolovaným prístupom, otvoril vybranú rezerváciu aj jej prílohu a porovnal ich s tým, čo má existovať v danom okamihu obnovy. To je užitočnejšie než snímka úvodnej stránky.

Historickou pripomienkou, prečo na tom záleží, je opis výpadku databázy GitLabu z januára 2017. Očakávané zálohy databázy neboli dostupné a e-maily s upozornením na chybu sa nedoručili; obnova sa opierala o inú snímku. Strata sa týkala databázových údajov GitLab.com, nie dát repozitárov ani zákazníkov s vlastnou inštaláciou. Ukazuje rozdiel medzi nastaveným zálohovaním a skutočne použiteľnou cestou späť.

Podľa výsledku rozhodnite, čo treba zmeniť

Požiadajte o stručný záznam toho, čo sa obnovilo a k akému okamihu, ktoré úlohy sa kontrolovali a s akým výsledkom. Mal by uvádzať aj vek obnovených údajov, čas obnovy a kontrol, potrebné prístupy a prepojené služby, ako aj to, čo zlyhalo alebo zostalo neoverené.

Úspešná kontrola rezervácie potvrdzuje túto úlohu za podmienok daného testu. Nedokazuje, že sú všetky záznamy neporušené, že fungujú všetky funkcie alebo že každá budúca obnova potrvá rovnako dlho. Izolovaná kópia sama osebe tiež nepotvrdzuje, že je obnovený web bezpečný alebo bez následkov útoku.

Porovnajte výsledok s tým, čo vaša firma potrebuje. Možno máte dosť dôkazov, že dohodnuté pokrytie vyhovuje. Možno nájdete konkrétnu medzeru, napríklad chýbajúce nahrané súbory alebo nedostupný účet. Alebo test nezodpovie dôležitú otázku a bude potrebné ho rozšíriť.

Ak s LINK-V preberáte údržbu webu, prineste zoznam úloh, ktoré by zamestnanci aj zákazníci potrebovali po obnove zvládnuť. Potrebné pokrytie a prípadné testovanie obnovy potom môžete dohodnúť pre svoj web.