Záloha, kterou jste nikdy neobnovili, není záloha

Nejhorší chvíle, kdy zjistit, že záloha nefunguje, je okamžik, kdy ji potřebujete. A přesto je nejčastější scénář přesně takový: zálohy se jednou nastaví, na dashboardu osmnáct měsíců svítí zelené zatržítko a pak obnova vytvoří prázdnou databázi.

Testování obnovy zálohy databáze není best practice ve smyslu, v jakém jsou většina best practices volitelné. Záloha je tvrzení — a dokud jste ji neobnovili, jde o neověřené tvrzení.

Takhle zálohy selhávají a tohle musí skutečné ověření kontrolovat.

Čtyři způsoby, jak může být záloha nenápadně k ničemu

1. Je prázdná a nikdo se nepodíval

pg_dump, který selže uprostřed běhu, může přesto vytvořit soubor. Dump spuštěný proti nesprávnému názvu databáze vytvoří platný, správný, ale prázdný soubor. Obojí vypadá jako úspěch pro cokoli, co kontroluje nenulový exit code nebo existenci souboru.

Nejlevnější kontrola na světě: podívejte se na velikost a porovnejte ji se včerejší hodnotou. Záloha o velikosti 400 bajtů, když včerejší měla 40 MB, vám řekla všechno. Záloha, která má 400 bajtů už šest měsíců, vás na to upozorňuje celou dobu.

2. Obsahuje data, ale ne věci kolem nich

pg_dump jediné databáze neobsahuje role ani jiné databáze. Obnovte ho na nový server a tabulky dorazí, zatímco každý GRANT odkazuje na neexistující roli. Aplikace se připojí a u všeho dostane chybu permission denied.

Stejné je to s extensions. Pokud vaše schema závisí na pgcrypto nebo uuid-ossp a cílové prostředí je nemá, obnova selže uprostřed a zůstanou vám jen některé tabulky.

3. Přepínače neodpovídaly obnově, kterou potřebujete

pg_dump vytváří různé výstupy podle zvoleného formátu a na chybu se obvykle přijde až pod tlakem:

• Plain SQL se obnovuje pomocí psql a je čitelný pro člověka. Nelze ho obnovovat selektivně a u velkých databází je pomalý.
• Custom format (-Fc) se obnovuje pomocí pg_restore, podporuje paralelní zpracování i selektivní obnovu a pro cokoli většího je přesně tím, co potřebujete.

Zálohovat v plain formátu jen proto, že to tak bylo v tutoriálu, a pak během incidentu zjistit, že nelze obnovit jedinou tabulku, je velmi specifický a zcela zbytečný způsob, jak si pokazit den.

4. Nedokážete ji dešifrovat

Pokud jsou zálohy šifrované — a měly by být — pak je klíč součástí zálohy. Klíč, který existuje pouze na ztraceném počítači nebo jen v environment variable služby, která je mimo provoz, je klíč, ke kterému se ve chvíli potřeby nedostanete.

Jak vypadá skutečné ověření

Test nezní „existuje soubor?“. Obnovte ho někam jinam a položte mu otázku.

# 1. Obnovte do pomocné databáze, ne do produkční
createdb verify_$(date +%Y%m%d)
pg_restore -d verify_$(date +%Y%m%d) --no-owner --no-privileges latest.dump

# 2. Zeptejte se na něco, na co dokážou odpovědět jen skutečná data
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. Odstraňte ji
dropdb verify_$(date +%Y%m%d)

Krok 2 je celý smysl testu. Obnova, která proběhne bez chyby, vám stále neřekne nic o tom, zda v databázi skutečně jsou data. To ukážou počty řádků a kontrola aktuálnosti.

Tři věci, které stojí za ověření:

• Počty řádků jsou ve správném řádu velikosti. Nemusí být přesné — data se mění — ale tabulka, která měla 200 000 řádků a teď jich má 12, znamená selhání.
• Nejnovější záznam je aktuální. Pokud je nejnovější objednávka ve vaší „noční“ záloze z března, úloha zálohování se v březnu zastavila.
• Aplikace se skutečně dokáže připojit. Nasměrujte stagingovou instanci na obnovenou databázi a načtěte jednu stránku.

Dělejte to podle plánu, ne až při řešení incidentu

Realistická frekvence je jednou měsíčně, automatizovaně a s výsledkem na místě, kde si ho všimnete. Připomínka v kalendáři „otestovat zálohy“ je připomínka, kterou odložíte.

Aby tento proces skutečně fungoval, musí být selhání hlasité: pokud ověřovací dotaz vrátí méně řádků než stanovený limit, měl by někoho upozornit stejně jako chyba v produkci. Systém zálohování, který selhává potichu, je až do kritického okamžiku k nerozeznání od systému, který žádné zálohy nemá.

Jak to řeší Dockup

Tři rozhodnutí, z nichž každé míří na jedno z výše uvedených konkrétních selhání.

Zálohy ukládáme jinam. Záloha na stejném disku jako databáze není záloha — je to kopie, která zanikne společně s diskem. Dockup streamuje zálohy databází přímo do object storage už během jejich vytváření, takže soubor nikdy nezávisí na hostiteli, který ho vytvořil.

Jsou šifrované a klíč není na daném počítači. Zálohy se během streamování šifrují pomocí AES-256-GCM. Pro obnovu je podstatné, že klíč spravuje platforma, místo aby ležel v environmentu zálohované služby.

Záloha, při jejímž vytvoření nic nevzniklo, se jako záloha nezaznamená. To přímo řeší selhání s prázdným souborem: pokud dump skončí s nenulovým exit code nebo vytvoří nula bajtů, upload se smaže a záloha se zaznamená jako neúspěšná. Neskončíte tak se seznamem zelených položek, z nichž jedna je soubor o velikosti 400 bajtů.

dockup db backup my-project/main-db --json     # vytvořit jednu hned
dockup db backups my-project/main-db --json    # vypsat je včetně velikostí

Velikosti v tomto výpisu jsou nejlevnější kontrolou stavu, kterou máte k dispozici. Sledujte jejich vývoj.

Nepříjemná otázka

Kdyby byla vaše produkční databáze během příštích deseti minut zničena, jak dlouho by trvalo ji obnovit a o kolik dat byste přišli?

Pokud nedokážete odpovědět na obě otázky, nemáte strategii zálohování — máte soubory se zálohami. Rozdíl spočívá výhradně v tom, zda někdo někdy provedl obnovu.

Často kladené otázky

Jak často bych měl testovat obnovu? Jednou měsíčně je rozumný výchozí interval, ideálně automatizovaně, nikoli ručně. Důležité je, aby bylo selhání viditelné, ne aby byl interval co nejkratší.

Proč obnova proběhla úspěšně, ale neobsahovala žádná data? Obvykle byl dump vytvořen proti nesprávné databázi nebo selhal uprostřed, přestože se soubor dál zapisoval. Porovnávejte velikosti záloh v čase — prázdný dump je ve vývoji velikosti zřejmý, ale ve sloupci se stavem neviditelný.

Měly by být zálohy šifrované? Ano, přičemž klíč musí být uložen na místě, které přežije ztrátu počítače. Šifrovaná záloha, jejíž klíč byl na ztraceném serveru, není obnovitelná.

Je snapshot totéž co záloha? Ne. Snapshot svazku zachytí disk včetně stavu, ve kterém se databáze v daném okamžiku nacházela. Logický dump je ze své podstaty konzistentní. Většina týmů potřebuje obojí, protože každé řeší jiný typ selhání.