Představme si menší firemní web, který bez problémů fungoval několik let. Správce jednoho pondělního rána aktualizoval redakční systém, aktualizace ale narušila databázi a stránky přestaly načítat obsah. Záloha existovala. Byla však uložená na stejném serveru, v adresáři přístupném napadenému systému. Spolu s webem zmizela i ona.
Taková situace není výjimečná jen u velkých projektů. Web bývá směsí souborů, databáze, nastavení serveru, nahraných obrázků, e-mailových konfigurací a někdy také objednávek či osobních údajů. Když se obnoví pouze část, výsledek může vypadat jako prázdná skořápka: stránka se zobrazí, ale chybí články, produkty, uživatelské účty nebo poslední objednávky.
Co má skutečná záloha obsahovat
Záloha webu není totéž co kopie několika souborů přes FTP. U redakčního systému je třeba myslet na databázi, ve které často žije většina důležitého obsahu. Patří sem také adresáře s obrázky a dokumenty, konfigurační soubory, šablony, doplňky a případné vlastní skripty. U některých služeb má smysl uchovat i konfiguraci domény, DNS záznamy nebo nastavení externích napojení, například platební brány.
Rozsah se řídí tím, co by po havárii skutečně bolelo. U jednoduché prezentační stránky může stačit pravidelná kopie souborů a databáze. U e-shopu nebo webu, který přijímá objednávky, je citlivější především databáze a její časová aktuálnost. Ztráta údajů za poslední měsíc se dá někdy přežít, ztráta posledních dvou hodin už může znamenat ruční dohledávání a finanční škody.
Právě proto neexistuje jediná správná frekvence pro všechny weby. Rozhoduje, kolik dat můžete reálně ztratit a jak dlouho smí být web mimo provoz. Stránka aktualizovaná jednou za několik týdnů nepotřebuje stejný režim jako obchod s desítkami objednávek denně.
Jak často zálohovat
U aktivního webu dává smysl automatická denní záloha. Je to rozumný základ pro firemní prezentace, blogy a menší projekty, kde se obsah mění průběžně, ale ne každou minutu. Zálohovat ručně jednou za měsíc je naopak riskantní: člověk na to snadno zapomene a při problému zjistí, že poslední kopie je stará několik týdnů.
Weby s častými objednávkami, komentáři nebo registracemi mohou potřebovat zálohy několikrát denně, případně průběžné ukládání změn databáze. Rozhodující není působivý počet kopií, ale časový odstup mezi poslední bezpečnou zálohou a okamžikem incidentu. Upravujete-li obsah několikrát týdně, hodinové zálohy by byly zbytečně náročné. U internetového obchodu mohou být naopak přiměřené.
Praktický retenční plán může kombinovat krátkodobé a dlouhodobé kopie. Jako příklad lze použít 48 hodinových snapshotů a 30 denních záloh. Hodinové snímky pomohou vrátit se k nedávné verzi po chybné aktualizaci, denní kopie zase pokryjí delší období. Starší zálohy je možné uchovávat po týdnech nebo měsících podle významu webu a dostupného prostoru.
Samotný automatický úkol ale ještě neznamená, že zálohování funguje.
Pravidlo 3–2–1 chrání před jedním místem selhání
Doporučované pravidlo 3–2–1 je jednoduché: mít tři kopie dat, uložené na dvou různých typech médií, přičemž jedna kopie se nachází mimo hlavní lokalitu. Originální web a dvě zálohy na stejném serveru tedy pravidlo nesplňují, i když jsou technicky tři.
Dvě různá média mohou znamenat například zálohu na serveru a další kopii v odděleném cloudovém úložišti. Kopie mimo hlavní lokalitu nemusí být fyzický disk v jiné kanceláři; může jít o jiné datové centrum nebo vzdálené úložiště, které není trvale připojené k webovému serveru. Smyslem je, aby požár, porucha, chyba administrátora nebo útok nesmetl všechny kopie najednou.
Ještě důležitější je oddělení přístupů. Účet, pod kterým běží web, by neměl mít bez omezení právo mazat všechny zálohy. Útočník, který získá přístup k administraci nebo serveru, se totiž může pokusit odstranit i dostupné kopie. Zálohy proto patří mezi data, která je vhodné chránit vícefaktorovým ověřením, oddělenými účty a omezenými oprávněními.
Offline a šifrované kopie
Ransomware se nesnaží pouze zašifrovat samotný web. Často hledá i připojené zálohy, aby oběť připravil o možnost rychlé obnovy. Jedna kopie by proto měla být offline, případně alespoň odpojená tak, aby ji napadený server nemohl přímo změnit nebo smazat. U cloudových služeb může podobnou roli plnit úložiště s odděleným účtem, neměnnými kopiemi nebo retenčním zámkem, pokud je daná funkce k dispozici.
Šifrování chrání obsah před neoprávněným přístupem, hlavně když se kopie nacházejí mimo vlastní infrastrukturu nebo na přenosném médiu. Nestačí však šifrování zapnout a zapomenout na něj. Klíče a hesla musí být spravované odděleně od samotné zálohy. Když jsou klíč i zašifrovaný soubor uložené ve stejném účtu bez další ochrany, bezpečnostní přínos se rychle zmenšuje.
Přístupové údaje k zálohám nepatří do sdíleného dokumentu nazvaného například „hesla k serveru“. Vhodnější je správce hesel, omezený okruh administrátorů a pravidelná kontrola toho, kdo má k úložišti přístup. U malého webu nemusí jít o složitý podnikový systém, ale základní oddělení účtů udělá velký rozdíl.
Test obnovy rozhoduje
Záloha, kterou nikdo nikdy neobnovil, je pouze předpoklad. Soubor může být poškozený, databáze neúplná, přístupové údaje zastaralé nebo postup obnovy závislý na člověku, který už ve firmě nepracuje. Kritická data by se proto měla testovat nejméně jednou měsíčně. Test má ověřit nejen integritu kopie, ale i její skutečnou obnovitelnost.
Nejbezpečnější je obnovit web do odděleného prostředí, nikoli přepisovat ostrý web naslepo. Tam lze zkontrolovat přihlášení do administrace, načtení databáze, obrázky, formuláře, objednávkový proces i návaznosti na externí služby. U webu, který používá více komponent, se při testu často ukáže detail, na který při samotném zálohování nikdo nemyslel.
Vyplatí se také sepsat stručný postup: kde se kopie nachází, kdo k ní má přístup, jak dlouho trvá obnova a co je třeba po ní zkontrolovat. Dokument by měl být uložený i mimo napadený server. Současná revize doporučení NIST SP 800-209 z 22. července 2026 je stále veřejným pracovním návrhem; platnou finální verzí zůstává vydání z 26. října 2020. Pro běžnou správu webu z toho plyne hlavně praktická věc: opírat se o ověřený postup, ne o příslib, že novější návrh už automaticky nahradil platné doporučení.
Dobře nastavené zálohování není vidět v běžném provozu. Projeví se až ve chvíli, kdy aktualizace pokazí databázi, někdo omylem smaže důležitý obsah nebo se server ocitne pod útokem. Tehdy rozhoduje, jestli existuje aktuální kopie, ke které se útočník nedostane, a zda ji správce dokáže bez improvizace vrátit do provozu.
