Jak wykonać backup PrestaShop

Dobrze wykonana kopia zapasowa to poduszka bezpieczeństwa każdego sklepu opartego na PrestaShop. Ten poradnik prowadzi krok po kroku przez kompletne tworzenie i kontrolę kopii: od przygotowań, przez archiwizację pliki sklepu i baza danych, po testy, automaty i praktyki przechowywania. Skupiamy się na działaniach powtarzalnych i odpornych na błędy, tak aby backup był szybki do wykonania i pewny w odtworzeniu także pod presją czasu.

Przygotowanie do kopii zapasowej

Co obejmuje kopia zapasowa w PrestaShop

Pełna kopia to zapis stanu zarówno plików, jak i danych w bazie. W praktyce potrzebujesz dwóch elementów z tego samego momentu:

• Archiwum katalogu sklepu (najczęściej public_html lub htdocs) z całym kodem źródłowym, motywem, modułami i zasobami multimedialnymi: /themes, /modules, /img, /upload, /download, /translations, /override, katalog administracyjny (np. /admin123), a także pliki konfiguracyjne.
• Zrzut bazy MySQL/MariaDB zawierający wszystkie tabele sklepu (prefiks ps_, chyba że użyto innego). To tu znajdują się produkty, zamówienia, klienci, konfiguracja i treści CMS.

Aby uniknąć problemów ze spójnością, wykonuj obie części bezpośrednio po sobie i najlepiej w czasie niskiego ruchu. Pamiętaj, że w przypadku większych sklepów kolejność i tempo działań mają znaczenie, szczególnie gdy trwa aktywna sprzedaż.

Wymagane dostępy i narzędzia

• Dostęp do panelu hostingu (np. cPanel, Plesk, DirectAdmin) lub do serwera przez SSH/FTP. Bezpieczniejszym wyborem do transferu jest SFTP z uwierzytelnieniem kluczem.
• Dostęp do narzędzia bazodanowego: phpMyAdmin w panelu lub konsolowe narzędzia MySQL, w tym mysqldump.
• Wiedza o lokalizacji katalogu instalacji (ścieżka na serwerze), wersji PHP/MariaDB, wolnej przestrzeni dyskowej i limicie czasu procesów.
• Opcjonalnie: program do kompresji i archiwizacji (zip, tar), narzędzia do kontroli integralności (sha256sum), narzędzia do szyfrowanie (gpg, openssl).

Polityka retencji i reguła 3-2-1

Ustal zawczasu: jak często tworzysz kopie, jak długo je przechowujesz i gdzie trafiają. Dobra praktyka to reguła 3-2-1: trzy kopie w sumie, na dwóch różnych nośnikach, z czego co najmniej jedna poza infrastrukturą produkcyjną (np. obiektowe S3/Backblaze, dysk zewnętrzny, inny dostawca). Dla sklepów o wysokiej dynamice danych planuj kopie dzienne, dla mniejszych – przynajmniej tygodniowe oraz przed każdą aktualizacją lub wdrożeniem.

Weryfikacja wersji, modułów i spójności

• Sprawdź wersję sklepu i zgodność motywu/modułów (Panel administracyjny → Parametry zaawansowane → Informacje). Zanotuj ją wraz z listą krytycznych modułów (płatności, wysyłki, integracje ERP/WMS).
• Wyłącz automatyczne zadania ciężkie (np. potężne importy, indeksacje), które mogłyby zmieniać dane podczas tworzenia kopii.
• Upewnij się, że katalogi cache i logów nie zapełniają dysku – zmniejszysz ryzyko przerwania procesów kopii.

Tryb konserwacji i okno serwisowe

W przypadku dużego ruchu rozważ włączenie trybu konserwacji (Parametry sklepu → Ogólne → Tryb konserwacji), aby zminimalizować zmiany w danych podczas tworzenia kopii. Alternatywą jest szybki snapshot bazy (transakcyjny eksport) i natychmiastowa archiwizacja plików, tak aby odstęp między tymi operacjami był jak najkrótszy.

Wykonanie kopii plików sklepu

Kopia przez panel hostingu

Najprostsze podejście to użycie wbudowanego kreatora kopii w panelu (cPanel: Backup/Backup Wizard; Plesk: Backup Manager; DirectAdmin: Create/Restore Backups). Wskaż katalog instalacji sklepu jako źródło. Zadbaj o:

• Kompresję archiwum (zip/tar.gz) z podziałem na części, jeśli panel to umożliwia (przy bardzo dużych katalogach).
• Zapis kopii poza katalogiem publicznym lub automatyczne wysłanie na zewnętrzny zasób (np. S3).
• Wykluczenie katalogów cache/logów, jeśli narzędzie pozwala (var/cache, var/logs, tools/smarty/cache, tools/smarty/compile).

Kopia przez FTP/SFTP

Skonfiguruj klienta, ustaw pasywne połączenie tylko w razie potrzeby i pobierz cały katalog sklepu. To metoda prosta, ale wolniejsza; przy dużych instalacjach preferowane jest zrobienie archiwum po stronie serwera i dopiero jego pobranie. Upewnij się, że pobrano także pliki ukryte (.htaccess, .env, .user.ini), ponieważ mają krytyczny wpływ na konfigurację serwera i reguł URL.

Kopia przez SSH (tar/zip/rsync)

Na serwerze możesz wykonać szybkie archiwum:

• tar czf sklep-files-YYYYmmdd.tar.gz –exclude=”var/cache/*” –exclude=”var/logs/*” –exclude=”app/cache/*” –exclude=”tools/smarty/{cache,compile}/*” /ścieżka/do/sklepu
• zip -r sklep-files-YYYYmmdd.zip /ścieżka/do/sklepu -x „var/cache/*” „var/logs/*” „tools/smarty/cache/*” „tools/smarty/compile/*”
• rsync -aH –delete –exclude 'var/cache/’ –exclude 'var/logs/’ /ścieżka/do/sklepu/ /ścieżka/do/kopii/

Archiwum trzymaj poza katalogiem publicznym (np. w /home/user/backups). Zwróć uwagę na poprawne odwzorowanie uprawnień i właścicieli plików – rsync z opcją -aH jest zwykle wystarczający, lecz na hostingach współdzielonych bywa ograniczony.

Co wykluczyć, a co koniecznie zachować

• Wyklucz: var/cache, var/logs, narzędziowe katalogi tymczasowe, stare archiwa i zrzuty, jeśli trzymasz je w tym samym drzewie.
• Koniecznie zachowaj: motyw (/themes), grafiki produktów i kategorii (/img), załączniki (/download), ręczne uploady (/upload), katalog /modules, pliki konfiguracyjne (w PS 1.6: config/settings.inc.php; w PS 1.7/8: app/config/parameters.php), oraz specyficzne override’y.

Kompresja, weryfikacja i opcjonalne szyfrowanie

Po utworzeniu archiwum zweryfikuj jego integralność sumą kontrolną: sha256sum sklep-files-YYYYmmdd.tar.gz. Dla wrażliwych danych rozważ zaszyfrowanie archiwów: gpg -c sklep-files.tar.gz lub openssl enc -aes-256-cbc -pbkdf2 -salt -in sklep-files.tar.gz -out sklep-files.tar.gz.enc. Hasła przechowuj w menedżerze haseł i nie zapisuj ich w czystej postaci na serwerze. Zaszyfrowanie jest szczególnie ważne, jeżeli kopie trafiają do chmury publicznej.

Wykonanie kopii bazy danych

Eksport przez phpMyAdmin

W panelu wybierz bazę sklepu i opcję Eksport. Dla większych sklepów użyj trybu „Niestandardowy”, włącz:

• Format SQL, kompresja GZIP lub ZIP (jeśli przeglądarka/serwer ma limity czasu, kompresja pomaga).
• Dodawanie instrukcji CREATE/DROP TABLE, zachowanie AUTO_INCREMENT, kompletne dane tabel, wyłączenie kluczy obcych na czas importu.
• Kodowanie UTF-8/utf8mb4, zgodne z ustawieniami bazy sklepu.

Po eksporcie sprawdź, czy plik nie został przycięty przez limit rozmiaru i czy zawiera zarówno strukturę, jak i dane. Jeśli eksport przez panel jest niestabilny, użyj narzędzi konsolowych.

Eksport przez mysqldump

Na serwerze z dostępem SSH wykonaj zrzut transakcyjny (bez blokowania tabel InnoDB):

• mysqldump -u nazwa_uzytkownika -p –single-transaction –quick –routines –triggers –events –default-character-set=utf8mb4 nazwa_bazy | gzip > sklep-db-YYYYmmdd.sql.gz

Parametry –routines, –triggers i –events dbają o kompletność metadanych. Po wykonaniu zrzutu zweryfikuj go szybką kontrolą: zgrep -a „INSERT INTO” sklep-db-YYYYmmdd.sql.gz | head -n 5 oraz sprawdź rozmiar i sumę kontrolną. W środowiskach z replikacją rozważ eksport z serwera slave, aby nie obciążać produkcji.

Podział dużych zrzutów i odporność na przerwy

Dla bardzo dużych baz (dziesiątki GB) rozważ pipeline z kompresją i ewentualnym dzieleniem pliku:

• mysqldump … | pv | gzip | split -b 2G – sklep-db-YYYYmmdd.sql.gz.part-

Podczas importu scalisz części: cat sklep-db-YYYYmmdd.sql.gz.part-* > sklep-db-YYYYmmdd.sql.gz. Jeśli w tabelach występują silne obciążenia zapisem, wykonuj zrzut poza szczytem i upewnij się, że format tabel to InnoDB (umożliwia spójny snapshot przy –single-transaction).

Kompatybilność, kolacje i kontrola wersji

Upewnij się, że docelowy serwer ma zgodną wersję silnika (MariaDB/MySQL) i właściwą kolację (np. utf8mb4_unicode_ci). Przy migracjach między środowiskami zachowaj identyczną strefę czasową serwera bazy. W PrestaShop 1.7/8 dane konfiguracyjne (np. domena) zapisane są w ps_shop_url i częściowo w ps_configuration – ich korekta będzie potrzebna przy odtwarzaniu na innym adresie.

Bezpieczeństwo dostępu do bazy

• Hasła do kont bazodanowych trzymaj w bezpiecznym menedżerze i nie zapisuj ich w repozytoriach.
• Pliki konfiguracyjne sklepu zawierają poświadczenia (PS 1.6: config/settings.inc.php; PS 1.7/8: app/config/parameters.php). Zaszyfruj backupy składowane w chmurze i ogranicz do nich dostęp na zasadzie najmniejszych uprawnień.

Automaty, testy i odtwarzanie

Automatyzacja tworzenia kopii

Najwyższą niezawodność zapewnia automatyzacja przez zadania cron i skrypty. Przykładowy schemat:

• Skrypt bash tworzący archiwum plików (tar z wykluczeniami) i zrzut bazy (mysqldump), dodający datę w nazwie, liczący sumy SHA256.
• Szyfrowanie wyników (gpg z kluczem publicznym) i wysyłka poza serwer (rclone do S3/Backblaze/Google Drive, scp/sftp na serwer zapasowy).
• Automatyczne czyszczenie starych backupów według retencji (np. keep last 7 daily, 4 weekly, 6 monthly).

Dbaj o powiadomienia e-mail/Slack z logów zadań i o monitoring błędów (niepowodzenia kompresji, brak miejsca na dysku, błędne poświadczenia). Zapisuj metadane kopii: data, wersja sklepu, suma kontrolna, rozmiar, lokalizacja docelowa.

Przechowywanie poza serwerem i transfer

Przetrzymuj minimum jedną kopię poza infrastrukturą produkcyjną: zasoby S3-kompatybilne, dysk w innej lokalizacji, repozytorium artefaktów. Do transferu używaj kanałów szyfrowanych i kontroli wersji plików. Rozważ lifecycle w S3 (przenoszenie na tańsze klasy po 30/60 dniach). W krytycznych środowiskach testuj odczyt losowej próbki kopii co tydzień – to jedyny sposób, by mieć pewność, że nie przechowujesz uszkodzonych archiwów.

Testy odtworzeniowe na stagingu

Regularnie odtwarzaj losową kopię w środowisku testowym. Procedura minimalna:

• Utwórz osobną bazę i użytkownika o ograniczonych uprawnieniach.
• Wgraj archiwum plików do katalogu staging i rozpakuj je.
• Zaimportuj zrzut bazy. Zmień dane w ps_shop_url: domain, domain_ssl, physical_uri dopasuj do subdomeny staging. Wyłącz wysyłkę e-maili i bramki płatności.
• Wyczyść cache (usuń var/cache/prod i var/cache/dev) i odbuduj .htaccess, np. przez przełączenie przyjaznych URL.

Sprawdź panel i front: logowanie klientów, koszyk, kasy, generowanie miniatur. Udokumentuj każdy błąd i popraw proces tworzenia lub przechowywania kopii.

Procedura przywracania po awarii

Scenariusz podstawowy, gdy zachowałeś kopie plików i bazy z tej samej daty:

• Włącz tryb konserwacji lub ustaw blokadę dostępu na poziomie serwera (np. htpasswd dla całej witryny).
• Usuń z serwera uszkodzone pliki i wgraj archiwum kopii. Zadbaj o właściciela i uprawnienia (na hostingach www-data lub użytkownik systemowy).
• Utwórz pustą bazę lub wyczyść obecną (ostrożnie!) i zaimportuj zrzut SQL. Dla plików .sql.gz: gunzip -c plik.sql.gz | mysql -u user -p baza.
• Ustaw poprawne poświadczenia bazy w pliku konfiguracyjnym (PS 1.6: config/settings.inc.php; PS 1.7/8: app/config/parameters.php) i dopasuj URL w tabeli ps_shop_url do aktualnej domeny.
• Wyczyść cache: usuń katalogi var/cache/prod i var/cache/dev (lub tools/smarty/cache i tools/smarty/compile w starszych wersjach). Przełącz przyjazne URL, aby wygenerować świeży .htaccess.
• Sprawdź logi serwera i Presta: var/logs, dzienniki PHP. Napraw ewentualne braki rozszerzeń PHP (zip, intl, gd, mbstring), niezgodność wersji czy limity pamięci.

Jeśli odtwarzasz na innym hostingu, zwróć uwagę na różnice ścieżek systemowych i uprawnień. Domena musi wskazywać na poprawny katalog publiczny sklepu, a konfiguracja HTTP(S) i certyfikat SSL powinny być ważne i spójne z ustawieniami w bazie.

Najczęstsze błędy i jak ich unikać

• Niespójny moment kopii (np. baza z godziny 00:05, pliki z 02:15) – minimalizuj odstęp, rozważ włączenie konserwacji lub osadzenie eksportu bazy w transakcji.
• Brak testów odtworzeniowych – bez ćwiczeń kopie bywają bezużyteczne. Raz w miesiącu wykonaj próbne odtworzenie.
• Przechowywanie kopii na tym samym serwerze produkcyjnym – naruszenie reguły 3-2-1; odseparuj lokalizacje.
• Nieszyfrowane kopie w chmurze – minimalizuj ryzyko wycieku przez szyfrowanie po stronie klienta i restrykcyjne uprawnienia dostępu.
• Brak retencji i porządku w nazwach – standaryzuj: sklep-files-YYYYmmdd.tar.gz, sklep-db-YYYYmmdd.sql.gz, dołącz sumy kontrolne.
• Poleganie wyłącznie na module aktualizacji 1-Click Upgrade – jego backupy są pomocne, ale nie zastępują pełnych, powtarzalnych kopii poza serwerem.

Dodatkowe wskazówki praktyczne

• Przed dużymi zmianami (aktualizacja modułu, motywu, wersji PHP) twórz bezwzględnie świeżą kopię.
• Dla sklepów o bardzo wysokim wolumenie rozważ binarne snapshoty systemu plików (LVM/ZFS) i replikację bazy – upraszcza to szybkie RPO/RTO.
• Po odtworzeniu sprawdź integracje zewnętrzne (płatności, kurierzy, ERP) i klucze API – czasem wymagają ponownego uwierzytelnienia.
• Dokumentuj procedurę: kto, gdzie i jak ma wykonać przywracanie, gdzie znajdują się klucze i hasła, jakie są osoby kontaktowe.