Backups und Staging in Shopware: sicher entwickeln

Viele Shopware-Betreiber denken beim Thema Backups erst dann daran, wenn es zu spät ist. Ein fehlgeschlagenes Plugin-Update, eine versehentlich gelöschte Datenbanktabelle oder ein kompromittierter Server, und plötzlich sind Stunden, Tage oder im schlimmsten Fall Jahre an Produktdaten, Bestellhistorie und Konfiguration weg. Staging ist das andere Sicherheitsnetz: Es sorgt dafür, dass Änderungen zuerst auf einer Kopie des Live-Systems getestet werden, bevor sie echten Traffic und echte Bestellungen gefährden. Beides gehört zu einer professionellen Shopware-Infrastruktur, und beides wird in der Praxis häufiger vernachlässigt als man denken würde.

Was ein vollständiges Shopware-Backup beinhaltet

Ein Shopware-Shop besteht aus zwei voneinander unabhängigen Bereichen, die beide gesichert werden müssen. Wer nur einen davon sichert, hat im Ernstfall eine unbrauchbare Wiederherstellung.

Datenbank: Hier liegen alle Bestellungen, Kunden, Produkte, Kategorien, Preise, Konfigurationen, Plugin-Einstellungen und CMS-Inhalte. Ein MySQL-Dump der gesamten Shopware-Datenbank ist der kritischste Bestandteil jedes Backups. Die Datei wächst je nach Shop-Größe von wenigen Megabyte bis zu mehreren Gigabyte. Wichtig: Shopware kann optional Elasticsearch oder OpenSearch als Suchindex nutzen. Dieser Index lässt sich jederzeit aus der Datenbank neu aufbauen und muss nicht zwingend gesichert werden.

Dateisystem: Dazu zählen das Shopware-Verzeichnis mit dem Core, allen Plugins und dem Theme, sowie das Verzeichnis public/media mit allen hochgeladenen Bildern und Dokumenten. Die Shopware-eigenen Core-Dateien können im Notfall neu heruntergeladen werden, aber individuelle Anpassungen, Custom-Plugins und Media-Assets nicht.

Ein vollständiges Backup umfasst also: Datenbank-Dump plus /var/www/html (oder dein jeweiliges Web-Root) einschließlich aller Unterverzeichnisse.

Backup-Strategien: Was wann sinnvoll ist

Nicht jeder Backup-Ansatz passt zu jedem Shop. Es gibt drei Hauptstrategien, die sich in der Praxis bewährt haben.

Full-Backup: Eine vollständige Sicherung aller Daten. Einfach in der Wiederherstellung, aber speicherintensiv und bei großen Shops langsam. Für kleine bis mittelgroße Shops mit moderatem Media-Volumen die unkomplizierteste Lösung.

Inkrementelles Backup: Es wird nur gesichert, was sich seit dem letzten Backup geändert hat. Spart Speicher und Zeit, macht die Wiederherstellung aber aufwendiger, weil mehrere Backup-Generationen zusammengespielt werden müssen. Sinnvoll bei Shops mit vielen Gigabyte an Media-Assets.

Datenbankbasiertes Snapshot-Backup: Moderne Hosting-Infrastrukturen (z.B. Hetzner, IONOS Managed Hosting, AWS RDS) bieten automatische Datenbank-Snapshots an, die auf Serverebene gezogen werden, ohne den laufenden Betrieb zu unterbrechen. Ergänzt durch ein tägliches Dateisystem-Backup ergibt sich damit ein solides Gesamtkonzept.

Was die Aufbewahrung betrifft: Mindestens 7 tägliche Backups, besser 30. Wöchentliche und monatliche Backups sollten zusätzlich aufbewahrt werden. Denn oft fällt ein Datenverlust nicht sofort auf. Ein Kunde ruft drei Wochen später an und fragt, wo sein Kundenkonto geblieben ist. Dann brauchst du den Stand von vor drei Wochen, nicht von gestern.

Mehr zu den Infrastruktur-Grundlagen findest du im Artikel Shopware Hosting: Anforderungen und die richtige Wahl.

Automatisiert statt manuell: Backups ohne Zutun

Manuelle Backups, die jemand per SSH oder im Admin-Panel auslöst, sind kein verlässliches Sicherheitsnetz. Sie werden vergessen, gerade dann, wenn es am kritischsten wäre, also kurz vor einem Update oder einer größeren Konfigurationsänderung.

Die saubere Lösung ist eine automatisierte Backup-Pipeline:

• Ein Cron-Job läuft täglich nachts und zieht einen mysqldump der Shopware-Datenbank.
• Ein zweiter Cron-Job synchronisiert das Dateisystem auf ein externes Speicherziel. Gängige Lösungen sind S3-kompatible Object-Storages (z.B. Hetzner Object Storage, Amazon S3, Backblaze B2), NFS-Mounts oder ein dedizierter Backup-Server.
• Backups werden lokal auf dem Server nicht unbegrenzt aufbewahrt. Sie laufen nach einer definierten Frist ab (z.B. nach 7 Tagen lokal, nach 90 Tagen im externen Storage).
• Backup-Läufe werden protokolliert und auf Fehler überwacht. Ein Backup, das still fehlschlägt, ist kein Backup.

Anders als oft angenommen, hat der Shopware-6-Admin keine native Backup-Funktion, die Datenbank und Dateien per Klick als ZIP-Archiv exportiert. Backups laufen in der Praxis über andere Wege: einen mysqldump per CLI oder Cron, ein Datenbank-Tool wie phpMyAdmin oder Adminer, Snapshots der Hosting-Infrastruktur oder dedizierte Backup-Plugins aus dem Store. Verlass dich also nicht auf eine vermeintliche Bordmittel-Lösung, sondern richte eine der unten beschriebenen Backup-Pipelines ein.

Backups testen: Der Teil, den fast alle weglassen

Ein Backup, das noch nie wiederhergestellt wurde, ist eine Annahme, kein Sicherheitsnetz. In der Agenturpraxis erleben wir regelmäßig, dass Backups zwar angelegt wurden, aber korrupt, unvollständig oder in einem Format gespeichert sind, das kein Wiederherstellungswerkzeug mehr versteht.

Mindestens einmal pro Quartal sollte ein Restore-Test durchgeführt werden: Backup in eine temporäre Umgebung einspielen, Shop starten, prüfen ob Datenbank konsistent ist, ob Produkte angezeigt werden und ob der Checkout läuft. Das dauert je nach Infrastruktur zwei bis drei Stunden, spart aber im Ernstfall tagelange Krisenarbeit.

Staging: Entwickeln ohne Live-Risiko

Staging bezeichnet eine Testumgebung, die eine möglichst genaue Kopie des Produktivsystems ist. Änderungen werden zuerst dort eingespielt und getestet, bevor sie auf dem Live-Shop landen.

Eine Staging-Umgebung ist kein Luxus für große Agenturen. Sie ist die Grundvoraussetzung für jede Änderung, die über das Korrigieren eines Tippfehlers hinausgeht. Das betrifft Shopware Updates, Plugin-Installationen, Theme-Anpassungen, ERP-Schnittstellen, Preisregel-Konfigurationen und Custom-Code.

Ein sinnvoller Staging-Aufbau hat folgende Eigenschaften:

• Identischer Software-Stack: Gleiche PHP-Version, gleiche Shopware-Version, gleiche Plugins in denselben Versionen. Wenn auf Staging ein Test mit einer neueren PHP-Version stattfindet, muss das explizit beabsichtigt sein.
• Aktueller Datenstand: Die Staging-Datenbank wird regelmäßig aus dem Live-System übernommen. Ein Staging-System, das auf sechs Monate alten Produktdaten läuft, testet unter unrealistischen Bedingungen.
• Anonymisierte Kundendaten: Echte Kundendaten dürfen aus Datenschutzgründen nicht unkontrolliert auf Staging-Systeme kopiert werden. E-Mail-Adressen, Namen und Zahlungsdaten müssen vor der Übernahme anonymisiert werden. Das lässt sich mit einem einfachen SQL-Script automatisieren.
• Kein externer Zugriff ohne Schutz: Eine Staging-Umgebung sollte durch HTTP Basic Auth oder IP-Whitelist gesperrt sein. Öffentlich zugängliche Staging-Systeme tauchen in Suchmaschinen auf und können Duplicate-Content-Probleme verursachen. Außerdem sind sie ein Sicherheitsrisiko.

Für den Zusammenhang zwischen Staging-Tests und regulären Wartungszyklen empfiehlt sich auch ein Blick auf den Artikel Shopware Wartung: Was professionelle Pflege umfasst.

Staging-Workflow in der Praxis

Wie ein Staging-Workflow konkret aussieht, hängt von der Hosting-Infrastruktur ab. Die häufigsten Modelle:

Subdomain-Staging auf demselben Server: Das Staging-System läuft unter staging.deinshop.de auf demselben Server wie Live. Einfach einzurichten und kostengünstig, aber ein Server-Ausfall trifft beide Systeme gleichzeitig. Für die meisten mittelgroßen Shops ausreichend.

Separater Staging-Server: Live und Staging laufen auf getrennten Servern. Aufwendiger und teurer, aber realistischerer Test unter Produktionsbedingungen. Sinnvoll für Shops, die hohe Verfügbarkeit brauchen oder häufig größere Änderungen einfahren.

Branch-Deployments via CI/CD: Moderne Entwicklungsworkflows nutzen Git-basierte Deployment-Pipelines, bei denen jede Änderung in einem Feature-Branch automatisch eine temporäre Staging-Umgebung aufbaut. Nach dem Merge in den Main-Branch wird die Umgebung wieder abgebaut. Das ist der Stand der Technik für intensiv entwickelte Shops, erfordert aber entsprechendes Infrastruktur-Know-how.

Die Verbindung zur Shopware Sicherheit: Updates, Patches und Schutz liegt auf der Hand: Staging verhindert, dass ein Sicherheits-Update mit einer unentdeckten Plugin-Inkompatibilität direkt auf dem Live-System auftrifft.

Häufige Fragen

Brauche ich Staging auch als kleiner Shop?

Ja. Gerade kleine Shops haben oft keinen Puffer, wenn der Shop für mehrere Stunden ausfällt. Ein fehlerhaftes Plugin-Update, das alle Produkte unsichtbar macht, kostet je nach Tageszeit und Traffic mehrere Hundert Euro in Umsatz, noch bevor das Problem gefunden und behoben ist. Eine einfache Subdomain-Staging-Umgebung auf demselben Server kostet kaum extra und schützt vor genau diesem Szenario.

Wie oft sollte ich die Staging-Daten aus Live aktualisieren?

Das hängt vom Entwicklungsrhythmus ab. Als Faustregel gilt: Vor jedem größeren Testlauf oder jedem Update sollte ein frischer Datenbankstand aus Live eingespielt werden. Wer kontinuierlich entwickelt, zieht die Daten wöchentlich oder bei jedem Sprint-Start. Wichtig: Kundendaten dabei immer anonymisieren.

Kann ich den Shopware-Admin für Backups nutzen?

Nein, der Shopware-6-Admin bringt keine native Backup-Funktion mit. Es gibt keinen Menüpunkt, über den du Datenbank und Dateien per Klick sicherst. Backups erstellst du über die Kommandozeile (mysqldump plus Dateisystem-Sync), über Snapshots deines Hosters oder über ein dediziertes Backup-Plugin aus dem Store. Die saubere Lösung ist immer eine automatisierte, externe Backup-Pipeline mit Versionierung über mehrere Tage hinweg.

Was passiert mit Staging, wenn ich Shopware in der Cloud betreibe?

Bei Shopware Cloud (Rise, Evolve, Beyond) liegt die Infrastruktur bei Shopware. Das Angebot an Staging-Umgebungen hängt von der gebuchten Edition ab. Eigene Backup-Kontrolle und individuelle Staging-Konfigurationen sind dort eingeschränkter als auf einem selbst verwalteten Server. Wer darüber mehr erfahren will, findet im Artikel Shopware Cloud vs self-hosted: Was passt zu dir? eine ausführliche Gegenüberstellung.

Sicherheit beginnt vor dem ersten Klick

Backups und Staging sind kein Selbstzweck und auch kein Zeichen von Misstrauen gegenüber der eigenen Arbeit. Sie sind das professionelle Fundament, das erst dann sichtbar wird, wenn man es braucht. Wer beides eingerichtet hat, kann Updates, Anpassungen und Experimente mit einer deutlich entspannteren Haltung angehen.

Wenn du nicht sicher bist, ob deine aktuelle Backup-Strategie und Staging-Infrastruktur wirklich tragen, was sie soll, lohnt sich ein Blick auf unsere Shopware Betreuungspakete. Wir prüfen das im Rahmen einer regelmäßigen Betreuung und stellen sicher, dass dein Shop im Ernstfall innerhalb von Minuten, nicht Tagen, wieder läuft.