Stručně: Spolehlivá strategie zálohování serveru se řídí pravidlem 3-2-1: tři kopie, dva typy úložiště, jedna kopie mimo pracoviště. Aby zálohy přežily i útok, potřebuje alespoň jedna kopie ochranu před smazáním ze strany samotného serveru. A teprve úspěšný test obnovy ukáže, že záloha v kritickém případě funguje.
Co znamená pravidlo 3-2-1
Pravidlo 3-2-1 je jednoduchá zásada zálohování, která se léta osvědčuje:
- 3 kopie: původní data a dvě zálohy.
- 2 typy úložiště: například lokální disk a objektové úložiště, nebo úložiště serveru a páska.
- 1 kopie mimo pracoviště: na jiném místě, u jiného poskytovatele nebo offline.
Pro webové servery to konkrétně znamená: záloha na stejném disku jako web se nepočítá jako samostatná kopie. Pokud server vypadne nebo je kompromitován, jsou ztraceny obě. Pro vedení proto základní otázka nezní „Máme zálohy?“, ale „Dokážeme provoz obnovit z kopie, kterou incident nezasáhl?“
Strategie zálohování serveru, která přežije útok
Útočníci vědí, že zálohy jejich práci ničí. Kdo má přístup na server, často proto hledá i zálohy, aby je smazal nebo zašifroval. Moderní strategie proto pravidlo 3-2-1 často rozšiřuje na 3-2-1-1-0: jedna kopie navíc offline nebo neměnná a nula chyb při testu obnovy.
Zálohy odolnými činí tři zásady:
- Pull místo push: Samostatný zálohovací systém si data z webového serveru vyzvedává. Webový server sám nemá přístupové údaje, jimiž by mohl zálohy mazat.
- Neměnnost: Objektové úložiště se zámkem uchování nebo snapshoty, které nelze po stanovenou dobu smazat.
- Oddělené přístupy: Zálohovací účet není tentýž jako zákaznický účet hostingu a má vlastní druhý faktor.
Zálohy uložené mimo pracoviště šifrujte a klíč uchovávejte odděleně. Ztracený klíč činí zálohu nepoužitelnou, společně uložený klíč činí šifrování bezcenným.
Co je třeba zálohovat
U webových serverů se často zálohuje jen webroot. Pro úplnou obnovu pak chybějí důležité části.
| Oblast | Příklady | Poznámka |
|---|---|---|
| Soubory aplikace | webroot, uploady, šablony, rozšíření | uploady se mění často |
| Databáze | MySQL/MariaDB, PostgreSQL | zálohovat konzistentně, nekopírovat jen soubory |
| Konfigurace | webový server, pooly PHP-FPM, php.ini, úlohy cron | nutné pro rychlé nové zprovoznění |
| Certifikáty a klíče | certifikáty TLS, klíče aplikace | ukládat šifrovaně a odděleně |
| Dokumentace | přístupy, závislosti, postup obnovy | bez ní trvá každé nové zprovoznění déle |
Příklad: záloha databáze a souborů
Následující příklad ukazuje základní stavební kameny denní zálohy. V praxi přenos mimo pracoviště zajišťuje zálohovací nástroj s šifrováním, deduplikací a pravidly uchování.
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"
# Zálohovat databázi konzistentně; přístupové údaje z chráněného souboru, ne v příkazu
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
--single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"
# Soubory aplikace a konfigurace
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d
# Kontrolní součty pro pozdější kontrolu
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
Soubor .backup-my.cnf obsahuje přístupové údaje databázového uživatele, který smí jen číst, a má práva 0600. --single-transaction zajišťuje u tabulek InnoDB konzistentní stav, aniž by se e-shop zastavoval.
Poté samostatný systém přenese zálohu mimo pracoviště. Důležité je, aby byl tento krok sledován: úloha zálohování, která už dny tiše selhává, by jinak vyšla najevo až v kritickém případě. Stačí denní hlášení o úspěchu, velikosti a době trvání, pokud je někdo čte a odchylkám se věnuje.
Pokud využíváte i zálohy nebo snapshoty svého poskytovatele hostingu, ujasněte si písemně, jak dlouho se uchovávají, zda můžete obnovovat sami a zda zálohy zůstanou zachovány i u vypovězeného nebo zablokovaného účtu. Tyto kopie jsou dobrým doplňkem, ale vlastní, nezávislou zálohu nenahrazují.
Uchování: proč jsou po PHP2Shell důležité starší stavy
Po útoku není nejcennější nejnovější záloha, ale nejnovější čistá. U PHP2Shell byl podle zpráv médií 17. 10. 2026 pozorován první pokus o útok, záplaty vyšly 21. 10. 2026. Kdo uchovává jen sedm dní, nemusí mít už stav, který leží bezpečně před možným průnikem.
Osvědčené schéma kombinuje několik období, například denní zálohy na několik týdnů, týdenní na několik měsíců a měsíční na rok. Přesná období se řídí vaší potřebou ochrany a povinnostmi mazání z oblasti ochrany osobních údajů.
Důležité je také: záloha z doby po průniku může obsahovat webshelly nebo změněné soubory. Po incidentu nikdy nenahrávejte zálohu naslepo, ale porovnejte soubory s čistým stavem a zkontrolujte je, než web znovu přejde online. Na co dbát, najdete v článku Příznaky kompromitace. Záplata podstrčený škodlivý software neodstraní a záloha sama od sebe také ne.
Testování a dokumentace obnovy
Záloha bez testu je domněnka. Teprve obnova ukáže, zda jsou přítomny všechny části, zda klíč funguje a jak dlouho postup skutečně trvá.
- Pravidelně obnovte úplnou zálohu v testovacím prostředí, včetně databáze a konfigurace.
- Ověřte, zda poté web funguje úplně: přihlášení, objednávky, formuláře, pošta.
- Změřte dobu trvání a zaznamenejte, které kroky byly ruční. Výsledek porovnejte s dobou, kterou váš provoz maximálně vydrží bez webu.
- Návod k obnově uložte tam, kde je dostupný i při vypadlém serveru, například v IT nouzovém plánu.
Jak konkrétně pomáhá PHP SOS?
- Zkontrolujeme vaše stávající zálohy z hlediska úplnosti, uchování, oddělení od serveru a ochrany před smazáním.
- Nastavíme zálohování 3-2-1 s neměnnou kopií a společně s vámi otestujeme obnovu.
- Po incidentu určíme poslední čistý stav a v rámci odstranění malwaru jej obnovíme na záplatovaném systému.
- V rámci bezpečnostní servisní smlouvy zálohy průběžně sledujeme a provádíme pravidelné testy obnovy.
Časté dotazy
Co znamená pravidlo 3-2-1 u záloh?
Tři kopie vašich dat, na dvou různých typech úložiště, z toho jedna na jiném místě. Pravidlo zajišťuje, že všechny kopie nezasáhne současně ani porucha hardwaru, ani útok či požár.
Stačí záloha mého poskytovatele hostingu?
Je to dobrý doplněk, ale zřídka dostatečný. Ujasněte si, jak dlouho poskytovatel stavy uchovává, zda můžete obnovovat sami a zda by útočník s vaším zákaznickým účtem mohl zálohy smazat. Vlastní, nezávislá kopie je vhodná.
Mohu po hacknutí prostě nahrát poslední zálohu?
Jen opatrně. Poslední záloha už může obsahovat škodlivý kód a zranitelnost, kterou útočník vnikl, je poté stále otevřená. Nejdřív objasněte a uzavřete příčinu, teprve potom obnovte ověřený stav na záplatovaný systém.
Jak často mám obnovu testovat?
Pravidelně a po větších změnách systému. Osvědčil se pevný rytmus, například jedna úplná obnova za čtvrtletí v testovacím prostředí. Důležité je, aby se test dokumentoval a mezery se odstranily.