Kopia zapasowa sklepu internetowego: RPO, RTO i test odtworzenia

Ten tekst ma nauczyć Cię dwóch liczb: RPO i RTO. Po ich ustaleniu rozmowa o kopiach przestaje być rozmową techniczną i staje się rozmową o zamówieniach. Bo przywracanie kopii w sklepie internetowym jest decyzją biznesową. Każda taka decyzja ma cenę wyrażoną w zamówieniach, których po przywróceniu po prostu nie będzie.

Dlaczego w sklepie kopia jest trudniejsza niż na zwykłej stronie

Strona firmowa zmienia się raz na kilka tygodni. Kopia sprzed doby jest praktycznie identyczna z wersją produkcyjną, więc jej przywrócenie niczego nie kosztuje. W sklepie internetowym dane zmieniają się co minutę i to jest cała różnica.

Wyobraź sobie, że przywracasz kopię sprzed 24 godzin. Razem z działającym sklepem cofasz też bazę danych, a w niej: zamówienia złożone przez ostatnią dobę, statusy płatności, stany magazynowe, nowe konta klientów, kody rabatowe, które ktoś już wykorzystał, oraz zwroty i reklamacje zgłoszone przez formularz. Zamówienia znikają, ale pieniądze za nie zostają. Klient ma potwierdzenie z bramki płatniczej, a w Twoim sklepie po przywróceniu nie ma jego zamówienia. Operator płatności widzi transakcję, magazyn nie widzi nic, a klient za trzy dni pyta, gdzie jest paczka.

To jest sedno całego tematu. W sklepie przywrócenie kopii nie jest powrotem do normalności. Jest wymianą jednego problemu na drugi, tańszy albo droższy. Zanim więc zaczniesz rozmawiać o częstotliwości kopii, musisz wiedzieć, ile ten drugi problem u Ciebie kosztuje.

RPO i RTO, czyli dwie liczby po ludzku

RPO (Recovery Point Objective) to odpowiedź na pytanie: ile danych możesz stracić. Inaczej mówiąc, jak stara może być najnowsza kopia w momencie awarii. Jeżeli kopia robi się raz na dobę o trzeciej w nocy, a awaria zdarza się o osiemnastej, Twoje realne RPO wynosi piętnaście godzin. Tyle zamówień jest do ręcznego odtworzenia.

RTO (Recovery Time Objective) to odpowiedź na pytanie: ile czasu możesz być offline, licząc od momentu awarii do momentu, w którym sklep znów przyjmuje zamówienia. To nie jest czas kopiowania plików. To jest czas diagnozy, decyzji, odtworzenia, sprawdzenia i przełączenia ruchu.

Obie liczby ustalasz z jednej danej, którą już masz: liczby zamówień na godzinę w typowym dniu. Weź zamówienia z ostatnich 30 dni, podziel przez liczbę godzin, w których realnie sprzedajesz. Sklep robiący 200 zamówień dziennie w oknie od 8 do 22 ma około 14 zamówień na godzinę. Przy średniej wartości koszyka 180 zł każda godzina cofnięcia to około 2 500 zł obrotu i 14 zamówień do ręcznego przepisania. Przy RPO 24 godzin mówimy o 336 zamówieniach. Nikt tego nie przepisze w jeden dzień.

Teraz odwróć rachunek. Jeżeli Twój zespół jest w stanie ręcznie obsłużyć 20 zamówień odzyskanych z bramki płatniczej i z poczty, Twoje RPO powinno wynosić mniej więcej godzinę, a nie dobę. Jeżeli szczyt sprzedaży przypada na listopad, policz to dla listopada, nie dla lipca. RPO i RTO nie są stałe przez cały rok i najuczciwiej jest mieć dwie wartości: zwykłą i sezonową.

Co musi obejmować kopia, bo kopia samych plików jest bezużyteczna

Najczęstszy błąd polega na tym, że ktoś kopiuje katalog sklepu i uznaje temat za zamknięty. Kompletna kopia sklepu to pięć elementów:

• baza danych, czyli zamówienia, klienci, produkty, ceny, konfiguracja modułów,
• pliki aplikacji: motyw, moduły i wtyczki, biblioteki, zdjęcia produktów i załączniki,
• konfiguracja serwera i usług: wersja PHP, reguły przepisywania adresów, cron, kolejki, certyfikat, konfiguracja cache i wyszukiwarki,
• klucze i zmienne środowiskowe: dane dostępowe do bazy, sole i klucze szyfrujące, tokeny API,
• dokumentacja tego, czego w sklepie w ogóle nie ma.

Ten ostatni punkt bywa pomijany, a potrafi wydłużyć odtworzenie o kilka godzin. Chodzi o ustawienia po stronie usług zewnętrznych: konfiguracja bramki płatniczej i adresy powiadomień zwrotnych, integracja z systemem magazynowym albo ERP, ustawienia przewoźników i punktów odbioru, konta w porównywarkach, piksele i tagi marketingowe, rekordy DNS. Tego nie ma w bazie sklepu i żadna kopia hostingu tego nie obejmie. Wystarczy prosty dokument z listą usług, adresami paneli i osobami, które mają tam dostęp.

W WooCommerce dochodzi jeszcze jedna rzecz: jeżeli sklep korzysta z HPOS, czyli nowego sposobu przechowywania zamówień, kopia musi być spójna z wersją wtyczek, bo częściowe odtworzenie potrafi rozjechać tabele zamówień. W PrestaShop najczęstszym problemem przy odtwarzaniu jest komplet płatnych modułów razem z licencjami, których po przenosinach trzeba czasem aktywować ręcznie.

Zasada 3-2-1 w wersji dla sklepu

Reguła jest prosta: trzy kopie danych, na dwóch różnych nośnikach albo w dwóch różnych lokalizacjach, z czego jedna poza infrastrukturą dostawcy hostingu.

Punkt trzeci jest tym, o który zwykle toczy się spór. Kopia leżąca w katalogu obok sklepu, na tym samym serwerze i tym samym koncie, chroni Cię wyłącznie przed jednym scenariuszem: przed Twoim własnym błędem w treści albo w konfiguracji. Nie chroni przed awarią dysku, przed zablokowaniem konta, przed usunięciem serwera, przed pomyłką po stronie dostawcy ani przed sytuacją, w której tracisz dostęp do panelu. Jeżeli pożar obejmuje cały budynek, kopia w sąsiednim pokoju spłonie razem z oryginałem.

Z tego samego powodu kopia dostępna z tego samego konta co sklep może zostać zaszyfrowana razem z nim w razie ataku ransomware, więc przynajmniej jedna kopia powinna być niezmienna albo leżeć poza tym kontem, z osobnym uwierzytelnianiem.

Test odtworzenia, czyli jedyna różnica między kopią a założeniem

Test odtworzenia jest jedyną czynnością, która zamienia założenie w fakt. Wygląda tak:

1. Odtwarzasz kopię na osobnym środowisku, nigdy na produkcji.
2. Sprawdzasz, czy sklep w ogóle się uruchamia: strona główna, kategoria, karta produktu, logowanie do panelu.
3. Przechodzisz pełną ścieżkę zakupu do potwierdzenia zamówienia, z płatnością w trybie testowym.
4. Porównujesz liczby: ile jest zamówień, ile produktów, ile klientów, czy ostatnie zamówienie ma datę zgodną z datą kopii.
5. Mierzysz czas od startu do momentu, w którym sklep byłby gotowy przyjąć ruch. Ta liczba to Twoje realne RTO, a nie to, które ktoś wpisał do oferty.

Jeżeli test wypadnie gorzej, niż zakładałeś, masz dwie drogi: skrócić RPO (częstsze kopie) albo skrócić RTO (przygotowane środowisko zapasowe i spisana procedura). Obie kosztują, ale znasz już cenę alternatywy w zamówieniach.

U nas kopie zapasowe robione są co 7 dni w pakiecie podstawowym, a test odtworzenia wykonujemy raz na kwartał i zapisujemy jego wynik razem z czasem. Jeżeli Twoje wyliczone RPO wychodzi poniżej doby, pakiet podstawowy nie wystarczy i mówimy o tym wprost przed podpisaniem umowy.

Kiedy nie przywracać kopii

Przy awarii odruch jest jeden: przywrócić i mieć spokój. To jest zwykle zły odruch. Kolejność powinna być odwrotna: najpierw diagnoza, potem decyzja.

Policz to na przykładzie. Awaria trwa trzy godziny, najnowsza kopia ma trzy godziny. Przywrócenie oznacza, że sklep wraca, ale w bazie nie ma zamówień z tych trzech godzin. Przy 14 zamówieniach na godzinę to 42 pozycje do ręcznego przepisania z bramki płatniczej i z poczty, wraz ze stanami magazynowymi. Jeżeli awaria dotyczy jednego modułu, ta cena jest absurdalnie wysoka.

Alternatywy, które warto rozważyć przed przywróceniem:

• naprawa na miejscu: wyłączenie wadliwego modułu, cofnięcie jednej aktualizacji, poprawa konfiguracji,
• przywrócenie samych plików, bez bazy danych: działa, gdy problem jest w kodzie, a dane są nienaruszone, i nie kosztuje ani jednego zamówienia,
• tryb serwisowy z czytelną informacją dla klientów, przyjmowanie zamówień telefonicznie i mailowo, a naprawa w tle bez presji.

Kopię przywracamy wtedy, gdy dane są realnie uszkodzone albo gdy koszt dalszej diagnozy przekracza koszt utraconych godzin. Tę decyzję podejmuje właściciel sklepu, nie osoba techniczna, bo to właściciel wie, ile warte są te 42 zamówienia.

Lista kontrolna do obecnego dostawcy

Wyślij te pytania osobie, która dziś utrzymuje Twój sklep, i poproś o odpowiedź na piśmie:

1. Jak często robiona jest kopia i o której godzinie?
2. Gdzie fizycznie leży i czy jest to inna infrastruktura niż sam sklep?
3. Jak długo jest przechowywana i ile wersji wstecz mam do dyspozycji?
4. Kto ma do niej dostęp i czy ja mam do niej dostęp bez pośrednika?
5. Kiedy ostatnio została odtworzona, na jakim środowisku i ile to trwało?
6. Czy kopia obejmuje bazę danych, czy tylko pliki?
7. Czy to kopia hostingu, a jeżeli tak, to czyją jest własnością i czy dostanę ją po zakończeniu współpracy?
8. Czy w umowie jest zapis o zwrocie albo usunięciu danych po rozwiązaniu umowy?

Brak odpowiedzi na pytanie piąte jest najważniejszym sygnałem z tej listy. Pytanie siódme bywa niewygodne: kopia hostingu należy do hostingu, jest robiona na jego warunkach i nie zawsze jest dostępna na żądanie w formacie, który da się gdziekolwiek wgrać.

Co jest u nas w usłudze i co kosztuje osobno

Kopie zapasowe i kwartalny test odtworzenia są częścią nadzoru nad dostępnością, który zaczyna się od 890 zł netto miesięcznie za poziom podstawowy. W tej samej usłudze mieści się sprawdzanie sklepu co 60 sekund, weryfikacja alertu przez człowieka do 15 minut i notatka poawaryjna po zdarzeniu.

Sama praca nad przywróceniem sklepu wykonana poza oknem usługi jest rozliczana według stawek interwencyjnych: w dni robocze od 8 do 18 jest to 150 zł za godzinę, wieczorami i w soboty 225 zł za godzinę, w niedziele i święta 300 zł za godzinę. Mówimy o tym otwarcie, bo to jest pozycja, która zaskakuje ludzi najczęściej, i bo różnica między nocnym a dziennym przywróceniem jest jednym z argumentów za tym, żeby RPO i RTO ustalić wcześniej, na spokojnie.

Umów przegląd stanu kopii zapasowych Twojego sklepu. Sprawdzimy, co realnie jest kopiowane, odtworzymy kopię na osobnym środowisku i zmierzymy, ile to trwa, a na tej podstawie ustalimy RPO i RTO dla Twojego sklepu. Szczegóły i formularz: /pl/sla-help-desk.