Kopie zapasowe sklepu internetowego

Sklep działa, ale kopia zapasowa nie daje pewności

Właściciel sklepu internetowego często dowiaduje się o problemie dopiero po awarii serwera, błędnej aktualizacji albo usunięciu danych. Sam fakt, że na dysku znajduje się plik opisany jako kopia, nie oznacza jeszcze, że można z niego odtworzyć działający sklep. Plik może być niepełny, uszkodzony, nieaktualny albo zapisany w tym samym miejscu co dane źródłowe.

Najczęstszy objaw to brak jasnej odpowiedzi na kilka podstawowych pytań: kiedy wykonano ostatnią kopię, co dokładnie zawiera, gdzie ją przechowywano i czy kiedykolwiek przeprowadzono odtwarzanie testowe. Problemem bywa również backup obejmujący wyłącznie bazę danych, mimo że sklep potrzebuje także plików aplikacji, zdjęć, konfiguracji i dodatków.

Kopia zapasowa, czyli dodatkowy zapis danych przeznaczony do ich odzyskania, powinna być częścią całego procesu ochrony sklepu. Liczy się nie tylko automatyczne tworzenie plików, lecz także ich rozdzielenie, kontrola poprawności i możliwość odtworzenia w określonej kolejności.

Co powinno znaleźć się w kopii sklepu

Podstawą jest baza danych. Zawiera między innymi produkty, warianty, kategorie, konta użytkowników, zamówienia, statusy płatności, ustawienia dostawy oraz treści zapisane w panelu administracyjnym. Baza może działać w systemie MySQL lub MariaDB, czyli silniku odpowiedzialnym za przechowywanie uporządkowanych informacji sklepu.

Drugim elementem są pliki sklepu. Należą do nich pliki aplikacji, szablonu graficznego, modułów, dodatków, konfiguracji, tłumaczeń oraz katalogi ze zdjęciami produktów i dokumentami. Pominięcie katalogu multimediów może spowodować, że po odtworzeniu zamówienia będą widoczne, ale sklep straci fotografie i materiały dołączone do oferty.

Warto zabezpieczyć również pliki konfiguracyjne, czyli ustawienia połączenia z bazą, poczty elektronicznej, płatności, dostaw i zewnętrznych usług. Nie powinny być jednak przechowywane bez ochrony, ponieważ mogą zawierać hasła, klucze dostępowe lub tokeny, czyli poufne ciągi znaków pozwalające aplikacji korzystać z innego systemu.

Jeżeli sklep współpracuje z systemem sprzedażowo-magazynowym, kopia powinna uwzględniać także zakres danych potrzebnych do ponownego uruchomienia integracji. Integracja, czyli automatyczna wymiana informacji między sklepem a systemem sprzedaży i magazynu, może obejmować produkty, stany, ceny, zamówienia i dokumenty. Sam backup sklepu nie zawsze zabezpiecza dane znajdujące się wyłącznie w drugim systemie.

Jak ustalić częstotliwość wykonywania kopii

Częstotliwość backupu powinna wynikać z tempa zmian w sklepie, a nie z przyjętego z góry zwyczaju. Sklep, w którym codziennie pojawiają się zamówienia, płatności i aktualizacje stanów magazynowych, wymaga częstszej ochrony bazy niż strona z niezmienianą ofertą.

Przydatne jest rozdzielenie kopii na kilka rodzajów. Kopia pełna obejmuje cały ustalony zakres danych i plików. Kopia przyrostowa zapisuje tylko zmiany od poprzedniego backupu, dzięki czemu zajmuje mniej miejsca, ale do odtworzenia potrzebuje również wcześniejszych kopii. Kopia różnicowa obejmuje zmiany od ostatniej kopii pełnej i zwykle ułatwia odtworzenie kosztem większego rozmiaru.

Bazę danych warto zabezpieczać częściej niż duże pliki graficzne, ponieważ zamówienia i płatności zmieniają się szybciej. Pliki aplikacji oraz zdjęcia można kopiować po zmianach, aktualizacjach lub dodaniu nowych materiałów. Istotne jest także wykonywanie kopii przed aktualizacją systemu sklepu, modułów, szablonu albo zmianą konfiguracji serwera.

Przy planowaniu trzeba określić akceptowalną utratę danych. Punkt odzyskiwania, czyli moment, do którego można przywrócić sklep, powinien być możliwie bliski ostatniej prawidłowej kopii. Jeżeli po awarii można odzyskać dane tylko sprzed wielu dni, wszystkie późniejsze zamówienia i zmiany będą wymagały ręcznego odtworzenia.

Najczęstsze przyczyny nieskutecznego backupu

Jedną z częstych przyczyn jest kopiowanie niewłaściwego katalogu. Sklep może korzystać z kilku lokalizacji na serwerze, a zdjęcia lub pliki przesyłane przez panel mogą trafiać do osobnego miejsca. Zdarza się też, że kopia bazy jest wykonywana, ale nie obejmuje plików aplikacji, albo odwrotnie.

Innym problemem są błędy uprawnień. Uprawnienia, czyli reguły określające, kto może odczytywać i zapisywać pliki, mogą uniemożliwić narzędziu backupu dostęp do części danych. Zadanie może kończyć się komunikatem o sukcesie, mimo że pominięto katalog z obrazami, pliki konfiguracyjne albo konkretną tabelę bazy.

Ryzyko zwiększa przechowywanie kopii na tym samym serwerze i na tym samym koncie administracyjnym. Awaria dysku, błąd systemu, infekcja ransomware lub zaszyfrowanie danych przez napastnika może wtedy objąć zarówno sklep, jak i jego backup. Ransomware, czyli złośliwe oprogramowanie blokujące dostęp do plików i żądające zapłaty, jest szczególnie groźne dla kopii stale dostępnych z tego samego środowiska.

Problemy wynikają również z braku monitorowania. Zadanie automatyczne może przestać działać po zmianie hasła, aktualizacji serwera, wyczerpaniu miejsca albo zmianie ścieżki do plików. Bez powiadomienia o błędzie przerwa w wykonywaniu kopii może pozostać niezauważona.

Gdzie przechowywać kopie zapasowe

Bezpieczny plan powinien rozdzielać dane produkcyjne od kopii. Dane produkcyjne to pliki i baza używane przez działający sklep. Backup zapisany wyłącznie na tym samym serwerze chroni przed przypadkowym usunięciem, ale nie daje wystarczającej ochrony przed awarią całej maszyny.

Praktyczne jest utrzymywanie kilku niezależnych lokalizacji. Jedna kopia może znajdować się na serwerze przeznaczonym do szybkiego odtworzenia, a druga poza środowiskiem sklepu. Dodatkowe zabezpieczenie może stanowić nośnik odłączany po wykonaniu kopii. Zasada 3-2-1, czyli trzy kopie danych na dwóch różnych rodzajach nośników, w tym jedna poza głównym środowiskiem, pomaga ograniczyć skutki pojedynczej awarii.

Przechowywanie poza serwerem nie oznacza automatycznie bezpieczeństwa. Należy zabezpieczyć dostęp, stosować silne, unikalne hasła i uwierzytelnianie wieloskładnikowe. Uwierzytelnianie wieloskładnikowe, nazywane MFA, wymaga potwierdzenia logowania więcej niż jednym sposobem, na przykład hasłem i kodem z aplikacji.

Kopie powinny być szyfrowane, zwłaszcza gdy zawierają dane klientów, historię zamówień lub dane kontaktowe. Szyfrowanie, czyli przekształcenie danych do postaci możliwej do odczytu dopiero po użyciu klucza, ogranicza ryzyko ujawnienia informacji po przejęciu nośnika.

Test odtwarzania jest ważniejszy niż sam plik

Odtwarzanie testowe polega na przywróceniu kopii w odseparowanym środowisku i sprawdzeniu, czy sklep faktycznie działa. Nie powinno się wykonywać takiego testu bezpośrednio na aktywnym sklepie, ponieważ można nadpisać aktualne dane lub zakłócić obsługę zamówień.

Podczas testu sprawdza się kompletność bazy, obecność zdjęć, działanie panelu administracyjnego, logowanie, koszyk, składanie zamówień oraz odczyt statusów płatności i dostawy. Należy też skontrolować, czy aplikacja łączy się z bazą i czy konfiguracja nie wskazuje przypadkiem na środowisko produkcyjne.

Warto zmierzyć czas potrzebny na przywrócenie oraz zapisać kolejność czynności. Procedura odtwarzania, czyli opis kroków prowadzących do ponownego uruchomienia systemu, powinna uwzględniać przygotowanie serwera, utworzenie bazy, import danych, wgranie plików, ustawienie uprawnień i sprawdzenie konfiguracji.

Test należy powtarzać po większych zmianach, na przykład po migracji serwera, wymianie systemu sklepowego lub zmianie sposobu wykonywania kopii. Jednorazowo poprawny backup nie gwarantuje poprawności po późniejszej zmianie środowiska.

Jak wygląda uporządkowane wdrożenie kopii

Prace zaczynają się od rozpoznania architektury sklepu. Architektura, czyli sposób rozmieszczenia aplikacji, bazy danych, plików i usług, określa, co trzeba objąć backupem i w jakiej kolejności przywracać elementy. Sprawdzane są także zadania automatyczne, dostępne zasoby dyskowe i sposób obsługi plików.

Następnie ustala się zakres kopii, częstotliwość, retencję oraz miejsce przechowywania. Retencja, czyli czas zachowania poszczególnych kopii, pozwala odzyskać dane nie tylko z ostatniego dnia, lecz także sprzed momentu, w którym błąd został zauważony. Zbyt krótka retencja może usunąć wszystkie poprawne kopie, zanim zostanie wykryte ciche uszkodzenie.

Konfiguracja może obejmować harmonogram, kompresję, szyfrowanie, rotację kopii i powiadomienia. Kompresja, czyli zmniejszanie rozmiaru danych bez utraty ich zawartości, ogranicza zajętość miejsca. Rotacja oznacza planowe zastępowanie najstarszych kopii nowszymi zgodnie z ustalonym okresem przechowywania.

Po konfiguracji wykonywana jest kopia próbna i kontrolowane odtworzenie. Wyniki powinny zostać zapisane wraz z informacją o zakresie danych, błędach i czynnościach wymaganych przy realnej awarii. Jeżeli sklep jest połączony z systemem sprzedażowo-magazynowym, sprawdza się także, czy po przywróceniu nie powstanie niekontrolowane ponowne wysłanie zamówień lub aktualizacji stanów.

Co można sprawdzić samodzielnie

Bez ingerowania w działający sklep można sprawdzić datę ostatniej kopii, jej rozmiar, miejsce zapisu oraz komunikat zakończenia zadania. Warto porównać, czy data odpowiada rzeczywistym zmianom w sklepie i czy rozmiar kopii nie zmienił się nagle bez wyraźnego powodu.

Można sporządzić listę elementów, które powinny być chronione: baza, zdjęcia, pliki konfiguracyjne, moduły, szablon oraz dane integracji. Pomocne jest również ustalenie, kto ma dostęp do kopii i czy konto używane do backupu jest nadal aktywne.

Bezpiecznym krokiem jest pobranie jednej kopii do oddzielnego katalogu i sprawdzenie, czy archiwum można otworzyć. Nie jest to pełny test odtworzenia, ale pozwala wykryć uszkodzenie pliku lub brak dostępu. Należy przy tym pracować na duplikacie, aby nie zmienić oryginalnego backupu.

Warto też sprawdzić, czy istnieją powiadomienia o błędach i czy osoba odpowiedzialna za sklep je otrzymuje. Samo uruchomienie automatyzacji bez monitorowania nie daje pewności, że zadanie będzie działało przez dłuższy czas.

Błędy popełniane przy samodzielnych próbach

Ryzykowne jest ręczne kopiowanie plików podczas intensywnej pracy sklepu bez zapewnienia spójności bazy. Spójność, czyli zgodność danych zapisanych w różnych tabelach i plikach, może zostać naruszona, gdy część informacji zmieni się w trakcie kopiowania.

Częstym błędem jest nadpisanie bieżącej bazy danymi ze starej kopii bez wcześniejszego zabezpieczenia aktualnego stanu. Taka operacja może usunąć nowsze zamówienia, konta klientów i zmiany w katalogu. Przed odtwarzaniem trzeba ustalić, czy celem jest pełny powrót do wcześniejszego punktu, czy odzyskanie tylko wybranych danych.

Nie należy przechowywać haseł do backupu w publicznym katalogu sklepu ani wysyłać archiwów bez szyfrowania. Nie powinno się także usuwać starszych kopii od razu po utworzeniu nowej. Nowa kopia może być niepełna, a błąd może ujawnić się dopiero po kilku dniach.

Problematyczne bywa również testowanie odtworzenia na produkcji. Zmiany wprowadzone podczas takiej próby mogą stać się widoczne dla klientów, zmienić stany magazynowe albo wysłać rzeczywiste powiadomienia. Test powinien odbywać się w odizolowanym środowisku z wyłączonymi połączeniami, które mogłyby wywołać realne operacje.

Kiedy problem nie dotyczy kopii zapasowej

Nie każda utrata widoczności danych oznacza brak backupu. Sklep może działać, ale nie wyświetlać produktów z powodu błędu cache. Cache, czyli tymczasowa pamięć przechowująca wcześniej wygenerowane dane, może pokazywać nieaktualną wersję strony albo ukrywać zmianę konfiguracji.

Inną przyczyną może być awaria połączenia z bazą, błędna konfiguracja domeny, problem z certyfikatem szyfrującym transmisję albo niedostępność zewnętrznej bramki płatniczej. Certyfikat szyfrujący, najczęściej TLS, chroni dane przesyłane między przeglądarką a serwerem, ale jego wygaśnięcie nie oznacza utraty kopii.

Brak zamówienia w panelu może wynikać z opóźnienia integracji z systemem sprzedażowo-magazynowym, błędu kolejki zadań albo niepoprawnego filtra. Kolejka zadań, czyli lista operacji oczekujących na wykonanie przez usługę w tle, może zatrzymać synchronizację mimo że dane w sklepie nadal istnieją.

Jeśli problem dotyczy wyłącznie jednej funkcji, należy najpierw ustalić jej źródło. Odtworzenie całego sklepu z kopii może pogorszyć sytuację, gdy awaria jest związana z bieżącą konfiguracją, usługą zewnętrzną albo pojedynczym modułem.

Czy kopia obejmuje zamówienia i dane klientów?

Może obejmować zamówienia i dane klientów, ale zależy to od zakresu bazy oraz przyjętej polityki ochrony danych. Polityka ochrony danych, czyli ustalone zasady dotyczące dostępu, przechowywania i usuwania informacji, powinna wskazywać, które elementy są kopiowane i jak długo pozostają dostępne.

Nie należy zakładać, że kopia sklepu zawiera historię przechowywaną w zewnętrznym systemie płatności, kurierskim lub sprzedażowo-magazynowym. Każda usługa może mieć własne zasady retencji i eksportu danych. Przy odtwarzaniu trzeba rozróżnić dane źródłowe od informacji pobieranych ponownie przez integrację.

Czy backup chroni przed złośliwym oprogramowaniem?

Backup ogranicza skutki infekcji, ale nie chroni automatycznie przed samym atakiem. Jeżeli złośliwe oprogramowanie ma dostęp do serwera i kopii, może zmienić albo zaszyfrować oba zasoby. Dlatego potrzebne są odseparowane lokalizacje, ograniczone uprawnienia i przynajmniej część kopii niedostępna z poziomu działającego sklepu.

Po wykryciu infekcji nie należy od razu przywracać pierwszej znalezionej kopii. Trzeba ustalić, kiedy pojawiły się niepożądane zmiany, sprawdzić starsze punkty odzyskiwania i zabezpieczyć obecny stan do analizy. Odtworzenie czystego backupu bez usunięcia przyczyny może doprowadzić do ponownej infekcji.

Czy można usuwać stare kopie?

Stare kopie można usuwać dopiero po sprawdzeniu retencji, poprawności nowszych archiwów i wymagań dotyczących przechowywania danych. Automatyczna rotacja jest wygodna, ale powinna zachowywać kilka punktów odzyskiwania z różnych okresów.

Nie warto pozostawiać wyłącznie najnowszego backupu. Uszkodzenie może być niewidoczne przez pewien czas, a kopia wykonana po wystąpieniu problemu może zawierać już zmienione lub zainfekowane pliki. Przed usunięciem starszego archiwum należy potwierdzić, że nowsza kopia została otwarta, zweryfikowana i uwzględnia wymagany zakres.

Dobrze przygotowany backup sklepu łączy pełny zakres danych, odpowiednią częstotliwość, rozdzielone przechowywanie i regularne testy odtwarzania. Dopiero te elementy razem dają realną możliwość powrotu do działania po awarii, błędnej zmianie lub utracie dostępu do serwera.