Shopware Backup: Anleitung, Plugins, Restore

Warum ein Shopware Backup unverzichtbar ist

Ein Shopware Backup schützt deinen Online-Shop vor Datenverlust durch Server-Ausfälle, fehlerhafte Updates oder Cyberangriffe. Ohne regelmäßige Sicherungen riskierst du den kompletten Verlust von Produktdaten, Bestellungen und Kundeninformationen. Stand Mai 2026 bietet Shopware 6 selbst keine eingebaute Backup-Funktion. Du musst sie separat einrichten.

Die Zahlen sprechen eine deutliche Sprache. Laut Ponemon Institute schließen 60% der KMUs innerhalb von sechs Monaten nach einem schweren Datenverlust. E-Commerce-Shops verlieren bei ungeplanter Downtime zwischen 50.000 und 100.000 USD pro Stunde, so Gartner. Und das betrifft nicht nur Enterprise-Shops. Ein fehlerhaftes Plugin-Update am Freitagabend reicht.

Wir sehen das bei Shopware-Shops regelmäßig: Ein Update auf eine neue Minor-Version bricht ein Custom-Plugin, die Datenbank-Migration schlägt fehl, der Shop ist offline. Wer dann kein getestetes Backup hat, steht vor einem Problem, das sich nicht mit einem Hosting-Ticket lösen lässt.

Was muss gesichert werden?

Ein vollständiges Shopware Backup umfasst drei Ebenen: das Dateisystem mit Themes und Plugins, die MySQL-Datenbank mit Produkten und Bestellungen, sowie Konfigurationsdateien wie .env und API-Keys. Fehlt eine Ebene, ist die Wiederherstellung unvollständig oder unmöglich.

Viele Shop-Betreiber sichern nur die Datenbank. Das reicht nicht. Ohne die .env-Datei fehlen Datenbankzugangsdaten und Verschlüsselungs-Keys. Ohne /custom/plugins fehlen alle Erweiterungen. Ohne /public/media fehlen sämtliche Produktbilder. Ein Restore ohne alle drei Ebenen führt zu einem Shop, der zwar startet, aber nicht funktioniert.

Bei der Shopware Installation werden diese Strukturen angelegt. Wenn du Plugins aktualisierst oder ein Shopware Update durchführst, ändert sich potenziell jede dieser drei Ebenen. Deshalb: Backup immer vor jedem Update. Die Server Anforderungen definieren, wie viel Speicherplatz du für deine Sicherungen einplanen musst.

RPO und RTO verstehen

RPO (Recovery Point Objective) definiert den maximal akzeptablen Datenverlust in Stunden, RTO (Recovery Time Objective) die maximale Wiederherstellungszeit. Für die meisten Shopware-Shops: tägliche Backups (RPO 24h) und Wiederherstellung unter 2 Stunden (RTO 2h).

Die richtige Frequenz hängt von deinem Bestellvolumen ab. Ein Shop mit 10 Bestellungen pro Tag verliert bei täglichem Backup maximal einen Tag. Ein Shop mit 500 Bestellungen pro Tag verliert im Worst Case einen fünfstelligen Betrag. Dann brauchst du stündliche Backups oder Point-in-Time Recovery (PITR).

Manuelles Backup per SSH erstellen

Ein manuelles Shopware Backup per SSH erstellst du in zwei Schritten: Zuerst sicherst du die Datenbank mit mysqldump, dann archivierst du das Dateisystem mit tar. Beide Befehle lassen sich in einem Shell-Script kombinieren und per Cron automatisieren.

Voraussetzung: SSH-Zugang zu deinem Server. Bei Managed Hosting ist das in der Regel im Paket enthalten, bei Cloud Hosting musst du je nach Anbieter einen Key hinterlegen.

Schritt 1: Datenbank sichern

Die Zugangsdaten findest du in der .env-Datei deines Shopware-Verzeichnisses. Die Variable DATABASE_URL enthält Host, User, Passwort und Datenbankname.

# Datenbank-Zugangsdaten aus .env lesen
cat .env | grep DATABASE_URL
# Ergebnis: mysql://user:passwort@host:3306/dbname

# MySQL-Dump erstellen
mysqldump --opt --no-tablespaces \
  -h localhost -u shopware_user -p shopware_db \
  > backup_$(date +%Y%m%d_%H%M%S).sql

Der Parameter --no-tablespaces verhindert Rechteprobleme auf Shared-Hosting. Mit --opt aktivierst du Optimierungen wie --add-drop-table und --lock-tables, die den Restore beschleunigen. Bei großen Datenbanken (über 2 GB) füge --single-transaction hinzu, um den Shop während des Dumps nicht zu blockieren.

Schritt 2: Dateisystem archivieren

# Ins übergeordnete Verzeichnis wechseln
cd /var/www/

# Komplettes Shop-Verzeichnis archivieren
tar czf "shopware_backup_$(date +%Y%m%d_%H%M%S).tar.gz" shopware/

# Alternative: Nur kritische Verzeichnisse (schneller)
tar czf "shopware_files_$(date +%Y%m%d).tar.gz" \
  shopware/.env \
  shopware/custom/plugins/ \
  shopware/config/ \
  shopware/public/media/

Automatisierung per Cron

Ein kombiniertes Backup-Script mit Cron-Job macht die manuelle Arbeit überflüssig. Das folgende Script sichert Datenbank und Dateisystem, komprimiert alles in ein Archiv und löscht Backups älter als 14 Tage.

#!/bin/bash
# shopware-backup.sh - Tägliches Backup mit Rotation
BACKUP_DIR="/var/backups/shopware"
SHOP_DIR="/var/www/shopware"
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p $BACKUP_DIR

# Datenbank sichern
mysqldump --opt --no-tablespaces --single-transaction \
  -h localhost -u shopware_user -p'DEIN_PASSWORT' shopware_db \
  | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

# Dateisystem sichern (ohne media)
tar czf "$BACKUP_DIR/files_$DATE.tar.gz" \
  --exclude='public/media' \
  -C /var/www shopware/

# Alte Backups löschen (älter als 14 Tage)
find $BACKUP_DIR -type f -mtime +14 -delete

echo "Backup abgeschlossen: $DATE"

# Cron-Job einrichten (täglich um 03:00 Uhr)
crontab -e
# Folgende Zeile einfügen:
0 3 * * * /usr/local/bin/shopware-backup.sh >> /var/log/shopware-backup.log 2>&1

Backup mit Plugins automatisieren

Shopware Backup-Plugins automatisieren die Sicherung von Datenbank und Medien auf externe Speicher. Sie eignen sich für Shop-Betreiber ohne SSH-Zugang oder ohne Linux-Kenntnisse. Stand Mai 2026 gibt es im Shopware Store zwei relevante Optionen.

Ich halte Plugins für eine gute Lösung, wenn du keinen SSH-Zugang hast oder das Backup nicht selbst scripten willst. Für Shops mit über 5 GB Medien wird es allerdings langsam, weil die Plugins den PHP-Prozess für die Archivierung nutzen. Ab dieser Größe ist ein serverseitiges Script per Cron die zuverlässigere Wahl.

Wichtig: Kein Plugin ersetzt den Restore-Test. Ob das Backup tatsächlich funktioniert, weißt du erst, wenn du es einmal vollständig wiederhergestellt hast.

Die 3-2-1 Backup-Regel

Die 3-2-1 Backup-Regel bedeutet: 3 Kopien deiner Daten, auf 2 verschiedenen Medientypen, davon 1 an einem externen Standort. Das BSI empfiehlt diese Regel explizit als Basismaßnahme gegen Ransomware.

Für einen Shopware-Shop sieht das konkret so aus: Kopie 1 liegt auf dem Server selbst (schneller Zugriff für Restore). Kopie 2 geht auf einen externen S3-Bucket oder SFTP-Server. Kopie 3 wird lokal heruntergeladen oder auf einen zweiten Cloud-Anbieter gespiegelt. Bei Managed Hosting übernimmt der Anbieter oft Kopie 1 und 2. Kopie 3 liegt in deiner Verantwortung.

Die erweiterte Variante ist 3-2-1-1: Die zusätzliche 1 steht für eine immutable Kopie, die auch bei einem Ransomware-Angriff nicht verschlüsselt werden kann. AWS S3 Object Lock oder Backblaze B2 mit Retention bieten das. Kostet wenige Euro pro Monat, schützt aber vor dem Worst Case.

Backup wiederherstellen (Restore)

Die Wiederherstellung eines Shopware Backups erfolgt in umgekehrter Reihenfolge: Zuerst importierst du die Datenbank mit mysql, dann entpackst du das Dateisystem. Danach müssen Cache geleert und Datenbankmigrationen geprüft werden.

Datenbank importieren

# SQL-Dump entpacken (falls komprimiert)
gunzip backup_db_20260524.sql.gz

# Datenbank importieren
mysql -h localhost -u shopware_user -p shopware_db < backup_db_20260524.sql

# Bei neuer Datenbank: Zugangsdaten in .env anpassen
nano /var/www/shopware/.env
# DATABASE_URL="mysql://user:pass@host:3306/neue_db"

Dateisystem wiederherstellen

# Aktuellen Shop-Ordner umbenennen (nicht löschen!)
mv /var/www/shopware /var/www/shopware_defekt

# Backup entpacken
tar xzf shopware_backup_20260524.tar.gz -C /var/www/

# Cache leeren
cd /var/www/shopware
bin/console cache:clear

# Datenbankmigrationen prüfen
bin/console database:migrate --all

Nach dem Restore: Shop im Browser testen. Prüfe Produktseiten, den Checkout-Prozess und das Admin-Panel. Wenn Bilder fehlen, liegt /public/media nicht im Backup oder der Medienpfad in der Datenbank stimmt nicht mehr. In dem Fall: Medien separat wiederherstellen oder den Asset-Pfad in .env korrigieren.

Restore-Tests einplanen

Ein Backup ohne Restore-Test ist wertlos. Laut der DATA REVERSE KMU-Backup-Studie 2025 prüfen 72% der KMUs nie, ob ihre Backups im Ernstfall funktionieren. Plane einen monatlichen Test ein: Restore auf einer Staging-Umgebung, kurzer Funktionscheck, Ergebnis dokumentieren. 30 Minuten Aufwand, die im Ernstfall Tage sparen.

Warum KI-Shops bessere Backups brauchen

Shops mit KI-gestützter KI-Produktberatung erzeugen zusätzliche Datenströme: Konversationshistorien, Kundenpräferenzen, trainierte Modellkonfigurationen. Diese Daten liegen teilweise außerhalb der Standard-Shopware-Datenbank und werden von einem einfachen mysqldump nicht erfasst.

Unser Kunde Rasendoktor verarbeitet mit seinem KI-Mitarbeiter Hektor hunderte Produktberatungen täglich. Die Konversationsdaten fließen in die Optimierung der Empfehlungen. Ein Backup, das diese Daten nicht einschließt, würde bei einem Restore bedeuten: Der KI-Mitarbeiter verliert sein Gedächtnis über Kundenpräferenzen und Saisonmuster. Das ist kein theoretisches Szenario.

Für Shops mit KI-Integration: Prüfe, welche Daten dein KI-System außerhalb der Shopware-Datenbank speichert. API-Konfigurationen, Trainingsdaten, Embedding-Vektoren. Diese Systeme brauchen ein eigenes Backup-Konzept parallel zur Shopware-Sicherung.

Häufige Fragen zum Shopware Backup