Proč „mít zálohu“ ještě neznamená být v bezpečí

Nejčastější chyba u webů i e-shopů je překvapivě jednoduchá: záloha leží na stejném hostingu, stejném VPS nebo dokonce ve stejné složce jako produkční data. Jakmile selže disk, odejde celý server, dojde k poškození файловého systému nebo zasáhne ransomware, zmizí aplikace i její kopie současně. V praxi to znamená, že „backup“ bez odděleného úložiště je spíš pojistka na papíře než reálná ochrana.

Podle dlouhodobých bezpečnostních statistik patří mezi hlavní příčiny ztráty dat kombinace hardwarové poruchy, chybné administrace a útoku na infrastrukturu. U webů navíc hraje roli i lidský faktor: špatně nasazený update, omylem smazaná databáze, přepsaný konfigurační soubor nebo neúspěšná migrace. Pokud se záloha nachází jen „vedle“ produkce, je zranitelná vůči úplně stejnému incidentu.

Co musí splňovat skutečně použitelná záloha

Funkční backup není jen kopie souborů. U webu potřebujete minimálně dvě vrstvy: souborový systém a databázi. U WordPressu jsou to například wp-content, konfigurace a SQL dump. U moderních aplikací navíc řešíte build artefakty, environment proměnné, tajné klíče, uploady uživatelů a často i objekty v cloudovém storage.

Důležité je, aby záloha splňovala tři podmínky:

  • Je oddělená od produkčního serveru i od primárního poskytovatele hostingu.
  • Je verzovaná, tedy obsahuje více historických bodů obnovy, ne jen poslední kopii.
  • Je obnovitelná v reálném čase a pravidelně testovaná.

Právě test obnovy bývá podceňovaný. Záloha, kterou nikdo nezkusil obnovit, má nulovou provozní hodnotu. V praxi doporučuji alespoň jednou měsíčně provést restore na staging nebo izolovaný testovací server a ověřit, že web skutečně naběhne, databáze sedí a nejsou poškozené mediální soubory.

3-2-1 pravidlo a jeho moderní podoba

Klasické pravidlo 3-2-1 stále platí: mít 3 kopie dat, na 2 různých typech úložišť, z toho 1 kopii mimo hlavní lokaci. Dnes se k tomu přidává praktický doplněk: jedna kopie by měla být neměnná nebo alespoň chráněná proti přepsání. To je zásadní obrana proti ransomwaru, který často cílí právě na připojené zálohovací repozitáře.

Pro menší weby to může vypadat takto: produkční server, denní záloha na externí cloudové úložiště a týdenní archiv do jiného regionu nebo jiného poskytovatele. U e-shopů a firemních webů s vyšší návštěvností je vhodné mít i krátký retenční interval, například hodinové inkrementální zálohy během dne, protože ztráta posledních 24 hodin objednávek může být finančně citelná.

Velmi praktická je kombinace:

  • lokální snapshot pro rychlou obnovu po drobné chybě,
  • off-site backup pro přežití výpadku serveru,
  • immutable storage pro ochranu před smazáním a ransomwarem.

Na úrovni nástrojů to může být například snapshot VPS přes poskytovatele, záloha do Amazon S3 s Object Lock, Backblaze B2, Wasabi, případně vzdálený rsync na oddělený server. Důležité není jméno služby, ale to, aby byla skutečně mimo primární infrastrukturu.

Jak zálohovat WordPress, WooCommerce i vlastní aplikace

U WordPressu je největší chyba spoléhat jen na plugin, který jednou za den vytvoří ZIP soubor na stejném hostingu. Lepší je rozdělit proces: databáze zálohovat častěji než soubory, protože v ní vznikají objednávky, formuláře a obsah. U WooCommerce je ideální frekvence databázové zálohy klidně každých 15–60 minut podle objemu transakcí.

Pro WordPress se v praxi osvědčují nástroje jako UpdraftPlus, BlogVault, Jetpack Backup nebo serverové řešení přes WP-CLI a cron. Pokud máte VPS nebo dedikovaný server, je technicky čistší dělat zálohy mimo WordPress pluginy: například mysqldump nebo mariadb-dump pro databázi, následně archivaci souborů přes tar a přenos do externího storage.

Pro vlastní aplikace v Next.js, Laravelu nebo jiném frameworku je důležité myslet i na:

  • konfigurační soubory a environment proměnné,
  • uploady uživatelů,
  • databázové dumpy,
  • asset storage v cloudu,
  • CI/CD konfiguraci a případné klíče k API.

Pokud používáte Docker, zálohuje se nejen databáze, ale i svazky s persistentními daty. U headless CMS je navíc potřeba ověřit, kde reálně leží obsah: někdy je v externím SaaS, jindy v vlastní databázi, a někdy se media ukládají do samostatného bucketu. Bez mapy datového toku se záloha snadno mine účinkem.

Obnova musí být rychlá, jednoduchá a otestovaná

Nezáleží jen na tom, jestli záloha existuje, ale za jak dlouho z ní umíte web obnovit. Tady vstupují do hry metriky RPO a RTO. RPO říká, kolik dat si můžete dovolit ztratit, RTO určuje, jak dlouho může být web mimo provoz. Pro blog může být akceptovatelné RPO 24 hodin a RTO několik hodin. Pro e-shop už bývá vhodné RPO v řádu minut až hodin a RTO co nejkratší.

Prakticky to znamená mít připravený postup obnovy krok za krokem:

  • obnovit čistý server nebo kontejner,
  • nahrát poslední validní zálohu dat,
  • obnovit databázi,
  • zkontrolovat práva k souborům a konfiguraci,
  • ověřit funkčnost webu, formulářů a objednávek,
  • provést kontrolu logů a bezpečnostních chyb.

Větší týmy by měly mít i jednoduchý runbook: kdo spouští obnovu, kdo komunikuje s hostingem, kdo kontroluje DNS, kdo hlídá SSL a kdo potvrzuje návrat do provozu. Když server spadne v pátek večer, improvizace je drahá.

Bezpečnost záloh: šifrování, přístupová práva a ochrana před útokem

Zálohy samy o sobě jsou citlivá data. Obsahují databázi uživatelů, objednávky, adresy, někdy i hesla nebo session data. Proto musí být šifrované při přenosu i v úložišti. Minimem je TLS při uploadu do cloud storage a šifrování na úrovni repozitáře nebo disku. U citlivých projektů dává smysl i vlastní šifrování před odesláním do externího úložiště.

Stejně důležitá jsou přístupová práva. Backup účet by neměl mít stejná oprávnění jako admin produkčního serveru. Ideální je oddělený účet jen pro zápis záloh a jiný, omezený účet pro restore. Pokud někdo kompromituje produkční server, neměl by mít automaticky možnost smazat všechny historické kopie.

Pro monitoring záloh se vyplatí automatické notifikace do e-mailu, Slacku nebo Microsoft Teams. Selhání zálohy nesmí být tiché. U kritických webů doporučuji i pravidelnou kontrolu logů a alertů v nástrojích jako UptimeRobot, Better Stack nebo vlastní monitoring přes Prometheus a Grafanu.

Kolik záloh je „dost“ a jak často je rotovat

Správná frekvence záloh závisí na rychlosti změn na webu. Statický firemní web s občasnou editací může fungovat s denní zálohou a týdenním archivem. U magazínu s častým publikováním je rozumné mít denní snapshot a inkrementální zálohy vícekrát denně. U WooCommerce nebo členských webů už je vhodné přemýšlet v hodinách, případně v minutách u databázové vrstvy.

Praktický model retence může vypadat takto:

  • 24 hodin – hodinové zálohy,
  • 7 dní – denní zálohy,
  • 4 týdny – týdenní zálohy,
  • 12 měsíců – měsíční archiv.

Takový systém umožní vrátit se nejen po havárii, ale i po tiché chybě, kterou objevíte až za několik dní. Typický příklad: po aktualizaci pluginu se poškodí část formulářů, ale problém si všimnete až po týdnu. Bez delší historie záloh už se k čistému stavu nemusíte dostat.

Pokud chcete mít jistotu, že zálohy opravdu plní svůj účel, sledujte tři jednoduché ukazatele: počet úspěšných backupů za měsíc, čas posledního úspěšného test restore a skutečné RPO/RTO při posledním incidentu. Teprve tato data ukážou, jestli je vaše zálohování jen položka v administraci, nebo skutečná pojistka přežití webu.