# Strategia backupu serwera: backupy według reguły 3-2-1

> Strategia backupu serwera według reguły 3-2-1: co trzeba zabezpieczyć, jak backupy przetrwają atak i dlaczego należy testować przywracanie.

Źródło: https://phpsos.de/pl/ratgeber/backups-3-2-1/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**Krótko:** Wytrzymała strategia backupu serwera opiera się na regule 3-2-1: trzy kopie, dwa rodzaje nośników, jedna kopia poza siedzibą. Aby backupy przetrwały także atak, co najmniej jedna kopia potrzebuje ochrony przed usunięciem przez sam serwer. A dopiero udany test przywracania pokazuje, że kopia zapasowa zadziała w poważnej sytuacji.

## Co oznacza reguła 3-2-1

Reguła 3-2-1 to prosta, od lat sprawdzona zasada tworzenia kopii zapasowych:

- **3 kopie:** dane oryginalne i dwie kopie zapasowe.
- **2 rodzaje nośników:** na przykład dysk lokalny i magazyn obiektowy albo pamięć serwera i taśma.
- **1 kopia poza siedzibą:** w innej lokalizacji, u innego dostawcy lub offline.

Dla serwerów WWW oznacza to konkretnie: kopia na tym samym dysku co strona nie liczy się jako samodzielna kopia. Jeśli serwer ulegnie awarii lub zostanie skompromitowany, obie przepadają. Dla zarządu kluczowe pytanie brzmi więc nie „Czy mamy backupy?”, lecz „Czy możemy przywrócić działanie z kopii, której incydent nie dosięgnął?”

## Strategia backupu serwera, która przetrwa atak

Atakujący wiedzą, że backupy niweczą ich pracę. Kto ma dostęp do serwera, często szuka więc także kopii zapasowych, by je usunąć lub zaszyfrować. Nowoczesna strategia rozszerza dlatego regułę 3-2-1 często do **3-2-1-1-0**: jedna dodatkowa kopia offline lub niezmienna oraz zero błędów w teście przywracania.

Trzy zasady czynią backupy odpornymi:

- **Pull zamiast push:** osobny system backupu pobiera dane z serwera WWW. Sam serwer WWW nie ma danych dostępowych, za pomocą których mógłby usuwać backupy.
- **Niezmienność:** magazyn obiektowy z blokadą przechowywania lub migawki, których nie da się usunąć przez ustalony czas.
- **Rozdzielone dostępy:** konto backupu nie jest tym samym co konto klienta u hostingu i ma własny drugi składnik.

> **Ważne:**
> Backupy przechowywane poza siedzibą proszę szyfrować, a klucz przechowywać oddzielnie. Zgubiony klucz czyni backup bezużytecznym, klucz zapisany razem z nim czyni szyfrowanie bezwartościowym.

## Co trzeba zabezpieczyć

W przypadku serwerów WWW często zabezpiecza się tylko webroot. Do pełnego przywrócenia brakuje wtedy ważnych części.

| Obszar | Przykłady | Wskazówka |
|---|---|---|
| Pliki aplikacji | webroot, uploady, motywy, rozszerzenia | uploady zmieniają się często |
| Bazy danych | MySQL/MariaDB, PostgreSQL | zabezpieczać spójnie, nie tylko kopiować pliki |
| Konfiguracja | serwer WWW, pule PHP-FPM, php.ini, zadania cron | potrzebna do szybkiej odbudowy |
| Certyfikaty i klucze | certyfikaty TLS, klucze aplikacji | przechowywać zaszyfrowane i oddzielnie |
| Dokumentacja | dostępy, zależności, przebieg przywracania | bez niej każda odbudowa trwa dłużej |

## Przykład: zabezpieczanie bazy danych i plików

Poniższy przykład pokazuje podstawowe elementy codziennej kopii zapasowej. W praktyce przesyłanie poza siedzibę przejmuje narzędzie backupu z szyfrowaniem, deduplikacją i regułami przechowywania.

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

# Zabezpiecz bazę danych spójnie; dane dostępowe z chronionego pliku, nie w poleceniu
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
  --single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"

# Pliki aplikacji i konfiguracja
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d

# Sumy kontrolne do późniejszej kontroli
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
```

Plik `.backup-my.cnf` zawiera dane dostępowe użytkownika bazy danych, który może tylko czytać, i ma uprawnienia `0600`. `--single-transaction` zapewnia w tabelach InnoDB spójny stan bez zatrzymywania sklepu.

Następnie osobny system przesyła kopię poza siedzibę. Ważne, aby ten krok był monitorowany: zadanie backupu, które od dni po cichu kończy się niepowodzeniem, wychodzi na jaw inaczej dopiero w poważnej sytuacji. Wystarcza codzienny komunikat o powodzeniu, rozmiarze i czasie trwania, o ile ktoś go czyta i zajmuje się odchyleniami.

Jeśli korzystają Państwo dodatkowo z backupów lub migawek swojego hostingu, proszę wyjaśnić na piśmie, jak długo są przechowywane, czy mogą Państwo przywracać samodzielnie i czy kopie zostają zachowane przy wypowiedzianym lub zablokowanym koncie. Te kopie są dobrym uzupełnieniem, ale nie zastępują własnej, niezależnej kopii.

## Przechowywanie: dlaczego starsze stany są ważne po PHP2Shell

Po ataku najcenniejszy nie jest najnowszy backup, lecz najnowszy czysty. W przypadku PHP2Shell według doniesień medialnych 17.10.2026 zaobserwowano pierwszą próbę ataku, a poprawki pojawiły się 21.10.2026. Kto przechowuje tylko siedem dni, może nie mieć już stanu, który bezpiecznie leży przed możliwym włamaniem.

Sprawdzony schemat łączy kilka okresów, na przykład codzienne kopie przez kilka tygodni, tygodniowe przez kilka miesięcy i miesięczne przez rok. Dokładne okresy zależą od Państwa potrzeb ochrony i od obowiązków usuwania wynikających z ochrony danych.

Ważne jest też: backup z okresu po włamaniu może zawierać webshelle lub zmienione pliki. Po incydencie nigdy nie należy wgrywać kopii na ślepo, lecz porównać pliki z czystym stanem i sprawdzić je, zanim strona wróci do sieci. Wskazówki, na co zwracać uwagę, znajdą Państwo na stronie [Oznaki kompromitacji](https://phpsos.de/pl/php2shell/bin-ich-gehackt-anzeichen/). Poprawka nie usuwa wprowadzonego złośliwego oprogramowania i backup też nie robi tego samoczynnie.

## Testowanie i dokumentowanie przywracania

Backup bez testu to założenie. Dopiero przywrócenie pokazuje, czy wszystkie części są dostępne, czy klucz działa i jak długo proces faktycznie trwa.

- Proszę regularnie wgrywać pełną kopię w środowisku testowym, wraz z bazą danych i konfiguracją.
- Proszę sprawdzić, czy strona po tym w pełni działa: logowanie, zamówienia, formularze, poczta.
- Proszę zmierzyć czas trwania i zapisać, które kroki były ręczne. Wynik proszę porównać z czasem, jaki Państwa działalność maksymalnie wytrzyma bez strony.
- Instrukcję przywracania proszę przechowywać tam, gdzie jest dostępna także przy niedziałającym serwerze, na przykład w [IT-planie awaryjnym](https://phpsos.de/pl/compliance/notfallplan-erstellen/).

## Jak konkretnie pomaga PHP SOS?

- Sprawdzamy Państwa istniejące backupy pod kątem kompletności, przechowywania, rozdzielenia od serwera i ochrony przed usunięciem.
- Wdrażamy kopię 3-2-1 z kopią niezmienną i wspólnie z Państwem testujemy przywracanie.
- Po incydencie ustalamy ostatni czysty stan i przywracamy go na załatanym systemie w ramach [usuwania malware](https://phpsos.de/pl/leistungen/malware-entfernung/).
- W [umowie serwisowej na bezpieczeństwo](https://phpsos.de/pl/leistungen/security-wartungsvertrag/) stale monitorujemy kopie zapasowe i przeprowadzamy regularne testy przywracania.


## Częste pytania

**Co oznacza reguła 3-2-1 przy backupach?**  
Trzy kopie danych, na dwóch różnych rodzajach nośników, z czego jedna w innym miejscu. Reguła zapewnia, że ani awaria sprzętu, ani atak, ani pożar nie dotkną wszystkich kopii jednocześnie.

**Czy backup mojego hostingu wystarczy?**  
Jest dobrym uzupełnieniem, ale rzadko wystarcza. Proszę wyjaśnić, jak długo hosting przechowuje stany, czy mogą Państwo przywracać samodzielnie i czy atakujący z dostępem do Państwa konta klienta mógłby usunąć backupy. Zalecana jest własna, niezależna kopia.

**Czy po włamaniu mogę po prostu wgrać ostatni backup?**  
Tylko z ostrożnością. Ostatni backup może już zawierać złośliwy kod, a luka, przez którą wszedł atakujący, jest potem nadal otwarta. Najpierw wyjaśnić i zamknąć przyczynę, potem wgrać sprawdzony stan na załatany system.

**Jak często powinienem testować przywracanie?**  
Regularnie i po większych zmianach w systemie. Sprawdził się stały rytm, na przykład pełne przywrócenie raz na kwartał w środowisku testowym. Ważne, aby test był udokumentowany, a luki usuwane.

## Źródła

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: Federalny Urząd ds. Bezpieczeństwa Informacji, kopie zapasowe (Niemcy)](https://www.bsi.bund.de/)
- [php.net: komunikaty o bezpieczeństwie dotyczące PHP2Shell](https://www.php.net/)