Ako zálohovať databázu aplikácie (a skutočne ju obnoviť)

Databázu aplikácie zálohujete tak, že ju podľa plánu exportujete do súboru (pre Postgres je štandardným nástrojom pg_dump), kópie uložíte na miesto oddelené od databázy a pravidelne jednu z nich obnovíte do prázdnej databázy, aby ste overili, že funguje. Pred každou rizikovou zmenou urobte ešte jednu zálohu. Záloha kódu, či už ide o repozitár na GitHube alebo o export, vaše dáta nezahŕňa.

Tento sprievodca je pre ľudí, ktorí prevádzkujú malú aplikáciu a chcú si prestať robiť starosti, že ju stratia. Príklady používajú Postgres, lebo ho väčšina aplikácií vytvorených pomocou AI používa, no princípy platia pre akúkoľvek databázu.

Čo má záloha pokrývať

Aplikácia je viac než jej databáza. Vedzieť treba, čo každá záloha chráni.

Dáta sú časť, ktorú nedokážete znovu vytvoriť. Kód sa dá napísať nanovo a nastavenia znovu zadať; objednávky vašich zákazníkov nie.

Krok 1: Rozhodnite, koľko môžete stratiť

Váš plán zálohovania určia dve otázky:

• Koľko čerstvých dát si môžete dovoliť stratiť? Ak zálohujete raz denne a databáza zlyhá večer, prídete o zmeny z daného dňa. Pri hobby aplikácii je to v poriadku. Pri aplikácii, ktorá prijíma objednávky, to môže byť neprijateľné.
• Ako dlho môže byť aplikácia nedostupná, kým prebehne obnova? Malá databáza sa obnoví za pár minút. Veľká môže trvať oveľa dlhšie a túto dobu chcete poznať skôr, než ju budete potrebovať.

Pre väčšinu malých aplikácií je rozumným začiatkom denná automatická záloha plus ručná záloha pred rizikovými zmenami. Aplikácie, v ktorých ide o peniaze alebo zdravotné dáta, si zaslúžia častejšie zálohy alebo spravovanú databázu s obnovou k určitému bodu v čase (schopnosť obnoviť stav kedykoľvek, nielen k poslednej zálohe).

Krok 2: Overte, čo váš hosting robí sám

Mnoho spravovaných databázových poskytovateľov vytvára zálohy automaticky. Zistite:

• Sú zálohy pri vašom pláne zapnuté a ako často bežia?
• Ako dlho sa uchovávajú?
• Viete obnoviť stav k určitému bodu v čase, alebo len k dennému snímku?
• Viete si zálohu stiahnuť, alebo ju možno obnoviť iba v ich systéme?

Zálohy poskytovateľa sú užitočné, ale zdieľajú jeden spoločný bod zlyhania s vašou databázou: účet. Ak sa účet zruší, pozastaví alebo sa projekt vymaže, zálohy môžu zaniknúť spolu s ním. Preto chcete aj vlastnú kópiu.

Krok 3: Vytvorte výpis pomocou pg_dump

pg_dump exportuje databázu Postgres do súboru. Číta konzistentný snímok, takže aplikácia môže počas jeho behu ďalej bežať.

Typický príkaz, ktorý používa reťazec pripojenia, už uložený vo vašej aplikácii v premennej prostredia:

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

Čo jednotlivé voľby robia:

• --format=custom zapíše komprimovaný súbor, ktorý dokáže pg_restore čítať, a neskôr vám umožní obnoviť aj jednotlivé tabuľky. Ak chcete radšej čitateľný súbor .sql, použite --format=plain.
• --no-owner vynechá príkazy pre vlastníkov, čo uľahčí obnovu do inej databázy.
• Dátum v názve súboru oddeľuje jednotlivé zálohy.

Verzia pg_dump by mala byť rovnaká ako verzia Postgresu vašej databázy, alebo novšia. Staršia verzia pg_dump môže odmietnuť spustenie.

Ak aplikáciu vytvárate s AI a nechcete pracovať s príkazovým riadkom, môžete požiadať:

Vytvor zálohu databázy aplikácie pomocou pg_dump vo vlastnom formáte, s dnešným dátumom v názve súboru. Nevypisuj reťazec pripojenia ani žiadne tajomstvo. Keď to bude hotové, povedz mi názov súboru a jeho veľkosť.

Krok 4: Automatizujte to

Ručné zálohy sa zabúdajú. Automatizujte ich tým, čo vaše nastavenie podporuje:

• Plánované zálohy vášho poskytovateľa databázy, ak ich ponúka.
• Naplánovaná úloha na serveri alebo v CI službe, ktorá spustí pg_dump a nahrá súbor do úložiska.
• Hostovaná zálohovacia služba, ktorá sa pripojí k vašej databáze.

Bez ohľadu na to, čo zvolíte, nastavte to tak, aby vás upozornilo na zlyhanie zálohy. Záložná úloha, ktorá potichu zlyháva tri mesiace, je klasický horor.

Krok 5: Ukladajte kópie inde

Pravidlo palca sa často nazýva 3-2-1: tri kópie dát, na dvoch rôznych typoch úložiska, z toho jedna mimo hlavnej lokality. Pre malú aplikáciu je praktická verzia takáto:

• Živá databáza
• Automatické zálohy samotného poskytovateľa
• Vlastné výpisy v oddelenom úložisku, napríklad v objektovom bucket v inom účte

Aj tieto body:

• Obmedzte prístup. Záloha obsahuje dáta každého používateľa. Zaobchádzajte s ňou ako so živou databázou.
• Majte pravidlá uchovávania. Napríklad denné zálohy na dva týždne a mesačné na rok. Staré zálohy mažte úmyselne a pamätajte, že zákony o ochrane súkromia môžu vyžadovať vymazanie osobných údajov na žiadosť.
• Nikdy nekomitujte zálohy do Gitu. Výpis v repozitári je únik dát, ktorý len čaká, kedy sa stane.

Krok 6: Otestujte obnovu

Záloha je taká dobrá, ako vaša posledná úspešná obnova. Aspoň každých pár mesiacov a po každej zmene zálohovacieho procesu:

1. Vytvorte novú, prázdnu databázu. Na testovanie nikdy neobnovujte cez živú databázu.
2. Obnovte do nej najnovšiu zálohu:

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

Pre čistý súbor .sql namiesto toho použite psql "$TEST_DATABASE_URL" -f backup.sql.

1. Skontrolujte, že existuje každá tabuľka, porovnajte počty riadkov so živou databázou a pozrite niekoľko posledných záznamov.
2. Ak môžete, spustite kópiu aplikácie nad touto databázou a prihláste sa.
3. Zapíšte si, ako dlho obnova trvala. To je vaša skutočná doba zotavenia.

Krok 7: Zálohujte pred rizikovými zmenami

Čerstvú zálohu urobte tesne pred tým, ako:

• Spustíte migráciu databázy, ktorá maže alebo premenúva stĺpce
• Hromadne importujete dáta
• Necháte AI agenta robiť veľké zmeny v dátovom modeli
• Mažete staré záznamy

V aplikácii vytvorenej s AI môže agent meniť štruktúru tabuliek ako súčasť novej funkcie. Checkpointy a verzovanie vrátia späť váš kód, ale nevrátia zmazané riadky. Záloha pred veľkou zmenou, ktorá trvá tridsať sekúnd, je lacná poistka.

Časté chyby

• Predpokladanie, že Git alebo export kódu je záloha. Obsahuje kód, nie dáta.
• Nikdy netestovaná obnova. Mnohé zálohy sa ukážu ako prázdne, neúplné alebo nečitateľné až vtedy, keď ich treba.
• Ukladanie záloh v tom istom účte ako databáza. Jeden napadnutý alebo zrušený účet stratí oboje.
• Zabudnuté nahrané súbory. Databáza ukladá cestu k súboru; samotný obrázok je v úložisku.
• Tajomstvá v zálohovacích skriptoch. Reťazec pripojenia čítajte z premennej prostredia, nikdy z textu skriptu. Pozri ako chrániť API kľúče.

Zálohy a Mythex

Projekty Mythex môžu mať vyhradenú databázu Postgres a jej pripojovacie údaje sa vkladajú do pracovného priestoru a publikovanej aplikácie. Dokumentácia Mythex neopisuje funkciu zálohovania ani obnovy databázy, takže si plánujte vlastnú: požiadajte agenta o výpis, stiahnite si ho a uložte na bezpečné miesto, najmä pred veľkými zmenami. Export projektu (Pro) obsahuje váš kód, pričom tajomstvá a node_modules sú vynechané; riadky databázy neobsahuje. Pozri Database a Data ownership v dokumentácii. Viac o samotnej databáze nájdete v článku čo je Postgres.

Kontrolný zoznam zálohovania

• Rozhodnuté, koľko dát si môžete dovoliť stratiť a ako dlho môžete byť bez prevádzky
• Overené, aké automatické zálohy ponúka váš poskytovateľ databázy
• Vlastný výpis beží podľa plánu a zlyhania vás upozornia
• Kópie sú uložené oddelene od databázy s obmedzeným prístupom
• Pravidlá uchovávania sú zapísané
• Nahrané súbory sú zálohované rovnako ako databáza
• Obnova otestovaná do prázdnej databázy, počty riadkov skontrolované
• Záloha vytvorená pred každou rizikovou zmenou

Otázky