Jak przywrócić stronę WordPress z backupu

Gdy strona nagle przestaje działać po aktualizacji, ataku lub błędzie serwera, spokojne i metodyczne odtwarzanie z kopii zapasowej jest Twoją polisą ubezpieczeniową. W tym poradniku przejdziesz krok po kroku przez proces przywracania: od weryfikacji zasobów, przez metody oparte na wtyczkach, aż po ręczne działania na plikach i bazie danych. Zobaczysz też, jak ograniczyć przestój i zminimalizować ryzyko utraty danych, aby Twój backup uratował witrynę WordPress wtedy, gdy najbardziej tego potrzebujesz.

Przygotowanie i weryfikacja kopii zapasowej

Rozpoznaj, co dokładnie zawiera Twoja kopia

Zacznij od sprawdzenia, z jakim typem kopii masz do czynienia. Kopia pełna obejmuje wszystkie pliki aplikacji oraz eksport bazy danych; kopia przyrostowa lub różnicowa zawiera tylko zmiany względem poprzedniego stanu. Jeżeli korzystasz z wtyczki do kopii zapasowych, najpewniej masz archiwum ZIP/TAR wraz z plikiem .sql (eksport bazy) lub zestawem paczek charakterystycznych dla danej wtyczki (np. paczka instalacyjna Duplicator, katalogi UpdraftPlus w chmurze itp.).

Sprawdź integralność archiwów: czy da się je rozpakować lokalnie, czy nie są uszkodzone, oraz czy rozmiar plików jest zbliżony do tego, co pamiętasz z momentu tworzenia kopii. Zwróć uwagę, czy w archiwum znajdują się: katalog wp-content (themes, plugins, uploads), główne pliki WordPress (wp-admin, wp-includes) oraz eksport bazy danych. Jeśli masz sumy kontrolne (np. SHA256), porównaj je z plikami, aby wykluczyć uszkodzenia.

Zweryfikuj środowisko docelowe

Przed rozpoczęciem odtwarzania sprawdź, czy środowisko docelowe spełnia wymagania techniczne Twojej kopii. Ustal wersję PHP i MySQL/MariaDB, limity pamięci i czasu wykonywania skryptów, dostęp do panelu hostingu oraz logów. Zadbaj, by na docelowym hostingu poprawnie działał serwer WWW (Apache/Nginx), a domena wskazywała na właściwy katalog. Ustal, czy masz wystarczającą przestrzeń dyskową na rozpakowanie i umieszczenie plików, oraz uwzględnij czas potrzebny na propagację DNS, jeśli witryna zmienia lokalizację.

Jeśli odtwarzasz stronę na innym serwerze niż oryginalny, przygotuj konto SFTP/SSH, dane do bazy oraz dostęp do narzędzi administracyjnych. W przypadku hostingu współdzielonego sprawdź, czy masz do dyspozycji narzędzia typu menedżer plików i phpMyAdmin; w przypadku VPS/serwera dedykowanego – czy masz uprawnienia sudo i możliwość instalacji niezbędnych narzędzi.

Pracuj bezpiecznie: staging i plan wycofania

Uwaga: jeśli tylko możesz, przywracaj kopię najpierw na środowisku testowym (staging), a dopiero potem na produkcji. Staging możesz utworzyć jako subdomenę (np. staging.twojadomena.pl) wskazującą na osobny katalog i bazę. Dzięki temu sprawdzisz poprawność działania motywu, wtyczek, integracji i bramek płatności bez ryzyka przerwy w działaniu głównej witryny.

Przygotuj prosty plan wycofania (rollback): cofnij rekordy DNS dopiero wtedy, gdy testy pozytywnie wypadną; miej pod ręką poprzednią kopię zapasową; zaplanuj komunikat o konserwacji (maintenance mode) na czas krytycznych operacji.

Zbierz wszystkie niezbędne dostępy i zasoby

Przygotuj loginy i hasła do: panelu hostingu, SFTP/SSH, konta bazy danych, narzędzi takich jak phpMyAdmin, a także do chmury, w której przechowywany jest backup (np. S3/Dropbox). Zgromadź dane produkcyjne: klucze API, konfiguracje bramek płatności, dane SMTP, rekordy DNS (A/CNAME/MX). Zapisz je w menedżerze haseł i używaj połączeń szyfrowanych.

Wykonaj dodatkową, bieżącą kopię przed startem

Nawet jeśli obecna witryna nie działa idealnie, wykonaj bieżący zrzut plików i bazy – pozwoli to wrócić do punktu wyjścia, jeśli coś pójdzie nie tak. Zatrzymaj automatyczne zadania (cron), włącz tryb konserwacji i komunikat dla użytkowników, a w e-commerce – rozważ czasowe wyłączenie przyjmowania zamówień, aby nie zgubić nowych danych podczas odtwarzania.

Przywracanie za pomocą popularnych wtyczek

UpdraftPlus: od chmury do gotowej witryny

Jeśli Twoja kopia została wykonana w UpdraftPlus, najwygodniej odtworzyć ją bezpośrednio z poziomu WordPress. Zainstaluj i aktywuj wtyczkę, przejdź do Ustawienia → UpdraftPlus Backups, połącz z miejscem przechowywania (np. Amazon S3, Google Drive), a następnie kliknij Rescan remote storage. Wybierz zestaw kopii (database, plugins, themes, uploads, others) i uruchom przywracanie. Po odtworzeniu zaloguj się ponownie i sprawdź strukturę odnośników, menu oraz formularze.

W razie problemów z limitem wykonywania skryptów, włącz odtwarzanie etapowe (split restore) i ustaw wyższy limit pamięci. Pamiętaj, by w razie zmiany domeny skorzystać z opcji zamiany adresów (search/replace) oferowanej przez UpdraftPlus lub wykonać to ręcznie po zakończeniu.

Duplicator: paczka instalacyjna i kreator

Duplicator generuje dwa pliki: installer.php i archiwum z całą stroną. Prześlij oba do katalogu docelowego (np. public_html), wejdź pod adres twojadomena.pl/installer.php, zaakceptuj warunki i wskaż bazę danych (nazwa, użytkownik, hasło, host). Kreator sam wypakuje pliki, utworzy strukturę bazy i zmigruje dane. Zwróć uwagę na ścieżki i adresy URL; kreator zaproponuje automatyczną korektę. Na koniec usuń pliki instalatora i zabezpiecz katalogi.

Jeśli plik archiwum jest bardzo duży, ładuj go przez SFTP/SSH zamiast przez menedżer plików w przeglądarce. Włącznie opcji rozpakowywania na serwerze pozwala uniknąć limitów uploadu i czasu wykonywania skryptów.

All-in-One WP Migration i podobne narzędzia

All-in-One WP Migration umożliwia import jednego pliku z całym snapshotem witryny. Zwiększ limit wielkości przesyłanego pliku (np. poprzez rozszerzenie Unlimited Extension lub konfigurację php.ini), następnie wejdź w Import i wskaż paczkę. Po imporcie zaloguj się ponownie (hasła i użytkownicy zostaną przeniesieni) i sprawdź działanie szczególnie w obszarach mediów, motywu i niestandardowych pól.

Analogicznie działają WPvivid Backup/Restore czy Jetpack Backup: po połączeniu z chmurą wybierz punkt w czasie i przeprowadź proces. Zaletą „time machine” jest łatwość cofnięcia tylko bazy lub tylko uploadów w razie potrzeby.

Co wybrać i kiedy

Wtyczki sprawdzają się, gdy odtwarzasz kopię na podobnym środowisku i masz dostęp do panelu administracyjnego. Gdy panel jest niedostępny, plik jest uszkodzony albo chcesz migrować na zupełnie inną infrastrukturę, bardziej przewidywalne bywa ręczne przywracanie plików i bazy.

Ręczne przywracanie plików i bazy danych

Transfer plików: struktura katalogów i uprawnienia

Jeśli kopia to archiwum ZIP/TAR, rozpakuj je lokalnie i przejrzyj strukturę: wp-admin, wp-includes, wp-content. Najważniejszy jest katalog wp-content (themes, plugins, uploads), ponieważ zawiera Twoje motywy, wtyczki i media. Połącz się z serwerem przez klienta FTP lub SFTP (preferowane, bo szyfrowane) i prześlij pliki do katalogu docelowego (np. public_html, httpdocs lub /var/www/…).

Zadbaj o poprawne uprawnienia: zwykle katalogi 755, pliki 644. Unikaj nadawania 777. Jeżeli na serwerze już istnieją pliki, zdecyduj, czy chcesz je nadpisać, czy wcześniej usunąć katalog docelowy (ostrożnie!). Dla dużych katalogów uploads warto stosować transfer przyrostowy i wznawianie, aby uniknąć przerw w przesyłaniu.

Import bazy danych: narzędzia i ograniczenia

Baza WordPress to struktura tabel (wp_options, wp_posts, wp_users itd.), które muszą zostać odtworzone z pliku .sql. Utwórz nową bazę i użytkownika, nadaj mu pełne uprawnienia. Do importu wykorzystaj phpMyAdmin lub wiersz poleceń. W phpMyAdmin wybierz bazę → Importuj → Wskaż plik .sql → ustaw kodowanie utf8mb4 i uruchom import. Jeżeli plik jest bardzo duży, użyj narzędzi CLI (mysql, WP-CLI) albo poproś hosting o zwiększenie limitów uploadu lub import „z serwera” (upload do katalogu tmp).

Gdy import się nie powodzi, sprawdź błędy: przekroczony czas, ograniczenie rozmiaru, niezgodność wersji, brakujące tabele. W razie potrzeby rozbij plik .sql na mniejsze części lub wyeksportuj bazę z kompresją. Przed importem upewnij się, że baza jest pusta, aby uniknąć konfliktów prefiksów tabel (wp_ vs niestandardowe).

Konfiguracja połączenia: wp-config.php i klucze

Plik konfiguracyjny WordPress, czyli wp-config.php, przechowuje nazwę bazy, użytkownika, hasło i hosta. Zaktualizuj wartości DB_NAME, DB_USER, DB_PASSWORD, DB_HOST tak, by wskazywały na nową bazę. Skoryguj $table_prefix, jeśli w kopii był inny niż domyślny. Odśwież klucze i soly uwierzytelniania (AUTH_KEY itd.) korzystając z generatora WordPress. W razie problemów włącz debugowanie (WP_DEBUG true) i logowanie do wp-content/debug.log.

Jeżeli przenosisz witrynę między różnymi środowiskami (np. z localhost na produkcję), zwróć uwagę na różnice w rozszerzeniach PHP i modułach serwera, które mogą wymagać modyfikacji konfiguracji (np. limity pamięci i czasu wykonania).

Aktualizacja adresów URL i ścieżek

Po imporcie baza wciąż może zawierać stare adresy domeny. Zaktualizuj wartości siteurl i home w tabeli wp_options (phpMyAdmin → Przeglądaj → edytuj). Następnie wykonaj bezpieczną zamianę adresów w całej bazie z zachowaniem serializacji. Najpewniejsze jest użycie WP-CLI (wp search-replace stara-domena.pl nowa-domena.pl) albo wtyczki Better Search Replace z opcją wykrywania danych serializowanych.

Sprawdź także osadzone media, linki w menu, widgety, shortcody, reguły wtyczek cache i mapy witryny. Po zmianie adresów wejdź w Ustawienia → Bezpośrednie odnośniki i zapisz je ponownie, aby wygenerować nowy plik .htaccess lub reguły Nginx.

Czynności wykończeniowe po odtworzeniu

Wyczyść pamięć podręczną (wtyczki cache, Varnish, CDN), odśwież miniatury (np. wtyczką Regenerate Thumbnails), sprawdź menu, widżety i role użytkowników. Przetestuj formularze kontaktowe i wysyłkę e‑mail (SMTP), płatności, logowanie, wyszukiwarkę oraz procesy CRON. Zaktualizuj mapy witryny i zgłoś je w Google Search Console. Jeśli zmieniła się domena, dodaj 301 z poprzedniej na nową i zaktualizuj integracje zewnętrzne (API, webhooki, klucze OAuth).

Naprawa typowych błędów po odtworzeniu

Biały ekran śmierci i błędy krytyczne

Biały ekran zwykle oznacza fatalny błąd PHP. Włącz WP_DEBUG i WP_DEBUG_LOG, sprawdź plik debug.log. Tymczasowo zmień nazwę katalogu wp-content/plugins, by zdezaktywować wszystkie wtyczki, a następnie przywracaj je pojedynczo, by znaleźć winowajcę. Zmień motyw na domyślny (np. Twenty Twenty‑Four), aby wykluczyć problem w motywie. Jeśli błąd pojawił się po imporcie bazy, sprawdź prefiks tabel i brakujące opcje.

500 Internal Server Error i problemy z .htaccess

Błąd 500 bywa efektem nieprawidłowych reguł .htaccess lub niezgodności wersji PHP. Utwórz bazowy .htaccess (zapisz bezpośrednie odnośniki) albo tymczasowo usuń obecny i pozwól WordPress wygenerować nowy. Podnieś limit pamięci (wp_memory_limit), sprawdź moduły PHP (mbstring, intl, imagick), przejrzyj logi serwera. Jeżeli witryna korzysta z Nginx, upewnij się, że reguły przepisywania (try_files) kierują żądania do index.php.

Problemy z logowaniem, ciasteczkami i pętlami przekierowań

Jeśli nie możesz się zalogować, wyczyść cache i ciasteczka, sprawdź, czy adresy siteurl/home są spójne z aktualnym protokołem (http/https) i domeną. Zaktualizuj klucze i sole w wp-config.php, aby unieważnić stare sesje. Wtyczki bezpieczeństwa mogą blokować dostęp po migracji – wyłącz je tymczasowo przez zmianę nazwy katalogu. Skontroluj ustawienia proxy/CDN, które mogą wymuszać inny protokół lub domenę.

Mieszana treść i certyfikaty HTTPS

Po przejściu na HTTPS często pojawia się mieszana treść (część zasobów po http). Zaktualizuj adresy w bazie i konfiguracjach, w razie potrzeby użyj wtyczki do przepinania adresów. Wymuś przekierowanie 301 na HTTPS i włącz HSTS. Przejrzyj zasoby w konsoli przeglądarki, aby znaleźć nieaktualne linki. Upewnij się, że certyfikat SSL jest poprawnie zainstalowany i odświeżony, a CDN dostarcza zasoby po HTTPS.

Specyfika Multisite, wielojęzyczności i niestandardowych integracji

W instalacjach Multisite sprawdź ustawienia sieci, mapowanie domen i pliki sunrise.php. Zaktualizuj tabelę wp_blogs oraz wp_site, a w przypadku subdomen – wildcard DNS. Dla witryn wielojęzycznych (WPML/Polylang) przetestuj struktury linków, tłumaczenia i synchronizację menu. Integracje (ERP, CRM, płatności) wymagają weryfikacji kluczy API, adresów webhooków i białych list IP po migracji.

Strategie backupu i testowania na przyszłość

Zasada 3‑2‑1 i retencja danych

Trzy kopie, na dwóch różnych nośnikach, jedna poza siedzibą – to fundament odporności. Przechowuj kopie w chmurze (S3/Backblaze) i lokalnie, z szyfrowaniem. Ustal politykę retencji (np. 7 dziennych, 4 tygodniowe, 12 miesięcznych), aby móc cofnąć się do stanu sprzed cichej korupcji danych. Dokumentuj, gdzie znajdują się kopie i kto ma do nich dostęp.

Harmonogramy i zakres kopii

Dobierz częstotliwość do dynamiki serwisu: blog – co noc, e‑commerce – częściej, z kopiami bazy nawet co godzinę. Rób pełną kopię cyklicznie i przyrostowe między nimi, aby oszczędzić transfer. Wyklucz z kopii katalogi cache i pliki tymczasowe, by skrócić czas odtwarzania. Przed każdą aktualizacją motywu, wtyczek i rdzenia wykonuj świeżą kopię.

Testy odtworzeniowe i runbook

Regularnie sprawdzaj, czy potrafisz odtworzyć stronę na stagingu: zmierz czas RTO (Recovery Time Objective) i weryfikuj RPO (Recovery Point Objective). Prowadź runbook: lista kroków, dostępy, scenariusze problemów i kontakty do osób odpowiedzialnych. Aktualizuj dokumentację po każdym ćwiczeniu i incydencie, aby przyszłe odtwarzanie było szybsze i mniej stresujące.

Automatyzacja i monitorowanie

Zautomatyzuj kopie i odtwarzanie: skrypty do eksportu bazy, synchronizacji uploadów i weryfikacji integralności, zadania cron oraz powiadomienia o nieudanych zadaniach. Przechowuj kod motywów potomnych i wtyczek niestandardowych w systemie kontroli wersji. Monitoruj dostępność, błędy 5xx i czas odpowiedzi; szybkie wykrycie problemu skraca czas niedostępności i ogranicza straty.

Na koniec wdrożenia przywracania sprawdź SEO (mapa witryny, robots.txt, przekierowania), analitykę (tagi śledzące), bezpieczeństwo (firewall aplikacyjny, nagłówki) oraz wydajność (cache, optymalizacja obrazów). Oznacz moment odtworzenia w narzędziach analitycznych, by móc później skorelować zmiany ruchu z operacją techniczną.