Awaria strony rzadko czeka na dogodny moment. Wtyczka po aktualizacji wyświetla biały ekran, sklep przestaje przyjmować zamówienia albo ktoś przypadkiem usuwa ważne pliki. W takiej sytuacji pytanie, jak odzyskać stronę z backupu, nie jest teoretyczne. Liczy się szybkie działanie, ale bez pochopnego nadpisania danych, których jeszcze możesz potrzebować.
Backup nie jest magicznym przyciskiem cofania czasu. To zapis stanu strony z konkretnego dnia i godziny. Jeśli przywrócisz kopię sprzed trzech dni, odzyskasz witrynę z tamtego momentu, ale możesz stracić zamówienia, formularze kontaktowe lub wpisy dodane później. Dlatego najpierw ustal zakres problemu, a dopiero potem wybierz kopię.
Zanim przywrócisz backup, zabezpiecz obecny stan
Nawet uszkodzona strona może zawierać nowsze dane niż backup. Zrób więc dodatkową kopię tego, co jest teraz - plików oraz bazy danych. Nie zakładaj, że bieżąca wersja nie ma żadnej wartości tylko dlatego, że nie działa poprawnie.
Jeżeli problem dotyczy wyłącznie wyglądu strony po aktualizacji motywu, pełne odtworzenie całego konta może być przesadą. Wystarczy czasem przywrócić jeden katalog z motywem lub wyłączyć wadliwą wtyczkę. Z kolei po infekcji, masowym usunięciu plików albo błędnym imporcie bazy danych częściowa naprawa bywa ryzykowna. Wtedy bezpieczniej odtworzyć kompletną, sprawdzoną kopię.
Przed rozpoczęciem zapisz sobie cztery rzeczy:
- kiedy strona działała ostatni raz bez błędów,
- co zmieniło się tuż przed awarią,
- czy od tego czasu pojawiły się nowe zamówienia, konta użytkowników lub zgłoszenia,
- czy problem dotyczy całej strony, tylko panelu administracyjnego czy pojedynczej funkcji.
Te informacje pozwalają wybrać właściwy punkt przywracania, zamiast odtwarzać przypadkową wersję tylko dlatego, że jest najstarsza lub pierwsza na liście.
Jak odzyskać stronę z backupu krok po kroku
Najwygodniejsza metoda zależy od tego, jak hosting przechowuje kopie. W panelu hostingu możesz znaleźć gotowe punkty przywracania dla całego konta, plików, bazy danych albo pojedynczej domeny. W innych przypadkach masz archiwum pobrane na komputer lub backup wykonany przez wtyczkę CMS.
1. Wybierz punkt przywracania, nie tylko datę
Szukaj kopii wykonanej bezpośrednio przed problemem. Jeśli awaria zaczęła się dziś po aktualizacji o 11:00, backup z dzisiejszego poranka będzie zwykle lepszy niż kopia sprzed tygodnia. Im świeższa poprawna wersja, tym mniej danych trzeba będzie później odtworzyć ręcznie.
Nie kieruj się wyłącznie nazwą pliku. Sprawdź datę, godzinę oraz zawartość backupu. Pełna kopia strony WordPress powinna obejmować zarówno pliki, jak i bazę danych. Same pliki nie przywrócą wpisów, ustawień, produktów i użytkowników. Sama baza nie przywróci motywu, wtyczek ani przesłanych zdjęć.
2. Przywróć pliki strony
Pliki mogą znajdować się w katalogu głównym domeny, często nazwanym public_html, httpdocs lub podobnie. Przy odtwarzaniu z panelu hostingowego wybierz konkretną domenę i zakres operacji, jeśli system daje taki wybór. Gdy przywracasz archiwum ręcznie, najpierw rozpakuj je lokalnie i upewnij się, że struktura katalogów jest prawidłowa.
Częsty błąd polega na wgraniu folderu nadrzędnego do katalogu domeny. Efekt? Adres strony wyświetla listę plików, błąd 404 albo przekierowanie do podkatalogu. W katalogu docelowym powinny znaleźć się bezpośrednio pliki instalacji, takie jak index.php, wp-admin i wp-content, a nie dodatkowy folder zawierający te elementy.
Jeśli masz dostęp SSH, kopiowanie większych archiwów może być szybsze i stabilniejsze niż FTP. Nie zmieniaj jednak poleceń na produkcyjnym koncie metodą prób i błędów. Jedna komenda usuwająca zawartość złego katalogu potrafi zamienić prostą naprawę w pełne odtwarzanie.
3. Odtwórz bazę danych i sprawdź konfigurację
Baza danych zawiera treść i ustawienia CMS. Przy imporcie wybierz właściwą bazę, a przed nadpisaniem wykonaj jej eksport. Jeśli odtwarzasz backup ręcznie, zaimportuj plik SQL przez narzędzie do zarządzania bazą lub z poziomu konsoli, zależnie od dostępu na hostingu.
Po imporcie sprawdź dane połączenia w pliku konfiguracyjnym strony. W WordPressie są one zapisane w wp-config.php. Nazwa bazy, użytkownik, hasło i host muszą zgadzać się z aktualnym środowiskiem. Gdy pliki pochodzą z innego hostingu albo starszej instalacji, te wartości często są nieaktualne.
Jeżeli domena lub adres strony zmieniły się od czasu wykonania kopii, konieczna może być również korekta adresów zapisanych w bazie. W przypadku WordPressa zwykłe zastąpienie tekstu w bazie może uszkodzić dane serializowane. Tu lepiej użyć narzędzia dostosowanego do CMS albo poprosić o wsparcie techniczne, zamiast edytować rekordy na ślepo.
4. Nie nadpisuj nowych danych bez planu
Dla sklepu internetowego pełne odtworzenie bazy jest szczególnie wrażliwe. Backup z wczoraj może przywrócić produkty i konfigurację, ale usunie też zamówienia z dzisiaj. Najpierw wyeksportuj nowe zamówienia, dane klientów lub zgłoszenia. Potem zdecyduj, czy można je zaimportować ponownie, czy trzeba odtworzyć je ręcznie.
To właśnie tutaj widać różnicę między kopią zapasową a strategią odzyskiwania. Codzienny backup chroni stronę, ale nie zwalnia z myślenia o danych, które powstały między wykonaniem kopii a awarią.
Testuj stronę, zanim ogłosisz sukces
Widok strony głównej nie wystarcza. Po przywróceniu otwórz kilka podstron, zaloguj się do panelu, sprawdź formularz kontaktowy, wysyłkę e-maili i wersję mobilną. W sklepie przejdź przez koszyk oraz proces złożenia testowego zamówienia, bez obciążania prawdziwych klientów.
Warto też sprawdzić, czy certyfikat SSL działa poprawnie i czy strona nie ładuje części zasobów przez niezabezpieczone połączenie. Jeżeli po odtworzeniu widzisz starą wersję strony mimo poprawnych plików, wyczyść cache przeglądarki, cache CMS, Redis oraz cache po stronie hostingu, jeśli są używane.
Po udanym przywróceniu od razu wykonaj nowy backup. Masz wtedy punkt odniesienia dla działającej wersji po naprawie, a nie tylko kopię sprzed incydentu.
Najczęstsze błędy przy odzyskiwaniu strony
Najgroźniejszy jest pośpiech połączony z brakiem kopii bieżącego stanu. Drugim częstym problemem jest odtworzenie samych plików bez bazy danych albo odwrotnie. Strona może wtedy wyświetlać się częściowo, ale panel administracyjny zgłasza błędy, brakuje mediów lub nie działają logowania.
Kłopot sprawia również mylenie backupu hostingu z kopią wykonaną przez wtyczkę. Wtyczka może zapisywać archiwum w zewnętrznej lokalizacji, na tym samym koncie albo w katalogu, który został usunięty wraz z awarią. Zawsze sprawdź, gdzie fizycznie znajduje się kopia i czy da się ją pobrać przed rozpoczęciem operacji.
Nie ignoruj też przyczyny awarii. Jeśli strona padła po aktualizacji wtyczki, samo przywrócenie backupu rozwiąże objaw, ale kolejna automatyczna aktualizacja może powtórzyć problem. Jeśli przyczyną była infekcja, odzyskaj kopię sprzed infekcji, zmień hasła, zaktualizuj komponenty i sprawdź konta użytkowników.
Backup ma działać wtedy, gdy go potrzebujesz
Dobra usługa hostingowa powinna jasno pokazywać, jak długo przechowuje kopie, co obejmują i jak wygląda przywracanie. Bez drobnego druku, bez dopłat ujawnianych dopiero podczas awarii. W IQHost.pl backupy są przechowywane przez 30 dni, co daje realny margines na wykrycie błędu i wybór właściwej wersji strony.
Własna kopia poza hostingiem nadal jest rozsądnym zabezpieczeniem, zwłaszcza dla sklepu, strony firmowej generującej zapytania i projektu rozwijanego przez kilka osób. Najlepszy backup to ten, który masz pod ręką, rozumiesz jego zawartość i potrafisz odtworzyć bez zgadywania.
Gdy strona znów działa, nie odkładaj porządków na później. Ustal prosty rytm: regularne kopie, aktualizacje wykonywane po wcześniejszym backupie i krótki test odtwarzania raz na jakiś czas. Awaria wtedy nadal będzie irytująca, ale nie będzie oznaczała utraty kontroli nad Twoją stroną.
