Backup przed aktualizacją prestashop: kopia zapasowa sklepu
Artykuł pokazuje, jak krok po kroku wykonać backup przed aktualizacją PrestaShop – zarówno bazę danych, jak i pliki sklepu, oraz jak zweryfikować kopię, zanim proces aktualizacji obejmie wersję produkcyjną.
Backup przed aktualizacją PrestaShop: jak to zrobić bezpiecznie
Każda zmiana wersji sklepu niesie ryzyko. Bez aktualnej kopii zapasowej sklepu PrestaShop nie da się bezpiecznie wrócić do poprzedniego stanu, dlatego backup przed aktualizacją wykonuje się jeszcze przed pobraniem pakietu i przed aktualizacją PrestaShop.
Czy backup jest konieczny przed każdą aktualizacją PrestaShop?
Tak. Jeśli pojawi się konflikt modułów, błąd środowiska albo problem w trakcie wdrożenia, tylko poprawnie przygotowana kopia zapasowa i kopia bazy danych pozwalają przywrócić dane sklepu oraz pliki sklepu bez długiego przestoju. To właśnie odpowiada na pytanie, czy backup jest konieczny.
- Pliki sklepu – bez kopii można stracić szablon, moduły i ręczne modyfikacje.
- Baza danych – brak kopii zapasowych bazy danych oznacza ryzyko utraty zamówień, klientów i konfiguracji.
- Moduły krytyczne – przed wdrożeniem nowej wersji warto spisać moduły płatności i dostawy; różnica ujawnia się przy aktualizacji modułów, gdy część z nich wymaga osobnego dostosowania.
- Modyfikacje rdzenia – zmiany w plikach core zostaną nadpisane, o ile wcześniej nie powstała kopia zapasowa.
Jak wykonać kopię zapasową bazy danych i plików sklepu?
Prestashop aktualizacja i backup to dwa osobne obszary pracy. Najpierw tworzenie kopii zapasowej bazy danych, z kolei potem archiwizacja plików sklepu, bo bez obu elementów trudno skutecznie przeprowadzić przywracanie.
- Kopia bazy danych przez phpMyAdmin – dane dostępowe zwykle znajdują się w pliku
app/config/parameters.phpdla PrestaShop 1.7 alboconfig/settings.inc.phpw starszych instalacjach; eksport w formacie SQL lub ZIP ogranicza ryzyko timeoutów przy większej bazie. Taki backup bazy danych daje pełną kopię danych sklepu. - Narzędzia dostępne w panelu administracyjnym – w Menu → Konfiguruj → Zaawansowane → Baza danych znajduje się sekcja kopii DB. Panel pokazuje ostrzeżenia przed eksportem, dopiero wtedy warto uruchomić zapis kopii zapasowych bazy danych.
- Pliki sklepu przez FTP lub SSH – zarządzanie plikami przez FTP jest najprostsze, choć PrestaShop przez FTP bywa czasochłonny przy dużych zasobach. Na serwerze hostingowym SSH pozwala szybciej spakować archiwum i pobrać je jednym transferem.
Obie kopie powinny powstać w tej samej sesji. Inaczej kopia bazy danych i pliki sklepu mogą nie pasować do siebie, a przywracanie lub próba przywrócenia sklepu po awarii okaże się niepełna.
Zasada 3-2-1 tworzenia kopii zapasowych w praktyce
Zasada backupu 3-2-1, nazywana też zasadą 3-2-1 tworzenia kopii zapasowych, pozostaje podstawą przy każdej aktualizacji PrestaShop. Chodzi o 3 kopie danych, 2 różne typy nośników i 1 lokalizację poza głównym serwerem. W praktyce oznacza to, że zapasową wersję sklepu trzeba trzymać nie tylko na koncie hostingowym.
Zanim zdecydujesz się na start wdrożenia, warto sprawdzić, czy istnieją także starsze archiwa. Świeża kopia jest ważna, ale dopiero kilka punktów odtworzenia zwiększa bezpieczeństwo, gdy problem wychodzi na jaw po czasie. Pomagają w tym automatyczne kopie zapasowe oraz cykliczny backup bazy danych zapisany poza serwerem.
| Element zasady 3-2-1 | Wymaganie | Przykład realizacji |
| 3 kopie danych | Oryginał + 2 niezależne kopie | Serwer produkcyjny + dysk lokalny + chmura |
| 2 typy nośników | Różne media przechowywania | Serwer hostingu + dysk zewnętrzny |
| 1 kopia poza lokalizacją | Offsite storage | S3, Google Drive, FTP backup zewnętrzny |
| Weryfikacja kopii | Test odtworzenia przed aktualizacją | Próbny import na środowisku staging |
Weryfikacja backupu i testy na środowisku staging
Nie każda kopia zapasowa nadaje się do odtworzenia. Krok, który często się pomija, to test kopii zapasowej i przywracanie na środowisku staging z taką samą wersją PHP oraz zgodną strukturą MySQL. Dopiero wtedy wiadomo, czy kopii zapasowej można realnie użyć i czy kopia bazy danych z phpMyAdmin oraz pliki sklepu są spójne.
Żeby przygotować sklep do bezpiecznej aktualizacji, trzeba sprawdzić nie tylko eksport, ale też możliwość przywrócenia bazy i plików. W praktyce obejmuje to import kopii zapasowych bazy danych, testowe przywracanie kopii zapasowych bazy danych, kontrolę działania koszyka, płatności i panelu administracyjnego. To zależy od wersji sklepu, dlatego osobne procedury opisano dla aktualizacji PrestaShop 1.7 oraz dla nowszych instalacji na stronie backup przed aktualizacją.
PRODO przeprowadza proces aktualizacji dopiero po potwierdzeniu, że kopia bazy danych, zapasowa wersja plików oraz kopia zapasowa da się odtworzyć. Jeśli planowana jest kopia zapasowa dla PrestaShop 8, warto wcześniej przygotować sklep, sprawdzić narzędzia dostępne w panelu, sposób pracy hostingu oraz pełne zarządzanie plikami.
Polecane produkty
Najczęściej zadawane pytania
Aby przygotować sklep, najpierw trzeba wykonać pełną kopię zapasową PrestaShop. Obejmuje ona kopię bazy danych oraz pliki sklepu, najlepiej zapisane jako jedna spójna kopia zapasowa, utworzona tuż przed aktualizacją systemu.
Dopiero wtedy warto sprawdzić moduły w panelu administracyjnym, także te nieaktywne. To one często wpływają na proces aktualizacji, podobnie jak własne modyfikacje i nadpisania w danych sklepu.
Kolejny krok to weryfikacja środowiska hostingu. Dla PrestaShop 1.7 wymagane jest PHP 7.1–8.0 i memory_limit 256 MB, z kolei dla wersji 8 i 9 potrzebne jest PHP 8.1–8.3 oraz memory_limit 512 MB. Różnica ujawnia się przy zmianie głównej wersji, gdy przed aktualizacją sklepu PrestaShop trzeba zaktualizować parametry serwera.
Na końcu dobrze porównać moment wykonania kopii zapasowej PrestaShop dla bazy i plików. Jeśli kopii zapasowej bazy danych oraz archiwum plików nie utworzono w tej samej chwili, późniejsze przywracanie bywa trudniejsze, bo środowisko nie jest w pełni spójne.
Dostępne narzędzia można podzielić na trzy grupy. Pierwsza to funkcje wbudowane w sklep PrestaShop: panel administracyjny pozwala wykonać kopię bazy danych, a moduł 1-Click Upgrade tworzy zapasową wersję na potrzeby aktualizacji.
Druga grupa to rozwiązania po stronie hostingu. Najczęściej obejmują phpMyAdmin do eksportu kopii zapasowych bazy danych, zarządzanie plikami w menedżerze serwera oraz automatyczne kopie zapasowe, o ile dostawca je udostępnia. To zależy od wersji sklepu i konfiguracji konta, ale warto przed rozpoczęciem prac sprawdzić, czy dostępne są także harmonogramy tworzenia kopii zapasowych bazy danych.
Trzecia metoda to działania ręczne. Chodzi o pobranie plików PrestaShop przez FTP lub SSH, czyli samodzielne zabezpieczenie danych sklepu i archiwum plików. W praktyce oznacza to większą kontrolę nad backupem, choć cały proces zajmuje więcej czasu.
Najbezpieczniej połączyć te podejścia. Jedna kopia zapasowa powinna pozostać poza serwerem, bo dopiero taki backup daje realną możliwość odzyskania sklepu po awarii.
Gdy proces aktualizacji zakończy się błędem, trzeba przywrócić ostatnią działającą wersję sklepu. Podstawą jest wcześniejsza kopia zapasowa obejmująca bazę i pliki, bo bez niej przywracanie zwykle oznacza ręczne odtwarzanie zmian.
Najczęściej zaczyna się od importu bazy przez phpMyAdmin: z użyciem opcji usunięcia istniejących tabel podczas importu. Następnie odtwarza się pliki sklepu na serwerze, zwykle przez FTP lub narzędzia dostawcy hostingu. Dopiero wtedy można przywrócić pełną spójność danych sklepu.
Jeżeli przed wdrożeniem przygotowano środowisko testowe, sytuacja jest prostsza. Takie środowisko można szybko przełączyć na produkcję i skrócić przestój, zamiast ponownie uruchamiać cały proces od zera.
Przy sklepach z bieżącą sprzedażą krok, który często się pomija, to plan awaryjny dla wdrożenia. PRODO przy aktualizacji sklepu PrestaShop wykonuje ręczny backup, sprawdza kopie zapasowe bazy danych i testuje działanie po wdrożeniu, tak aby w razie potrzeby szybko przywrócić sklep po nieudanej aktualizacji.
Udostępnij ten artykuł:
