Takébackup databáze, DB backup, dump databázePokročilý
Definice
Záloha databáze je samostatně uložená kopie databázových dat a potřebných metadat, ze které lze databázi po chybě obnovit. V praxi chrání před smazáním, poškozením, selháním infrastruktury i ransomwarem, ale smysl má jen tehdy, když je pravidelně vytvářená, bezpečně uložená a ověřená obnovou.
Proč nestačí mít data jen v databázi
Záloha databáze chrání proti situacím, které běžná integrita dat neřeší. Transakce a ACID pomáhají udržet konzistentní změny, ale nevrátí omylem smazanou tabulku, zašifrovaný server ani chybnou migraci nasazenou do produkce. Záloha proto patří k provoznímu návrhu databáze stejně jako monitoring, řízení přístupů a plán obnovy.
Důležitá otázka nezní jen „máme zálohu“, ale „jak stará data dokážeme přijmout“ a „za jak dlouho bude služba znovu dostupná“. První hranice se obvykle popisuje jako RPO, tedy přijatelná ztráta dat v čase. Druhá hranice je RTO, tedy cílová doba obnovy služby. Databáze e-shopu, účetního systému a analytického sandboxu proto často potřebují rozdílnou strategii.
Co se do zálohy databáze skutečně ukládá
Záloha databáze může obsahovat logický export, fyzickou kopii souborů nebo kombinaci plné zálohy a průběžných záznamů změn. Logický export ukládá strukturu a data ve formě příkazů nebo přenositelného formátu, často blízkého SQL. Fyzická záloha kopíruje interní datové soubory databázového stroje a obvykle se obnovuje rychleji, ale bývá více svázaná s konkrétní verzí a konfigurací.
Produkční prostředí často používá plné, inkrementální nebo rozdílové zálohy. Plná záloha je samostatný bod návratu. Inkrementální záloha ukládá změny od poslední zálohy, takže šetří místo, ale obnova skládá více částí. Rozdílová záloha ukládá změny od poslední plné zálohy. U databází s velkým provozem se přidávají transakční logy, oplog nebo write-ahead log, aby šlo obnovit stav blízko konkrétnímu okamžiku.
Obnova je test, ne formalita
Záloha databáze bez vyzkoušené obnovy je jen předpoklad. Skutečná jistota vzniká až tehdy, když tým pravidelně obnoví data do odděleného prostředí, ověří konzistenci, přístupová práva, vazby mezi tabulkami a chování aplikace. Kontrola samotné existence souboru nestačí, protože poškozený archiv, chybějící klíč nebo nekompatibilní verze databáze se projeví až při obnově.
Bezpečnostní část je stejně důležitá jako technická. Zálohy mají být oddělené od produkce, omezeně přístupné a u citlivých dat chráněné šifrováním. Ransomware často hledá i záložní úložiště, takže kopie uložená pod stejným účtem jako produkční databáze nemusí přežít incident.
Kdy se volí dump, snapshot nebo průběžné logy
Menší aplikace často vystačí s pravidelným dumpem, protože obnova je srozumitelná a přenos mezi prostředími snadný. Velké produkční databáze obvykle kombinují snapshoty úložiště, archivaci logů a automatizované retenční politiky. NoSQL databáze mohou mít vlastní mechanismy replikace a zálohování, ale replika sama o sobě není náhrada zálohy: smazání nebo chybný zápis se na repliku často přenese také.
Příklady z praxe
Chybná migrace v PostgreSQL
Tým před nasazením větší migrace vytvoří dump produkční PostgreSQL databáze. Migrace v produkci omylem smaže sloupec s historickými údaji, takže tým obnoví poslední dump do samostatné databáze a chybějící data porovná s aktuálním stavem. Výpadek je kratší, protože postup obnovy byl předem vyzkoušený.
pg_dump -Fc -d app_production -f app_2026-07-28.dump pg_restore -d app_restore_test app_2026-07-28.dumpObnova MongoDB do testovacího prostředí
Vývojář potřebuje bezpečně otestovat změnu ve vyhledávání objednávek nad reálnějšími daty. Administrátor vytvoří zálohu MongoDB a obnoví ji do testovacího clusteru, kde se citlivá pole následně anonymizují. Produkce zůstane nedotčená a test odhalí pomalý dotaz dřív, než se změna dostane k uživatelům.
mongodump --uri="$MONGODB_URI" --out=backup-2026-07-28 mongorestore --uri="$MONGODB_TEST_URI" backup-2026-07-28
Časté omyly
- MýtusKdyž máme databázi v cloudu, zálohy řeší poskytovatel a nemusíme se o nic starat.
- Ve skutečnostiCloud může nabízet automatické zálohy, ale tým stále odpovídá za nastavení retence, oprávnění, obnovu a pokrytí okolních dat. Nesprávně nastavené cloudové zálohy mohou zmizet spolu se smazanou instancí nebo nemusí splnit požadované RPO.
- MýtusDump databáze je vždy nejlepší typ zálohy.
- Ve skutečnostiDump databáze je přehledný a přenositelný, ale u velkých systémů může být pomalý a obnova může trvat příliš dlouho. Fyzické zálohy, snapshoty a transakční logy mohou být vhodnější, pokud je cílem rychlý návrat produkce.
Časté dotazy
- Jak často se má dělat záloha databáze?
- Záloha databáze potřebuje frekvenci podle toho, kolik dat smí firma ztratit. Blog s několika komentáři denně může zálohovat méně často než platební nebo objednávkový systém. Praktické nastavení vychází z RPO: pokud je přijatelná ztráta nejvýše patnáct minut práce, samotná noční záloha nestačí a musí se přidat průběžné logy, replikace nebo častější inkrementální zálohy.
- Stačí místo zálohy databáze replika?
- Replika databáze není plnohodnotná záloha databáze, protože replika obvykle přebírá i špatné změny. Smazaná tabulka, chybný update nebo zašifrovaná data se mohou rychle propsat na další uzly. Replika pomáhá hlavně s dostupností a čtením při výpadku jednoho serveru. Záloha má poskytovat návrat do staršího bodu v čase a ideálně ležet mimo běžné produkční oprávnění.
- Jak poznám, že je záloha databáze použitelná?
- Záloha databáze se má testovat pravidelnou obnovou do odděleného prostředí. Test má ověřit, že archiv lze přečíst, databázový server ho přijme, aplikace se připojí a data dávají věcně smysl. U relační databáze se kontrolují například počty záznamů, cizí klíče, důležité dotazy a přístupová práva. Automatizovaný restore test často odhalí problém dřív než skutečný incident.
- Co všechno musí záloha databáze obsahovat?
- Záloha databáze má obsahovat nejen samotná data, ale také schéma, indexy, uživatelská oprávnění, rozšíření, konfiguraci potřebnou k běhu a postup obnovy. U některých systémů se části ukládají mimo databázi, například soubory nahrané uživateli nebo tajné klíče. Plán obnovy musí počítat i s těmito závislostmi, jinak se sice obnoví tabulky, ale aplikace nebude plně fungovat.
Zdroje
- Chapter 25. Backup and Restore(otevře se v novém okně)
- MongoDB Backup Methods(otevře se v novém okně)
- SQLite Backup API(otevře se v novém okně)
- Back Up and Restore of SQL Server Databases(otevře se v novém okně)
Související pojmy
