Backup i disaster recovery sklepu internetowego: plan na czarną godzinę

Backup to polisa na awarię, hack i nieudaną aktualizację, nie zbędny koszt
Zasada 3-2-1: trzy kopie, dwa nośniki, jedna poza serwerem sklepu
Bazę kopiuj częściej niż pliki, bo to w niej są zamówienia i klienci
Kopia bez przetestowanego odtworzenia to tylko nadzieja
RTO mówi jak szybko wrócisz online, RPO ile danych możesz stracić
[/dwb_keytakeaways]

Dlaczego backup sklepu to nie luksus

Backup brzmi nudno do dnia, w którym sklep przestaje działać. Wtedy nagle okazuje się, że to najtańsza polisa, jaką mogłeś mieć. W sklepie internetowym stawka jest wyższa niż w zwykłej stronie wizytówce, bo tracisz nie tylko treść, ale żywe zamówienia, dane klientów i pieniądze za każdą godzinę przestoju.

Powodów, dla których sklep nagle znika, jest kilka i wszystkie zdarzają się częściej, niż się wydaje. Nieudana aktualizacja wtyczki, która kładzie cały sklep. Awaria dysku na serwerze. Ransomware, który szyfruje pliki i żąda okupu. Włamanie przez nieaktualną dziurę w motywie. Zwykła ludzka pomyłka, gdy ktoś usunie nie ten plik albo wyczyści złą tabelę w bazie. W każdym z tych przypadków różnica między godziną przestoju a tygodniem chaosu to jakość Twojego backupu.

Najgorszy moment na odkrycie, że backup nie działa, to chwila po awarii. Dlatego traktuję kopie zapasowe jak pas bezpieczeństwa: zakładasz go zanim coś się stanie, nie po. Reszta tego tekstu to konkretny plan, który stosuję u klientów, żeby ten pas naprawdę trzymał.

Zasada 3-2-1 w praktyce sklepu

Zasada 3-2-1 to najprostszy sprawdzony przepis na backup, który przetrwa realną awarię. Brzmi tak: trzy kopie danych, na dwóch różnych nośnikach, z czego jedna leży poza siedzibą sklepu. To nie jest teoria z podręcznika, tylko reguła, która chroni Cię przed pojedynczym punktem awarii.

Przełóżmy to na język sklepu WooCommerce. Pierwsza kopia to Twój żywy sklep na serwerze, to oczywiste. Druga to kopia robiona automatycznie, na przykład przez wtyczkę, i wysyłana do niezależnej chmury. Trzecia to kopia trzymana jeszcze gdzie indziej, na przykład pobierana okresowo na dysk poza biurem albo do drugiego, osobnego konta w chmurze.

Najczęstszy błąd, jaki widzę, to trzymanie wszystkich kopii na tym samym serwerze, na którym stoi sklep. Wtedy awaria dysku albo ransomware zabiera oryginał i wszystkie kopie naraz. Zasada 3-2-1 istnieje właśnie po to, żeby żadne pojedyncze zdarzenie nie wymazało Ci całej historii sklepu.

Co dokładnie trzeba kopiować

Sklep WooCommerce składa się z dwóch światów, które trzeba kopiować osobno, bo zmieniają się w różnym tempie. Jeśli zrozumiesz tę różnicę, od razu wiesz, dlaczego bazę kopiuje się częściej niż pliki.

• Baza danych: tu żyje cała dynamiczna część sklepu, czyli zamówienia, klienci, produkty, stany magazynowe, ustawienia i treści. To serce sklepu i to ono zmienia się przy każdej transakcji.
• Pliki: motyw, wtyczki, rdzeń WordPress oraz katalog uploads ze zdjęciami produktów i fakturami. Te zmieniają się rzadko, głównie przy aktualizacjach i dodawaniu nowych zdjęć.

Z tego podziału wynika prosta strategia. Bazę danych kopiujesz często, nawet co godzinę w szczycie sprzedaży, bo każda kopia mniej to potencjalnie utracone zamówienia. Pliki kopiujesz rzadziej, bo wczorajszy motyw i wtyczki są praktycznie identyczne jak dzisiejsze. Wyjątkiem jest katalog uploads, który warto trzymać razem z plikami, bo gubienie zdjęć produktów boli.

Częstotliwość i okno na utratę danych

Częstotliwość backupu nie jest kwestią gustu, tylko prostej matematyki: ile zamówień jesteś w stanie stracić, gdyby sklep padł tuż przed kolejną kopią. Im więcej sprzedajesz, tym częściej musisz kopiować bazę. To wszystko.

Dla orientacji, tak rozkładam to u klientów w zależności od skali. Te wartości to punkt startowy, nie sztywna reguła, ale dobrze pokazują kierunek myślenia.

Osobny przypadek to chwila przed każdą aktualizacją wtyczki, motywu albo rdzenia WordPress. To statystycznie najczęstszy moment, w którym coś się sypie. Dlatego niezależnie od harmonogramu rób kopię tuż przed każdą większą zmianą. Płatny UpdraftPlus potrafi to robić automatycznie, ale nawet ręczne kliknięcie przed aktualizacją ratuje wiele nerwów.

UpdraftPlus krok po kroku

Na WordPress moim domyślnym wyborem do backupu jest UpdraftPlus, bo łączy prostotę z funkcjami, których naprawdę używasz. Darmowa wersja realizuje regułę kopii poza serwerem, a płatna dokłada to, co przydaje się w większym sklepie. Konfiguracja wygląda tak.

Kluczowy jest ten ostatni punkt: po pierwszej konfiguracji wejdź do swojej chmury i zobacz na własne oczy, że kopia tam jest i ma sensowny rozmiar. Backup, który teoretycznie się wykonuje, ale w praktyce nigdy nie dotarł do chmury z powodu błędu połączenia, to najgorszy rodzaj fałszywego poczucia bezpieczeństwa.

Test odtwarzania, czyli sedno sprawy

To jest część, którą pomija dziewięć osób na dziesięć, i to jest dokładnie ta część, która decyduje, czy przeżyjesz awarię. Kopia, której nigdy nie przywróciłeś, to nie backup, tylko nadzieja, że plik się nada. A nadzieja w dniu awarii jest bezwartościowa.

Test odtwarzania jest prosty: bierzesz swoją kopię i przywracasz ją w bezpiecznym miejscu, na przykład na lokalnym środowisku albo na osobnym subdomenie staging. Sprawdzasz, czy sklep się podnosi, czy zamówienia są na miejscu, czy zdjęcia się ładują i czy da się złożyć testowe zamówienie. Robisz to na spokojnie, bez presji, żeby w dniu prawdziwej awarii znać już całą procedurę.

1. Pobierz najnowszą kopię bazy i plików z miejsca docelowego.
2. Przywróć ją na środowisku testowym, lokalnie albo na osobnym staging.
3. Zaloguj się do panelu i sprawdź zamówienia, produkty oraz ustawienia płatności.
4. Otwórz kilka kart produktów i sprawdź, czy zdjęcia oraz ceny są poprawne.
5. Złóż testowe zamówienie, żeby potwierdzić, że sklep działa od początku do końca.
6. Zapisz, ile czasu zajęło pełne odtworzenie, bo to Twoje realne RTO.

Taki test rób przynajmniej raz na kwartał, a po każdej większej zmianie w sklepie częściej. Dzięki temu wiesz dwie rzeczy: że kopia jest dobra i ile naprawdę trwa powrót online. Ta druga liczba jest bezcenna, gdy klient pyta w panice, kiedy sklep wróci.

Plan na awarię i hack krok po kroku

Plan disaster recovery to po prostu spisana procedura, co robisz, gdy sklep padnie. Spokojna lista kroków zamienia panikę w wykonywanie punktów. Dwa scenariusze wyglądają nieco inaczej, bo przy włamaniu kolejność ma kluczowe znaczenie.

Zwykła awaria, na przykład nieudana aktualizacja albo padnięty dysk: cofasz się do ostatniej dobrej kopii. Przywracasz bazę i pliki, sprawdzasz zamówienia, robisz testowe zamówienie i wracasz online. Tu liczy się przede wszystkim szybkość, bo nie ma zagrożenia, że kopia jest zatruta.

Włamanie albo ransomware: tu nie wolno działać na ślepo, bo łatwo przywrócić zainfekowaną kopię i wpuścić atakującego ponownie. Najpierw ustal, kiedy nastąpiło włamanie, bo kopia z wczoraj może już zawierać tylne wejście. Dopiero kopia sprzed infekcji jest bezpieczna.

RTO i RPO prosto, bez żargonu

Te dwa skróty brzmią korporacyjnie, ale za nimi stoją dwa proste pytania, na które warto odpowiedzieć zanim coś się stanie. Razem opisują, czego oczekujesz od swojego backupu.

• RTO (Recovery Time Objective): jak szybko chcesz wrócić online po awarii. To Twój cel czasowy. Jeśli ustalisz RTO na cztery godziny, to znaczy, że cała procedura odtworzenia ma się zmieścić w tych czterech godzinach.
• RPO (Recovery Point Objective): ile danych możesz stracić, licząc wstecz od momentu awarii. RPO jedna godzina znaczy, że kopię robisz przynajmniej co godzinę, bo w najgorszym razie tracisz tylko ostatnią godzinę zamówień.

Te dwie liczby ustalasz przy biurku, na spokojnie, patrząc na swoją sprzedaż. Sklep z dwoma zamówieniami dziennie spokojnie zniesie RPO jednego dnia. Sklep robiący setki zamówień w szczycie potrzebuje RPO liczonego w godzinach albo minutach, bo każda stracona godzina to realne pieniądze. Gdy znasz swoje RTO i RPO, cała reszta planu, czyli częstotliwość kopii i wybór narzędzi, układa się sama.

Jeśli to wszystko brzmi jak dużo pracy do ogarnięcia, to dlatego, że dobry backup faktycznie wymaga raz porządnej konfiguracji. W DawidWeb robię to regularnie: zasada 3-2-1, automatyczne kopie poza serwerem, harmonogram pod realną sprzedaż, przetestowane odtwarzanie i spisany plan na awarię oraz hack. Strony i sklepy buduję od 1800 zł, mam za sobą ponad 120 projektów, a wycenę konkretnego wdrożenia, w tym audytu backupu istniejącego sklepu, dostajesz w 24 godziny.