Záloha, ktorú ste nikdy neobnovili, nie je záloha

Najhorší moment na zistenie, že záloha nefunguje, je chvíľa, keď ju potrebujete. A predsa je najbežnejší scenár presne takýto: zálohy sa raz nastavia, osemnásť mesiacov svieti v dashboarde zelená fajka a potom obnovenie vytvorí prázdnu databázu.

Testovanie obnovenia databázovej zálohy nie je best practice v zmysle, v akom sú väčšinou best practices voliteľné. Záloha je tvrdenie a kým ste ju neobnovili, ide o neoverené tvrdenie.

Pozrime sa, ako zlyhávajú a čo musí overenie skutočne kontrolovať.

Štyri spôsoby, ako môže byť záloha potichu nepoužiteľná

1. Je prázdna a nikto sa nepozrel

pg_dump, ktorý zlyhá uprostred procesu, môže stále vytvoriť súbor. Dump spustený nad nesprávnym názvom databázy vytvorí platný, správny, ale prázdny súbor. Obe situácie vyzerajú ako úspech pre čokoľvek, čo kontroluje nenulový exit code alebo existenciu súboru.

Najlacnejšia kontrola na svete: pozrite sa na veľkosť a porovnajte ju so včerajšou. Záloha s veľkosťou 400 bajtov, keď včerajšia mala 40 MB, vám povedala všetko. Záloha, ktorá má už šesť mesiacov 400 bajtov, vám to hovorí celý čas.

2. Obsahuje dáta, ale nie veci okolo nich

pg_dump jednej databázy neobsahuje roly ani ostatné databázy. Obnovte ho na nový server a tabuľky sa objavia, no každý GRANT odkazuje na neexistujúcu rolu. Aplikácia sa pripojí a pri všetkom dostane permission denied.

Pri extensions platí to isté. Ak vaša schéma závisí od pgcrypto alebo uuid-ossp a cieľové prostredie ich nemá, obnovenie zlyhá uprostred procesu a zostane vám len časť tabuliek.

3. Flagy nezodpovedali obnoveniu, ktoré potrebujete

pg_dump vytvára rôzne výstupy v závislosti od formátu a na chybu sa zvyčajne príde až pod tlakom:

• Plain SQL sa obnovuje pomocou psql a je čitateľný pre človeka. Nedá sa obnoviť selektívne a pri veľkých databázach je pomalý.
• Custom format (-Fc) sa obnovuje pomocou pg_restore, podporuje paralelizmus aj selektívne obnovenie a je to formát, ktorý chcete použiť pri čomkoľvek väčšom.

Zálohovať v plain formáte, pretože to tak bolo v návode, a potom počas incidentu zistiť, že nemôžete obnoviť jednu tabuľku, je špecifický a úplne zbytočný druh zlého dňa.

4. Nedokážete ju dešifrovať

Ak sú zálohy šifrované — a mali by byť — kľúč je súčasťou zálohy. Kľúč, ktorý existuje iba na stratenom počítači alebo iba v environment variable nedostupnej služby, je kľúč, ktorý v rozhodujúcej chvíli nemáte.

Ako vyzerá skutočné overenie

Test nie je „existuje súbor“. Obnovte ho niekam inam a položte mu otázku.

# 1. Restore into a scratch database, not the live one
createdb verify_$(date +%Y%m%d)
pg_restore -d verify_$(date +%Y%m%d) --no-owner --no-privileges latest.dump

# 2. Ask it something only real data can answer
psql -d verify_$(date +%Y%m%d) -c "
  select
    (select count(*) from users)            as users,
    (select count(*) from orders)           as orders,
    (select max(created_at) from orders)    as newest_order;
"

# 3. Drop it
dropdb verify_$(date +%Y%m%d)

Krok 2 je podstatou celého procesu. Obnovenie, ktoré sa dokončí bez chyby, vám stále nič nehovorí o tom, či sa v databáze skutočne nachádzajú dáta. Počty riadkov a kontrola aktuálnosti áno.

Oplatí sa overovať tri veci:

• Počty riadkov sú približne správne. Nemusia byť presné — dáta sa menia — ale tabuľka, ktorá mala 200 000 riadkov a teraz ich má 12, znamená zlyhanie.
• Najnovší záznam je aktuálny. Ak je najnovšia objednávka vo vašej „nočnej“ zálohe z marca, úloha zálohovania sa v marci zastavila.
• Aplikácia sa dokáže skutočne pripojiť. Nasmerujte stagingovú inštanciu na obnovenú databázu a načítajte jednu stránku.

Robte to podľa plánu, nie až po incidente

Realistická frekvencia je raz mesačne, automatizovane a s výsledkom na mieste, kde si ho všimnete. Pripomienka v kalendári s textom „otestovať zálohy“ je pripomienka, ktorú odložíte.

Aby tento proces fungoval, musí byť zlyhanie dostatočne hlasné: ak overovací dotaz vráti menej riadkov než stanovený limit, mal by niekoho upozorniť rovnako ako chyba v produkcii. Systém zálohovania, ktorý zlyháva potichu, je až do rozhodujúcej chvíle na nerozoznanie od žiadneho systému zálohovania.

Ako to rieši Dockup

Tri rozhodnutia, z ktorých každé cieli na jedno z vyššie uvedených zlyhaní.

Zálohy smerujú na iné miesto. Záloha na rovnakom disku ako databáza nie je záloha — je to kópia, ktorá zanikne spolu s diskom. Dockup streamuje databázové zálohy priamo do object storage počas ich vytvárania, takže súbor nikdy nezávisí od hostiteľa, ktorý ho vytvoril.

Sú šifrované a kľúč nie je uložený na danom serveri. Zálohy sa počas streamovania šifrujú pomocou AES-256-GCM. Z hľadiska obnovy je podstatné, že kľúč spravuje platforma, namiesto toho, aby bol uložený v prostredí zálohovanej služby.

Záloha, pri ktorej nič nevzniklo, sa nezaznamená ako záloha. Toto priamo rieši problém prázdneho súboru: ak dump skončí s nenulovým exit code alebo vytvorí nula bajtov, upload sa odstráni a záloha sa zaznamená ako neúspešná. Nezostane vám zoznam zelených položiek, z ktorých jedna je 400-bajtový súbor.

dockup db backup my-project/main-db --json     # take one now
dockup db backups my-project/main-db --json    # list them with sizes

Veľkosti v tomto zozname sú najlacnejšou kontrolou zdravia, ktorú máte k dispozícii. Sledujte ich trend.

Nepríjemná otázka

Ak by bola vaša produkčná databáza v priebehu nasledujúcich desiatich minút zničená, ako dlho by vám trvalo obnoviť ju a koľko dát by ste stratili?

Ak nedokážete odpovedať na obe otázky, nemáte stratégiu zálohovania — máte súbory so zálohami. Rozdiel spočíva výlučne v tom, či už niekto niekedy vykonal obnovenie.

Často kladené otázky

Ako často by som mal testovať obnovenie? Raz mesačne je rozumný predvolený interval, ideálne automatizovane, nie manuálne. Dôležité je, aby bolo zlyhanie hlasné, nie aby bola frekvencia čo najvyššia.

Prečo sa obnovenie dokončilo, ale neobsahovalo žiadne dáta? Zvyčajne bol dump vytvorený nad nesprávnou databázou alebo zlyhal uprostred procesu, pričom súbor sa ďalej zapisoval. Porovnávajte veľkosti záloh v čase — prázdny dump je v trende veľkostí viditeľný, no v stĺpci so stavom nie.

Mali by byť zálohy šifrované? Áno a kľúč musí byť uložený na mieste, ktoré prežije stratu počítača. Šifrovaná záloha, ktorej kľúč bol uložený na stratenom serveri, sa nedá obnoviť.

Je snapshot to isté ako záloha? Nie. Snapshot volume zachytáva disk vrátane stavu, v akom sa databáza v danom okamihu nachádzala. Logický dump je konzistentný už zo svojej podstaty. Väčšina tímov chce oboje, pretože každé rieši iný typ zlyhania.