Kopie zapasowe WordPressa, które da się przywrócić

Typowa konfiguracja kopii zapasowych WordPressa zawodzi dokładnie wtedy, gdy jest potrzebna. Wtyczka zapisuje plik zip w wp-content, na tym samym koncie hostingowym co strona. Gdy witrynę przejmie atakujący lub ransomware albo konto zostanie zawieszone, ta kopia znika razem z nią.

Kopia zapasowa ma wartość tylko wtedy, gdy da się z niej odtworzyć stronę. Ten poradnik omawia, co do niej włączyć, gdzie trzymać kopie, jak często je wykonywać, jak przetestować odtwarzanie i jak wybrać czysty punkt przywracania po włamaniu.

Co musi zawierać kopia zapasowa WordPressa: pliki i baza danych

Strona WordPress składa się z dwóch części i potrzebna jest każda z nich. Baza danych przechowuje wpisy, podstrony, użytkowników i skróty haseł, ustawienia, zamówienia WooCommerce oraz zgłoszenia z formularzy. Weźmy wtyczkę formularza kontaktowego, która zapisuje zgłoszenia w bazie. Kopia samych plików traci wszystkie zapytania klientów, a kopia samej bazy przywraca zgłoszenia, ale nie ma już wtyczki, która potrafiłaby je odczytać.

Z plików potrzebne są wp-content (przesłane pliki, wtyczki, motywy), wp-config.php oraz .htaccess lub konfiguracja serwera. Rdzeń WordPressa można pobrać ponownie, ale tylko wtedy, gdy wiadomo, jaka wersja działała na stronie.

Z katalogu głównego WordPressa, za pomocą WP-CLI:

# Eksport bazy danych, zapisany poza katalogiem głównym serwisu
mkdir -p ~/backups
wp db export ~/backups/db-$(date +%F).sql

# Pliki: wp-content, wp-config.php i .htaccess (bez cache i starych katalogów z kopiami)
tar --exclude='wp-content/cache' \
    --exclude='wp-content/backups' \
    -czf ~/backups/files-$(date +%F).tar.gz \
    wp-content wp-config.php .htaccess

# Zapis wersji, aby rdzeń, wtyczki i motywy można było zainstalować ponownie z oficjalnych źródeł
wp core version > ~/backups/versions-$(date +%F).txt
wp plugin list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt
wp theme list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt

Ścieżkę wp-content/backups należy zastąpić katalogiem, którego używa Państwa wtyczka do kopii. Na nginx nie ma .htaccess, więc trzeba usunąć go z polecenia i zamiast tego zarchiwizować konfigurację serwera. Kopie wewnątrz kopii powiększają każde archiwum. Polecenia WP-CLI do obsługi bazy opisano na WordPress.org.

Zasada 3-2-1 i dlaczego kopia na koncie hostingowym się nie liczy

Zasada brzmi: trzy kopie danych, na dwóch różnych rodzajach nośników, z jedną kopią przechowywaną poza główną lokalizacją. Działająca strona liczy się jako jedna kopia. Kopia na tym samym koncie hostingowym to druga, ale ma te same dane logowania, ten sam serwer i tego samego dostawcę co witryna.

Kto może zapisywać w Państwa witrynie, zwykle może też usunąć taką kopię. Ransomware szyfrujący katalog główny serwisu zaszyfruje też leżący obok plik zip. Zawieszone konto lub awaria hostingu zabiera obie rzeczy naraz. Migawki (snapshoty) hostingu są przydatne i szybko się je przywraca, ale to wciąż jedna kopia, nad którą nie mają Państwo kontroli.

Liczy się trzecia kopia. Powinna trafiać do magazynu u innego dostawcy, z osobnymi danymi dostępowymi, które nie są przechowywane na serwerze WWW w postaci umożliwiającej usuwanie. Dwa ustawienia robią dużą różnicę:

• Wersjonowanie lub niezmienność. Wiele usług magazynowania obiektów oferuje wersjonowanie, blokadę obiektów (object lock) lub blokadę retencji po stronie dostawcy. Wersjonowanie zachowuje starsze kopie, ale każdy, kto ma prawo usuwania, nadal może je skasować. Blokada w najostrzejszym trybie (compliance) uniemożliwia wszystkim, także Państwu, usunięcie lub nadpisanie kopii do końca okresu retencji.
• Dane dostępowe tylko do zapisu dla zadania tworzącego kopię. Jeśli klucz na serwerze pozwala wyłącznie wysyłać pliki, a wersjonowanie lub blokada chroni starsze kopie, atakujący, który go wykradnie, nie wymaże ani nie nadpisze historii kopii.

Jak często robić kopie i jak długo je przechowywać

Częstotliwość zależy od tego, jak szybko zmieniają się dane. Wizytówka edytowana raz w miesiącu wystarczy z cotygodniową kopią. Sklep przyjmujący zamówienia codziennie potrzebuje kopii bazy co najmniej raz dziennie, a często częściej. Pliki zmieniają się zwykle rzadziej niż baza, więc mogą mieć osobny harmonogram.

Okres przechowywania to kompromis. Włamania często wykrywa się po tygodniach od ich początku. Jeśli trzymają Państwo kopie tylko z siedmiu dni, każda z nich może już zawierać backdoora. Z drugiej strony stare kopie podtrzymują istnienie danych osobowych, także kont, które użytkownicy poprosili usunąć.

Warto ustalić stały okres przechowywania i rotację, na przykład kopie dzienne przez kilka tygodni oraz miesięczne przez ograniczony czas. Ten harmonogram należy spisać. Pomaga też przy żądaniach usunięcia danych: dane znikają z kopii wraz z wygaśnięciem ich okresu przechowywania, a do tego czasu dba się o to, by nie zostały przywrócone ani wykorzystane. Przepisywanie archiwów przy każdym żądaniu rzadko jest praktyczne; warto sprawdzić wytyczne organu nadzorczego dotyczące kopii zapasowych.

Kopie zapasowe to dane osobowe: szyfrowanie, dostęp i umowy

Kopia zapasowa WordPressa zawiera konta użytkowników, skróty haseł, dane klientów i zamówień oraz zgłoszenia z formularzy. Jej utrata jest równie poważna jak utrata aktywnej bazy danych.

• Szyfrowanie w transmisji i w spoczynku. Szyfrowanie należy do środków wymienionych w art. 32 ust. 1 lit. a RODO. Klucz trzeba przechowywać w innym miejscu niż chroniony nim magazyn.
• Ograniczony dostęp. Pobierać kopie powinny tylko osoby, które przywracają strony. Stare, współdzielone linki do pobierania i wygasłe konta użytkowników w magazynie należy usunąć.
• Umowy. Dostawca magazynu na kopie lub agencja, która przechowuje kopie, jest podmiotem przetwarzającym w rozumieniu art. 28 i wymaga umowy powierzenia przetwarzania danych.

Niezaszyfrowana kopia, która zaginie lub będzie publicznie dostępna, sama może być naruszeniem ochrony danych osobowych. W takim przypadku warto sięgnąć po poradnik o zgłoszeniu w 72 godziny.

Przetestuj odtwarzanie, zanim będzie potrzebne

Odtwarzać należy na stronie testowej (staging) lub lokalnej kopii, nigdy na działającej witrynie. Trzeba użyć kopii zdalnej, a nie wygodnej lokalnej, bo właśnie kopię zdalną będą Państwo mieli po prawdziwym incydencie.

# W pustym katalogu głównym na stagingu; WP_VERSION pochodzi z pliku z wersjami
wp core download --version="$WP_VERSION" --skip-content
tar -xzf files-2026-10-23.tar.gz
# Edytuj wp-config.php: dane dostępowe do bazy stagingu, następnie:
wp db import db-2026-10-23.sql
wp search-replace 'https://www.example.com' 'https://staging.example.com' --skip-columns=guid
wp option update blog_public 0

blog_public 0 jedynie prosi wyszukiwarki, by omijały stronę. Staging trzeba dodatkowo zabezpieczyć uwierzytelnianiem HTTP. Należy też zablokować wysyłanie wiadomości do prawdziwych klientów i wywoływanie webhooków płatności, a na czas testów warto rozważyć define( 'DISABLE_WP_CRON', true );.

Następnie sprawdzić:

• Logowanie do panelu administratora działa
• Wysłanie formularza przechodzi
• Najnowsze zamówienie lub wpis jest obecny
• Obrazy i pliki do pobrania się ładują
• Lista wtyczek i wersje zgadzają się z zapisem
• Zanotowano łączny czas od startu do działającej strony

Ten czas to rzeczywisty czas odtworzenia, często dłuższy, niż się zakłada. Należy zapisać datę, użytą kopię, wynik i znalezione problemy. Kopia, której nigdy nie przywrócono, niczego nie dowodzi ani przed Państwem, ani przed nikim, kto zapyta, jak spełniają Państwo wymogi art. 32 ust. 1 lit. c i d lub zasadę rozliczalności z art. 5 ust. 2.

Odtwarzanie po włamaniu: znajdź ostatni czysty punkt

Najnowszej kopii nie należy przywracać w ciemno. Prawdopodobnie zawiera backdoora. Najstarsza kopia może być czysta, ale brakuje w niej zamówień z kilku tygodni. Zanim cokolwiek zostanie zmienione, trzeba zachować kopię zainfekowanego stanu, aby móc później prowadzić analizę.

Potem należy oszacować, kiedy zaczęło się włamanie. Pomagają logi serwera i dostępu, daty modyfikacji plików, nieznani administratorzy oraz pliki różniące się od starszej kopii. Następnie wybiera się kopię sprzed tej daty. Przydaje się tu wzorzec integralności plików. Wtyczka Security Audit & Compliance zapisuje taki wzorzec oraz oznacza zmienione pliki i wskaźniki naruszenia, co zawęża czas, w którym coś się zmieniło. Nie tworzy ani nie przywraca kopii zapasowych.

Czystsze podejście niż pełne przywracanie:

1. Zainstalować ponownie rdzeń, wtyczki i motywy z oficjalnych źródeł w znanych wersjach.
2. Z czystego punktu wziąć tylko przesłane pliki i bazę danych. Sprawdzić, czy w uploadach nie ma plików PHP (jak znaleźć web shelle w uploadach).
3. Sprawdzić w bazie, czy nie ma podrzuconych administratorów (wp user list --role=administrator) i spamowych treści.
4. Ponownie wprowadzić lub zmigrować zamówienia i dane powstałe od tamtego momentu.

Przywrócenie nie zamyka luki. Zanim strona wróci do sieci, trzeba zaktualizować lub usunąć podatny komponent i zmienić wszystkie hasła, klucze oraz sole. W przeciwnym razie ta sama droga posłuży do kolejnego włamania. Pełną procedurę opisuje nasz plan usuwania złośliwego oprogramowania, a weryfikacja sum kontrolnych rdzenia potwierdza, że rdzeń jest czysty.

Czego RODO i NIS2 oczekują od kopii zapasowych

RODO w art. 5 ust. 1 lit. f wymaga odpowiedniego bezpieczeństwa, w tym integralności i poufności. Art. 32 ust. 1 lit. c dotyczy zdolności do szybkiego przywrócenia dostępności danych osobowych i dostępu do nich w razie incydentu, a lit. d – regularnego testowania stosowanych środków. Utrata danych klientów bez możliwości ich odtworzenia może być naruszeniem dostępności.

Dla podmiotów objętych przepisami krajowymi NIS2 w art. 21 ust. 2 lit. c wymienia ciągłość działania, w tym zarządzanie kopiami zapasowymi i odtwarzanie po awarii. Nawet jeśli NIS2 Państwa nie dotyczy, klienci objęci NIS2 mogą wymagać od Państwa jako dostawcy lub agencji dowodów. Szerszy obraz daje nasz przegląd art. 32 RODO.

Warto prowadzić jednostronicowy zapis dotyczący kopii: co jest archiwizowane, gdzie, jak często, jaki jest okres przechowywania, jakie szyfrowanie, kto ma dostęp oraz data i wynik ostatniego testu odtwarzania. Najbliższy krok: zaplanować w tym tygodniu pierwszy test odtwarzania, z użyciem kopii zdalnej.

FAQ

Czy codzienna kopia od hostingodawcy wystarczy?

Zwykle sama nie. To jedna kopia, przechowywana u tego samego dostawcy, często przez krótki czas. Trzeba sprawdzić, jak długo jest zachowywana, i dodać kopię zdalną, nad którą mają Państwo kontrolę.

Czy trzeba archiwizować rdzeń WordPressa?

Nie, jeśli zapisane są wersje rdzenia, wtyczek i motywów. Ponowna instalacja z WordPress.org daje też sprawdzone pliki rdzenia.

Co zrobić z żądaniem usunięcia danych, gdy dane tej osoby są w kopiach?

Dane należy usunąć z działającej strony, a w odniesieniu do kopii oprzeć się na udokumentowanym okresie przechowywania. Jeśli kiedykolwiek dojdzie do przywracania, trzeba zadbać, by dane tej osoby nie wróciły na działającą stronę.

Jak często testować odtwarzanie?

Regularnie, a zawsze po większych zmianach w hostingu, na stronie lub w narzędziu do kopii. Warto wybrać odstęp, którego uda się dotrzymać, i zapisywać każdy test.

Dieser Artikel ist eine allgemeine Information und keine Rechtsberatung.