Kopia zapasowa WordPress - jak robić backup, który uratuje stronę po włamaniu

TL;DR: Kopia zapasowa WordPress musi obejmować dwie rzeczy: pliki i bazę danych. Bez jednej z nich strony nie odtworzysz. Żeby kopia uratowała Cię po włamaniu, a nie tylko po awarii serwera, potrzebujesz trzech rzeczy: kilku kopii w różnych miejscach (w tym co najmniej jednej poza kontem hostingowym), odpowiednio długiej historii, bo atakujący często siedzi na stronie tygodniami, zanim ktoś go zauważy, oraz sprawdzonego przywracania. Sama kopia nie usuwa luki, przez którą wszedł włamywacz. Po przywróceniu trzeba ją jeszcze zamknąć, inaczej strona zostanie zainfekowana ponownie.

Kiedy dzwoni do mnie właściciel zhakowanej strony, jedno z pierwszych pytań brzmi: „Ma Pan kopię?”. Odpowiedzi są różne. „Hosting coś robi”, „mam wtyczkę, ale nie wiem, gdzie zapisuje”, „mam, z zeszłego roku na pendrivie”. Bardzo rzadko słyszę: „mam kilka kopii z ostatnich tygodni na zewnętrznym dysku w chmurze i raz w kwartale sprawdzam, czy się odtwarzają”. W tym wpisie pokazuję, jak ustawić kopię zapasową WordPressa tak, żeby w dniu włamania była naprawdę przydatna, i jak wybrać z niej właściwy punkt do przywrócenia.

Co musi zawierać kopia zapasowa WordPress

Dokumentacja WordPressa mówi wprost: kopia strony składa się z dwóch części, bazy danych i plików, i do pełnego odtworzenia typowej witryny potrzebne są obie^[1].

• Baza danych to treść wpisów i stron, ustawienia, konta użytkowników, zamówienia w sklepie, zgłoszenia z formularzy.
• Pliki to przede wszystkim katalog wp-content (motyw, wtyczki, wgrane zdjęcia i dokumenty) oraz plik wp-config.php z danymi dostępu do bazy. Pliki rdzenia WordPressa zawsze da się pobrać na nowo z wordpress.org, ale wygodniej mieć je w kopii.

Częsty błąd, który widzę: wtyczka robi kopię samej bazy, a pliki „są przecież na serwerze”. Po włamaniu to właśnie pliki są najbardziej zmienione. Druga skrajność: ktoś pakuje cały katalog strony, ale zapomina o bazie, która w hostingu żyje osobno i nie wchodzi do archiwum z menedżera plików.

Gdzie trzymać kopie: zasada 3-2-1

Klasyczna reguła 3-2-1, opisana m.in. przez amerykańską agencję CISA, brzmi: trzy kopie ważnych danych (oryginał i dwie kopie), na dwóch różnych rodzajach nośników, z czego jedna przechowywana poza siedzibą^[2]. Dokumentacja WordPressa przenosi to na grunt stron: trzymaj co najmniej 3-5 ostatnich kopii w różnych miejscach, np. jedną na serwerze, jedną w chmurze (Google Drive, Dropbox) i jedną na swoim komputerze^[1].

Przy włamaniu ta zasada ma bardzo konkretne znaczenie. Jeśli atakujący ma dostęp do plików na koncie hostingowym, ma też dostęp do wszystkich kopii, które tam leżą. Może je skasować, podmienić albo po prostu pobrać. CISA w poradniku o ransomware zaleca trzymanie kopii offline i włączanie ochrony przed usunięciem lub blokady obiektów w magazynie, bo kopie zapasowe są jednym z pierwszych celów ataku^[3].

Kopia w public_html to prezent dla włamywacza

Osobny problem to archiwa zostawione w katalogu strony, np. backup.zip albo stara-strona.tar.gz w public_html. Taki plik często da się po prostu pobrać przez przeglądarkę, jeśli ktoś zgadnie nazwę. W środku jest cała baza z danymi klientów i wp-config.php z hasłem do bazy. Kopie, które muszą leżeć na serwerze, powinny być poza katalogiem publicznym albo zablokowane przed dostępem z zewnątrz.

Jak długa historia kopii? Dłuższa, niż myślisz

To najważniejsza rzecz w całym wpisie. Większość osób myśli o kopii jak o zabezpieczeniu przed awarią: dysk padł, przywracam wczorajszą wersję i gotowe. Przy włamaniu wczorajsza wersja zwykle jest już zainfekowana.

Według raportu Mandiant M-Trends 2026 mediana czasu, przez jaki atakujący pozostaje niewykryty w zaatakowanej organizacji, wzrosła w 2025 roku do 14 dni^[4]. To dane z dochodzeń w firmach, nie ze stron WWW, ale z mojego doświadczenia przy małych stronach jest podobnie albo gorzej, bo nikt nie monitoruje ich na bieżąco. Właściciel dowiaduje się o włamaniu od klienta albo z ostrzeżenia w Google, nieraz po kilku tygodniach.

Do tego dochodzą furtki. W raporcie Sucuri za 2023 rok 49,21% zainfekowanych stron miało w chwili infekcji co najmniej jeden backdoor^[7], czyli ukryty plik lub kod, który pozwala atakującemu wrócić nawet po usunięciu widocznego malware. Jeśli kopia powstała po podrzuceniu backdoora, przywracasz go razem ze stroną.

Z mojej praktyki: przy jednym włamaniu pierwsza fala była w okolicach 10. dnia miesiąca, a kolejny webshell, podrzucony przez tego samego sprawcę, pojawił się 11 dni później. Kopia „sprzed tygodnia” zawierała już pierwszą falę. Gdyby historia kopii sięgała tylko kilku dni, nie byłoby czystego punktu do przywrócenia.

Warto też wiedzieć, co dokładnie daje hosting. Na przykład cyberFolks reklamuje „codzienne kopie zapasowe, dostępne do 28 dni wstecz”, ale w szczegółach wyjaśnia, że przechowuje po jednej kopii z 4 ostatnich dni oraz 4 kopie tygodniowe^[5]. Czyli codzienne punkty przywracania masz tylko z ostatnich 4 dni, starsze są co tydzień. To dobra podstawa, ale nie zastępuje własnej kopii poza hostingiem.

Moja rekomendacja dla typowej strony firmowej: kopie codzienne trzymane przez co najmniej 2 tygodnie, do tego kopie tygodniowe przez 2-3 miesiące i jedna kopia miesięczna z dłuższą historią. Przy sklepie internetowym baza danych częściej, bo każde zamówienie to nowe dane.

Jak często robić kopię zapasową WordPressa

Dokumentacja WordPressa proponuje prosty podział: przy małych stronach z niewielką liczbą wpisów kopia raz w tygodniu, przy stronach z dużym ruchem i częstymi zmianami codziennie. Bazę danych należy kopiować regularnie i zawsze przed aktualizacją^[1].

W praktyce częstotliwość ustala się według tego, ile pracy jesteś w stanie stracić. Jeśli dodajesz jeden wpis w miesiącu, cotygodniowa kopia wystarczy. Jeśli prowadzisz sklep, utrata dnia zamówień jest bolesna, więc baza danych powinna być kopiowana codziennie albo częściej. Pliki, zwłaszcza duży katalog zdjęć, można kopiować rzadziej.

Narzędzia: wtyczka, hosting, WP-CLI

Wtyczka do kopii zapasowych

Najpopularniejsza jest UpdraftPlus, aktywna według wordpress.org na ponad 3 milionach stron^[6]. Darmowa wersja pozwala ustawić harmonogram (od co 2 godziny do co miesiąc) i wysyłać kopie m.in. do Dropboxa, Google Drive, Amazon S3, na FTP albo e-mailem^[6]. Kopie przyrostowe, czyli zapisywanie tylko zmian, są w wersji płatnej.

Ważne: wtyczka działa wewnątrz WordPressa. Jeśli strona jest zhakowana, atakujący ma dostęp także do jej ustawień i danych dostępowych do chmury. Dlatego dostęp wtyczki do magazynu w chmurze najlepiej ograniczyć tylko do zapisu, a w samym magazynie włączyć wersjonowanie albo ochronę przed usunięciem, jeśli usługa to oferuje.

Kopie hostingu

Większość polskich hostingów robi kopie automatycznie i pozwala przywrócić pliki lub bazę z panelu. To wygodne i niezależne od WordPressa. Wady: nie masz wpływu na długość historii, kopie są u tego samego dostawcy, a przy zablokowaniu konta za malware dostęp do nich bywa utrudniony. Sprawdź w panelu, ile dni wstecz faktycznie możesz się cofnąć, zanim będzie Ci to potrzebne.

WP-CLI i zrzut bazy

Jeśli masz dostęp SSH, polecenie wp db export zapisuje bazę danych do pliku, a wp db import wczytuje ją z pliku^[10]. Ja tak robię kopię stanu przed każdą większą zmianą i przed czyszczeniem zainfekowanej strony. Zrzut bazy plus spakowany katalog wp-content, pobrane na zewnątrz, to najprostsza kopia, nad którą masz pełną kontrolę.

Kopia, której nie sprawdziłeś, to tylko nadzieja

Sucuri pisze krótko: nie polegaj na kopiach, dopóki ich nie przetestujesz^[9]. CISA zaleca regularne sprawdzanie dostępności i integralności kopii w scenariuszu odtwarzania po awarii^[3]. W praktyce widywałem kopie, które:

• miały 0 bajtów, bo skrypt przekraczał limit czasu na hostingu i nikt nie czytał powiadomień o błędzie,
• zawierały bazę, ale bez katalogu ze zdjęciami,
• przestały się wysyłać do chmury, bo wygasło połączenie z kontem Google, i od pół roku leżały tylko na serwerze,
• były zaszyfrowane hasłem, którego nikt nie pamiętał.

Test nie musi być skomplikowany. Raz na kwartał przywróć kopię na subdomenie testowej albo lokalnie i sprawdź, czy strona się otwiera, czy są zdjęcia i czy działa logowanie. Pół godziny pracy, które oszczędza bardzo nerwowy dzień.

Jak przywrócić kopię po włamaniu, żeby nie przywrócić włamywacza

Google w poradniku dla zhakowanych stron ustala kolejność: najpierw sprawdź, czy kopia powstała przed zhakowaniem strony, potem ją przywróć, a następnie usuń lukę^[8]. Ten ostatni krok jest kluczowy, bo czysta kopia ma dokładnie te same dziury, przez które wszedł atakujący. Pełny proces postępowania przy włamaniu, od pierwszych objawów do zgłoszenia do Google, opisałem we wpisie o tym, jak rozpoznać zhakowaną stronę WordPress i co zrobić od razu. Tu skupiam się tylko na samym przywracaniu.

1. Zrób kopię obecnego, zainfekowanego stanu. Brzmi absurdalnie, ale to materiał dowodowy. Z dat modyfikacji plików i logów serwera ustalisz, kiedy zaczęło się włamanie.
2. Ustal datę pierwszej infekcji, a nie datę, w której ją zauważyłeś. Pomagają w tym logi dostępu (pierwsze wywołania podejrzanych plików), daty utworzenia nieznanych kont i nowych plików. Uwaga: daty modyfikacji plików da się sfałszować, więc nie opieraj się tylko na nich. Jakie narzędzia pomagają w takiej diagnozie, opisałem we wpisie jak sprawdzić, czy strona ma wirusa.
3. Wybierz kopię sprzed tej daty, z zapasem kilku dni. Jeśli takiej nie masz, przywracanie nie wystarczy i potrzebne jest ręczne czyszczenie.
4. Przywróć pliki i bazę razem, z tego samego momentu. Mieszanie plików z jednego dnia i bazy z innego kończy się błędami albo zostawia infekcję w jednej z warstw.
5. Od razu zamknij lukę: zaktualizuj WordPressa, motyw i wtyczki, usuń porzucone dodatki, zmień wszystkie hasła (WordPress, hosting, FTP, baza), wygeneruj nowe klucze bezpieczeństwa w wp-config.php, przejrzyj listę administratorów i hasła aplikacji.
6. Przenieś dane, które powstały po dacie kopii: zamówienia, zgłoszenia, nowe wpisy. Rób to ręcznie, z zainfekowanej kopii bierz tylko treść, nigdy pliki PHP.
7. Obserwuj stronę przez kolejne dni. Jeśli usunięte pliki wracają albo pojawia się nowy administrator, w środowisku zostało coś, czego kopia nie obejmuje: zadanie cron, inna strona na tym samym koncie hostingowym albo wyciekłe hasło.

Ostatni punkt nie jest teoretyczny. Według tego samego raportu Sucuri 55% stron z malware w bazie danych miało co najmniej jednego złośliwego administratora^[7]. Sucuri ostrzega też, że jeśli w systemie zostaną złośliwi użytkownicy WordPressa lub FTP, strona szybko zostanie zainfekowana ponownie^[9].

Kiedy przywracanie kopii nie wystarczy

Są sytuacje, w których sama kopia nie załatwi sprawy: brak czystego punktu sprzed włamania, infekcja całego konta hostingowego z kilkoma stronami, spam SEO już zaindeksowany przez Google albo ostrzeżenie przy domenie w wynikach wyszukiwania. Wtedy potrzebne jest pełne czyszczenie plików i bazy, zamknięcie wszystkich furtek i zgłoszenie strony do ponownej weryfikacji. Tym zajmuję się w ramach naprawy i czyszczenia zhakowanych stron.

Checklista: kopia zapasowa WordPress, która ratuje po włamaniu

• Kopia obejmuje bazę danych i pliki (co najmniej wp-content i wp-config.php).
• Co najmniej jedna kopia jest poza kontem hostingowym, najlepiej w magazynie z wersjonowaniem lub ochroną przed usunięciem.
• Historia sięga kilku tygodni wstecz, nie kilku dni.
• Żadnych archiwów z kopią w katalogu publicznym strony.
• Kopia bazy przed każdą aktualizacją.
• Przywracanie przetestowane w ostatnim kwartale.
• Wiesz, kto ma dostęp do kopii i gdzie są hasła do nich.

Kopie to jeden z kilkunastu elementów ochrony strony. Pozostałe, od aktualizacji po 2FA i wyłączenie XML-RPC, zebrałem na liście zabezpieczeń WordPressa przed włamaniem.

FAQ - kopia zapasowa WordPress

Czy kopie robione przez hosting wystarczą?

Jako jedyna kopia nie. Są wygodne i niezależne od WordPressa, ale leżą u tego samego dostawcy, a historia bywa krótka. Warto mieć dodatkowo własną kopię w innym miejscu, np. w chmurze albo na dysku firmowym.

Jak długo przechowywać kopie zapasowe strony?

Na tyle długo, żeby mieć czysty punkt sprzed włamania, którego nikt nie zauważył od razu. Dla typowej strony firmowej rozsądne minimum to kopie dzienne z 2 tygodni i tygodniowe z 2-3 miesięcy.

Czy mogę po prostu przywrócić kopię, gdy strona zostanie zhakowana?

Tylko wtedy, gdy kopia powstała przed włamaniem i od razu po przywróceniu zamkniesz lukę, którą wszedł atakujący. Inaczej przywracasz albo backdoor, albo stronę, która zostanie zainfekowana tą samą drogą w ciągu kilku dni.

Czy kopia zapasowa jest objęta RODO?

Jeśli strona przechowuje dane osobowe (formularze, konta klientów, zamówienia), to kopia zawiera te same dane. Dlatego powinna być zabezpieczona tak samo jak strona: ograniczony dostęp, najlepiej szyfrowanie, a stare kopie usuwane zgodnie z przyjętym okresem przechowywania.

Ile kosztuje kopia zapasowa strony WordPress?

Podstawową kopię da się zrobić za darmo: darmowa wtyczka plus darmowe miejsce w chmurze wystarczą małej stronie. Płaci się raczej czasem: za ustawienie, pilnowanie, czy kopie się wykonują, i za testy przywracania. Dlatego w ramach administracji stronami biorę to na siebie.

Strona już zhakowana, a kopii brak albo nie wiesz, czy jest czysta?

Zanim cokolwiek przywrócisz, zadzwoń. Ocenię, czy w Twoich kopiach jest czysty punkt, przywrócę stronę i zamknę furtkę, a jeśli kopii nie ma, wyczyszczę stronę ręcznie z plików i bazy. Szczegóły znajdziesz na stronie naprawa zhakowanych stron. Telefon: +48 606 719 343, e-mail: lukasz@freelancerka.com.

Przypisy i źródła

Wszystkie źródła zweryfikowane; dostęp: 19 października 2026.

1. WordPress Developer Resources, „Backups”, Advanced Administration Handbook (aktualizacja 14.10.2026) - developer.wordpress.org
2. Paul Ruggiero, Matthew A. Heckathorn, US-CERT, „Data Backup Options” (2012) - cisa.gov
3. CISA, „#StopRansomware Guide” (wrzesień 2023) - cisa.gov
4. Google Cloud / Mandiant, „M-Trends 2026” (23.03.2026) - cloud.google.com
5. cyberFolks, „Hosting” (opis kopii zapasowych) - cyberfolks.pl
6. WordPress.org, „UpdraftPlus: WP Backup & Migration Plugin” - wordpress.org
7. Sucuri, „2023 Hacked Website & Malware Threat Report” (czerwiec 2024) - sucuri.net
8. Google, web.dev, „Clean and maintain your site” - web.dev
9. Sucuri, „How to Clean a Hacked WordPress Site” - sucuri.net
10. WordPress Developer Resources, „wp db export” i „wp db import” - developer.wordpress.org