O kopii sklepu można powiedzieć, że działa dopiero wtedy, gdy na odizolowanej kopii serwera da się uruchomić właściwe pliki, bazę oraz sprawdzić kilka kluczowych scenariuszy zamówienia. Sam plik ZIP albo zielony komunikat w panelu nie potwierdza, że odzyskasz aktualny katalog, ustawienia, zamówienia i konfigurację integracji. Dla sklepu WooCommerce pełny zestaw obejmuje co najmniej pliki oraz bazę; przed odtworzeniem trzeba też ustalić, jakie dane pojawiły się po dacie kopii.
Nie testuj tego przez przywrócenie archiwum na działającej sprzedaży. Bezpieczny test wykonuje się na osobnym adresie lub w odizolowanym środowisku, z wyłączoną wysyłką e-maili, płatnościami oraz komunikacją z zewnętrznymi systemami. Poniżej jest praktyczna lista kontroli, którą można zastosować niezależnie od dostawcy hostingu.
Co musi zawierać pełna kopia sklepu?
Typowa instalacja WordPressa trzyma kod, motyw, wtyczki i media w plikach serwera, a treści, ustawienia, produkty i zamówienia w bazie danych. Kopia samych plików nie zawiera bazy. Sam eksport bazy nie przywróci motywu, rozszerzeń ani przesłanych zdjęć. Zestaw trzeba traktować jako jedną parę, wykonaną możliwie blisko siebie.
| Element zestawu |
Co zwykle chroni |
Co sprawdzić |
| Baza danych |
Produkty, zamówienia, konta, wpisy, ustawienia i dane wtyczek |
Czy plik da się odczytać lub zaimportować oraz jaka jest jego data i zakres tabel |
| Pliki witryny |
Motyw, wtyczki, media, własny kod i konfigurację w katalogu strony |
Czy archiwum jest kompletne i czy ma odnotowaną wersję PHP oraz rozszerzeń |
| Dostępy i konfiguracja środowiska |
Połączenie z bazą, DNS, poczta, bramki płatności i integracje |
Czy test jest odcięty od produkcyjnych kluczy, wysyłki i zadań cyklicznych |
| Informacja o czasie wykonania |
Możliwość oceny luki między kopią a awarią |
Data, strefa czasowa, identyfikator kopii i wynik ostatniego testu |
WordPress opisuje pliki i bazę jako dwa odrębne składniki kopii w dokumentacji administracyjnej. W przypadku WooCommerce baza obejmuje również dane operacyjne sklepu, dlatego eksport treści WordPress XML nie jest zamiennikiem zrzutu bazy.
Najpierw odpowiedz: do jakiego momentu wrócimy?
RPO, czyli dopuszczalna luka danych, nie musi być osobnym projektem korporacyjnym. Wystarczy proste pytanie: ile ostatniej sprzedaży firma jest gotowa odtworzyć ręcznie, jeśli potrzebny będzie powrót do kopii? Dla sklepu z codziennymi zamówieniami odpowiedź „wczorajsza kopia” oznacza ryzyko utraty danych od jej wykonania do chwili awarii.
Warto sporządzić krótką tabelę źródeł prawdy: zamówienie w sklepie, płatność u operatora, wysyłka u przewoźnika, stan magazynowy w ERP oraz dokument sprzedaży. Dzięki temu w sytuacji awaryjnej nie zakładamy, że jedno przywrócenie bazy automatycznie uzgodni wszystkie systemy.
Przykład: kopia została wykonana o 02:00, a problem pojawia się o 15:00. Przed decyzją o odtworzeniu trzeba policzyć zamówienia, płatności i zmiany stanów z tych 13 godzin. Nie należy ponawiać ich automatycznie tylko dlatego, że nie występują w starszej bazie. Takie działanie może utworzyć duplikaty lub wysłać kolejne wiadomości.
Jak przeprowadzić test odtworzenia bez ryzyka dla klientów?
- Wybierz konkretną kopię i zapisz jej identyfikator. Test ma być powtarzalny: wiadomo, z którego dnia pochodzi archiwum oraz jakie pliki i bazę obejmuje.
- Utwórz izolowane środowisko. Nie może wysyłać produkcyjnej poczty, przyjmować płatności ani komunikować się z ERP, Allegro, kurierem czy drukarkami etykiet.
- Odtwórz pliki i bazę jako parę. Dopasuj konfigurację połączenia z bazą wyłącznie do testowego środowiska. Nie podmieniaj aktywnej produkcyjnej bazy pod pretekstem sprawdzenia kopii.
- Sprawdź funkcje krytyczne. Otwórz stronę główną, wybraną kategorię, kilka produktów, koszyk, panel administracyjny oraz odczyt zamówienia testowego już obecnego w kopii. Nie składaj prawdziwego zamówienia.
- Zapisz wynik i różnice. Data kopii, czas uruchomienia, lista sprawdzonych elementów oraz przeszkody są ważniejsze niż ogólne „backup OK”.
WooCommerce zaleca bieżącą kopię i testowanie zmian na środowisku stagingowym, a nie bezpośrednio na produkcji. Dokumentacja aktualizacji WooCommerce wymienia przy tym m.in. koszyk, płatności, wysyłkę i e-maile jako scenariusze wymagające kontroli. W teście odtworzenia e-maile i płatności pozostają zablokowane — sprawdzamy ich konfigurację, nie uruchamiamy ich.
Dlaczego starsza kopia może być niebezpieczna dla bieżących zamówień?
Przywrócenie całej bazy do dawnego stanu może cofnąć konta klientów, zamówienia, statusy płatności albo wykonane już odnowienia. Ryzyko rośnie, gdy sklep jest połączony z systemem magazynowym, księgowym lub kanałem marketplace. Producent dokumentacji WooCommerce zwraca uwagę na lukę danych powstałą między chwilą kopii a przywróceniem — w tym na brakujące zamówienia i dane klientów.
To nie znaczy, że odtworzenie jest niemożliwe. Oznacza, że najpierw trzeba oddzielić warstwę wymagającą naprawy od aktualnych danych sprzedażowych. Czasem właściwą drogą jest odzyskanie zaufanych plików przy zachowaniu bieżącej bazy. Innym razem potrzebne jest kontrolowane odtworzenie i uzgodnienie różnic. Wybór zależy od przyczyny awarii, zgodności wersji oraz danych z okresu luki.
Jeżeli sklep ma aktywne subskrypcje, importer, synchronizację stanów albo własne zadania kolejki, sprawdź również harmonogram i jego konsekwencje po uruchomieniu kopii. Przed testem należy je wstrzymać w środowisku testowym, a nie usuwać w produkcji.
Checklist odbioru kopii sklepu
- Archiwum plików i zrzut bazy mają znaną datę, są czytelne i należą do tego samego zestawu.
- Odtworzenie odbyło się na osobnym środowisku, bez dostępu do prawdziwych płatności i adresatów e-mail.
- Po uruchomieniu działają reprezentatywne strony, media, panel oraz odczyt istniejących danych sklepu.
- Zweryfikowano listę wtyczek i wersję PHP wymaganą przez odtworzoną instalację.
- Wiadomo, gdzie trzymane są kopie, kto ma do nich dostęp i jak długo są przechowywane.
- Jest zapisany kontakt oraz kolejność decyzji na wypadek awarii: diagnoza, zabezpieczenie bieżących danych, test, dopiero potem produkcja.
Test nie jest jednorazowym rytuałem. Powtórz go po istotnej zmianie hostingu, sposobu przechowywania zamówień, migracji platformy lub dołączeniu nowej integracji. Wtedy wykrycie brakującej tabeli, za dużego archiwum czy niezgodnej wersji PHP nie następuje dopiero w czasie awarii.
Jak Panther pomaga przygotować odzyskiwanie sklepu?
W Panther porządkujemy kopie, konfigurację środowiska i procedurę testu pod rzeczywisty przepływ danych klienta. Zakres może obejmować utworzenie odizolowanej kopii, weryfikację plików i bazy, kontrolę krytycznych widoków oraz opis różnic, które trzeba uzgodnić przed ewentualnym powrotem na produkcję. Nie uruchamiamy przy tym płatności, faktur, wiadomości ani zadań integracyjnych.
ZUT Uszczelnienia pokazuje, dlaczego przy sklepie technicznym trzeba patrzeć szerzej niż na sam front: katalog WooCommerce jest połączony z Comarch ERP Optima. Robiwood pokazuje dalszy przepływ od konfiguracji produktu do realizacji produkcyjnej. To przykłady złożonych zależności w sklepach, a nie deklaracja konkretnej procedury backupowej tych firm.
Jeśli chcesz sprawdzić gotowość swojego sklepu do odtworzenia, napisz do Panther, podając platformę, sposób wykonywania kopii i wykorzystywane integracje. Na tej podstawie możemy ustalić bezpieczny zakres testu oraz to, jakie dane wymagają szczególnej ochrony.
