# Stratégia zálohovania servera: zálohy podľa pravidla 3-2-1

> Stratégia zálohovania servera podľa pravidla 3-2-1: čo musíte zálohovať, ako zálohy prežijú útok a prečo otestovať obnovu.

Zdroj: https://phpsos.de/sk/ratgeber/backups-3-2-1/  
Stav: 25.10.2026  
Poskytovateľ: PHP SOS, Núdzová pomoc pri PHP a bezpečnosť serverov. Okamžitá pomoc cez WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20de%C5%88%2C%20PHP%20SOS%2C%20potrebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20serverom%20s%20PHP.%20Spolo%C4%8Dnos%C5%A5%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručne:** Spoľahlivá stratégia zálohovania servera sleduje pravidlo 3-2-1: tri kópie, dva druhy úložiska, jedna kópia mimo pracoviska. Aby zálohy prežili aj útok, potrebuje aspoň jedna kópia ochranu pred zmazaním zo strany samotného servera. A až úspešný test obnovy ukáže, že záloha v krízovej situácii funguje.

## Čo znamená pravidlo 3-2-1

Pravidlo 3-2-1 je jednoduchá, roky osvedčená zásada zálohovania údajov:

- **3 kópie:** pôvodné údaje a dve zálohy.
- **2 druhy úložiska:** napríklad lokálny disk a objektové úložisko, alebo úložisko servera a páska.
- **1 kópia mimo pracoviska:** na inom mieste, u iného poskytovateľa alebo offline.

Pre webové servery to konkrétne znamená: záloha na tom istom disku ako web sa nepočíta ako samostatná kópia. Ak server vypadne alebo sa kompromituje, obe sú stratené. Pre vedenie preto základná otázka nezní „Máme zálohy?“, ale „Dokážeme obnoviť prevádzku z kópie, ktorú incident nezasiahol?“

## Stratégia zálohovania servera, ktorá prežije útok

Útočníci vedia, že zálohy ich prácu zmarí. Kto má prístup na server, často hľadá aj zálohy, aby ich zmazal alebo zašifroval. Moderná stratégia preto rozširuje pravidlo 3-2-1 často na **3-2-1-1-0**: jedna kópia navyše offline alebo nemenná a nula chýb pri teste obnovy.

Tri zásady robia zálohy odolnými:

- **Pull namiesto push:** Samostatný záložný systém si údaje z webového servera vyzdvihne. Samotný webový server nemá prístupové údaje, ktorými by mohol zálohy zmazať.
- **Nemennosť:** Objektové úložisko s retenčným zámkom alebo snapshoty, ktoré sa nedajú po stanovený čas zmazať.
- **Oddelené prístupy:** Záložný účet nie je rovnaký ako zákaznícky účet hostingu a má vlastný druhý faktor.

> **Dôležité:**
> Zálohy uložené mimo pracoviska šifrujte a kľúč uschovajte oddelene. Stratený kľúč robí zálohu nepoužiteľnou, spoločne uložený kľúč robí šifrovanie bezcenným.

## Čo sa musí zálohovať

Pri webových serveroch sa často zálohuje iba webroot. Pre úplnú obnovu potom chýbajú dôležité časti.

| Oblasť | Príklady | Poznámka |
|---|---|---|
| Súbory aplikácie | Webroot, uploady, témy, rozšírenia | Uploady sa často menia |
| Databázy | MySQL/MariaDB, PostgreSQL | zálohovať konzistentne, nielen kopírovať súbory |
| Konfigurácia | Webový server, pooly PHP-FPM, php.ini, cronjoby | potrebné pre rýchlu novú výstavbu |
| Certifikáty a kľúče | Certifikáty TLS, kľúče aplikácie | ukladať šifrovane a oddelene |
| Dokumentácia | Prístupy, závislosti, postup obnovy | bez nej trvá každá nová výstavba dlhšie |

## Príklad: zálohovať databázu a súbory

Nasledujúca ukážka zobrazuje základné stavebné prvky dennej zálohy. V praxi prenos mimo pracoviska preberá záložný nástroj so šifrovaním, deduplikáciou a pravidlami uchovávania.

```bash
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"

# Zálohovať databázu konzistentne; prístupové údaje z chráneného súboru, nie v príkaze
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
  --single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"

# Súbory aplikácie a konfigurácia
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d

# Kontrolné súčty pre neskoršiu kontrolu
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
```

Súbor `.backup-my.cnf` obsahuje prístupové údaje databázového používateľa, ktorý smie iba čítať, a má práva `0600`. `--single-transaction` zaisťuje pri tabuľkách InnoDB konzistentný stav bez zastavenia e-shopu.

Potom samostatný systém prenesie zálohu mimo pracoviska. Dôležité je, aby sa tento krok monitoroval: záložná úloha, ktorá už dni potichu zlyháva, by inak vyšla najavo až v krízovej situácii. Stačí denné hlásenie o úspechu, veľkosti a trvaní, pokiaľ ho niekto číta a odchýlkam sa venuje.

Ak navyše využívate zálohy alebo snapshoty svojho poskytovateľa hostingu, vyjasnite písomne, ako dlho sa uchovávajú, či môžete obnovovať sami a či zálohy zostanú zachované pri vypovedanom alebo zablokovanom účte. Tieto kópie sú dobrým doplnkom, ale nenahrádzajú vlastné, nezávislé zálohovanie.

## Uchovávanie: prečo sú po PHP2Shell dôležité staršie stavy

Po útoku nie je najcennejšia najnovšia záloha, ale najnovšia čistá. Pri PHP2Shell sa podľa správ médií 17. 10. 2026 pozoroval prvý pokus o útok, záplaty vyšli 21. 10. 2026. Kto uchováva iba sedem dní, nemusí mať už stav, ktorý bezpečne leží pred možným vlámaním.

Osvedčená schéma kombinuje viac období, napríklad denné zálohy niekoľko týždňov, týždenné niekoľko mesiacov a mesačné rok. Presné obdobia sa riadia vašou potrebou ochrany a povinnosťami mazania z ochrany údajov.

Dôležité je aj toto: záloha z obdobia po vlámaní môže obsahovať webshelly alebo zmenené súbory. Po incidente nikdy neobnovujte naslepo, ale porovnajte súbory s čistým stavom a skontrolujte ich, skôr než web opäť pôjde online. Pokyny, na čo dbať, nájdete na stránke [Príznaky kompromitácie](https://phpsos.de/sk/php2shell/bin-ich-gehackt-anzeichen/). Záplata neodstráni zavlečený škodlivý softvér a záloha to sama od seba tiež nerobí.

## Obnovu testovať a dokumentovať

Záloha bez testu je predpoklad. Až obnova ukáže, či sú k dispozícii všetky časti, či kľúč funguje a ako dlho postup skutočne trvá.

- Pravidelne nasadzujte úplnú zálohu v testovacom prostredí, vrátane databázy a konfigurácie.
- Skontrolujte, či web potom úplne funguje: prihlásenie, objednávky, formuláre, pošta.
- Zmerajte trvanie a zaznamenajte, ktoré kroky boli manuálne. Výsledok porovnajte s časom, ktorý vaša prevádzka najviac zvládne bez webu.
- Návod na obnovu uložte tam, kde je dostupný aj pri vypadnutom serveri, napríklad v [IT núdzovom pláne](https://phpsos.de/sk/compliance/notfallplan-erstellen/).

## Ako konkrétne pomáha PHP SOS?

- Vaše existujúce zálohy kontrolujeme na úplnosť, uchovávanie, oddelenie od servera a ochranu pred zmazaním.
- Zriadime zálohovanie 3-2-1 s nemennou kópiou a obnovu otestujeme spolu s vami.
- Po incidente identifikujeme posledný čistý stav a obnovíme ho na zaplátanom systéme v rámci [odstránenia malvéru](https://phpsos.de/sk/leistungen/malware-entfernung/).
- V [zmluve o bezpečnostnej údržbe](https://phpsos.de/sk/leistungen/security-wartungsvertrag/) zálohy priebežne monitorujeme a vykonávame pravidelné testy obnovy.


## Časté otázky

**Čo znamená pravidlo 3-2-1 pri zálohách?**  
Tri kópie vašich údajov, na dvoch rôznych druhoch úložiska, z toho jedna na inom mieste. Pravidlo zaisťuje, že poruchu hardvéru, útok ani požiar nezasiahnu všetky kópie naraz.

**Stačí záloha môjho poskytovateľa hostingu?**  
Je to dobrý doplnok, ale zriedka postačuje. Vyjasnite si, ako dlho poskytovateľ stavy uchováva, či môžete obnovovať sami a či by útočník s vaším zákazníckym účtom mohol zálohy zmazať. Odporúča sa vlastná, nezávislá kópia.

**Môžem po hacku jednoducho nasadiť poslednú zálohu?**  
Len opatrne. Posledná záloha už môže obsahovať škodlivý kód a zraniteľnosť, cez ktorú útočník prišiel, je potom stále otvorená. Najprv objasniť a uzavrieť príčinu, potom preverený stav obnoviť na zaplátaný systém.

**Ako často by som mal testovať obnovu?**  
Pravidelne a po väčších zmenách na systéme. Osvedčil sa pevný rytmus, napríklad úplná obnova raz za štvrťrok v testovacom prostredí. Dôležité je, aby sa test zdokumentoval a medzery sa odstránili.

## Zdroje

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: zálohovanie údajov](https://www.bsi.bund.de/)
- [php.net: bezpečnostné hlásenia k PHP2Shell](https://www.php.net/)