Jak przywrócić backup PrestaShop

Awaria, nieudana aktualizacja lub migracja potrafią zatrzymać sprzedaż w sklepie opartym na PrestaShop. Dlatego kluczową umiejętnością administratora jest szybkie i bezpieczne przywrócenie backupu. Ten przewodnik prowadzi krok po kroku: od weryfikacji kopii i zgodności środowiska, przez odtworzenie bazy oraz plików, po testy i działania naprawcze. Zawiera instrukcje dla panelu hostingu, pracy ręcznej oraz przez wiersz poleceń. Dzięki niemu zminimalizujesz przestój i unikniesz typowych pułapek.

Przygotowanie i weryfikacja kopii

Zanim zaczniesz: porządek działań i tryb konserwacji

Najpierw zaplanuj kolejność: przygotowanie środowiska, przywrócenie bazy, wgranie plików, dopasowanie ustawień, testy. Jeżeli sklep jest publiczny, włącz tryb konserwacji (Back office > Parametry serwisu > Konserwacja) lub ustaw tymczasowe ograniczenie dostępu na poziomie serwera, by uniknąć zakupów w trakcie odtwarzania i błędów indeksowania przez roboty.

Zapewnij dostęp do: panelu hostingu (menedżer plików, baza), SFTP/FTP, narzędzia do zarządzania bazą (np. phpMyAdmin), ewentualnie SSH. Przygotuj najnowszą działającą kopię bazy i plików oraz dane logowania. Ustal, czy odtwarzasz na ten sam serwer i domenę, czy na nowe środowisko/staging – to wpłynie na konfigurację domen oraz ścieżek.

Rozpoznanie wersji i zgodności środowiska

Sprawdź wersję sklepu (np. 1.6, 1.7, 8.x), wersję PHP oraz MySQL/MariaDB obsługiwane przez backup. W logach i pliku app/config/parameters.php (1.7/8) lub config/settings.inc.php (1.6) znajdziesz dane serwera i prefiksy tabel. Wybór zgodnych wersji środowiska minimalizuje błędy 500, problemy z zależnościami Composer i modułami.

Zweryfikuj, czy używano kompozycji multisklepu (multi-store), niestandardowego motywu, nadpisów (overrides) i kluczowych modułów (płatności, dostawy). Te elementy wymagają uwagi przy odtwarzaniu, zwłaszcza gdy backup plików i bazy są z różnych dat.

Inwentaryzacja kopii i kontrola integralności

Ustal, co zawiera kopia: pełne archiwum katalogu sklepu (w tym /modules, /themes, /img, /upload, /download, /var lub /cache) oraz zrzut bazy SQL. Jeżeli kopia jest spakowana, rozpakuj ją lokalnie i sprawdź rozmiary oraz daty modyfikacji kluczowych plików. W bazie upewnij się, że eksport nie jest niepełny (przerwane pliki .sql, puste tabele, brak semikolonu zamykającego ostatnie instrukcje).

Jeżeli dysponujesz tylko kopią bazy bez plików (lub odwrotnie), przygotuj się na działania ratunkowe: pliki można odzyskać z poprzednich wdrożeń, repozytorium lub pobrać tę samą wersję silnika i dołączyć brakujące elementy, ale zdjęcia i uploady klientów są wtedy krytyczne.

Środowisko testowe i plan przywracania

Najbezpieczniej odtwarzać w środowisku staging (subdomena lub katalog serwera), a po weryfikacji przepiąć ruch. Zmniejsza to czas niedostępności i ryzyko. Zaplanuj kopię bieżącego, uszkodzonego stanu przed działaniami – pozwoli to się wycofać w razie potrzeby.

Przygotuj czystą bazę (bez obcych tabel), zapisz aktualne dane dostępowe (host, nazwa bazy, użytkownik, hasło), a po imporcie w razie innej domeny zaktualizujesz rekordy URL. Ustal okno serwisowe i poinformuj zespół obsługi, by nie edytował treści w trakcie operacji.

Elementy, których nie nadpisywać bezrefleksyjnie

Ostrożnie z katalogami zawierającymi treści klientów (np. /img, /upload, /download) – ich nadpisanie starszą kopią może spowodować utratę plików. Podobnie z niektórymi generowanymi plikami konfiguracyjnymi – najpierw sprawdź, czy po przywróceniu nie wymagają ponownego wygenerowania w panelu.

Przywracanie bazy danych

Przygotowanie bazy: czystość i parametry

Utwórz nową, pustą bazę lub wyczyść obecną, jeśli masz pewność, że nie zawiera nic niezbędnego. Zanotuj prefiks tabel (domyślnie ps_), kodowanie (utf8mb4 zalecane) i silnik (InnoDB). Zapewnij odpowiednie limity serwera: maksymalny rozmiar uploadu i czasu wykonania – duże zrzuty mogą wymagać importu poza przeglądarką.

Jeżeli eksport pochodzi z wbudowanego modułu DB Backup, może zawierać instrukcje wyłączające ograniczenia kluczy obcych – to ułatwia import. W razie błędów kolejności tabel rozważ import sekwencyjny lub tymczasowe wyłączenie kluczy obcych.

Import przez phpMyAdmin

Wejdź do narzędzia, wybierz docelową bazę, kliknij Import i wskaż plik .sql lub .sql.gz. Upewnij się, że format to SQL, a zestaw znaków to utf8mb4 lub zgodny z eksportem. W przypadku bardzo dużych plików rozważ ich podział (np. narzędziem split) lub przejście na import przez CLI.

Po imporcie sprawdź, czy wszystkie tabele zostały utworzone, a liczba rekordów w kluczowych tabelach (ps_product, ps_orders, ps_customer) nie jest podejrzanie niska. Jeżeli pojawią się błędy duplikatów kluczy – baza mogła nie być pusta; jeżeli błędy składni – plik może być uszkodzony.

Import przez SSH (CLI)

Na serwerach z dostępem do powłoki import jest szybszy i stabilniejszy. Zaloguj się, prześlij plik SQL (SCP/SFTP), a następnie wykonaj komendę importu wskazując użytkownika, nazwę bazy i plik. Dla skompresowanych plików użyj decompression w locie. Monitoruj błędy w konsoli i logach serwera MySQL/MariaDB.

Jeżeli baza jest bardzo duża, wyłącz binlog na czas importu (gdy to możliwe), ustaw dłuższe limity czasu i buforów, a po zakończeniu włącz walidację tabel (ANALYZE/OPTIMIZE w panelu hostingu lub przez narzędzia administracyjne).

Korekta domeny i ścieżek po imporcie

Po odtworzeniu bazy z innego środowiska zaktualizuj rekordy domeny i ścieżek (tabele ps_shop_url oraz ps_configuration dla wartości PS_SHOP_DOMAIN i PS_SHOP_DOMAIN_SSL). Dopasuj base_uri w ps_shop_url, jeśli sklep działa w podkatalogu. W razie przenoszenia między http i https upewnij się, że włączone jest odpowiednie wymuszanie SSL w panelu.

Jeżeli masz multisklep, zaktualizuj domeny i ścieżki dla każdej instancji. Po zmianach wyczyść cache i sprawdź, czy nie występują pętle przekierowań wynikające z niezgodności ustawień domeny a wpisów w .htaccess lub konfiguracji serwera.

Specyfika kopii z modułu DB Backup

Wbudowany mechanizm tworzy zrzuty z instrukcjami DROP TABLE/CREATE TABLE i INSERT, najczęściej bez danych tymczasowych. Przy imporcie do pustej bazy działa to dobrze. Gdy odtwarzasz na istniejącej bazie, upewnij się, że prefiksy i nazwy tabel pokrywają się, a import nie miesza wersji struktur (różnice w schemacie między wersjami sklepu).

Jeśli zrzut podzielono na kilka plików, importuj je w odpowiedniej kolejności (najpierw struktury, potem dane). W przypadku timeoutów w przeglądarce użyj importu przez CLI, co znacznie redukuje ryzyko przerwania procesu.

Weryfikacja po imporcie

Otwórz losowe tabele i sprawdź poprawność znaków (polskie litery), porównaj liczby rekordów z poprzednimi statystykami. Skontroluj tabele logów i cache w bazie – czasem warto je wyczyścić, by nie przenosić starych błędów. Jeżeli zamierzasz odtwarzać pliki z innej daty, zanotuj potencjalne rozjazdy (np. brak zdjęć dla produktów dodanych po dacie kopii).

Przywracanie plików sklepu

Struktura katalogów i co jest krytyczne

Najważniejsze katalogi to: /modules (moduły), /themes (motyw), /img (zdjęcia), /upload i /download (pliki klientów i wgrywane), /var lub /cache (pamięć podręczna), /classes i /controllers (logika), /override (nadpisy), oraz pliki na poziomie głównym (index.php, autoload, composer). Upewnij się, że przywracasz zgodny zestaw z tą samą wersją aplikacji.

Jeżeli odtwarzasz tylko część, priorytetem są pliki unikalne dla Twojego sklepu (zdjęcia, motyw, moduły premium). Rdzeń możesz uzupełnić z oficjalnego pakietu tej samej wersji, ale nie nadpisuj bezrefleksyjnie motywu i uploadów starszą kopią.

Wgrywanie plików: sposoby i dobre praktyki

Najbezpieczniej przesłać archiwum na serwer (SFTP/Menedżer plików), wypakować po stronie serwera i podmienić katalog sklepu lub wskazane podkatalogi. To szybsze i mniej podatne na błędy niż masowe przesyłanie przez FTP. Zachowaj kopię obecnego katalogu jako _bak przed nadpisaniem.

Jeżeli pracujesz przez FTP, włącz wznawianie i weryfikację sum kontrolnych (jeśli klient wspiera). Unikaj mieszania starych i nowych wersji – najlepiej usuń pliki rdzenia i wgraj je z kopii, pozostawiając uploady, a następnie dodaj moduły i motyw ze spójnej daty kopii.

Plik config i dane dostępowe

W wersjach 1.7/8 kluczowe ustawienia znajdują się w app/config/parameters.php, w 1.6 – w config/settings.inc.php. Zaktualizuj dane połączenia z bazą (host, nazwa, użytkownik, hasło), prefiks, a także klucze kryptograficzne (cookie, hashing). To właśnie część odpowiedzialna za konfiguracja sklepu po stronie aplikacji.

Jeżeli przenosisz sklep na inną domenę, po imporcie bazy i dopasowaniu rekordów URL niektóre ścieżki mogą wciąż wskazywać na stare zasoby. Wtedy regeneracja cache i pliku .htaccess (patrz niżej) oraz ponowne zapisanie ustawień SEO & URL zwykle rozwiązuje problem.

Uprawnienia i właściciel plików

Prawidłowe uprawnienia to fundament stabilności i bezpieczeństwa. Standardowo katalogi 755, pliki 644, właścicielem powinien być użytkownik serwera WWW (lub skonfigurowane PHP-FPM z właściwym userem). Zbyt liberalne prawa (777) narażają na ataki, a zbyt surowe powodują błędy zapisu cache, logów i uploadów.

Po wgraniu plików sprawdź możliwość tworzenia plików tymczasowych i logów. Jeżeli widzisz błędy 403/500 przy zapisie miniatur lub kompilacji szablonu, skoryguj właściciela i prawa dla /var (lub /cache) oraz /img, /upload.

Czyszczenie i odbudowa pamięci podręcznej

Usuń zawartość katalogów pamięci podręcznej: var/cache/prod i var/cache/dev (w 1.7/8) lub cache/smarty/compile i cache/smarty/cache (w 1.6). To często natychmiast naprawia błędy po przenosinach. Pamiętaj, że cache może przechowywać stare ścieżki i konfiguracje, więc zawsze czyść go po przywróceniu.

W back office włącz rekompilację szablonów na czas testów, a po zakończeniu wróć do kompilacji na żądanie lub w trybie produkcyjnym. Jeżeli używasz dodatkowych warstw cache (Varnish, Redis, CDN), opróżnij je również.

Regeneracja .htaccess i adresów przyjaznych

W panelu Sklep > SEO i URL wyłącz, zapisz, a następnie włącz ponownie przyjazne adresy. Mechanizm wygeneruje świeży plik .htaccess z poprawnymi regułami. Na serwerach Nginx zrewiduj konfigurację vhost, aby odzwierciedlała bieżący katalog i index front controllera.

Jeżeli po regeneracji nadal występują pętle redirectów, sprawdź ustawienia wymuszania SSL oraz reguły przepisywania w konfiguracji serwera. Często pomocne jest usunięcie starego pliku i ponowne wygenerowanie go z panelu.

Czynności po przywróceniu i testy

Logowanie do zaplecza i reset hasła

Wejdź do panelu administracyjnego. Jeśli logowanie się nie udaje, zresetuj hasło przez mechanizm e-mail lub – awaryjnie – modyfikując rekord w tabeli administratorów, pamiętając o właściwym algorytmie hash. Sprawdź, czy zmiana adresu URL panelu (losowy sufiks) pozostała taka sama jak przed kopią.

Przejdź po najważniejszych sekcjach zaplecza: Zamówienia, Klienci, Katalog, Moduły. Weryfikuj, czy liczby zgadzają się z tym, co oczekujesz po odtworzeniu z konkretnej daty.

Tryb konserwacji, domeny i warstwy pośrednie

Wciąż trzymaj sklep w trybie konserwacji dla klientów. Skontroluj ustawienia domen (z SSL), a jeśli korzystasz z CDN i zapór (np. Cloudflare, WAF), oczyść cache i tryb Development/Bypass, by nie oglądać przestarzałych odpowiedzi. Upewnij się, że rekordy DNS wskazują docelowy serwer i że propagacja nie koliduje z testami.

Jeżeli włączone są systemy kolejkowania e-mail (SMTP, zewnętrzne API), wykonaj test wysyłki, ale unikaj masowego wysyłania powiadomień w czasie testów – tymczasowo wyłącz transakcyjne mailingi w modułach.

Testy krytycznej ścieżki zakupowej

Przeprowadź kompletny scenariusz: wyświetlenie strony głównej, listy i karty produktu, dodanie do koszyka, rejestracja/logowanie, checkout, wybór dostawy i płatności, finalizacja i generacja dokumentu (faktura/paragon), potwierdzenia e-mail. Zrób to w różnych przeglądarkach i urządzeniach.

Sprawdź konfiguracje przewoźników, stref, walut i modułów płatności (sandbox/test). Jeżeli moduł płatności nie działa, często pomaga jego ponowna instalacja lub wgranie zgodnej wersji z daty kopii. Pamiętaj o testach kuponów, kombinacji produktów i magazynu.

Odbudowa indeksów, miniatur i wyszukiwania

W panelu zregeneruj miniatury (Katalog > Zdjęcia) – po przenosinach ścieżki mogły się zmienić. Odbuduj indeks wyszukiwania produktów. Jeżeli masz duży katalog, rozważ uruchamianie w partiach, by uniknąć timeoutów. Monitoruj logi błędów i użycie zasobów.

Włącz ponownie optymalizacje: kompilację CSS/JS, cache Smarty, opcjonalnie CDN. Upewnij się, że mapy witryny i robots.txt są spójne z domeną – wyślij ponownie sitemap do narzędzi dla webmasterów.

Bezpieczeństwo po przywróceniu

Zweryfikuj uprawnienia administratorów i ról, usuń zbędne konta techniczne. Jeżeli to możliwe, zmień adres URL panelu i klucze bezpieczeństwa. Sprawdź, czy katalog /install nie istnieje, a tryb developerski jest wyłączony. Upewnij się, że kopie zapasowe nie są dostępne publicznie w katalogu serwera.

Skonfiguruj alerty błędów i logów. Jeżeli odtwarzałeś po incydencie bezpieczeństwa, wykonaj skan plików pod kątem złośliwych wstawek, zaktualizuj moduły i rdzeń do wersji pozbawionej znanych luk – ale dopiero po pełnym i sprawnym przywróceniu.

Scenariusze specjalne i rozwiązywanie problemów

Migracja na inny serwer lub domenę

Przy zmianie serwera dopasuj wersję PHP i moduły (intl, zip, gd, curl). Zaktualizuj limity (memory_limit, max_execution_time) zgodnie z rozmiarem katalogu i bazy. Domena: po imporcie bazy popraw ps_shop_url i konfiguracje domen, zregeneruj .htaccess oraz wyczyść cache. Pamiętaj o ustawieniu właściwego katalogu dokumentów (docroot) w panelu hostingu.

Zmniejsz TTL rekordów DNS przed migracją, aby szybciej przełączyć ruch. Po przepięciu monitoruj logi błędów i 404 – szybko wychwycisz brakujące pliki i niewłaściwe przekierowania.

Multisklep: wiele domen i kontekstów

Jeżeli używasz multistore, przywracanie wymaga zachowania układu sklepów (tabele ps_shop, ps_shop_url, ps_shop_group). Podczas testów przełączaj konteksty w back office i weryfikuj, czy każdy sklep ma właściwą domenę, motyw i moduły. Pamiętaj o oddzielnej regeneracji miniatur i map witryny dla każdego sklepu.

Ustal, czy katalogi motywów i modułów są współdzielone, czy dedykowane per sklep. Rozjazdy między bazą a plikami któregoś sklepu potrafią objawiać się wybiórczo tylko w jednym kontekście.

Konflikty wersji i błędy 500

Biały ekran lub 500 po przywróceniu zwykle oznacza konflikt wersji rdzenia z modułami, brakujące rozszerzenia PHP lub złe uprawnienia. Tymczasowo włącz tryb debug (odpowiednie stałe w konfiguracji), aby zobaczyć stack trace. Wyłączaj podejrzane moduły, usuń katalog /var/cache, napraw właściciela plików.

Jeżeli problem dotyczy nadpisów (override), zmień nazwę katalogu /override i sprawdź, czy sklep ruszy. Następnie przywróć wybrane pliki override selektywnie. Konflikty composer/autoload rozwiąż przez wgranie kompletnego zestawu rdzenia zgodnego z bazą i odświeżenie vendor.

Odtwarzanie z panelu hostingu i automatycznych kopii

Wielu dostawców hostingu oferuje automatyczne snapshoty plików i baz. W panelu wybierz datę kopii, przywróć bazę do wskazanej instancji oraz pliki do katalogu docelowego lub alternatywnego (na potrzeby testów). Uważaj, by nie nadpisać aktywnych danych niezamierzenie – często dostępna jest opcja przywrócenia do osobnego katalogu.

Jeżeli sklep był instalowany przez instalator (np. Softaculous), możesz skorzystać z jego funkcji restore. Miej jednak świadomość, że nie zawsze przywraca niestandardowe zasoby (zewnętrzne katalogi, dodatkowe cron’y). Po takim przywróceniu i tak wykonaj ręczną weryfikację domen i .htaccess.

Braki w kopii i odzyski awaryjne

Gdy masz tylko bazę, a brakuje plików, pobierz czysty pakiet tej samej wersji i dołącz motyw oraz moduły z dostępnych źródeł. Zdjęcia produktów czasem da się częściowo odtworzyć z miniaturek lub z archiwum CDN. Gdy masz tylko pliki, ale brak bazy – sprawdź, czy hosting utrzymuje backupy binlogów lub wykonywał mrożenie woluminów.

W sytuacjach mieszanych rozważ przywrócenie najpierw rdzenia i panelu, a następnie import selektywny kluczowych tabel (produkty, zamówienia, klienci). To wymaga ostrożności przy spójności kluczy i prefiksów, ale bywa jedyną drogą do minimalnego uruchomienia sprzedaży.

Automatyzacja i testy odtwarzania na przyszłość

Skonfiguruj cykliczne kopie plików i bazy w różnych oknach czasowych (dziennie/tygodniowo), przechowuj je poza serwerem produkcyjnym. Przetestuj odtwarzanie co najmniej raz na kwartał w środowisku staging – tylko sprawdzona kopia jest wartościowa. Dokumentuj wersje PHP, modułów i zależności.

Dodaj monitorowanie integralności (sumy kontrolne), rotację i szyfrowanie kopii. Zautomatyzuj czyszczenie starych backupów, ale zawsze utrzymuj punkt przywracania sprzed dużych zmian (aktualizacji rdzenia, modułów, motywu). Dzięki temu kolejne przywrócenie będzie krótsze i bardziej przewidywalne.