Strona firmowa po przywróceniu z wczorajszej kopii wygląda jak wczoraj i nikt nie zauważa różnicy - sklep po tym samym zabiegu ma dziurę w zamówieniach, które ktoś już opłacił. To jest cała różnica między backupem strony a backupem sklepu i dlatego kopia zapasowa sklepu WooCommerce wymaga innego podejścia niż kopia bloga czy wizytówki. Nie chodzi o to, czy robisz kopię. Chodzi o to, co w niej jest, sprzed której minuty pochodzi i czy ktoś kiedykolwiek próbował ją odtworzyć.
Podstawy - czym różni się kopia plików od kopii bazy, czemu kopia hostingu nie wystarcza i o co chodzi w zasadzie trzech kopii - opisałem w wpisie o kopii zapasowej WordPressa i nie będę ich tu powtarzał. Ten tekst zaczyna się tam, gdzie tamten kończy: w sklepie, w którym baza danych żyje własnym życiem, a każda godzina bez kopii to realne pieniądze.
Kopia zapasowa sklepu WooCommerce - baza, zamówienia, backup poza serwerem
W zwykłej stronie firmowej wartość siedzi w plikach: motyw, zdjęcia, teksty, których od miesięcy nikt nie ruszał. Baza danych zmienia się rzadko, więc kopia sprzed tygodnia jest praktycznie tak samo dobra jak kopia sprzed godziny.
W sklepie jest odwrotnie. Pliki są duże, ale nudne - zdjęcia produktów i wtyczki zmieniają się co kilka dni. Cała akcja dzieje się w bazie: nowe zamówienie, status zmieniony na opłacone, zdjęty stan magazynowy, wykorzystany kupon, nowe konto klienta, notatka obsługi. Baza sklepu zmienia się co minutę, a przy promocji co kilka sekund. Backup bazy danych WooCommerce to nie archiwum - to zdjęcie, które ma swoją godzinę i minutę.
Z tego wynika najważniejsza rzecz: odstęp między ostatnią kopią a awarią to dokładnie tyle zamówień, których po odtworzeniu w sklepie nie będzie. Jeśli kopia robi się raz na dobę o trzeciej w nocy, a serwer pada o siedemnastej, sklep po przywróceniu nie pamięta niczego z tego dnia. Klienci zapłacili, bramka ma pieniądze, kurier może już jechać - a w panelu zamówień ich nie ma. Zdjęte stany magazynowe wracają na półkę i sklep znowu sprzedaje towar, którego fizycznie nie ma.
Ten odstęp to decyzja biznesowa, nie techniczna. Dla sklepu z kilkoma zamówieniami tygodniowo doba jest w porządku, bo brakujące zamówienia da się odtworzyć ręcznie z maili. Dla sklepu, który sprzedaje bez przerwy, akceptowalny odstęp liczy się w godzinach albo minutach.
Druga rzecz specyficzna dla sklepu to spójność kopii. Zamówienie w WooCommerce nie leży w jednym miejscu: osobno samo zamówienie, osobno jego pozycje, osobno adresy i metadane, a przy nowszym magazynie zamówień, który opisałem przy przejściu na HPOS, sklep ma na to własny zestaw tabel. Jeśli kopia powstaje w trakcie ruchu i tabele zrzucane są jedna po drugiej, zamówienie może już być, a jego pozycji jeszcze nie. Dlatego pytam zawsze, czy kopia bazy robi się jako jedna spójna migawka z jednej chwili. Narzędzia do zrzutu bazy to potrafią, ale trzeba to włączyć świadomie.
Co pomaga: sprawdź godzinę powstania ostatniej kopii bazy, jaką masz, i policz w panelu, ile zamówień wpadło od tej godziny. Ta liczba to Twoja realna strata, gdyby sklep padł teraz. Jeśli robi wrażenie, kopie robią się za rzadko.
Jak często i gdzie
Skoro pliki i baza żyją w innym tempie, nie ma powodu kopiować ich w tym samym rytmie. Rozdzielam to na dwa strumienie.
Baza danych - często, dopasowane do tempa sprzedaży. W sklepach sprzedających codziennie ustawiam kopię bazy co kilka godzin, a w sezonie i podczas promocji częściej. Baza sklepu jest zwykle niewielka w porównaniu z folderem zdjęć, więc częste kopie nie zjadają miejsca ani zasobów. Przy większych sklepach idę krok dalej: baza z ciągłym zapisem zmian, który pozwala wrócić do dowolnej minuty, nie tylko do godziny kopii. Coraz więcej hostingów ma to w cenie.
Pliki - rzadziej, bo rzadziej się zmieniają. Pełna kopia raz na dobę w nocy wystarcza większości sklepów, a dodatkowo zawsze przed każdą zmianą w kodzie, motywie albo wtyczkach - ten sam nawyk, który rozpisałem w checkliście bezpiecznych aktualizacji WooCommerce. Zdjęcia produktów można kopiować przyrostowo, czyli tylko to, co doszło od ostatniego razu.
Teraz gdzie trzymać backup WooCommerce. Poza serwerem, na którym stoi sklep, i najlepiej u innego dostawcy niż hosting. Najgroźniejsze awarie - włamanie, zaszyfrowanie serwera, błąd hostingu, nieopłacona faktura za serwer - zabierają stronę i kopię naraz, jeśli leżą w tym samym miejscu. Kopia hostingu jest dobrym dodatkiem, nie jedynym miejscem.
Trzy pytania, które zadaję przy wyborze miejsca na kopie:
- Jak długo kopie są trzymane? Błędu w sklepie nie zawsze widać od razu. Cicha wtyczka psująca stany magazynowe albo włamanie, które przez tygodnie tylko podsłuchuje, wychodzą na jaw późno. Potrzebujesz kopii z różnych momentów: ostatnie dni gęsto, ostatnie tygodnie rzadziej, kilka kopii z ostatnich miesięcy.
- Kto ma do nich dostęp? W kopii bazy są dane osobowe klientów: imiona, adresy, telefony, historia zakupów. Kopia na otwartym dysku w chmurze albo wysyłana mailem to wyciek czekający na okazję. Kopie szyfruję i ograniczam dostęp do osób, które faktycznie przywracają sklep. Zastrzeżenie: piszę to jako praktyk od sklepów, nie prawnik - obowiązki wokół danych osobowych i umowy z dostawcą kopii potwierdź z kimś, kto zajmuje się RODO zawodowo.
- Czy da się przywrócić samą bazę? Przy awarii najczęściej trzeba cofnąć tylko bazę, zostawiając pliki w spokoju, albo odwrotnie. Rozwiązanie przywracające wyłącznie całość zmusza do cofnięcia zdjęć i wtyczek tylko po to, żeby odzyskać zamówienia.
Co pomaga: zrób prosty rozkład - baza co ile, pliki co ile, gdzie leżą, jak długo, kto ma hasło. Jeśli na którekolwiek pytanie odpowiedź brzmi „nie wiem”, to jest pierwsza rzecz do ustalenia, zanim cokolwiek się stanie.
Test odtworzenia - bez niego backup nie istnieje
To zdanie powtarzam przy każdej stronie, ale przy sklepie ma dodatkowe piętro. Przy wizytówce test odtworzenia to „czy strona się otwiera”. Przy sklepie odtworzona kopia potrafi narobić szkód, zanim w ogóle sprawdzisz, czy działa.
Odtwarzasz wczorajszą kopię pod adresem testowym. Kopia wstaje, a razem z nią wszystkie automaty: zaplanowane zadania, które widzą zamówienia bez wysłanego maila i wysyłają je klientom jeszcze raz, wtyczka kurierska zgłaszająca paczki po raz drugi, integracja z programem do faktur wystawiająca duplikaty, bramka płatności odpytywana o statusy. Klient dostaje drugi mail „Twoje zamówienie jest gotowe”, księgowa duplikaty faktur, a Ty dowiadujesz się po fakcie.
Dlatego test odtworzenia sklepu zaczyna się od odcięcia, a nie od sprawdzania. Zanim kopia wykona pierwsze zadanie w tle, robię trzy rzeczy:
- Odcinam pocztę wychodzącą. Kopia testowa nie może wysłać żadnego maila do klienta. Wysyłkę wyłączam albo przekierowuję wszystko na jedną skrzynkę testową.
- Odłączam integracje. Klucze do bramki płatności, kuriera, faktur, hurtowni ustawiam na puste albo na tryb testowy dostawcy. Integracja, która zostanie z kluczami produkcyjnymi, działa jak produkcja.
- Zatrzymuję zadania w tle i chowam kopię przed wyszukiwarką. Adres testowy zamykam hasłem, żeby Google nie zaindeksował drugiego sklepu z tymi samymi produktami.
Dopiero teraz zaczyna się właściwy test. Nie pytam „czy strona się otwiera”, tylko sprawdzam rzeczy, które mówią, czy kopia jest kompletna i aktualna:
- Ostatni numer zamówienia zgadza się z godziną kopii. Kopia z trzeciej w nocy ma mieć ostatnie zamówienie z poprzedniego wieczora, nie z zeszłego tygodnia.
- Liczba zamówień z ostatnich dni jest taka sama jak w sklepie produkcyjnym za ten sam okres. Rozjazd oznacza niekompletną kopię bazy.
- Stany magazynowe kilku losowych produktów zgadzają się z tym, co było o godzinie kopii.
- Konto klienta - loguję się na losowe konto i sprawdzam historię i adresy.
- Zdjęcia produktów ładują się, nie tylko tytuły. To wyłapuje kopię plików urwaną w połowie.
- Pełna ścieżka zakupu na bramce w trybie testowym: koszyk, dane, płatność, mail z potwierdzeniem na skrzynkę testową.
I rzecz, o której się zapomina: mierzę czas. Od „zaczynam odtwarzać” do „da się kupić”. To Twój realny czas powrotu po awarii i jedyny sposób, żeby go poznać, to zmierzyć go na spokojnie. Jeśli odtworzenie zajmuje pół dnia, bo kopia plików jest ogromna, lepiej wiedzieć o tym dziś.
Całą procedurę zapisuję w jednym dokumencie: gdzie leżą kopie, co odciąć, w jakiej kolejności przywracać, co sprawdzić. W dniu awarii nikt nie ma głowy, żeby to wymyślać.
Co pomaga: test odtworzenia wpisz do kalendarza jak przegląd auta - po każdej większej zmianie w sklepie i przynajmniej raz na kwartał. Kopia testowana pół roku temu, przy zmienionych wtyczkach i nowym magazynie zamówień, to znowu tylko nadzieja.
Co z zamówieniami, które wpadły po kopii
Nawet przy gęstych kopiach po awarii zostaje luka: zamówienia złożone między ostatnią kopią a padnięciem sklepu. W przywróconej bazie ich nie ma, ale wydarzyły się naprawdę i klienci czekają.
Sklep nie jest jedynym miejscem, które o nich wie. Bramka płatności ma listę transakcji z kwotami, godzinami i mailami klientów. Panel kuriera ma zgłoszone paczki. Program do faktur ma dokumenty. Skrzynka sklepu ma kopie potwierdzeń. To Twoje drugie źródła prawdy i po odtworzeniu kopii pierwsze, co robię, to zestawiam je z panelem zamówień: transakcja po transakcji od godziny kopii do godziny awarii, brakujące zamówienia odtwarzam ręcznie z tymi samymi pozycjami, kwotą i adresem. Przy kilku zamówieniach to kwadrans. Przy kilkuset to dzień pracy i dokładnie dlatego częstotliwość kopii bazy dobiera się do tempa sprzedaży, a nie do domyślnego ustawienia wtyczki.
W pakiecie idzie korekta magazynu. Po przywróceniu kopii stany cofnęły się razem z bazą, więc towar sprzedany po godzinie kopii w sklepie znowu jest „dostępny”. Jeśli nie poprawisz tego od razu, sklep sprzeda go drugi raz.
Kiedy zdjąć to z siebie
Da się to zrobić samemu i przy małym sklepie, który sprzedaje okazjonalnie, tak właśnie radzę: kopia bazy codziennie, pliki raz w tygodniu, miejsce poza serwerem, test odtworzenia raz na kwartał z checklistą wyżej. Tak wygląda sensowna kopia zapasowa sklepu internetowego, gdy dzień przestoju nie boli.
Granica przebiega tam, gdzie sklep zarabia na tyle, że dzień bez zamówień boli, a Ty nie masz czasu pamiętać o kopiach między obsługą klientów a towarem. W ramach stałego wsparcia i pomocy kopie bazy i plików robią się w rytmie dobranym do sklepu, leżą poza serwerem, a test odtworzenia robię ja i to ja dostaję alarm, kiedy kopia się nie wykonała. Przy awarii przywracam sklep według sprawdzonej procedury, a Ty dostajesz informację, że działa, i listę zamówień do uzupełnienia, jeśli jakaś luka została. Kopie to jeden z pięciu elementów opieki; pozostałe cztery opisałem w przewodniku opieka nad sklepem WooCommerce.
Najczęstsze pytania
Jak często robić kopię zapasową sklepu WooCommerce? Bazę tak często, jak często wpadają zamówienia, których nie chciałbyś odtwarzać ręcznie - w sklepach sprzedających codziennie co kilka godzin, przy dużym ruchu ciągły zapis zmian. Pliki raz na dobę plus zawsze przed zmianą w kodzie albo wtyczkach.
Czy wystarczy kopia, którą robi hosting? Jako dodatek tak, jako jedyne zabezpieczenie nie. Leży w tym samym miejscu co sklep, rzadko ma rytm dopasowany do sprzedaży i często przywraca całość zamiast samej bazy. Potrzebujesz przynajmniej jednej kopii poza serwerem, u innego dostawcy.
Co się stanie, jeśli odtworzę kopię sklepu bez odcięcia integracji? Odtworzona kopia zachowuje się jak żywy sklep: może wysłać klientom powtórzone maile, zgłosić paczki drugi raz albo wystawić duplikaty faktur. Przed testem odcinasz pocztę, wymieniasz klucze integracji na testowe i zatrzymujesz zadania w tle.
Jak sprawdzić, czy kopia zapasowa sklepu jest kompletna? Odtwórz ją pod adresem testowym i porównaj z produkcją: ostatni numer zamówienia, liczbę zamówień z ostatnich dni, stany magazynowe kilku produktów, logowanie na konto klienta i ładowanie zdjęć. Rozjazd w którymkolwiek punkcie oznacza, że kopia nie zawiera wszystkiego.
Nie chcesz pilnować tego co miesiąc samemu? Biorę strony i sklepy pod stałą opiekę - backupy, aktualizacje, monitoring i priorytet, kiedy coś padnie. Napisz, co masz pod sobą, a odeślę zakres i cenę.