Backup daje możliwość cofnięcia zmian, ale restore jest operacją równie ważną jak samo tworzenie kopii. Na prostej stronie firmowej pełne odtworzenie sprzed kilku godzin może być akceptowalne. Na WooCommerce ten sam ruch może skasować nowe zamówienia, płatności i konta klientów. Dlatego przed przywróceniem trzeba ustalić, co faktycznie uległo uszkodzeniu i jaki zakres danych należy cofnąć.
Szybka odpowiedź
Jeśli awaria dotyczy jednego pliku wtyczki, nie odtwarzaj automatycznie całej bazy. Jeśli baza została uszkodzona, sama kopia wp-content nie pomoże. Zrób kopię aktualnego, nawet zepsutego stanu, zapisz godzinę incydentu, wybierz właściwy punkt odtworzenia i najpierw — jeśli to możliwe — sprawdź backup w odseparowanym środowisku.
Pliki i baza to dwie różne części
Pliki zawierają rdzeń, wtyczki, motyw i media, a baza — treści, użytkowników, ustawienia i dane wielu rozszerzeń. Kompletny backup powinien obejmować oba elementy, ale restore nie musi zawsze obejmować oba. Precyzyjne odtworzenie minimalizuje utratę zmian wykonanych po dacie kopii.
Najpierw ustal punkt RPO
RPO mówi, ile danych możesz zaakceptować jako utracone. Jeśli backup jest z nocy, a sklep miał cały dzień sprzedaży, pełne cofnięcie bazy jest poważną decyzją biznesową. Czasem lepiej naprawić uszkodzenie ręcznie, odtworzyć wybrane tabele lub odzyskać pliki, zachowując aktualną bazę.
Kopia musi być sprawdzona
Plik ZIP istniejący na serwerze nie jest jeszcze gwarancją odtwarzalności. Weryfikuj sumy kontrolne, możliwość rozpakowania, integralność dumpa bazy i okresowo wykonuj próbne restore. Najgorszy moment na odkrycie, że backup jest pusty albo zaszyfrowany nieznanym kluczem, to dzień awarii.
Restore na osobnym środowisku
Jeśli masz czas i zasoby, odtwórz kopię najpierw na stagingu. Sprawdź stronę główną, wp-admin, media, formularze, logowanie i kluczowe funkcje. Przy incydencie bezpieczeństwa nie uruchamiaj zainfekowanej kopii publicznie; środowisko analityczne powinno być izolowane.
Po restore problem może wrócić
Jeżeli awarię spowodowała podatna wtyczka, błędna automatyczna aktualizacja lub zapełnienie dysku, samo cofnięcie strony nie usuwa źródła. Po przywróceniu wykonaj aktualizację, popraw konfigurację, zwolnij przestrzeń albo napraw proces, który doprowadził do incydentu.
Jak potwierdzić, że naprawa naprawdę działa?
Po restore porównaj datę i liczbę najnowszych rekordów z oczekiwanym punktem odtworzenia. Na sklepie sprawdź zamówienia i płatności z okresu tuż przed awarią; na stronie leadowej formularze; na portalu konta użytkowników. Następnie przetestuj logowanie, media, cron i wysyłkę e-maili. Odtworzona strona może wyglądać dobrze, ale mieć rozjechane zadania lub brak części plików.
Co obserwować po zmianie?
Zachowaj informację, z którego backupu wykonano restore, jaki miał hash/rozmiar oraz dlaczego został wybrany. Po incydencie od razu uruchom nową, świeżą kopię działającego stanu. Nie czekaj do kolejnej nocy, jeśli dopiero co przywróciłeś serwis po awarii i masz potwierdzenie, że działa poprawnie.
Kiedy przekazać temat dalej?
Eskaluj, gdy backup jest starszy niż dopuszczalna utrata danych, zawiera podejrzenie malware albo nie masz pewności, czy dump bazy jest spójny. W takim przypadku częściowe odzyskanie lub ręczne scalanie danych może być bezpieczniejsze niż pełny restore.
Praktyczny scenariusz diagnostyczny
Załóżmy, że po błędnej aktualizacji chcesz cofnąć stronę o godzinę. Jeśli od tego czasu w sklepie pojawiło się pięć zamówień, pełne przywrócenie bazy usunie je z aktualnego stanu. Dlatego przed restore wykonaj dodatkową kopię uszkodzonego, ale najnowszego środowiska i ustal, które dane trzeba zachować. Czasem wystarczy cofnąć pliki wtyczki, czasem potrzebny jest restore bazy, a czasem selektywne odtworzenie. Po operacji sprawdź wersję plików, bazę, logowanie, formularze, płatności i zadania cron. Backup nie jest przyciskiem „cofnij wszystko bez konsekwencji”. Dobra procedura uwzględnia RPO, czyli ile najnowszych danych można realnie stracić, oraz plan odzyskania danych powstałych między kopią a awarią.
Dodatkowa kontrola po naprawie
Przy krytycznych serwisach warto raz na jakiś czas wykonać próbne odtworzenie do osobnego środowiska. Taki test wykrywa problemy, których nie pokaże samo „backup zakończony sukcesem”: brak części uploadów, uszkodzone archiwum, złą wersję bazy albo brak procedury uruchomienia strony. Restore drill jest najlepszym sposobem, aby przed prawdziwą awarią sprawdzić, czy kopia jest rzeczywiście użyteczna.
Bezpieczna kolejność działań
- Zabezpiecz kopię aktualnego stanu i logi.
- Określ, czy problem dotyczy plików, bazy czy obu.
- Wybierz punkt odtworzenia i oceń utratę danych od tej chwili.
- Jeśli możliwe, przetestuj kopię na stagingu.
- Odtwórz minimalny potrzebny zakres.
- Napraw przyczynę awarii i sprawdź monitoring oraz kolejne backupy.
Czego nie robić
Nie nadpisuj produkcji pierwszą dostępną kopią tylko dlatego, że „jest backup”. Nie przywracaj starej bazy sklepu bez zabezpieczenia nowych zamówień. Nie kasuj również zepsutego stanu przed zapisaniem logów potrzebnych do analizy.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeśli trzeba szybko odtworzyć WordPressa, HeatLogic może dobrać zakres restore, zabezpieczyć nowe dane, przetestować kopię i usunąć przyczynę awarii po przywróceniu.
Najczęściej zadawane pytania
Czy backup plików wystarczy?
Nie dla pełnego WordPressa. Treści, użytkownicy i większość ustawień są w bazie danych.
Czy można przywrócić tylko jedną wtyczkę?
Tak, jeśli problem dotyczy wyłącznie jej plików i wiesz, że wersja jest zgodna z bazą.
Czy restore sklepu może usunąć zamówienia?
Tak. Pełne cofnięcie bazy do starszego punktu usuwa dane zapisane później, jeśli nie zostaną osobno zabezpieczone.
Jak sprawdzić, czy backup działa?
Najpewniej przez okresowe testowe odtworzenie i weryfikację integralności plików oraz bazy.