Backup przed aktualizacją PrestaShop: kopię zapasową zrobisz w kilku krokach

Artykuł wyjaśnia, jak wykonać backup przed aktualizacją PrestaShop: krok po kroku, od przełączenia sklepu w tryb konserwacji, przez eksport bazy danych i archiwum plików, aż po weryfikację kopii na środowisku testowym. Znajdzie tu Pan/Pani konkretne metody dla każdej wersji instalacji oraz wskazówki, jak przechowywać kopie poza serwerem.

Dlaczego backup PrestaShop jest konieczny

Każda zmiana wersji PrestaShop wiąże się z realnym ryzykiem. Konflikt modułów, niezgodność środowiska albo błąd wdrożenia wystarczą, by sklep przestał działać poprawnie. Bez aktualnej kopii nie da się wrócić do poprzedniego stanu, dlatego tworzenie kopii zapasowej nie jest dodatkiem, tylko podstawowym zabezpieczeniem danych, zamówień i konfiguracji sklepu prestashop. Szczegółowy przewodnik dotyczący wykonania kopii zapasowej sklepu PrestaShop omawia cały proces. Krok, który często się pomija, to sprawdzenie, czy kopię da się odczytać i odtworzyć przed rozpoczęciem aktualizacji.

Co obejmuje pełna kopia zapasowa

Na pytanie, czy backup jest potrzebny przed zmianą wersji, odpowiedź pozostaje jednoznaczna: tak, pełna kopia. Przed każdą zmianą wersji należy mieć pełną kopię bezpieczeństwa, bo tylko wtedy można odtworzyć sklep po nieudanej aktualizacji. W praktyce oznacza to dwa elementy: pliki serwera oraz bazę danych. Brak jednego z nich uniemożliwia skuteczne przywrócenie sklepu.

• Baza danych – zawiera produkty, kategorie, zamówienia, dane klientów, konfigurację oraz zaszyfrowane hasła; jej utrata oznacza utratę historii sprzedaży.
• Pliki sklepu – obejmują kod źródłowy, motyw, moduły, katalog administracyjny, obrazy produktów, przesłane pliki, crony i własne skrypty.
• Pliki konfiguracyjne i overrides – własne modyfikacje w plikach core, override klas i kontrolerów zostaną nadpisane podczas aktualizacji, o ile wcześniej nie wykonano ich archiwum.
• Spersonalizowane tłumaczenia – wymagają osobnego zapisania tylko wtedy, gdy były ręcznie modyfikowane lub rozszerzane poza standardowe zasoby językowe PrestaShop.

Kopia zapasowa plików oraz bazy musi pochodzić z tego samego momentu. Wersja bazy powinna odpowiadać wersji plików, bo różnica ujawnia się przy przywracaniu i kończy się błędem. Dlatego przed archiwizacją należy przełączyć sklep w tryb konserwacji, aby zatrzymać nowe zapisy. Dopiero wtedy można wykonać backup i mieć spójny punkt odtworzenia, czyli pełną kopię.

Rodzaje backupu przed aktualizacją

Zanim zdecydujesz się na konkretną metodę, warto wiedzieć, jakie są rodzaje kopii zapasowych w PrestaShop: pełna, przyrostowa i różnicowa. Przed aktualizacją sklepu liczy się wyłącznie pełna kopia, ponieważ tylko ona pozwala odtworzyć całe środowisko bez zależności od wcześniejszych archiwów. Jeśli celem jest backup przed aktualizacją PrestaShopu, nie warto opierać się na rozwiązaniu częściowym.

Moduł 1-Click Upgrade tworzy techniczny backup na potrzeby własnego procesu. Nie zastępuje jednak niezależnej kopii zapisanej poza serwerem, dlatego kopię trzeba przygotować osobno. To zależy od wersji sklepu, ale krytyczne moduły i pojedynczy moduł odpowiedzialny za płatności, dostawy, checkout, faktury czy integracje z ERP oraz marketplace warto spisać przed pracami. Ułatwia to później ocenę, czy modułów nie dotknęła niezgodność po zmianie wersji.

Praktyczna strona procesu jest prosta: kopia obejmuje dane i pliki, a gotowe archiwum najlepiej trzymać poza serwerem produkcyjnym. Dotyczy to również każdej mniejszej aktualizacji PrestaShopu.

Kopie PrestaShop przed aktualizacją krok po kroku

Procedura obejmuje dwa niezależne etapy: eksport bazy danych oraz archiwizację plików serwera. Różnica ujawnia się przy sklepach z dużą liczbą zamówień lub obrazów: im większy sklep, tym ważniejsza staje się metoda i kolejność prac.

Eksport bazy danych PrestaShop

Wykonanie kopii bazy danych sklepu przed zmianą wersji jest warunkiem koniecznym każdego zlecenia PRODO. Backup wykonywany przed upgradem PrestaShop powinien obejmować pełny zrzut struktury oraz danych, a nie tylko wybrane tabele. Dane połączenia z bazą znajdują się w pliku app/config/parameters.php w PrestaShop 1.7 albo w config/settings.inc.php w starszych instalacjach. Dostępne są trzy metody eksportu, zależnie od poziomu dostępu technicznego:

• Panel administracyjny PrestaShop – ścieżka: Menu → Konfiguruj → Zaawansowane → Baza danych. Wynikowy plik jest skompresowanym archiwum SQL w formacie BZip2 z rozszerzeniem .sql.bz2.
• phpMyAdmin – należy wybrać właściwą bazę, przejść do zakładki Eksport, a przy dużych bazach użyć formatu ZIP lub podzielić eksport na partie. Aby uzyskać wynik zbliżony do mysqldump, warto zaznaczyć opcje LOCK TABLES oraz DROP TABLE.
• SSH i mysqldump – jedno polecenie tworzy plik dump.sql z pełną strukturą i danymi. Metoda jest zalecana przy dużych sklepach, w których phpMyAdmin może przekroczyć limit czasu.

Po zakończeniu eksportu plik należy od razu pobrać na dysk lokalny albo do zewnętrznej lokalizacji. Kopia przechowywana wyłącznie na serwerze produkcyjnym nie chroni przed awarią sprzętu ani błędem administracyjnym. Warto sprawdzić przed kolejnymi pracami, czy pobrany plik otwiera się i ma niezerowy rozmiar.

Moduł kopii bazy dostępny w panelu PrestaShop tworzy wyłącznie archiwum danych. Nie obejmuje plików instalacji, motywu, modułów ani obrazów produktów.

Archiwum plików sklepu PrestaShop

Kopia zapasowa plików jest potrzebna nie tylko przed aktualizacją. Backup wykonywany przed migracją sklepu na inny serwer lub do innego dostawcy hostingu opiera się na tym samym archiwum plików i bazie, lecz punkt docelowy znajduje się gdzie indziej. Panel administracyjny PrestaShop nie oferuje dedykowanego narzędzia do archiwizacji plików, dlatego potrzebny jest FTP, SSH albo panel hostingowy. Wybór metody zależy od rozmiaru sklepu i dostępnych uprawnień:

• FTP, na przykład FileZilla – należy wskazać katalog instalacji, taki jak public_html, zaznaczyć całą zawartość i pobrać ją na dysk lokalny. Przy dużej liczbie obrazów kopiowanie trwa od kilkudziesięciu minut do kilku godzin.
• SSH: archiwum ZIP lub TAR – jedna komenda pakuje cały katalog sklepu do pojedynczego archiwum. Później pobiera się jeden plik zamiast tysięcy pojedynczych, co skraca transfer do kilkunastu minut nawet przy dużym sklepie.
• WebFTP lub panel hostingowy – przy mniejszych instalacjach wystarczy zaznaczyć katalog i wybrać opcję ZIP w interfejsie hostingu. Przy dużych plikach metoda bywa zawodna, dlatego zalecane jest połączenie SSH.

Kopia zapasowa plików powinna obejmować katalogi admin, themes, modules i uploads, a także pliki konfiguracyjne, własne skrypty oraz crony. Backup plików PrestaShop zapisany w folderze o nazwie na przykład prestashop-prod na dysku lokalnym ułatwia uporządkowanie archiwum i szybkie wskazanie właściwej wersji podczas przywracania.

Spójność kopii z wersją PrestaShop

Oba archiwa muszą powstać w tym samym momencie. Tylko wtedy baza danych i pliki tworzą spójny punkt odtworzenia. W praktyce oznacza to następującą kolejność: sklep przechodzi w tryb konserwacji, następnie wykonywany jest eksport bazy, a bezpośrednio po nim archiwum plików. Aktywność użytkowników między tymi etapami może zaburzyć spójność i spowodować błąd podczas importu.

To zależy od wersji sklepu, jakie parametry środowiskowe trzeba zaktualizować przed rozpoczęciem właściwej aktualizacji. PrestaShop 1.7 wymaga PHP 7.1–8.0 oraz memory_limit 256 MB. PrestaShop 8 i 9 wymagają natomiast PHP 8.1–8.3 oraz memory_limit 512 MB. Warto zaktualizować parametry serwera hostingowego przed uruchomieniem procesu zmiany wersji, ponieważ dopiero wtedy środowisko jest gotowe.

Moduł płatności, dostaw lub checkoutu wymaga osobnego sprawdzenia zgodności z nową wersją sklepu.

Polecane produkty

Aktualizacja PrestaShop 1.6 do wersji 1.6.1.24 – poprawa stabilności sklepu internetowego

Od 1 200,00 zł

Aktualizacja PrestaShop 8.x - bezpieczna aktualizacja sklepu PrestaShop 8

Od 1 200,00 zł

Bezpieczna aktualizacja PrestaShop 9 - wersja 9.x do najnowszej

Od 1 200,00 zł

Jak przechowywać kopię zapasową PrestaShop

Poprawnie wykonana kopia traci wartość, jeśli znajduje się w miejscu narażonym na tę samą awarię co serwer produkcyjny. Gdy kopię zapasową bazy danych i plików przygotowano, trzeba zapewnić do niej dostęp wtedy, gdy sklep wymaga odtworzenia, najczęściej po nieudanej aktualizacji.

Zasada 3-2-1 dla kopii

Najlepsze strategie zapisu kopii zapasowych, takie jak zasada 3-2-1, opierają się na trzech kopiach danych. Oznacza ona trzy kopie danych: oryginał oraz dwa niezależne archiwa, zapisane na dwóch różnych nośnikach, przy czym jedna kopia powinna znajdować się poza główną lokalizacją. Dostępne warianty zewnętrznego zapisu to:

• Zewnętrzny serwer FTP – u innego dostawcy hostingu, w innym mieście lub kraju; ogranicza skutki fizycznej awarii serwerowni.
• Usługi chmurowe – Amazon S3, Google Drive lub podobne rozwiązania; automatyczny transfer po wykonaniu kopii zmniejsza ryzyko pominięcia tego kroku.
• Dysk lokalny – komputer roboczy albo zewnętrzny nośnik; zapewnia drugi niezależny nośnik i natychmiastowy dostęp bez połączenia z serwerem.

Nie należy przechowywać jedynej kopii w katalogu głównym sklepu ani w publicznie dostępnym miejscu na serwerze. Kopie zapisane wyłącznie na tym samym hostingu nie chronią przed awarią sprzętu, błędem administracyjnym ani problemem w tej samej serwerowni. Kopia zapasowa przed aktualizacją, która znika razem z serwerem, jest równoznaczna z brakiem kopii. Kilka punktów odtworzenia zwiększa bezpieczeństwo, zwłaszcza gdy problem ujawnia się z opóźnieniem.

Test przywracania sklepu PrestaShop

Kopia zapasowa plików i bazy nie jest wiarygodna bez sprawdzenia, czy rzeczywiście można jej użyć. Dopiero skuteczne odtworzenie na środowisku testowym potwierdza, że archiwum działa.

Środowisko staging powinno możliwie wiernie odwzorowywać produkcję: tę samą wersję PHP, zgodną strukturę MySQL, wymagane rozszerzenia i właściwy limit pamięci. W praktyce oznacza to, że bez testu kopia zapasowa pozostaje niezweryfikowana.

• Import bazy danych – import przez phpMyAdmin z opcją usunięcia istniejących tabel oraz sprawdzenie, czy wszystkie tabele odtworzyły się poprawnie.
• Przywrócenie plików – transfer archiwum na staging przez FTP lub SSH i weryfikacja katalogów, w tym themes, modules oraz uploads.
• Kontrola panelu administracyjnego – logowanie, konfiguracja, lista modułów oraz ustawienia dostaw i płatności; poszczególne sekcje powinny działać tak jak na produkcji.
• Test koszyka i procesu zamówienia – przejście ścieżki zakupowej od wyboru produktu do potwierdzenia zamówienia; test weryfikuje współpracę plików z bazą danych.

Staging powinien być zabezpieczony hasłem i mieć zablokowane indeksowanie. Należy także wyłączyć wysyłkę wiadomości, płatności automatyczne oraz integracje zewnętrzne. Testy przywracania warto wykonywać regularnie: w środowiskach e-commerce zaleca się co miesiąc sprawdzać, czy kopie zapisują się prawidłowo i czy odzyskiwanie danych działa zgodnie z oczekiwaniami.

Plan rollbacku po aktualizacji

Plan awaryjny powinien być gotowy przed uruchomieniem aktualizacji, a nie tworzony podczas incydentu. Przywracanie sklepu po nieudanej aktualizacji obejmuje import bazy danych przez phpMyAdmin z usunięciem istniejących tabel, a następnie przywrócenie plików przez FTP lub narzędzia hostingowe. Bazę i pliki należy odtwarzać razem, z tego samego punktu w czasie. Przywrócenie tylko jednego elementu kończy się niespójnością i błędem.

Aktualizację należy zaplanować w okresie najmniejszego ruchu sprzedażowego, z przygotowanym komunikatem serwisowym i jasno określonymi kryteriami rollbacku. Jeśli wcześniej przygotowano środowisko testowe z tą samą wersją sklepu oraz kopią produkcji, przełączenie po weryfikacji zajmuje minuty, a nie godziny ponownego uruchamiania całego procesu.

Bezpieczna aktualizacja PrestaShop do nowej wersji, realizowana przez PRODO na serwerze testowym, wymaga pełnej kopii danych i modułów. Taki krok ogranicza konieczność ręcznego rollbacku w większości przypadków. Warto sprawdzić przed wdrożeniem, czy utworzono kopię zapasową plików, kopię bazy oraz archiwum zgodne z używaną wersją sklepu PrestaShop.