Backup WordPressa powinien obejmować jednocześnie pliki strony i bazę danych MySQL. Restore tylko jednego z tych elementów często kończy się brakiem treści, błędami wtyczek albo nieprawidłowymi ustawieniami. Przed nadpisaniem działającej lub uszkodzonej witryny zawsze wykonaj kopię jej bieżącego stanu.
Backup i restore WordPressa – co trzeba odtworzyć?
Pliki zawierają kod WordPressa, motywy, wtyczki oraz multimedia, szczególnie katalog wp-content. Baza danych przechowuje wpisy, strony, ustawienia, użytkowników i konfigurację wielu rozszerzeń. Oba elementy muszą pochodzić z porównywalnego momentu.
Przywrócenie starej bazy przy pozostawieniu nowych plików lub odwrotnie może doprowadzić do niespójności. Dlatego pełny backup to nie samo archiwum plików ani sam eksport SQL, lecz komplet pozwalający odtworzyć witrynę w działającym stanie.
Jak wybrać metodę restore?
Najpierw sprawdź, czy możesz zalogować się do kokpitu WordPressa. Jeśli działa /wp-admin, wygodna będzie wtyczka. Przy awarii panelu lepiej zacząć od narzędzi hostingu. Ręczne odtwarzanie zostaw na sytuacje, w których nie masz działającego automatu albo potrzebujesz pełnej kontroli nad plikami i bazą.
| Metoda | Poziom trudności | Zastosowanie | Zalety |
|---|---|---|---|
| Wtyczka backupowa | Niski | Działający panel WordPress | Restore bezpośrednio z kokpitu i szybki wybór kopii |
| Panel hostingu | Niski lub średni | Awaria strony, niedostępny wp-admin | Systemowe odtworzenie plików i bazy bez ręcznego importu |
| FTP i phpMyAdmin | Wysoki | Brak automatycznego restore lub pełna kontrola | Możliwość osobnego odtworzenia plików i bazy |
Narzędzia hostingowe są zwykle najbezpieczniejsze podczas poważnej awarii, ponieważ pozwalają wybrać datę i przywrócić oba składniki w ramach jednej operacji. Przy migracji dużej witryny można użyć rozwiązania obsługującego transfer pliku w częściach, na przykład WP Staging Pro. Nie jest to jednak jedyna metoda, a wybór zależy od hostingu, rozmiaru strony i dostępnych kopii.
Przygotowanie do restore – lista kontrolna
Przed rozpoczęciem zapisz stan, do którego możesz wrócić, i upewnij się, że masz dostęp do wszystkich potrzebnych narzędzi:
- Panel hostingu oraz dane dostępu do FTP, SFTP lub menedżera plików.
- Dostęp do bazy danych przez phpMyAdmin albo inne narzędzie administracyjne.
- Pełny backup zawierający pliki strony i eksport bazy danych.
- Informację o dacie kopii oraz prefiksie tabel, który domyślnie ma postać
wp_, ale może być niestandardowy. - Sprawdzenie wersji PHP, MySQL lub MariaDB na środowisku docelowym.
Ostrzeżenie: zawsze wykonaj kopię bieżącego stanu, nawet jeśli strona nie działa. Przywrócenie starszego backupu może nadpisać nowe wpisy, zamówienia, formularze, konta użytkowników i zmiany w ustawieniach. Bez kopii aktualnego stanu cofnięcie operacji może być niemożliwe.
Jak wykonać restore WordPressa krok po kroku?
Restore przez wtyczkę
Ta metoda wymaga dostępu do kokpitu oraz wcześniej utworzonego backupu przechowywanego na serwerze lub w zewnętrznym miejscu. Nazwy przycisków zależą od wtyczki, ale przebieg zwykle wygląda podobnie:
- Zaloguj się do
/wp-admini otwórz ustawienia narzędzia backupowego. - Wybierz pełną kopię obejmującą pliki oraz bazę danych.
- Utwórz kopię bieżącego stanu, jeśli wtyczka na to pozwala.
- Uruchom restore i nie przerywaj procesu, nawet jeśli strona chwilowo przestanie odpowiadać.
- Zaloguj się ponownie i sprawdź działanie witryny, formularzy oraz najważniejszych podstron.
Jeżeli panel WordPressa zwraca błąd krytyczny, ta ścieżka może być niedostępna. Wtedy przejdź do panelu hostingu albo zastosuj restore ręczny.
Restore przez panel hostingu
W panelu znajdź sekcję Backup, Kopie zapasowe lub Backup Manager. Konkretne opcje różnią się między dostawcami, ale najważniejsze jest zaznaczenie obu komponentów.
- Zaloguj się do panelu hostingu i otwórz menedżer kopii.
- Wybierz datę sprzed wystąpienia problemu.
- Zaznacz przywrócenie plików strony oraz bazy MySQL.
- Uruchom operację i zaczekaj na jej pełne zakończenie.
- Wyczyść cache, zaloguj się do WordPressa i przetestuj witrynę.
Jeśli hosting pozwala przywrócić tylko wybrane elementy, nie wybieraj samej bazy albo samych plików bez wyraźnej przyczyny. Takie rozdzielenie ma sens głównie podczas świadomej diagnostyki, a nie przy standardowym odzyskiwaniu po awarii.
Restore ręczny przez FTP i phpMyAdmin
Ręczna metoda wymaga większej ostrożności. Potrzebujesz archiwum plików, eksportu SQL oraz danych dostępowych do bazy zapisanych w wp-config.php.
- Pobierz aktualne pliki strony i zachowaj je w osobnym katalogu lub archiwum.
- Przez FTP albo menedżer plików wgraj pliki z backupu do katalogu witryny.
- Utwórz nową bazę lub przygotuj obecną do importu, nie usuwając danych bez wykonania kopii.
- Otwórz phpMyAdmin i zaimportuj plik SQL z backupu.
- Sprawdź w
wp-config.phpwartościDB_NAME,DB_USER,DB_PASSWORDiDB_HOST. - Zweryfikuj adresy witryny, zaloguj się do panelu i przetestuj działanie strony.
Przy migracji na inną domenę trzeba sprawdzić wartości siteurl i home. W bazie mogą znajdować się także serializowane odwołania do starego adresu. Ich zamiana powinna być wykonana narzędziem świadomym struktury danych WordPressa, a nie prostą edycją przypadkowych fragmentów pliku SQL.
Co zrobić, gdy strona nie działa po restore?
Nieudane przywrócenie nie zawsze oznacza uszkodzony backup. Przyczyną może być różnica między środowiskiem źródłowym i docelowym, niepełny import albo pozostały cache. Sprawdź po kolei:
- Wersję PHP oraz kompatybilność WordPressa, motywu i wtyczek z serwerem.
- Logi PHP i serwera, szczególnie przy białym ekranie lub błędzie krytycznym.
- Połączenie z bazą oraz poprawność wartości w
wp-config.php. - Cache przeglądarki, wtyczki, serwera i CDN, który może podawać stare zasoby.
- Uprawnienia plików i katalogów, zwłaszcza
wp-contentoraz katalogów uploadów. - Formularze, wysyłkę wiadomości, logowanie i działanie REST API.
Przy dużych bazach import może zatrzymać się z powodu limitu max_allowed_packet albo krótkiego PHP Execution Timeout. W takiej sytuacji sprawdź limity hostingu i log procesu. Jeśli restore dotyczy dużej witryny, narzędzie działające przez SSH lub mechanizm transferu w częściach może być stabilniejsze niż import uruchamiany w przeglądarce.
Pętla przekierowań po zmianie domeny często wynika z pozostawienia starego adresu w ustawieniach WordPressa. Błąd REST API może z kolei wskazywać na niepoprawne reguły przepisywania adresów, konfigurację serwera lub aktywny cache. Po migracji na inną domenę odśwież także strukturę bezpośrednich odnośników przez zapisanie ustawień w sekcji Permalinks.
Przywrócenie backupu cofa witrynę do wybranego momentu, więc nowe dane mogą zostać nadpisane. Najbezpieczniej najpierw zabezpieczyć bieżący stan, wykonać restore plików i bazy, a następnie sprawdzić stronę przed przełączeniem DNS lub ponownym uruchomieniem cache.
Jeśli po imporcie baza jest uszkodzona, dane są niekompletne albo nie możesz ustalić przyczyny błędów serwera, wstrzymaj kolejne próby nadpisywania i skonsultuj proces z administratorem hostingu lub specjalistą WordPress.