26. Zálohování a obnova databází

Úvod a kontext

"Databáze bez zálohy neexistuje" je jedno z nejtvrdších pravidel provozu
— chyba v aplikaci, chybný DELETE bez WHERE, selhání disku nebo
ransomware dokážou nenávratně zničit data během vteřiny. Zálohování
databází se od zálohování běžných souborů liší v jedné důležité věci:
databáze je za běhu neustále měněna, takže záloha musí zachytit
konzistentní stav dat, ne rozházené útržky z různých okamžiků. Tato
lekce vysvětluje typy záloh, konkrétní nástroje pro PostgreSQL a proč je
záloha bez otestované obnovy prakticky bezcenná.

Teorie

Typy záloh

• Logická záloha — export dat do souboru s SQL příkazy (nebo jiným
  přenositelným formátem), který po spuštění znovu vytvoří stejná data.
  Výhoda: čitelná, přenositelná mezi verzemi databáze, dá se obnovit i
  jen část dat. Nevýhoda: pomalejší při velkých objemech dat.
• Fyzická záloha — kopie souborů, ve kterých databáze fyzicky
  ukládá data na disku. Výhoda: rychlejší zálohování i obnova u velkých
  databází. Nevýhoda: méně flexibilní (obvykle jde obnovit jen celá
  databáze najednou, ne vybraná tabulka), a zálohu obvykle nelze obnovit
  do jiné verze databáze.
• Plná vs. inkrementální záloha — plná záloha obsahuje všechna data,
  inkrementální jen změny od poslední zálohy. Inkrementální zálohy šetří
  místo a čas, ale obnova je složitější (potřeba plné zálohy plus
  všech navazujících inkrementů ve správném pořadí).

Konzistence za běhu

Databáze za běhu neustále mění data. Naivní kopírování souborů databáze
za běhu ("cp -r" na datový adresář) může vytvořit nekonzistentní zálohu —
část souborů odpovídá stavu z jednoho okamžiku, část z jiného. PostgreSQL
i MySQL proto mají vlastní nástroje, které zálohu koordinují s databázovým
enginem tak, aby výsledek byl konzistentní snapshot k jednomu přesnému
okamžiku, i když se databáze mezitím dál mění.

RPO a RTO

Dva klíčové pojmy pro návrh zálohovací strategie:

• RPO (Recovery Point Objective) — kolik dat si firma může dovolit
  ztratit, vyjádřeno v čase. Záloha jednou denně o půlnoci znamená RPO
  až 24 hodin (v nejhorším případě přijdete o skoro celý den dat).
• RTO (Recovery Time Objective) — jak dlouho smí trvat obnova
  systému do provozu po havárii. Obnova z fyzické zálohy bývá rychlejší
  (nižší RTO) než z logické zálohy u velkých databází.

Čím nižší požadované RPO, tím častěji se musí zálohovat (nebo se použije
průběžná replikace transakčních logů — viz příští lekce). Čím nižší
požadované RTO, tím víc se vyplatí investovat do rychlejších (fyzických)
metod zálohování a do procvičené obnovy.

Pravidlo 3-2-1

Osvědčené obecné pravidlo pro zálohy jakéhokoliv typu dat: mít 3
kopie dat, na 2 různých typech úložiště, z čehož 1 kopie je
mimo primární lokalitu (jiný datacentrum, cloud úložiště). Chrání to
před selháním disku, selháním celého serveru i lokální katastrofou
(požár, zaplavení serverovny).

Praktický příklad

Logická záloha celé PostgreSQL databáze nástrojem pg_dump:

pg_dump -U appka_user -h localhost -d moje_appka -F c -f zaloha.dump

• -F c — vlastní (custom) binární formát PostgreSQL, komprimovaný a
  umožňující selektivní obnovu jednotlivých tabulek,
• -f zaloha.dump — cílový soubor.

Obnova z takové zálohy do nové (prázdné) databáze:

createdb moje_appka_obnovena
pg_restore -U appka_user -h localhost -d moje_appka_obnovena zaloha.dump

Automatizace pravidelné zálohy pomocí cronu (viz lekce o cronu), s
rotací starých souborů a uložením mimo primární server:

#!/bin/bash
set -euo pipefail

DATUM=$(date +%Y-%m-%d)
ZALOHA_DIR=/var/backups/postgresql
SOUBOR="$ZALOHA_DIR/moje_appka-$DATUM.dump"

mkdir -p "$ZALOHA_DIR"
pg_dump -U appka_user -d moje_appka -F c -f "$SOUBOR"

# nahrání zálohy na vzdálené úložiště (např. S3 kompatibilní storage)
aws s3 cp "$SOUBOR" s3://moje-zalohy/postgresql/

# smazání lokálních záloh starších než 14 dní
find "$ZALOHA_DIR" -name '*.dump' -mtime +14 -delete

Naplánování v crontabu:

0 3 * * * /usr/local/bin/zaloha-postgres.sh >> /var/log/zaloha-postgres.log 2>&1

Test obnovy — nejdůležitější a nejčastěji zanedbávaný krok. Záloha,
která se nikdy neobnovila, je jen soubor s neznámým obsahem. Doporučená
praxe: pravidelně (např. jednou měsíčně) obnovit poslední zálohu do
testovacího prostředí a ověřit, že aplikace nad obnovenými daty funguje:

createdb test-obnova
pg_restore -d test-obnova /var/backups/postgresql/moje_appka-2026-09-01.dump
psql -d test-obnova -c "SELECT COUNT(*) FROM zakaznici;"

Pokud tento příkaz vrátí očekávaný, neprázdný počet řádků, záloha je
prokazatelně použitelná — což je jediný způsob, jak si být jistý, že
záloha skutečně funguje.

Shrnutí

Zálohování databází vyžaduje konzistentní snapshot dat, ne naivní
kopírování souborů za běhu, a dělí se na logické (pg_dump, přenositelné,
selektivní) a fyzické (rychlejší u velkých dat) zálohy. RPO a RTO určují,
jak často zálohovat a jak rychle musí proběhnout obnova, a pravidlo 3-2-1
chrání data před selháním disku, serveru i celé lokality. Nejdůležitější
a nejčastěji přeskakovaný krok je pravidelné testování obnovy — bez něj
nikdo neví, jestli záloha vůbec funguje.

Kontrolní otázky

1. Jaký je rozdíl mezi logickou a fyzickou zálohou a kdy byste zvolili
   kterou?
2. Co znamenají zkratky RPO a RTO a jak ovlivňují frekvenci zálohování?
3. Vysvětlete pravidlo 3-2-1 pro zálohování dat.
4. Proč je záloha, která nikdy nebyla obnovena, prakticky bezcenná? Jak
   byste navrhli pravidelný test obnovy pro produkční databázi?