Jak ustawić kopie zapasowe sklepu internetowego?
Awaria serwera, błąd podczas aktualizacji albo atak hakerski mogą usunąć nie tylko pliki sklepu, lecz także zamówienia, dane klientów i katalog produktów. Dlatego kopia zapasowa nie jest dodatkiem, ale podstawą bezpieczeństwa. Ustaw ją tak, aby obejmowała pliki i bazę danych, zapisywała się automatycznie, była przechowywana poza serwerem sklepu i regularnie przechodziła test przywracania.
Co musi zawierać kompletna kopia zapasowa?
Backup sklepu składa się z dwóch niezależnych części. Pierwsza to pliki, czyli kod aplikacji, szablony, zdjęcia, konfiguracja, moduły i wtyczki. Druga to baza danych, w której znajdują się między innymi produkty, klienci, zamówienia, stany magazynowe i ustawienia sklepu.
Samo skopiowanie plików nie odtworzy zamówień, a sama baza danych nie wystarczy do uruchomienia sklepu bez kodu, szablonu i grafik. Przywracanie obu elementów może odbywać się osobno, dlatego przed konfiguracją sprawdź, czy wybrany mechanizm obejmuje cały sklep.
W kompletnej kopii powinny znaleźć się:
- Pliki sklepu – kod, zdjęcia, szablony, konfiguracja, moduły i wtyczki.
- Baza danych MySQL – produkty, zamówienia, konta klientów, ustawienia i dane raportowe.
- Pliki konfiguracyjne – dane potrzebne do połączenia aplikacji z bazą danych.
- Informacja o dacie kopii – pozwala ocenić, ile danych utracisz po przywróceniu.
Jaką metodę tworzenia kopii wybrać?
Sposób konfiguracji zależy od hostingu i platformy sklepowej. Na hostingu współdzielonym kopie często wykonuje dostawca. W przypadku VPS-a lub serwera dedykowanego właściciel sam odpowiada za harmonogram, miejsce przechowywania i procedurę przywracania. Możesz też użyć modułu CMS, na przykład dla WooCommerce lub PrestaShop.
| Metoda | Poziom trudności | Zalety | Wady |
|---|---|---|---|
| Automatyczny backup hostingu | Niski | Mało konfiguracji, harmonogram po stronie dostawcy | Mniejsza kontrola, ograniczony czas przechowywania, zależność od polityki dostawcy |
| Moduł CMS | Średni | Wygodna obsługa z panelu, możliwość ustawienia automatyzacji | Zużywa zasoby serwera, wymaga aktualizacji i kontroli konfiguracji |
| Własny skrypt lub VPS | Wysoki | Duża kontrola nad zakresem, harmonogramem i lokalizacją kopii | Wymaga wiedzy, monitorowania i osobnego miejsca na backup |
Na hostingu współdzielonym sprawdź w panelu, czy kopia obejmuje jednocześnie pliki i bazę danych, jak długo jest przechowywana oraz jak wygląda przywracanie. Wtyczka lub moduł CMS może wykonywać kopie ręcznie albo przez zadanie CRON. Wybieraj takie rozszerzenia ostrożnie, aktualizuj je i po każdej większej zmianie testuj działanie.
Nie traktuj komunikatu „backup wykonany” jako dowodu bezpieczeństwa. Automatyczna kopia może być niepełna, nadpisana po błędzie albo zapisana w tej samej lokalizacji co sklep. Przy ataku złośliwe oprogramowanie może objąć także pliki kopii, jeśli system nie rozdziela ich od środowiska produkcyjnego.
Na VPS-ie możesz tworzyć osobne kopie plików i bazy danych, korzystać ze skryptów uruchamianych przez CRON albo wykonywać snapshoty całego serwera. Snapshot ułatwia szybki powrót do wcześniejszego stanu, ale nie powinien być jedynym zabezpieczeniem. Trzeba sprawdzić, gdzie fizycznie jest przechowywany i czy można go odtworzyć po awarii całego serwera.
Jak sprawdzić, czy kopia działa?
Backup, którego nigdy nie przywrócono, pozostaje tylko obietnicą. Test wykonuj na środowisku stagingowym, czyli odizolowanej kopii sklepu, a nie bezpośrednio na produkcji. Dzięki temu nie nadpiszesz bieżących zamówień i nie przerwiesz sprzedaży.
Procedura weryfikacji może wyglądać tak:
- Wybierz konkretną kopię i zapisz jej datę, zakres oraz lokalizację.
- Przygotuj środowisko stagingowe z odpowiednią wersją PHP, CMS-a i bazy danych.
- Odtwórz bazę danych, a następnie wgraj pliki sklepu z tego samego punktu w czasie.
- Sprawdź, czy sklep się uruchamia, obrazy są dostępne, a panel administracyjny działa.
- Wykonaj testowe zamówienie, sprawdź koszyk, płatność, wysyłkę wiadomości i integracje.
- Porównaj produkty, klientów i zamówienia z oczekiwanym stanem oraz zapisz wynik testu.
Przy dużej bazie danych przywracanie przez panel CMS może przekroczyć limity serwera. Wtedy administrator może użyć narzędzia takiego jak phpMyAdmin albo importu wykonywanego z poziomu serwera. Konkretna metoda zależy od konfiguracji hostingu, rozmiaru pliku i dostępnych limitów.
Zasada 3-2-1 – gdzie przechowywać backup?
Zasada 3-2-1 oznacza posiadanie trzech kopii danych, na dwóch różnych nośnikach, z jedną kopią poza serwerem produkcyjnym. Jej sens jest prosty: awaria dysku, błąd administratora lub problem w serwerowni nie powinny zniszczyć sklepu i wszystkich kopii jednocześnie.
Backup zapisany wyłącznie na tym samym serwerze nie chroni przed fizycznym uszkodzeniem urządzenia, skasowaniem całego konta ani częścią ataków. Jedną kopię możesz przechowywać u dostawcy hostingu, a drugą w niezależnej lokalizacji. Sprawdź przy tym, czy dostęp do archiwum jest chroniony, a kopie nie są publicznie dostępne.
Harmonogram kopii i testów
Częstotliwość zależy od liczby zamówień i tego, ile danych możesz odtworzyć ręcznie. Sklep, który codziennie przyjmuje sprzedaż, potrzebuje częstszych kopii niż witryna z niewielką liczbą zmian.
- Codziennie – sprawdź, czy ostatnia kopia plików i bazy danych została wykonana oraz czy jest dostępna.
- Co tydzień – zweryfikuj wolne miejsce, logi zadań automatycznych i kopię przechowywaną poza serwerem.
- Co miesiąc – przeprowadź pełny test przywracania na stagingu w ramach Disaster Recovery Plan.
- Po zmianach – wykonaj dodatkową kopię przed aktualizacją CMS, modułów, konfiguracji lub migracją serwera.
Na początku zapisz, kto może uruchomić przywracanie, gdzie znajdują się archiwa i jakie dane dostępowe są potrzebne. Właściciel sklepu powinien znać tę procedurę także wtedy, gdy za techniczną konfigurację odpowiada hosting lub zewnętrzny administrator. Dobrze ustawiony system nie tylko tworzy kopie, ale pozwala szybko i przewidywalnie wrócić do sprzedaży.
