Backup i odzyskiwanie danych PrestaShop: Kompletny przewodnik

Dlaczego kopie zapasowe są ważniejsze, niż myślisz

Każdy właściciel sklepu PrestaShop myśli „mnie to nie dotyczy” — dopóki się nie wydarzy. Kopie zapasowe to najważniejsza siatka bezpieczeństwa Twojego biznesu online. Oto realne scenariusze, które regularnie zdarzają się w społeczności PrestaShop:

• Nieudana aktualizacja: Aktualizujesz sklep z PS 1.7 do 8.x. Proces zawiesza się w połowie migracji bazy danych. Twój katalog jest częściowo skonwertowany, zamówienia mają niedopasowane kolumny, a panel administracyjny się nie ładuje. Bez kopii zapasowej sprzed aktualizacji Twój sklep utkął w zawieszeniu
• Włamanie do sklepu: Atakujący wykorzystuje nieaktualny moduł, wstrzykuje backdoory i modyfikuje Twój .htaccess. Odkrywasz to dopiero po kilku dniach. Ponieważ pliki rdzenia również zostały zmodyfikowane, nie możesz stwierdzić, które pliki są czyste. Tylko kopia zapasowa sprzed włamania może przywrócić zaufanie
• Awaria hostingu: Macierz RAID Twojego hostingu ulega awarii. Ich najnowsza kopia zapasowa ma 9 dni. Twoja kopia była na tym samym serwerze. Dziewięć dni zamówień, klientów i zmian — bezpowrotnie stracone
• Przypadkowe usunięcie: Ktoś kasuje /img/p/ myśląc, że to katalog tymczasowy. Tysiące zdjęć produktów skasowane w kilka sekund

Pytanie nie brzmi czy będziesz potrzebować kopii zapasowej — tylko kiedy. Każdy tydzień, w którym działasz bez przetestowanych kopii zapasowych, to hazard z całym Twoim biznesem.

Co należy archiwizować

Baza danych (najważniejsza)

Twoja baza MySQL/MariaDB zawiera wszystko, co sprawia, że Twój sklep jest biznesem: zamówienia, konta klientów, produkty, konfigurację, reguły koszyka, dane SEO i konta pracowników. Jeśli stracisz pliki, ale zachowasz bazę danych — możesz odbudować sklep. Jeśli stracisz bazę danych — tracisz dane swojego biznesu.

Kluczowe pliki

• /modules/ — zainstalowane moduły, ich konfiguracje, szablony i przesłane zasoby
• /themes/ — aktywny motyw i motywy potomne ze wszystkimi modyfikacjami
• /img/ — zdjęcia produktów, grafiki kategorii, obrazy CMS (często największy katalog — ponad 10 GB)
• /upload/ — załączniki i pliki produktów wirtualnych
• /override/ — niestandardowe nadpisania klas rdzenia
• /app/config/parameters.php (PS 1.7+) lub /config/settings.inc.php (PS 1.6) — dane logowania do bazy danych i klucze szyfrowania
• /mails/ i /translations/ — jeśli były modyfikowane
• .htaccess, konfiguracje virtual host, nadpisania php.ini, definicje cron
• Certyfikaty SSL — jeśli zarządzasz nimi samodzielnie (nie przez Cloudflare ani hosting)

Czego NIE trzeba archiwizować

• /var/cache/ — odtwarzany automatycznie
• /var/logs/ — przydatny do debugowania, nie do odzyskiwania
• /vendor/ — można zainstalować ponownie przez composer install
• /node_modules/ — nigdy tego nie archiwizuj
• /var/sessions/ — dane tymczasowe

Metody tworzenia kopii zapasowej bazy danych

mysqldump (zalecana metoda)

Złoty standard tworzenia kopii zapasowych MySQL/MariaDB:

mysqldump \
  --single-transaction \
  --quick \
  --lock-tables=false \
  --routines \
  --triggers \
  --events \
  -u YOUR_DB_USER \
  -p'YOUR_DB_PASSWORD' \
  YOUR_DB_NAME > prestashop_$(date +%Y%m%d_%H%M%S).sql

Dlaczego każda flaga ma znaczenie:

• --single-transaction — spójny snapshot InnoDB bez blokowania tabel. Twój sklep działa dalej bez przestojów
• --quick — pobiera wiersze pojedynczo zamiast ładować całe tabele do pamięci
• --lock-tables=false — zapobiega blokowaniu tabel MyISAM, które nadal występują w niektórych starszych instalacjach PS
• --routines, --triggers, --events — uwzględnia procedury składowane, triggery i zaplanowane zdarzenia, które mogą tworzyć moduły

Nigdy nie pomijaj --single-transaction na działającym sklepie. Bez tego mysqldump blokuje tabele podczas tworzenia kopii, co może zawiesić koszyk zakupowy na sekundy lub minuty.

Eksport phpMyAdmin

Dla hostingu współdzielonego bez dostępu SSH: wybierz bazę danych, kliknij Eksportuj, wybierz metodę Niestandardowa, włącz kompresję gzip, zaznacz „Dodaj DROP TABLE” i wyeksportuj. Ograniczenie: może wystąpić timeout dla baz danych powyżej 100 MB.

Wbudowana kopia zapasowa PrestaShop

Dostępna w Zaawansowane → Kopia zapasowa BD. Wygodna do szybkiego snapshota przed zmianami, ale ma poważne ograniczenia: pomija triggery/procedury, może przekroczyć limit czasu przy dużych bazach, przechowuje kopię na tym samym serwerze, a niektóre wersje PS generują niepełne dumpy. Traktuj ją wyłącznie jako uzupełnienie.

Kompresja i automatyzacja

Dumpy SQL kompresują się o 80-90%. Zawsze przepuszczaj przez gzip:

# Backup + compress in one step
mysqldump --single-transaction --quick --lock-tables=false \
  -u USER -p'PASS' prestashop | gzip > backup_$(date +%Y%m%d).sql.gz

# Restore from compressed backup
gunzip < backup_20260228.sql.gz | mysql -u USER -p'PASS' prestashop

Automatyczna codzienna kopia zapasowa z rotacją

Ten skrypt przechowuje 7 kopii dziennych, 4 tygodniowe i 12 miesięcznych:

#!/bin/bash
# /home/user/scripts/backup-db.sh

DB_USER="your_db_user"
DB_PASS="your_db_password"
DB_NAME="prestashop"
BACKUP_DIR="/home/user/backups/database"
DATE=$(date +%Y%m%d_%H%M%S)
DAY_OF_WEEK=$(date +%u)
DAY_OF_MONTH=$(date +%d)

mkdir -p "$BACKUP_DIR"/{daily,weekly,monthly}

# Take the backup
mysqldump --single-transaction --quick --lock-tables=false \
  --routines --triggers \
  -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" \
  | gzip > "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz"

if [ $? -ne 0 ]; then
    echo "BACKUP FAILED at $(date)" | mail -s "BACKUP FAILED" your@email.com
    exit 1
fi

# Weekly snapshot (Sunday)
[ "$DAY_OF_WEEK" -eq 7 ] && cp "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz" \
  "$BACKUP_DIR/weekly/prestashop_weekly_${DATE}.sql.gz"

# Monthly snapshot (1st of month)
[ "$DAY_OF_MONTH" -eq "01" ] && cp "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz" \
  "$BACKUP_DIR/monthly/prestashop_monthly_${DATE}.sql.gz"

# Rotation
find "$BACKUP_DIR/daily/"   -name "*.sql.gz" -mtime +7   -delete
find "$BACKUP_DIR/weekly/"  -name "*.sql.gz" -mtime +28  -delete
find "$BACKUP_DIR/monthly/" -name "*.sql.gz" -mtime +365 -delete

# Add to crontab — runs daily at 3:00 AM
0 3 * * * /home/user/scripts/backup-db.sh >> /home/user/logs/backup.log 2>&1

Metody tworzenia kopii zapasowej plików

Pełna kopia zapasowa za pomocą tar

# Full backup excluding unnecessary directories
tar -czf prestashop_files_$(date +%Y%m%d).tar.gz \
  --exclude='var/cache/*' --exclude='var/logs/*' \
  --exclude='var/sessions/*' --exclude='node_modules' \
  /var/www/html/

# Critical files only (faster, smaller)
tar -czf prestashop_critical_$(date +%Y%m%d).tar.gz \
  /var/www/html/{modules,themes,img,upload,override,mails,.htaccess} \
  /var/www/html/app/config/parameters.php

Przyrostowa kopia zapasowa za pomocą rsync

Dla dużych sklepów rsync kopiuje tylko zmienione pliki — idealny dla ogromnego katalogu /img/:

# Local incremental sync
rsync -avz --delete \
  --exclude='var/cache/' --exclude='var/logs/' --exclude='var/sessions/' \
  /var/www/html/ /home/user/backups/files/current/

# Remote sync (off-site — much safer)
rsync -avz --delete \
  --exclude='var/cache/' --exclude='var/logs/' \
  -e "ssh -p 22" \
  /var/www/html/ backupuser@remote-server:/backups/prestashop/

Zdjęcia produktów w /img/p/ rzadko się zmieniają po przesłaniu, dlatego rsync jest wyjątkowo wydajny — po początkowej pełnej kopii codzienne synchronizacje przesyłają tylko nowo dodane obrazy.

Gdzie przechowywać kopie zapasowe

NIE na tym samym serwerze

To błąd numer jeden w tworzeniu kopii zapasowych. Jeśli kopie są na tym samym serwerze, awaria dysku, ransomware lub bankructwo hostingu niszczy wszystko jednocześnie. Kopie zapasowe muszą istnieć na co najmniej jednej oddzielnej lokalizacji fizycznej.

Zdalne opcje przechowywania

# Amazon S3
aws s3 sync /home/user/backups/ s3://your-bucket/prestashop/ --storage-class STANDARD_IA

# Backblaze B2 (cheaper than S3, excellent for backups)
b2 sync /home/user/backups/ b2://your-bucket/prestashop/

# Google Cloud Storage
gsutil cp backup.sql.gz gs://your-bucket/prestashop/database/

# SCP/rsync to another server
rsync -avz -e ssh /home/user/backups/ backupuser@backup-server:/backups/prestashop/

Reguła 3-2-1

Przechowuj 3 kopie danych na 2 różnych typach nośników z 1 kopią poza siedzibą. Dla PrestaShop: działający sklep + lokalna kopia na osobnym dysku + kopia w chmurze w innym regionie.

Szyfrowanie kopii zapasowych (RODO)

Kopie zapasowe baz danych zawierają dane osobowe klientów. Zgodnie z RODO musisz chronić te dane również w kopiach zapasowych:

# Encrypt with GPG
mysqldump --single-transaction --quick --lock-tables=false \
  -u USER -p'PASS' prestashop | gzip \
  | gpg --symmetric --cipher-algo AES256 --batch --passphrase "STRONG_PASSPHRASE" \
  > backup_$(date +%Y%m%d).sql.gz.gpg

# Decrypt and restore
gpg --decrypt --batch --passphrase "STRONG_PASSPHRASE" backup.sql.gz.gpg \
  | gunzip | mysql -u USER -p'PASS' prestashop

Przechowuj hasło szyfrowania w menedżerze haseł — oddzielnie od kopii zapasowych. Jeśli stracisz hasło, zaszyfrowane kopie są trwale nieodzyskiwalne.

Testowanie kopii zapasowych

Kopia zapasowa, której nie przetestowałeś, nie jest kopią zapasową. Typowe błędy, które ujawniają się dopiero podczas rzeczywistego przywracania: obcięte dumpy SQL (limit miejsca na dysku), pliki o rozmiarze 0 bajtów (wygasłe hasło do bazy), niekompatybilności wersji MySQL, brakujące uprawnienia plików, pominięte krytyczne katalogi lub zmienione klucze szyfrowania.

Jak testować

# Create a test database and restore
mysql -u root -p -e "CREATE DATABASE prestashop_test;"
gunzip < backup.sql.gz | mysql -u root -p prestashop_test

# Verify data completeness
mysql -u root -p prestashop_test -e "
  SELECT COUNT(*) AS products FROM ps_product;
  SELECT COUNT(*) AS orders FROM ps_orders;
  SELECT COUNT(*) AS customers FROM ps_customer;
  SELECT MAX(date_add) AS latest_order FROM ps_orders;
"

Aby przeprowadzić pełny test: rozpakuj kopię plików, zaktualizuj parameters.php, załaduj stronę, zweryfikuj czy strona główna ładuje się ze zdjęciami, logowanie do panelu administracyjnego działa, produkty wyświetlają się poprawnie i koszyk zakupowy funkcjonuje. Zaplanuj to co kwartał.

Plan odzyskiwania po awarii

Spisz te procedury i przechowuj je w miejscu dostępnym nawet wtedy, gdy Twój serwer jest nieosiągalny.

Scenariusz 1: Sklep całkowicie niedostępny (awaria serwera)

1. Określ zakres problemu — Twój serwer, sieć hostingu czy DNS?
2. Skontaktuj się z dostawcą hostingu; uzyskaj szacowany czas naprawy i potwierdź status danych
3. Jeśli nie da się naprawić: uruchom nowy serwer z odpowiednimi wersjami OS/PHP/MySQL
4. Przywróć pliki ze zdalnej kopii zapasowej (nie z tej na uszkodzonym serwerze)
5. Przywróć bazę danych z najnowszej kopii przechowywanej poza serwerem
6. Zaktualizuj DNS, jeśli zmienił się adres IP
7. Zweryfikuj front sklepu, panel administracyjny, koszyk zakupowy i wysyłkę e-maili

Scenariusz 2: Uszkodzona baza danych

1. Zatrzymaj serwer WWW: systemctl stop apache2
2. Spróbuj najpierw naprawy: mysqlcheck -u root -p --auto-repair prestashop
3. Jeśli naprawa się nie powiedzie, przywróć z kopii zapasowej:

   mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
   gunzip < latest_backup.sql.gz | mysql -u root -p prestashop

4. Zrestartuj serwer WWW, wyczyść cache PrestaShop
5. Oceń stratę danych — sprawdź numery zamówień i znaczniki czasu, aby zidentyfikować lukę

Scenariusz 3: Włamanie — zmodyfikowane pliki

1. Natychmiast wyłącz stronę
2. Zabezpiecz dowody: tar -czf hacked_site.tar.gz /var/www/html/
3. Zidentyfikuj wektor ataku:

   find /var/www/html/ -name "*.php" -mtime -7 -ls
   grep -rl "eval(base64_decode" /var/www/html/
   grep -rl "shell_exec" /var/www/html/modules/

4. Przywróć pliki z kopii zapasowej sprzed włamania
5. Sprawdź bazę danych pod kątem nieuprawnionych kont administracyjnych i podejrzanych zmian konfiguracji
6. Zmień WSZYSTKIE dane dostępowe: hasło do bazy, hasła administratorów, FTP, klucze SSH, klucze API
7. Zaktualizuj rdzeń PrestaShop i wszystkie moduły
8. Ściśle monitoruj przez 2-4 tygodnie — atakujący często zostawiają wiele backdoorów

Scenariusz 4: Przypadkowe usunięcie modułu/motywu

1. Wyodrębnij tylko usunięty katalog z kopii zapasowej plików:

   tar -xzf prestashop_files_backup.tar.gz \
     --directory /var/www/html/ var/www/html/modules/your_module_name/

2. Jeśli moduł został odinstalowany przez panel administracyjny (tabele bazy usunięte), przywróć również bazę danych lub zainstaluj ponownie z oryginalnego pliku ZIP
3. Wyczyść cache PrestaShop

RTO i RPO

• RTO (Recovery Time Objective) — maksymalny akceptowalny czas przestoju. RTO wynoszące 4 godziny oznacza, że proces przywracania musi zakończyć się w mniej niż 4 godziny. RTO wynoszące 15 minut wymaga zautomatyzowanej infrastruktury failover
• RPO (Recovery Point Objective) — maksymalna akceptowalna utrata danych. Codzienne kopie = 24-godzinne RPO. Sklepy o dużym wolumenie (setki zamówień dziennie) powinny dążyć do RPO wynoszącego 1-4 godziny

Oblicz swój koszt: 100 zamówień dziennie przy średniej 50 EUR = około 200 EUR/godzinę utraconych przychodów podczas przestoju, plus straty wizerunkowe i spadek pozycji SEO.

Odzyskiwanie punkt-w-czasie

Codzienne kopie zapasowe pozostawiają lukę: jeśli problem wystąpił 2 godziny temu, a ostatnia kopia była 20 godzin temu, tracisz 20 godzin danych. Logi binarne MySQL rozwiązują ten problem.

Włączenie logowania binarnego

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
log_bin = /var/log/mysql/mysql-bin
binlog_expire_logs_seconds = 604800
max_binlog_size = 100M
binlog_format = ROW

systemctl restart mysql
mysql -u root -p -e "SHOW VARIABLES LIKE 'log_bin';"  # Should show ON

Odzyskiwanie do konkretnego momentu

# 1. Restore the most recent full backup (from 3:00 AM)
gunzip < daily_backup.sql.gz | mysql -u root -p prestashop

# 2. Replay binlogs up to the moment BEFORE the problem (e.g., 14:29)
mysqlbinlog \
  --start-datetime="2026-02-28 03:00:00" \
  --stop-datetime="2026-02-28 14:29:00" \
  /var/log/mysql/mysql-bin.000042 /var/log/mysql/mysql-bin.000043 \
  | mysql -u root -p prestashop

Daje to dokładny stan bazy danych z minuty przed incydentem. Zastosowania: przypadkowe masowe usunięcia, nieudane importy lub odzyskiwanie zamówień złożonych między ostatnią kopią zapasową a awarią modułu.

Logi binarne zwiększają zużycie dysku — obciążony sklep generuje setki MB dziennie. Ustaw binlog_expire_logs_seconds tak, aby zrównoważyć możliwości odzyskiwania z przestrzenią dyskową. Siedem dni to dobra wartość domyślna.

Kopie zapasowe od hostingu: ufaj, ale weryfikuj

Większość hostingów reklamuje „codzienne kopie zapasowe”, ale rzeczywistość często wygląda inaczej:

• „Regularne kopie” mogą oznaczać tygodniowe, nie codzienne
• Przywracanie może kosztować 50-200 EUR za zlecenie i trwać 24-48 godzin
• Zazwyczaj nie można przywrócić pojedynczych plików lub tabel — przywracane jest wszystko albo nic
• Retencja często ogranicza się do 2-3 kopii
• Wiele regulaminów zawiera klauzule „nie ponosimy odpowiedzialności za utratę danych”

Jak zweryfikować: Zapytaj hosting, co dokładnie jest archiwizowane, jak często, gdzie kopie są przechowywane i ile jest zachowywanych. Następnie poproś o testowe przywracanie do tymczasowego katalogu. Sprawdź panel sterowania pod kątem dat kopii — jeśli najnowsza ma 3 tygodnie, masz problem.

Hosting współdzielony ma dodatkowe ograniczenia: kopie mogą pomijać konta powyżej 10 GB, możesz nie mieć dostępu SSH do mysqldump, a przywracanie zawsze nadpisuje aktualny stan. Uzupełniaj eksportami z phpMyAdmin i okresowym pobieraniem krytycznych katalogów przez FTP.

Traktuj kopie zapasowe hostingu jako dodatkową siatkę bezpieczeństwa, nigdy jako główną strategię. Twoje dane, Twoja odpowiedzialność.

Kompletna lista kontrolna kopii zapasowych

Wydrukuj ją i przeglądaj co kwartał.

Codziennie (automatycznie)

• ☐ Kopia zapasowa bazy danych uruchamia się przez cron i tworzy plik o rozmiarze różnym od zera
• ☐ Kopia jest skompresowana i skopiowana do zdalnego/zewnętrznego magazynu
• ☐ Stare codzienne kopie są rotowane (7 dni retencji)

Co tydzień (automatycznie)

• ☐ Uruchamia się pełna lub przyrostowa kopia plików
• ☐ Tygodniowy snapshot bazy danych jest zachowywany (4 tygodnie retencji)
• ☐ Kopia na zdalnym magazynie jest zsynchronizowana

Co miesiąc (automatycznie + ręczna weryfikacja)

• ☐ Miesięczny snapshot bazy danych jest zachowywany (12 miesięcy retencji)
• ☐ Sprawdź, czy zadania cron nadal działają (przegląd logów)
• ☐ Zweryfikuj, że zdalne magazyny zawierają aktualne pliki
• ☐ Sprawdź wolne miejsce na dysku magazynu kopii zapasowych

Co kwartał (ręcznie)

• ☐ Pełny test przywracania w środowisku testowym
• ☐ Zweryfikuj zgodność liczby rekordów z produkcją (produkty, zamówienia, klienci)
• ☐ Potwierdź, że logowanie do panelu, wyświetlanie produktów i koszyk działają
• ☐ Udokumentuj czas przywracania
• ☐ Przeglądnij i zaktualizuj plan odzyskiwania po awarii

Przed każdą dużą zmianą

• ☐ Ręczna kopia przed aktualizacją rdzenia PrestaShop
• ☐ Ręczna kopia przed instalacją/aktualizacją modułów
• ☐ Ręczna kopia przed migracjami bazy danych lub masowymi importami
• ☐ Ręczna kopia przed zmianami konfiguracji serwera

Bezpieczeństwo

• ☐ Kopie zapasowe z danymi klientów są zaszyfrowane
• ☐ Hasło szyfrowania przechowywane w menedżerze haseł (nie na serwerze)
• ☐ Zdalny magazyn używa silnego uwierzytelniania (klucze SSH lub tokeny API)
• ☐ Skrypty kopii zapasowych używają ~/.my.cnf zamiast haseł w linii poleceń
• ☐ Pliki kopii zapasowych mają chmod 600 (odczyt tylko przez właściciela)

Wskazówka: bezpieczne przechowywanie danych logowania

# Create ~/.my.cnf so backup scripts don't contain plaintext passwords
cat > ~/.my.cnf << 'EOF'
[mysqldump]
user=your_db_user
password=your_db_password
[mysql]
user=your_db_user
password=your_db_password
EOF
chmod 600 ~/.my.cnf

# Now mysqldump works without -u and -p flags
mysqldump --single-transaction --quick --lock-tables=false prestashop | gzip > backup.sql.gz

Podsumowanie

Każdy sklep PrestaShop potrzebuje co najmniej: automatycznych codziennych kopii bazy danych z 7-dniową retencją, tygodniowych kopii plików, przynajmniej jednej kopii poza serwerem, kwartalnych testów przywracania i spisanego planu odzyskiwania po awarii. Wszystko poza tym — odzyskiwanie punkt-w-czasie, szyfrowane kopie, przechowywanie wieloregionowe — skaluje się wraz z wartością Twojego sklepu.

Czas na skonfigurowanie kopii zapasowych to dziś. Godzina konfiguracji teraz może uratować cały Twój biznes w przyszłości.