Knowledge Base Guide

PrestaShop Backup & Disaster Recovery: Vollständige Anleitung

Praktische Backup-Strategie für PrestaShop — mysqldump, Datei-Backups, automatisierte Cron-Jobs, Offsite-Speicherung, Testwiederherstellungen und Notfallpläne.

Warum Backups wichtiger sind, als Sie denken

Jeder PrestaShop-Shopbetreiber denkt „mir passiert das nicht“ — bis es passiert. Backups sind das wichtigste Sicherheitsnetz, das Ihr Online-Geschäft hat. Hier sind reale Szenarien, die in der PrestaShop-Community regelmäßig vorkommen:

  • Das fehlgeschlagene Upgrade: Sie aktualisieren von PS 1.7 auf 8.x. Der Prozess bricht mitten in den Datenbankmigrationen ab. Ihr Katalog ist teilweise konvertiert, Bestellungen haben nicht übereinstimmende Spalten und das Back Office lädt nicht mehr. Ohne ein Backup vor dem Upgrade befindet sich Ihr Shop im Schwebezustand
  • Der gehackte Shop: Ein Angreifer nutzt ein veraltetes Modul aus, schleust Backdoors ein und verändert Ihre .htaccess. Sie entdecken es erst Tage später. Da auch Core-Dateien verändert wurden, können Sie nicht feststellen, welche Dateien sauber sind. Nur ein Backup von vor dem Angriff kann das Vertrauen wiederherstellen
  • Die Hosting-Katastrophe: Das RAID-Array Ihres Hosters fällt aus. Dessen aktuellstes Backup ist 9 Tage alt. Ihr Backup lag auf demselben Server. Neun Tage an Bestellungen, Kunden und Änderungen — weg
  • Das versehentliche Löschen: Jemand löscht /img/p/ im Glauben, es sei ein temporäres Verzeichnis. Tausende Produktfotos, in Sekunden gelöscht
Die Frage ist nicht, ob Sie ein Backup brauchen werden — sondern wann. Jede Woche, in der Sie ohne getestete Backups arbeiten, ist ein Glücksspiel mit Ihrem gesamten Geschäft.

Was Sie sichern sollten

Die Datenbank (am wichtigsten)

Ihre MySQL/MariaDB-Datenbank enthält alles, was Ihren Shop zu einem Geschäft macht: Bestellungen, Kundenkonten, Produkte, Konfiguration, Warenkorbregeln, SEO-Daten und Mitarbeiterkonten. Wenn Sie Ihre Dateien verlieren, aber die Datenbank behalten, können Sie alles neu aufbauen. Wenn Sie die Datenbank verlieren, haben Sie Ihre Geschäftsdaten verloren.

Wichtige Dateien

  • /modules/ — installierte Module, deren Konfigurationen, Templates und hochgeladene Assets
  • /themes/ — Ihr aktives Theme und Child-Themes mit allen Anpassungen
  • /img/ — Produktbilder, Kategoriebilder, CMS-Bilder (oft das größte Verzeichnis — 10 GB+)
  • /upload/ — Anhänge und virtuelle Produktdateien
  • /override/ — individuelle Overrides für Core-Klassen
  • /app/config/parameters.php (PS 1.7+) oder /config/settings.inc.php (PS 1.6) — Datenbank-Zugangsdaten und Verschlüsselungsschlüssel
  • /mails/ und /translations/ — falls angepasst
  • .htaccess, Virtual-Host-Konfigurationen, php.ini-Überschreibungen, Cron-Definitionen
  • SSL-Zertifikate — falls selbst verwaltet (nicht über Cloudflare oder Ihren Hoster)

Was Sie NICHT benötigen

  • /var/cache/ — wird automatisch neu generiert
  • /var/logs/ — nützlich für Debugging, nicht für die Wiederherstellung
  • /vendor/ — kann über composer install neu installiert werden
  • /node_modules/ — niemals sichern
  • /var/sessions/ — temporäre Daten

Methoden zur Datenbanksicherung

mysqldump (empfohlen)

Der Goldstandard für MySQL/MariaDB-Backups:

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

Warum jedes Flag wichtig ist:

  • --single-transaction — konsistenter InnoDB-Snapshot ohne Tabellensperren. Ihr Shop bleibt ohne Ausfallzeit in Betrieb
  • --quick — ruft Zeilen einzeln ab, anstatt ganze Tabellen in den Speicher zu laden
  • --lock-tables=false — verhindert das Sperren von MyISAM-Tabellen, die einige ältere PS-Installationen noch verwenden
  • --routines, --triggers, --events — schließt Stored Procedures, Trigger und geplante Events ein, die Module möglicherweise erstellt haben
Überspringen Sie niemals --single-transaction bei einem laufenden Shop. Ohne dieses Flag sperrt mysqldump während des Backups Tabellen, was Ihren Checkout für Sekunden oder Minuten blockieren kann.

phpMyAdmin-Export

Für Shared Hosting ohne SSH: Wählen Sie Ihre Datenbank aus, klicken Sie auf Export, wählen Sie die Methode Custom, aktivieren Sie die gzip-Komprimierung, setzen Sie den Haken bei „Add DROP TABLE“ und exportieren Sie. Einschränkung: Bei Datenbanken über 100 MB kann es zu Timeouts kommen.

PrestaShop-internes Backup

Verfügbar unter Advanced Parameters → DB Backup. Praktisch für einen schnellen Snapshot vor Änderungen, aber mit ernsthaften Einschränkungen: Es überspringt Trigger/Routinen, kann bei großen Datenbanken einen Timeout verursachen, speichert das Backup auf demselben Server, und einige PS-Versionen erzeugen unvollständige Dumps. Verwenden Sie es nur als Ergänzung.

Komprimierung und Automatisierung

SQL-Dumps lassen sich um 80–90 % komprimieren. Leiten Sie die Ausgabe immer durch 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

Automatisiertes tägliches Backup mit Rotation

Dieses Skript behält 7 tägliche, 4 wöchentliche und 12 monatliche Backups:

#!/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

Methoden zur Dateisicherung

Vollständiges Backup mit 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

Inkrementelles Backup mit rsync

Für große Shops kopiert rsync nur geänderte Dateien — ideal für das riesige /img/-Verzeichnis:

# 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/

Produktbilder in /img/p/ ändern sich nach dem Hochladen nur selten, was rsync extrem effizient macht — nach der ersten vollständigen Kopie übertragen die täglichen Synchronisierungen nur neu hinzugefügte Bilder.

Wo Sie Backups speichern sollten

NICHT auf demselben Server

Das ist der häufigste Backup-Fehler. Wenn Ihre Backups auf demselben Server liegen, vernichtet ein Festplattenausfall, Ransomware oder eine Insolvenz des Hosters alles gleichzeitig. Backups müssen an mindestens einem separaten physischen Standort existieren.

Remote-Speicheroptionen

# 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/

Die 3-2-1-Regel

Halten Sie 3 Kopien Ihrer Daten auf 2 verschiedenen Speichermedien vor, wobei 1 Kopie extern aufbewahrt wird. Für PrestaShop: Ihr Live-Shop + ein lokales Backup auf einer separaten Festplatte + ein Cloud-Backup in einer anderen Region.

Backups verschlüsseln (DSGVO)

Datenbank-Backups enthalten personenbezogene Kundendaten. Gemäß der DSGVO müssen Sie diese Daten auch in Backups schützen:

# 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
Speichern Sie Ihre Verschlüsselungspassphrase in einem Passwortmanager — getrennt von den Backups. Wenn Sie die Passphrase verlieren, sind verschlüsselte Backups dauerhaft nicht wiederherstellbar.

Ihre Backups testen

Ein Backup, das Sie nicht getestet haben, ist kein Backup. Häufige Fehler, die erst bei einer echten Wiederherstellung sichtbar werden: abgeschnittene SQL-Dumps (Speicherplatzlimit), 0-Byte-Dateien (abgelaufenes DB-Passwort), MySQL-Versionsinkompatibilitäten, fehlende Dateiberechtigungen, ausgeschlossene kritische Verzeichnisse oder geänderte Verschlüsselungsschlüssel.

So testen Sie

# 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;
"

Für einen vollständigen Test: Entpacken Sie das Datei-Backup, aktualisieren Sie parameters.php, laden Sie die Seite und überprüfen Sie, ob die Startseite mit Bildern lädt, der Back-Office-Login funktioniert, Produkte korrekt angezeigt werden und der Checkout funktioniert. Planen Sie dies vierteljährlich ein.

Disaster-Recovery-Plan

Schreiben Sie diese Verfahren auf und bewahren Sie sie an einem Ort auf, der auch dann zugänglich ist, wenn Ihr Server nicht erreichbar ist.

Szenario 1: Shop komplett ausgefallen (Serverausfall)

  1. Bestimmen Sie den Umfang — Ihr Server, das Netzwerk des Hosters oder DNS?
  2. Kontaktieren Sie den Hosting-Anbieter; fordern Sie eine geschätzte Wiederherstellungszeit an und klären Sie den Datenstatus
  3. Falls nicht wiederherstellbar: Stellen Sie einen neuen Server mit passenden OS/PHP/MySQL-Versionen bereit
  4. Stellen Sie die Dateien aus Ihrem Remote-Backup wieder her (nicht aus dem auf dem defekten Server)
  5. Stellen Sie die Datenbank aus Ihrem aktuellsten externen Backup wieder her
  6. Aktualisieren Sie den DNS-Eintrag, falls sich die IP geändert hat
  7. Überprüfen Sie Front Office, Back Office, Checkout und E-Mail

Szenario 2: Datenbank beschädigt

  1. Stoppen Sie den Webserver: systemctl stop apache2
  2. Versuchen Sie zuerst eine Reparatur: mysqlcheck -u root -p --auto-repair prestashop
  3. Falls die Reparatur fehlschlägt, stellen Sie aus dem Backup wieder her: 
    mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
gunzip < latest_backup.sql.gz | mysql -u root -p prestashop
  4. Starten Sie den Webserver neu und leeren Sie den PrestaShop-Cache
  5. Bewerten Sie den Datenverlust — prüfen Sie Bestellnummern und Zeitstempel, um die Lücke zu identifizieren

Szenario 3: Gehackt — Dateien verändert

  1. Nehmen Sie die Seite sofort offline
  2. Sichern Sie die Beweise: tar -czf hacked_site.tar.gz /var/www/html/
  3. Identifizieren Sie den Angriffsvektor: 
    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. Stellen Sie die Dateien aus einem Backup wieder her, das vor dem Angriff erstellt wurde
  5. Prüfen Sie die Datenbank auf unautorisierte Admin-Konten und verdächtige Konfigurationsänderungen
  6. Ändern Sie ALLE Zugangsdaten: DB-Passwort, Admin-Passwörter, FTP, SSH-Schlüssel, API-Schlüssel
  7. Aktualisieren Sie den PrestaShop-Core und alle Module
  8. Überwachen Sie den Shop 2–4 Wochen lang genau — Angreifer hinterlassen oft mehrere Backdoors

Szenario 4: Versehentliche Modul-/Theme-Löschung

  1. Extrahieren Sie nur das gelöschte Verzeichnis aus Ihrem Datei-Backup: 
    tar -xzf prestashop_files_backup.tar.gz \
  --directory /var/www/html/ var/www/html/modules/your_module_name/
  2. Wenn das Modul über das Back Office deinstalliert wurde (DB-Tabellen entfernt), stellen Sie auch die Datenbank wieder her oder installieren Sie es aus der Original-ZIP-Datei neu
  3. Leeren Sie den PrestaShop-Cache

RTO und RPO

  • RTO (Recovery Time Objective) — maximal akzeptable Ausfallzeit. Ein RTO von 4 Stunden bedeutet, dass Ihr Wiederherstellungsprozess in unter 4 Stunden abgeschlossen sein muss. Ein RTO von 15 Minuten erfordert eine automatisierte Failover-Infrastruktur
  • RPO (Recovery Point Objective) — maximal akzeptabler Datenverlust. Tägliche Backups = 24 Stunden RPO. Shops mit hohem Volumen (Hunderte Bestellungen pro Tag) sollten ein RPO von 1–4 Stunden anstreben

Berechnen Sie Ihre Kosten: 100 Bestellungen pro Tag bei durchschnittlich 50 EUR = ca. 200 EUR/Stunde an entgangenem Umsatz während der Ausfallzeit, zuzüglich Vertraüns- und SEO-Schäden.

Point-in-Time-Wiederherstellung

Tägliche Backups hinterlassen eine Lücke: Wenn das Problem vor 2 Stunden aufgetreten ist und Ihr letztes Backup 20 Stunden alt ist, verlieren Sie 20 Stunden an Daten. MySQL Binary Logs lösen dieses Problem.

Binary Logging aktivieren

# /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

Wiederherstellung zu einem bestimmten Zeitpunkt

# 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

So erhalten Sie den exakten Datenbankzustand von einer Minute vor dem Vorfall. Anwendungsfälle: versehentliche Massenlöschungen, fehlgeschlagene Importe oder die Wiederherstellung von Bestellungen, die zwischen dem letzten Backup und einem Modulausfall eingegangen sind.

Binlogs erhöhen den Speicherverbrauch — ein stark frequentierter Shop erzeugt Hunderte MB pro Tag. Passen Sie binlog_expire_logs_seconds an, um Wiederherstellungsfähigkeit und Speicherplatz auszubalancieren. Sieben Tage sind ein guter Standardwert.

Backups des Hosting-Anbieters: Vertrauen ist gut, Kontrolle ist besser

Die meisten Hoster werben mit „täglichen Backups“, aber die Realität sieht oft anders aus:

  • „Regelmäßige Backups“ kann wöchentlich statt täglich bedeuten
  • Eine Wiederherstellung kann 50–200 EUR pro Anfrage kosten und 24–48 Stunden dauern
  • Sie können in der Regel keine einzelnen Dateien oder Tabellen wiederherstellen — es ist alles oder nichts
  • Die Aufbewahrung ist oft auf 2–3 Kopien begrenzt
  • Viele AGB enthalten Klauseln wie „keine Haftung für Datenverlust“

Zur Überprüfung: Fragen Sie Ihren Hoster, was gesichert wird, wie oft, wo die Backups gespeichert werden und wie viele aufbewahrt werden. Fordern Sie dann eine Testwiederherstellung in ein temporäres Verzeichnis an. Prüfen Sie Ihr Control Panel auf Backup-Daten — wenn das neüste 3 Wochen alt ist, haben Sie ein Problem.

Shared Hosting hat zusätzliche Einschränkungen: Backups können Accounts über 10 GB überspringen, Sie haben möglicherweise keinen SSH-Zugang für mysqldump, und eine Wiederherstellung überschreibt immer Ihren aktuellen Stand. Ergänzen Sie dies mit phpMyAdmin-Exporten und regelmäßigen FTP-Downloads kritischer Verzeichnisse.

Betrachten Sie die Backups Ihres Hosters als zusätzliches Sicherheitsnetz, niemals als Ihre primäre Strategie. Ihre Daten, Ihre Verantwortung.

Vollständige Backup-Checkliste

Drucken Sie diese aus und überprüfen Sie sie vierteljährlich.

Täglich (automatisiert)

  • ☐ Datenbank-Backup läuft per Cron und erzeugt eine Datei größer als null Bytes
  • ☐ Backup wird komprimiert und auf Remote-/externen Speicher kopiert
  • ☐ Alte tägliche Backups werden rotiert (7 Tage aufbewahren)

Wöchentlich (automatisiert)

  • ☐ Vollständiges oder inkrementelles Datei-Backup läuft
  • ☐ Wöchentlicher Datenbank-Snapshot wird aufbewahrt (4 Wochen aufbewahren)
  • ☐ Remote-Speicherkopie wird synchronisiert

Monatlich (automatisiert + manuelle Prüfung)

  • ☐ Monatlicher Datenbank-Snapshot wird aufbewahrt (12 Monate aufbewahren)
  • ☐ Prüfen, ob Cron-Jobs noch laufen (Logs überprüfen)
  • ☐ Überprüfen, ob der Remote-Speicher aktuelle Dateien enthält
  • ☐ Speicherplatz auf dem Backup-Speicher prüfen

Vierteljährlich (manuell)

  • ☐ Vollständige Testwiederherstellung in einer Staging-Umgebung
  • ☐ Datensätze mit der Produktion abgleichen (Produkte, Bestellungen, Kunden)
  • ☐ Bestätigen, dass Back-Office-Login, Produktanzeige und Checkout funktionieren
  • ☐ Wiederherstellungszeit dokumentieren
  • ☐ Disaster-Recovery-Plan überprüfen und aktualisieren

Vor jeder größeren Änderung

  • ☐ Manuelles Backup vor PrestaShop-Core-Upgrades
  • ☐ Manuelles Backup vor Modulinstallationen/-updates
  • ☐ Manuelles Backup vor Datenbankmigrationen oder Massenimporten
  • ☐ Manuelles Backup vor Server-Konfigurationsänderungen

Sicherheit

  • ☐ Backups mit Kundendaten sind verschlüsselt
  • ☐ Verschlüsselungspassphrase in einem Passwortmanager gespeichert (nicht auf dem Server)
  • ☐ Remote-Speicher verwendet starke Authentifizierung (SSH-Schlüssel oder API-Tokens)
  • ☐ Backup-Skripte verwenden ~/.my.cnf statt Inline-Passwörter
  • ☐ Backup-Dateien sind chmod 600 (nur für den Besitzer lesbar)

Tipp: Sichere Speicherung von Zugangsdaten

# 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

Abschließende Gedanken

Jeder PrestaShop-Shop braucht mindestens: automatisierte tägliche Datenbank-Backups mit 7-Tage-Aufbewahrung, wöchentliche Datei-Backups, mindestens eine externe Kopie, vierteljährliche Wiederherstellungstests und einen schriftlichen Disaster-Recovery-Plan. Alles darüber hinaus — Point-in-Time-Wiederherstellung, verschlüsselte Backups, Multi-Region-Speicher — skaliert mit dem Wert Ihres Shops.

Der richtige Zeitpunkt, um Backups einzurichten, ist heute. Eine Stunde Einrichtung jetzt kann später Ihr gesamtes Geschäft retten.

More guides available

Browse our knowledge base for more practical PrestaShop tutorials, or reach out if you need help.

Browse Knowledge Base Contact Us
Back to top