Backup i restore w Magento 2

Backup to najtańsza polisa ubezpieczeniowa, której większość sklepów potrzebuje dopiero, gdy coś pójdzie nie tak. Ten poradnik pokazuje, jak konfigurować regularne kopie zapasowe Magento i jak je przywrócić.

Częstotliwość rekomendowana:

• Baza danych: codziennie (1× / dobę).
• Media files (pub/media/): tygodniowo (rzadko się zmieniają).
• Kod (kod Magento + moduły): przy każdym deploy → wystarczy git.

Backup nie ma sensu, jeśli nie jest testowany. Raz na kwartał: przywróć backup na środowisku stagingowym i sprawdź, czy działa.

Co backupować

Magento dzieli się na trzy warstwy:

Warstwa	Co zawiera	Strategia backupu
Database	Wszystkie dane (produkty, klienci, zamówienia, konfiguracja).	Codzienny mysqldump.
Media files	pub/media/ - zdjęcia produktów, banery CMS, downloads.	Tygodniowy rsync lub tar.
Kod	app/code/, vendor/, motywy, composer.json.	Git - kod jest wersjonowany, nie kopiowany.

Plus konfiguracja - pliki app/etc/env.php (env-specyficzne) i app/etc/config.php (cross-env). Te backup-uj osobno z bazą.

Metoda 1: Magento native backup

Ścieżka: Stores > Configuration > Advanced > System > Backup Settings

Pole	Wartość
Enable Backup	Yes

Po włączeniu, w System > Tools > Backups masz przyciski:

• System Backup - kod + baza + media (cały sklep).
• Database and Media Backup - baza + media.
• Database Backup - tylko baza.

Generowane backupy lądują w var/backups/.

CLI

# Tylko baza
bin/magento setup:backup --db

# Baza + media
bin/magento setup:backup --db --media

# Wszystko (baza + kod + media)
bin/magento setup:backup --db --media --code

# Backup do konkretnego pliku
bin/magento setup:backup --db --backup-file="/backup/db_$(date +%Y%m%d).sql"

Tryb maintenance podczas backupu: setup:backup automatycznie włącza tryb maintenance, robi backup, wyłącza maintenance. Sklep jest niedostępny podczas backupu (kilka minut do kilkudziesięciu, zależnie od rozmiaru).

Dla dużych sklepów rób backup w nocy (najmniejszy ruch).

Restore z backupu

# Pokaż dostępne backupy
bin/magento info:backups:list

# Restore konkretnego pliku
bin/magento setup:rollback --db-file="db_20260105_140532.sql"

# Restore + media + kod
bin/magento setup:rollback --db-file="..." --media-file="..." --code-file="..."

Metoda 2: mysqldump (zalecana dla bazy)

Magento native backup ma kilka ograniczeń (memory limits, czas wykonania w trybie maintenance). Dla produkcji zaleca się bezpośredni mysqldump:

mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  --host=localhost \
  --user=magento_user \
  --password='haslo' \
  magento_db \
  | gzip > /backup/magento_db_$(date +%Y%m%d_%H%M%S).sql.gz

Bezpieczne hasło

Nie umieszczaj hasła w komendzie (ps aux pokazuje wszystkim). Lepiej:

~/.my.cnf (chmod 600):

[client]
user=magento_user
password=haslo
host=localhost

Wtedy:

mysqldump --single-transaction magento_db | gzip > backup.sql.gz

Wyklucz tabele logów / cache

Tabele cache i logów są ogromne i nie warto ich backupować:

mysqldump --single-transaction magento_db \
  --ignore-table=magento_db.session \
  --ignore-table=magento_db.search_query \
  --ignore-table=magento_db.report_event \
  --ignore-table=magento_db.report_viewed_product_index \
  --ignore-table=magento_db.cron_schedule \
  | gzip > backup.sql.gz

To redukuje rozmiar backupu o 30-50% i przyspiesza restore.

Metoda 3: Backup mediów (rsync)

rsync -avz --delete \
  /var/www/magento/pub/media/ \
  user@backup-server:/backups/magento/media/

Przy regularnym uruchamianiu rsync przenosi tylko zmiany - bardzo wydajne.

Backup pełny tar (raz w miesiącu)

tar -czf /backup/media_$(date +%Y%m).tar.gz \
  --exclude='*/cache/*' \
  --exclude='*/tmp/*' \
  /var/www/magento/pub/media/

Harmonogram cron

/etc/cron.d/magento-backup:

# Backup bazy codziennie o 2:00
0 2 * * * www-data /usr/local/bin/magento-backup-db.sh

# Backup mediów co tydzień w niedzielę o 4:00
0 4 * * 0 www-data /usr/local/bin/magento-backup-media.sh

Przykładowy skrypt /usr/local/bin/magento-backup-db.sh:

#!/bin/bash
set -e

BACKUP_DIR=/backup/magento
DATE=$(date +%Y%m%d_%H%M%S)
RETENTION_DAYS=30

mkdir -p "$BACKUP_DIR"

# Backup
mysqldump --single-transaction --quick magento_db \
  --ignore-table=magento_db.session \
  --ignore-table=magento_db.cron_schedule \
  | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

# Cleanup starsze niż 30 dni
find "$BACKUP_DIR" -name "db_*.sql.gz" -mtime +$RETENTION_DAYS -delete

# Powiadomienie do Slack / email (opcjonalnie)
echo "Magento DB backup: $DATE OK ($(du -h $BACKUP_DIR/db_$DATE.sql.gz | cut -f1))" \
  | mail -s "Magento Backup" [email protected]

Off-site backup (kopia poza serwerem)

Backup tylko na tym samym serwerze → praktycznie bez wartości (awaria dysku = utrata wszystkiego).

Rozwiązania off-site:

Metoda	Zalety	Wady
AWS S3	Pewne, tanie, szyfrowanie at-rest.	Wymaga konfiguracji IAM.
Backblaze B2	Bardzo tanie ($0.006/GB/mc).	Mniej znane, ale solidne.
Dropbox / Google Drive	Łatwe.	Niezalecane dla produkcji (limity, prywatność).
rsync na drugi serwer	Pełna kontrola.	Wymaga drugiego serwera.

Przykład: backup do S3

# After backup
aws s3 cp /backup/magento/db_$DATE.sql.gz \
  s3://magento-backups/db/db_$DATE.sql.gz \
  --storage-class STANDARD_IA

Encryption

Wrażliwe dane (PII klientów, dane karty) muszą być szyfrowane podczas backupu off-site:

mysqldump magento_db | gzip | \
  gpg --encrypt --recipient [email protected] > backup.sql.gz.gpg

Restore - krok po kroku

Database restore

# 1. Włącz maintenance mode
bin/magento maintenance:enable

# 2. Drop & recreate database
mysql -e "DROP DATABASE magento_db; CREATE DATABASE magento_db CHARACTER SET utf8mb4;"

# 3. Restore
gunzip < /backup/db_20260105.sql.gz | mysql magento_db

# 4. Setup upgrade (na wypadek różnic w wersjach)
bin/magento setup:upgrade

# 5. Wyczyść cache + reindex
bin/magento cache:flush
bin/magento indexer:reindex

# 6. Wyłącz maintenance
bin/magento maintenance:disable

Media restore

# Stop web server (opcjonalne - żeby nikt nie modyfikował mediów w trakcie)
sudo systemctl stop nginx

# Restore
tar -xzf /backup/media_202601.tar.gz -C /

# Permissions
sudo chown -R www-data:www-data /var/www/magento/pub/media/

# Restart web server
sudo systemctl start nginx

Disaster recovery - testowanie

Backup nie jest backupem, dopóki nie został przywrócony. Plan kwartalnego testu:

1. Sklonuj produkcję na staging (kod + baza + media).
2. Symulacja awarii - usuń bazę / wyczyść media na stagingu.
3. Restore z najnowszego backupu - pełen proces.
4. Weryfikacja - sprawdź losowe 5 produktów, 5 zamówień, login klienta.
5. Dokumentuj czas - ile zajęło restore, czy nie ma luk w danych.

Raport z testu (RTO - Recovery Time Objective, RPO - Recovery Point Objective) trzymaj w dokumentacji wewnętrznej.

Najczęstsze problemy

Backup setup:backup kończy się błędem "Out of memory"

PHP CLI ma niski memory_limit. Edytuj php.ini dla CLI:

memory_limit = 2048M

Lub używaj mysqldump zamiast Magento native backup.

Restore "1062: Duplicate entry"

Database nie została wyczyszczona przed restore. Drop & recreate:

DROP DATABASE magento_db;
CREATE DATABASE magento_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

Restore "Unknown collation utf8mb4_0900_ai_ci"

Backup zrobiony na MySQL 8.0, restore na MySQL 5.7 (lub MariaDB). Konwertuj:

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' backup.sql

Magento po restore nie działa - błędy "Class not found"

Brakuje setup:di:compile po restore. Uruchom:

bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush

Backup mediów trwa godzinami

Media zawierają dużo cache resized images (pub/media/catalog/product/cache/). Wyklucz je z backupu:

tar -czf media.tar.gz \
  --exclude='pub/media/catalog/product/cache/*' \
  --exclude='pub/media/captcha/*' \
  --exclude='pub/media/tmp/*' \
  /var/www/magento/pub/media/

Cache się regeneruje automatycznie z plików źródłowych.

Backup do AWS S3 - slow upload

Użyj multipart upload:

aws s3 cp big_backup.sql.gz s3://bucket/path/ \
  --expected-size 10737418240 \
  --storage-class STANDARD_IA

Lub: rclone ze zoptymalizowanymi parametrami (więcej concurrent connections).

---

Powiązane

• Magento Cron - harmonogram backupu przez cron
• Tryb utrzymania - maintenance mode podczas restore
• Logi i diagnostyka - gdzie szukać błędów backupu
• Bezpieczeństwo panelu admina - szyfrowanie backupów off-site