Jak zálohovat databázi aplikace (a skutečně ji obnovit)

Zálohu databáze aplikace uděláte tak, že ji pravidelně exportujete do souboru (u Postgresu k tomu slouží standardní nástroj pg_dump), kopie uložíte odděleně od databáze a pravidelně některou obnovíte do prázdné databáze, abyste ověřili, že funguje. Před každou rizikovou změnou udělejte navíc čerstvou zálohu. Záloha kódu, ať už jde o repozitář na GitHubu nebo export projektu, vaše data neobsahuje.

Tento návod je určený lidem, kteří provozují menší aplikaci a chtějí přestat si dělat starosti, že ji ztratí. Příklady používají Postgres, protože ho většina aplikací vytvořených s AI využívá, ale zásady platí pro jakoukoli databázi.

Co musí záloha pokrývat

Aplikace je víc než její databáze. Zjistěte, kterou část která záloha chrání.

Data jsou část, kterou nelze znovu vytvořit. Kód lze přepsat a nastavení znovu zadat; objednávky vašich zákazníků ne.

Krok 1: Rozhodněte, kolik můžete ztratit

Plán zálohování určují dvě otázky:

• Kolik nedávných dat si můžete dovolit ztratit? Pokud zálohujete jednou denně a databáze večer selže, přijdete o změny z celého dne. Pro hobby aplikaci je to v pořádku. Pro aplikaci, která přijímá objednávky, možná ne.
• Jak dlouho může být aplikace kvůli obnově nedostupná? Malá databáze se obnoví během minut. Velká může trvat mnohem déle a je dobré to vědět dřív, než to budete potřebovat.

U většiny menších aplikací je rozumný začátek jedna automatická denní záloha a ruční záloha před rizikovými změnami. Aplikace, které pracují s penězi nebo zdravotními údaji, si zaslouží častější zálohy, nebo spravovanou databázi s obnovou k určitému okamžiku (tedy možností obnovit stav přesně k libovolnému času, ne jen k poslední záloze).

Krok 2: Zjistěte, co už dělá váš hostingový poskytovatel

Mnoho poskytovatelů spravovaných databází zálohuje automaticky. Zjistěte:

• Jsou zálohy u vašeho tarifu zapnuté a jak často běží?
• Jak dlouho se uchovávají?
• Lze obnovit stav k určitému okamžiku, nebo jen k denní kopii?
• Můžete si zálohu stáhnout, nebo ji lze obnovit jen uvnitř jejich systému?

Zálohy poskytovatele jsou užitečné, ale sdílejí jedno místo selhání s databází: účet. Pokud je účet zrušen, pozastaven nebo se projekt smaže, zálohy mohou zmizet spolu s ním. Proto si chcete udělat i vlastní kopii.

Krok 3: Vytvořte výpis pomocí pg_dump

pg_dump exportuje databázi Postgres do souboru. Pracuje s konzistentním snímkem dat, takže aplikace může během exportu dál běžet.

Typický příkaz, který používá připojovací řetězec, jenž už vaše aplikace má v proměnné prostředí:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Co dělají jednotlivé volby:

• --format=custom zapíše komprimovaný soubor, který umí načíst pg_restore, a později umožní obnovit i jednotlivé tabulky. Pokud chcete čitelný soubor .sql, použijte --format=plain.
• --no-owner vynechá příkazy pro vlastníky, což usnadní obnovu do jiné databáze.
• Datum v názvu souboru odlišuje jednotlivé zálohy.

Verze pg_dump by měla být stejná jako verze vaší databáze Postgres, nebo novější. Starší pg_dump může spuštění odmítnout.

Pokud stavíte s AI a nechcete pracovat s příkazovou řádkou, můžete napsat:

Vytvoř zálohu databáze aplikace pomocí pg_dump ve vlastním formátu, s dnešním datem v názvu souboru. Nevypisuj připojovací řetězec ani žádné tajné údaje. Až to bude hotové, napiš mi název souboru a jeho velikost.

Krok 4: Zautomatizujte to

Ruční zálohy se zapomínají. Zautomatizujte je pomocí toho, co vaše nastavení podporuje:

• Plánované zálohy vašeho poskytovatele databáze, pokud je nabízí.
• Naplánovaná úloha na serveru nebo v CI službě, která spustí pg_dump a soubor nahraje do úložiště.
• Hostovaná služba pro zálohy, která se připojí k vaší databázi.

Ať zvolíte cokoli, nastavte to tak, aby vás upozornilo na selhání. Záloha, která tiše selhávala tři měsíce, je klasický horor.

Krok 5: Ukládejte kopie jinam

Obecné pravidlo se často nazývá 3-2-1: tři kopie dat, na dvou různých typech úložišť, z nichž jedna je mimo hlavní místo. Pro menší aplikaci je praktická verze tato:

• Živá databáze
• Automatické zálohy poskytovatele
• Vlastní výpisy v odděleném úložišti, například v objektovém úložišti v jiném účtu

Také:

• Omezte přístup. Záloha obsahuje data všech uživatelů. Zacházejte s ní stejně jako s živou databází.
• Stanovte pravidla uchovávání. Například denní zálohy na dva týdny a měsíční na rok. Staré zálohy mažte úmyslně a pamatujte, že zákony o ochraně osobních údajů mohou vyžadovat smazání osobních údajů na žádost.
• Nikdy nedávejte zálohy do Gitu. Výpis v repozitáři je připravený únik dat.

Krok 6: Otestujte obnovu

Záloha je jen tak dobrá jako vaše poslední úspěšná obnova. Alespoň každých pár měsíců a po každé změně procesu zálohování:

1. Vytvořte novou, prázdnou databázi. Nikdy netestujte obnovu přes živou databázi.
2. Obnovte do ní nejnovější zálohu:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Pro prostý soubor .sql místo toho použijte psql "$TEST_DATABASE_URL" -f backup.sql.

1. Zkontrolujte, že existují všechny tabulky, porovnejte počty řádků s živou databází a podívejte se na několik nedávných záznamů.
2. Pokud můžete, spusťte kopii aplikace na této databázi a přihlaste se.
3. Zapište si, jak dlouho obnova trvala. To je váš skutečný čas na zotavení.

Krok 7: Zálohujte před rizikovými změnami

Čerstvou zálohu udělejte těsně před:

• Spuštěním migrace databáze, která maže nebo přejmenovává sloupce
• Hromadným importem dat
• Tím, že necháte AI agenta provést velké změny datového modelu
• Mazáním starých záznamů

V aplikaci vytvořené s AI může agent změnit strukturu tabulek jako součást nové funkce. Kontrolní body a verzování vrátí zpět kód, ale neobnoví smazané řádky. Třicetisekundová záloha před velkou změnou je levné pojištění.

Časté chyby

• Předpoklad, že Git nebo export kódu je záloha. Obsahuje kód, ne data.
• Nikdy netestovaná obnova. Mnoho záloh se ukáže jako prázdných, neúplných nebo nečitelných až ve chvíli, kdy je potřeba.
• Uložení záloh ve stejném účtu jako databáze. Jeden napadený nebo zrušený účet ztratí obojí.
• Zapomenuté nahrané soubory. Databáze ukládá cestu k souboru; samotný obrázek je v úložišti.
• Tajné údaje ve skriptech pro zálohy. Připojovací řetězec čtěte z proměnné prostředí, nikdy z textu skriptu. Viz jak bezpečně uchovat API klíče.

Zálohy a Mythex

Projekty v Mythexu mohou mít vlastní databázi Postgres a její připojovací údaje se vloží do pracovního prostředí i do publikované aplikace. Dokumentace Mythexu nepopisuje funkci zálohování ani obnovy databáze, proto si zálohování naplánujte sami: nechte agenta vytvořit výpis, stáhněte si ho a uložte na bezpečné místo, zvlášť před velkými změnami. Export projektu (Pro) obsahuje váš kód bez tajných údajů a bez node_modules; databázové řádky neobsahuje. Podrobnosti najdete v dokumentaci: Databáze a Vlastnictví dat. Více o samotné databázi viz co je Postgres.

Kontrolní seznam zálohování

• Rozhodnuto, kolik dat si můžete ztratit a jak dlouho můžete být nedostupní
• Zkontrolováno, jaké automatické zálohy nabízí váš poskytovatel databáze
• Vlastní výpis běží podle plánu a selhání vás upozorní
• Kopie jsou uloženy odděleně od databáze s omezeným přístupem
• Pravidla uchovávání jsou sepsána
• Nahrané soubory jsou zálohované stejně jako databáze
• Obnova otestována do prázdné databáze a počty řádků zkontrolovány
• Záloha se provede před každou rizikovou změnou

Otázky