Strona padła po aktualizacji wtyczki, pokazuje biały ekran, wyrzuca błąd krytyczny albo po włamaniu wygląda inaczej niż powinna? Najgorsze, co można teraz zrobić, to chaotycznie klikać „aktualizuj”, usuwać foldery na serwerze i instalować kolejne wtyczki ratunkowe. Przy awarii WordPressa liczy się kolejność: najpierw zabezpieczenie obecnego stanu, potem wybór właściwego backupu, dopiero na końcu przywracanie kopii zapasowej WordPress.
Dobra wiadomość: jeśli masz gotowy backup wykonany wcześniej przez wtyczkę, najczęściej nie trzeba odbudowywać strony od zera. Trzeba tylko wiedzieć, czy kokpit WordPressa jeszcze działa. Jeśli działa — idziesz przez panel i kreator przywracania. Jeśli nie działa — odtwarzasz dostęp awaryjnie przez serwer, pliki i bazę danych. Poniżej konkretna procedura, bez uczenia konfiguracji automatycznych backupów.
Pierwsza pomoc po awarii: jak przygotować się do przywrócenia WordPressa z kopii
Najpierw zatrzymaj działania, które mogą pogorszyć sytuację. Nie aktualizuj kolejnych wtyczek „na próbę”, nie usuwaj motywu aktywnego na stronie, nie nadpisuj bazy danych bez eksportu aktualnego stanu. Nawet uszkodzona witryna bywa przydatna: można z niej odzyskać ostatnie zamówienia, wpisy, formularze, pliki z katalogu uploads albo sprawdzić, co dokładnie wywołało awarię.
Pierwsza decyzja brzmi: czy przywracasz całą stronę, czy tylko jej część? Po nieudanej aktualizacji jednej wtyczki czasem wystarczy przywrócić folder plugins albo bazę danych sprzed kilkunastu minut. Po włamaniu zwykle bezpieczniej odtworzyć komplet: bazę, motywy, wtyczki i pliki przesłane przez użytkowników. Przy sklepie WooCommerce ostrożność jest większa, bo starsza baza może cofnąć zamówienia, konta klientów i stany magazynowe.
Zanim uruchomisz backup WordPress, sprawdź cztery rzeczy:
- Data backupu — wybierz kopię sprzed awarii, nie najnowszą kopię wykonaną już po problemie.
- Zakres backupu — potrzebujesz bazy danych oraz plików strony: wtyczek, motywów, uploadów i pozostałych plików z
wp-content. - Dostęp do hostingu — przygotuj login do panelu hostingu, SFTP/FTP, menedżera plików i phpMyAdmin albo innego narzędzia do bazy danych.
- Miejsce na serwerze — przywracanie wymaga wolnej przestrzeni na pliki archiwum, rozpakowane katalogi i bazę. Przy stronie ważącej 5 GB nie zakładaj, że 5 GB wolnego miejsca wystarczy; bezpieczniej mieć wyraźny zapas.
W UpdraftPlus bezpłatna wersja obejmuje bazę danych WordPressa oraz pliki w katalogu wp-content, czyli m.in. wtyczki, motywy i przesłane media. Pliki takie jak wp-config.php, ręczne modyfikacje rdzenia WordPressa i katalogi spoza typowej struktury strony należą już do obszarów obsługiwanych przez wersję Premium albo wymagają osobnego zabezpieczenia. To ważne, bo po czystej instalacji WordPressa trzeba poprawnie ustawić dane bazy w wp-config.php, zamiast zakładać, że backup zrobił wszystko za Ciebie.
Jeżeli widzisz biały ekran śmierci WordPress, zacznij od sprawdzenia skrzynki administratora strony. WordPress ma tryb Recovery Mode, który przy części błędów krytycznych wysyła link logowania awaryjnego. W tym trybie wadliwa wtyczka lub motyw mogą zostać wstrzymane tylko dla sesji administratora, dzięki czemu da się wejść do kokpitu i użyć wtyczki backupowej bez ruszania serwera. Taki link nie zawsze dochodzi, szczególnie gdy błąd blokuje wysyłkę e-maili albo wiadomość trafia do spamu, ale sprawdzenie skrzynki zajmuje minutę i potrafi oszczędzić godzinę pracy.
Przed właściwym odtwarzaniem zrób jeszcze kopię obecnego, uszkodzonego stanu:
- wyeksportuj bazę danych w phpMyAdmin,
- pobierz albo skopiuj katalog strony z serwera,
- nazwij kopię jasno, np.
awaria-przed-przywroceniem-2026-06-18, - nie trzymaj jej w tym samym katalogu, który zaraz będziesz nadpisywać.
To nie jest przesadna ostrożność. Jeśli backup okaże się starszy, niepełny albo uszkodzony, ta „brzydka” kopia awaryjna może uratować najnowsze zdjęcia, formularze kontaktowe, zamówienia lub wpisy dodane po dacie backupu.
Przywracanie strony jednym kliknięciem za pomocą wtyczki (instrukcja dla działającego kokpitu)
Jeśli kokpit działa, użyj tej ścieżki jako pierwszej. Jest najprostsza, najmniej ryzykowna i daje największą kontrolę nad tym, które elementy strony zostaną odtworzone. Poniższy schemat dotyczy przede wszystkim UpdraftPlus przywracanie strony, ale logika jest podobna w innych wtyczkach: znajdujesz istniejący backup, wybierasz zakres, uruchamiasz kreator i sprawdzasz efekt.
W UpdraftPlus przejdź do:
Kokpit WordPressa → Ustawienia → UpdraftPlus Backups
Następnie znajdź sekcję z istniejącymi kopiami. W dokumentacji UpdraftPlus jest ona opisywana jako Existing backups. Jeśli backup jest widoczny na liście, wybierz przy nim przycisk Restore. Jeśli kopii nie widać, masz trzy typowe wyjścia: ponownie przeskanować zdalne miejsce przechowywania, wgrać pliki przez Upload backup files albo przesłać je przez FTP/SFTP do katalogu /wp-content/updraft, a potem wykonać ponowne skanowanie lokalnego folderu.
Praktyczna kolejność wygląda tak:
- Zaloguj się do WordPressa jako administrator.
- Wejdź w Ustawienia → UpdraftPlus Backups.
- Przejdź do listy istniejących backupów.
- Przy właściwej dacie kliknij Restore.
- Zaznacz elementy do przywrócenia:
- Database — baza danych: wpisy, strony, ustawienia, użytkownicy, zamówienia, konfiguracja wtyczek;
- Plugins — pliki wtyczek;
- Themes — pliki motywów;
- Uploads — media, zdjęcia, dokumenty;
- Others — pozostałe pliki z
wp-content.
- Kliknij Restore i poczekaj, aż wtyczka pobierze oraz przygotuje pliki.
- Przeczytaj komunikaty ostrzegawcze przed ostatnim potwierdzeniem.
- Uruchom właściwe odtwarzanie.
- Po komunikacie sukcesu wróć do kokpitu i sprawdź stronę w nowej karcie.
Przy zwykłym odtwarzaniu tej samej strony pod tym samym adresem nie zaznaczaj opcji typu Search/Replace database, jeśli wtyczka ją pokazuje. Ta opcja służy do podmiany adresów w bazie przy migracji domeny lub lokalizacji. Gdy przywracasz stronę na tym samym URL-u, jej użycie jest zbędne i może wprowadzić chaos w linkach, ścieżkach i danych serializowanych. UpdraftPlus wprost wskazuje, że przy przywracaniu bazy w tej samej lokalizacji nie trzeba wybierać opcji Search/Replace.
Najważniejsza decyzja dotyczy bazy danych. Jeśli awaria wydarzyła się po aktualizacji wtyczki i od tego czasu nie pojawiły się nowe zamówienia, formularze ani wpisy — przywrócenie całej bazy jest rozsądne. Jeśli prowadzisz sklep i po dacie backupu wpadły zamówienia, pełne cofnięcie bazy je usunie. W takim przypadku lepiej najpierw przywrócić pliki wtyczek i motywu, a bazę ruszać dopiero po eksporcie aktualnych danych sprzedażowych lub konsultacji z administratorem.
Po zakończeniu procesu nie oceniaj sukcesu tylko po tym, że strona główna się ładuje. Sprawdź rzeczy, które najczęściej pękają po odtworzeniu:
- logowanie do
/wp-admin, - podstrony i wpisy, nie tylko stronę główną,
- formularz kontaktowy,
- koszyk i finalizację zamówienia w WooCommerce,
- obrazki w bibliotece mediów,
- linki bezpośrednie,
- wersję PHP ustawioną na hostingu,
- działanie cache po wyczyszczeniu pamięci podręcznej.
Jeśli po przywróceniu strona główna działa, ale podstrony zwracają 404, wejdź w Ustawienia → Bezpośrednie odnośniki i zapisz ustawienia bez zmian. To odświeża reguły permalinków. WordPress wskazuje reset permalinków jako standardową reakcję przy problemach z ładnymi adresami i błędami 404 po zmianach w strukturze strony.
Jeśli proces zatrzyma się w połowie, nie kasuj od razu backupu ani wtyczki. UpdraftPlus może pokazać na górze ekranu opcję wznowienia przywracania, gdy wykryje timeout albo przerwanie procesu. Jeżeli to nie pomoże, pliki backupu UpdraftPlus nadal mają użyteczną postać: archiwa ZIP dla plików i plik bazy danych SQL/GZ, więc można przejść do trybu awaryjnego.
Co zrobić, gdy panel WordPressa nie działa – jak awaryjnie wgrać backup na serwer
Gdy /wp-admin nie odpowiada, pokazuje błąd krytyczny albo wpada w pętlę przekierowań, nie próbuj na siłę instalować kolejnych wtyczek przez panel. Tu przechodzisz poziom niżej: hosting, pliki, baza danych. Nadal możesz wykonać jak przywrócić WordPress z wtyczki, ale najpierw trzeba stworzyć warunki, w których wtyczka w ogóle się uruchomi.
Najbezpieczniejsza procedura awaryjna dla UpdraftPlus wygląda tak:
- Zrób kopię uszkodzonej strony
W panelu hostingu albo przez SFTP skopiuj cały katalog strony, najczęściejpublic_html,www,htdocsalbo katalog przypisany do domeny. Nie usuwaj go. Zmień nazwę np. napublic_html_awaria_2026-06-18. - Wyeksportuj obecną bazę danych
Wejdź do phpMyAdmin, Adminer albo panelu baz danych hostingu i wykonaj eksport. Nawet jeśli baza jest częściowo uszkodzona, eksport daje możliwość odzyskania danych dodanych po backupie. - Przygotuj czystą instalację WordPressa
Zainstaluj świeżego WordPressa w katalogu domeny. Możesz użyć instalatora hostingu albo ręcznie wgrać pliki WordPressa. Użyj nowej, pustej bazy danych, jeśli hosting na to pozwala. To ogranicza ryzyko, że nieudane odtwarzanie nadpisze jedyną kopię starej bazy. - Zainstaluj tę samą wtyczkę backupową
Jeśli backup był wykonany w UpdraftPlus, instalujesz UpdraftPlus. Jeśli był wykonany w Duplicatorze, używasz Duplicatora. Backupów z różnych wtyczek nie traktuj jak uniwersalnych paczek — formaty i kreatory są inne. - Wgraj pliki backupu
W UpdraftPlus możesz użyć linku Upload backup files w sekcji istniejących kopii. Przy dużych plikach lepszy jest SFTP: wgraj paczki do/wp-content/updraft, potem w kokpicie UpdraftPlus wybierz ponowne skanowanie lokalnego folderu. Ten katalog jest domyślną lokalizacją, w której wtyczka szuka lokalnych backupów. - Uruchom przywracanie z poziomu świeżego kokpitu
Po wykryciu backupu kliknij Restore, zaznacz potrzebne komponenty i wykonaj odtwarzanie. Po przywróceniu bazy danych dane logowania zmienią się na te z odtworzonej strony, nie z tymczasowej świeżej instalacji.
Jeśli nawet świeża instalacja z wtyczką nie daje rady, przechodzisz na ręczne odtwarzanie. To już nie jest „jedno kliknięcie”, ale nadal da się to zrobić metodycznie.
Dla backupu UpdraftPlus pliki strony są archiwami ZIP, a baza danych zwykle występuje jako plik kończący się na db.gz. Dokumentacja UpdraftPlus opisuje ręczne odtwarzanie przez phpMyAdmin: importujesz plik bazy, a jeśli dana wersja phpMyAdmin oczekuje końcówki .sql.gz, zmieniasz końcówkę pliku z db.gz na db.sql.gz przed importem. Jeśli backup bazy jest zaszyfrowany i kończy się na .gz.crypt, potrzebujesz najpierw odszyfrowania — bez właściwego klucza sama paczka nie wystarczy.
Ręczne wgrywanie plików wykonaj tak:
- Pobierz wszystkie części backupu na komputer.
- Rozpakuj archiwa ZIP lokalnie.
- Połącz się z serwerem przez SFTP albo użyj menedżera plików hostingu.
- Wejdź do katalogu
wp-content. - Skopiuj rozpakowane foldery:
pluginsdowp-content/plugins,themesdowp-content/themes,uploadsdowp-content/uploads,- zawartość „others” do właściwego miejsca w
wp-content.
- Nie pomijaj kolejnych części archiwum. UpdraftPlus domyślnie dzieli duże dane na paczki po 400 MB, więc przy większej stronie możesz mieć np.
uploads.zip,uploads2.zip,uploads3.zip. Wszystkie części trzeba rozpakować i scalić na serwerze.
Przy Duplicatorze procedura wygląda inaczej. Typowy backup składa się z archiwum oraz instalatora. Po wgraniu ich na serwer uruchamia się kreator instalacji, który sprawdza paczkę, pyta o dane bazy i rozpakowuje archiwum. Duplicator opisuje przywracanie jako proces przez kreator „Restore Backup Installer”, z walidacją paczki i etapem ekstrakcji plików.
Granica bezpieczeństwa jest prosta: jeśli nie wiesz, która baza jest podpięta do strony, nie importuj niczego „na czuja”. Otwórz plik wp-config.php i sprawdź wartości:
DB_NAME— nazwa bazy,DB_USER— użytkownik bazy,DB_PASSWORD— hasło,DB_HOST— host bazy, częstolocalhost, ale nie zawsze.
Błąd w tych danych kończy się komunikatem o problemie z połączeniem z bazą. WordPress wskazuje nieprawidłowe dane w wp-config.php jako typową przyczynę błędu „Error establishing a database connection”.
Po awaryjnym przywróceniu wykonaj krótką kontrolę techniczną. Nie zostawiaj strony tylko dlatego, że „już się otwiera”. Usuń pliki instalatorów, jeżeli używałeś narzędzi typu Duplicator. Wyczyść cache wtyczki, cache hostingu i CDN. Zmień hasła administratorów, FTP/SFTP, bazy danych i panelu hostingu, jeśli przyczyną awarii było włamanie. Potem zaktualizuj tylko te elementy, które rozumiesz: najpierw rdzeń WordPressa, później wtyczki krytyczne, na końcu dodatki poboczne. Po każdej większej zmianie sprawdzaj stronę, zamiast odpalać wszystkie aktualizacje naraz.
FAQ: najczęstsze pytania o przywracanie WordPressa z backupu
Czy mogę przywrócić WordPressa bez dostępu do kokpitu?
Tak. Najpierw tworzysz świeżą instalację WordPressa, instalujesz tę samą wtyczkę backupową i wgrywasz paczki backupu. Jeśli to się nie uda, zostaje ręczne odtworzenie plików przez SFTP oraz import bazy danych przez phpMyAdmin.
Czy UpdraftPlus przywraca całą stronę za darmo?
W typowym scenariuszu odtwarza bazę danych oraz pliki z wp-content, czyli wtyczki, motywy, media i pozostałe pliki tego katalogu. Elementy spoza standardowej struktury, wp-config.php i modyfikacje rdzenia wymagają osobnego podejścia albo funkcji Premium.
Który backup wybrać po włamaniu?
Wybierz ostatnią kopię sprzed pierwszych objawów włamania. Jeśli nie znasz daty infekcji, samo przywrócenie backupu nie daje pewności oczyszczenia strony. Po odtworzeniu trzeba jeszcze zmienić hasła, usunąć podejrzane konta administratorów, sprawdzić pliki i zaktualizować podatne dodatki.
Czy przywrócenie backupu usunie nowe zamówienia i formularze?
Tak, jeśli przywracasz bazę danych sprzed ich złożenia. W sklepie internetowym przed odtworzeniem bazy wyeksportuj najnowsze zamówienia albo skonsultuj częściowe odzyskiwanie danych. Pliki można zwykle przywracać bez cofania zamówień, baza danych wymaga większej ostrożności.
Co zrobić, gdy backup jest większy niż limit uploadu w WordPressie?
Nie walcz z formularzem uploadu w kokpicie. Wgraj paczki przez SFTP do katalogu /wp-content/updraft, a potem użyj ponownego skanowania lokalnego folderu w UpdraftPlus. Przy bardzo dużych stronach sprawdź też wolne miejsce na hostingu i limity czasu wykonywania PHP.
Czy po przywróceniu trzeba aktualizować wtyczki od razu?
Nie wszystkie naraz. Najpierw upewnij się, że strona działa po odtworzeniu. Potem aktualizuj etapami: rdzeń, wtyczki bezpieczeństwa i płatności, motyw, reszta dodatków. Po każdej grupie sprawdź stronę. Masowa aktualizacja tuż po awarii utrudnia ustalenie, co ponownie zepsuło witrynę.
Od czego zacząć, gdy strona właśnie przestała działać?
Zacznij od kopii obecnego stanu i sprawdzenia, czy masz dostęp do kokpitu lub Recovery Mode. Jeśli panel działa, użyj kreatora wtyczki. Jeśli nie działa, przejdź przez hosting: kopia plików, eksport bazy, świeży WordPress, instalacja tej samej wtyczki i dopiero wtedy przywracanie kopii zapasowej WordPress.

