Większość sprzedawców uważa, że ma kopie zapasowe. Większość realnie ich nie ma. W prowadzonych przez nas audytach 6 sklepów na 10 nie dysponuje kopią możliwą do przywrócenia w mniej niż 4 godziny, 3 na 10 mają kopie uszkodzone albo niekompletne, a mniej więcej 1 na 10 nie ma żadnej użytecznej kopii od ponad miesiąca, często o tym nie wiedząc.
Koszt incydentu bez działającej kopii to od 24 godzin do kilku tygodni przestoju, utracone dane klientów, a czasem zakończenie działalności. Ten artykuł opisuje strategię kopii zapasowych, jaką powinno się mieć w 2026 roku w sklepie PrestaShop: regułę 3-2-1, szyfrowanie, rotację, a przede wszystkim przetestowane przywracanie.
Dlaczego domyślne kopie zapasowe nie wystarczają
„Mój hostingodawca robi kopie” to zdanie, które pada najczęściej. Zwykle jest prawdziwe i zarazem niewystarczające w praktyce:
- Kopie hostingodawcy leżą w tym samym centrum danych. Poważny pożar (OVH Strasburg 2021), atak ransomware albo przejęcie panelu administracyjnego hostingodawcy i kopie płoną razem z danymi.
- Retencja jest krótka. Od 7 do 14 dni w ofertach standardowych. Jeśli wykryjesz podmianę treści albo uszkodzenie 3 tygodnie później, zainfekowana kopia zdążyła już zastąpić zdrową.
- Czy kopia obejmuje naprawdę wszystko? Wielu hostingodawców kopiuje bazę, ale nie pliki, albo odwrotnie. A o przesłane pliki (zdjęcia produktów, faktury PDF, eksporty) czasem nikt nie dba.
- Przywracanie nigdy nie jest testowane. W dniu zdarzenia okazuje się, że procedura nie działa, trwa 36 godzin albo wymaga dostępu do panelu, który dawno przepadł.
- Brak szyfrowania. Niezaszyfrowana kopia u podmiotu zewnętrznego oznacza całą bazę klientów wystawioną na wyciek po stronie usługodawcy.
Reguła 3-2-1: branżowy punkt odniesienia od 30 lat
Sformułowana przez fotografa Petera Krogha w 2005 roku dla archiwów cyfrowych, przyjęta przez agencje cyberbezpieczeństwa i praktycznie wszystkie ramy bezpieczeństwa IT:
3 kopie danych, na 2 różnych nośnikach, z czego 1 poza lokalizacją.
Konkretnie dla sklepu PrestaShop:
- Kopia 1: produkcja (Twój serwer produkcyjny).
- Kopia 2: kopia lokalna albo u tego samego hostingodawcy (szybka do przywrócenia przy drobnych incydentach).
- Kopia 3: kopia poza lokalizacją, u zewnętrznego dostawcy przestrzeni (S3, Backblaze B2, Wasabi, Dropbox).
Kopia poza lokalizacją jest ostatnią linią obrony przed poważnymi zdarzeniami: pożarem, ransomware, upadłością hostingodawcy.
Co trzeba kopiować w sklepie PrestaShop
1. Pełna baza danych
Wszystkie tabele, nie tylko te biznesowe. Zrzut mysqldump z opcjami --single-transaction --quick --routines --triggers dla spójności oraz uwzględnienia procedur składowanych i wyzwalaczy.
2. Przesłane pliki
Katalog /img/ (zdjęcia produktów, kategorii, producentów), /upload/ (pliki dołączone do produktów), /download/ (produkty wirtualne i ich pliki) oraz wszystkie katalogi modułów zewnętrznych przechowujących pliki (faktury PDF, eksporty księgowe, logi).
3. Kod i moduły
Nawet jeśli masz Git, kopiowanie kodu produkcyjnego pozwala uchwycić niewersjonowane poprawki awaryjne i dokładny stan zainstalowanych modułów. Obejmuje /modules/, /themes/, /override/ oraz katalog główny PrestaShop z pominięciem /var/cache/.
4. Konfiguracja systemowa
Pliki app/config/parameters.php, .htaccess, konfiguracje Nginx albo Apache, certyfikaty SSL, wpisy crona. Często pomijane, a krytyczne przy odtwarzaniu instalacji od zera.
5. Wysyłane e-maile i świeże logi
Na potrzeby obowiązków prawnych (RODO, księgowość) warto zachować kopię świeżych logów i e-maili transakcyjnych. Nie zawsze konieczne, ale przydatne.
Szyfrowanie nie jest już opcjonalne
Niezaszyfrowana kopia przechowywana u zewnętrznego dostawcy to poważne ryzyko RODO: jeśli usługodawca zostanie skompromitowany, cała baza klientów wycieka w postaci jawnej. Artykuł 32 RODO nakłada obowiązek wdrożenia „odpowiednich środków technicznych”, co obejmuje szyfrowanie w spoczynku dla kopii zawierających dane osobowe.
Standard w 2026 roku: AES-256 z kluczem przechowywanym oddzielnie od kopii. Nigdy nie trzymaj klucza szyfrującego razem z kopiami, bo wtedy szyfrowanie traci sens.
Rotacja: ile wersji zachowywać
Im więcej zachowujesz, tym lepiej, ale to kosztuje. Sprawdzona strategia GFS (Grandfather-Father-Son):
- Kopie dobowe przechowywane 7 dni.
- Kopie tygodniowe przechowywane 4 tygodnie.
- Kopie miesięczne przechowywane 12 miesięcy.
- Kopie roczne przechowywane przez okres wynikający z lokalnych obowiązków księgowych.
Przy tej strategii przywrócisz dowolny dzień z ostatnich 7 dni, dowolny tydzień z ostatniego miesiąca i dowolny miesiąc z ostatniego roku. Pokrywa to 99 % scenariuszy odzyskiwania.
Przetestowane przywracanie: jedyna kopia, która się liczy
Nieprzetestowana kopia to przesąd, a nie kopia zapasowa. Zasada bezwzględna:
Testuj przywracanie na środowisku przedprodukcyjnym co najmniej raz na kwartał.
Ten test musi sprawdzić:
- Czy kopia jest kompletna (wszystkie tabele, wszystkie pliki)?
- Czy zrzut daje się przywrócić bez błędu?
- Czy witryna działa po przywróceniu (strony kategorii, koszyk, checkout, zaplecze)?
- Ile trwa pełne przywrócenie (RTO, Recovery Time Objective)?
- Jaka jest maksymalna utrata danych (RPO, Recovery Point Objective)?
W sklepach, które wykonują ten kwartalny test, czas przywracania spada z 6 do 8 godzin na 1 do 2 godzin w ciągu kilku iteracji. A rozbieżności (brakująca tabela, błędne uprawnienia, uszkodzony plik) są wykrywane przed incydentem, a nie w jego trakcie.
Nasz moduł dfbackup: kopie zapasowe pod klucz
Wdrożenie tej strategii ręcznie wymaga utrzymywania skryptu zrzutu, systemu szyfrowania, rotacji oraz wysyłki do przestrzeni S3. Nasz moduł dfbackup dla PrestaShop 8 i 9 pakuje cały ten stack:
- Zaplanowana kopia bazy i plików przez cron, z konfigurowalnym interwałem (dobowy, tygodniowy).
- Szyfrowanie AES-256 z osobnym kluczem, możliwym do przechowywania poza serwerem.
- Wiele miejsc docelowych: S3 i zgodne (Wasabi, Backblaze B2, Scaleway), FTP i SFTP, Dropbox.
- Zautomatyzowana rotacja GFS z konfigurowalnym przechowywaniem per warstwa.
- Przywracanie jednym kliknięciem z zaplecza, opcjonalnie na środowisko przedprodukcyjne.
- Powiadomienia e-mailem albo webhookiem przy niepowodzeniu i powodzeniu.
- Szczegółowe logi każdej kopii (wolumen, czas trwania, suma kontrolna).
- Zgodność z multisklepem i wielojęzycznością, z retencją różnicowaną per zakres.
Za 129 € wdrażasz zgodną z RODO i uprzemysłowioną strategię kopii zapasowych, bez uzależnienia od hostingodawcy.
Ile kosztuje brak kopii zapasowej
W sklepie generującym 400 tys. zł miesięcznego obrotu 48 godzin przestoju kosztuje bezpośrednio około 27 tys. zł niezrealizowanego obrotu. Dolicz koszty pośrednie: odzyskiwanie utraconych klientów, negatywne opinie o obsłudze, wpływ na SEO przy dłuższym przestoju (Google potrafi wyindeksować, jeśli witryna zwraca 404 dłużej niż kilka dni), utratę zaufania partnerów. Realistyczna suma: od 60 do 120 tys. zł przy 48 godzinach przestoju. Przy miesiącu przestoju mówimy o przetrwaniu firmy.
Koszt solidnej strategii kopii zapasowych: 129 € za moduł plus od 5 do 20 € miesięcznie za przestrzeń S3. Stosunek kosztu do ryzyka nie podlega dyskusji.
FAQ
Czy kopie przyrostowe wystarczą?
Nie same. Kopia przyrostowa zależy od poprzedzającej ją kopii pełnej. Jeśli kopia pełna jest uszkodzona, cały łańcuch przyrostowy jest bezużyteczny. Zasada: pełna kopia tygodniowa albo miesięczna, uzupełniana przyrostowymi dobowymi. Nie odwrotnie.
Ile powinno trwać przywracanie?
Akceptowalne RTO zależy od krytyczności. Dla działającego sklepu internetowego celem jest poniżej 4 godzin na pełne przywrócenie. Poniżej 2 godzin przy dopracowanej procedurze i przestrzeni blisko serwera. Powyżej 8 godzin masz problem ze strategią albo z narzędziami.
Kopiować pliki i bazę razem czy osobno?
Razem, najlepiej w wąskim oknie czasowym (10 do 15 minut). Rozjechana baza i pliki (na przykład baza kopiowana rano, pliki wieczorem) tworzą niespójności przy przywracaniu: produkty w bazie bez zdjęcia, faktury z odwołaniem do nieistniejącego pliku.
Czy przestrzeń chmurowa (S3) jest zgodna z RODO?
Tak, jeśli dostawca działa w Unii Europejskiej albo oferuje standardowe klauzule umowne przy transferach poza Unię. AWS, Scaleway, OVH Object Storage i Backblaze są zgodne przy właściwej konfiguracji. Szyfrowanie przed wysyłką gwarantuje, że nawet skompromitowany dostawca nie da dostępu do niczego użytecznego.
Czym to się różni od replikacji w czasie rzeczywistym?
Replikacja (na przykład MySQL master-slave) chroni przed awarią sprzętu, a nie przed błędem człowieka czy uszkodzeniem logicznym. Jeśli skrypt omyłkowo usunie 10 000 produktów, replika zastosuje usunięcie natychmiast. Wersjonowana kopia zachowuje zdrową wersję sprzed zdarzenia. Oba mechanizmy się uzupełniają, ale nie zastępują.
Aby pójść dalej
Kopia zapasowa to jedno z ogniw szerszego łańcucha: bezpieczeństwa, monitoringu i obsługi incydentów. Dobrze kopiowana, ale źle monitorowana witryna i tak traci dane między incydentem a jego wykryciem. Zobacz także nasz przewodnik po instalacji modułów PrestaShop, aby zrozumieć, gdzie dfbackup wpina się w stack, oraz materiał o czyszczeniu bazy PrestaShop: odchudzenie bazy przed kopią pięciokrotnie skraca czas kopiowania i obniża koszt przechowywania.
Aby przejść do działania: nasz wybór modułów do utrzymania, kopii zapasowych i niezawodności.
