WooCommerce-Shop sichern: Backups und Wiederherstellung ohne Bestellverlust
So sichern Sie einen WooCommerce-Shop so, dass im Ernstfall keine Bestellung verloren geht: konsistente Datenbanksicherung, die richtigen Ordner, passende Häufigkeit und ein sicherer Ablauf für die Wiederherstellung.
Mit KI erstellt – redaktionelle Prüfung ausstehend
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Mehr dazu
Ein WooCommerce-Shop verändert seine Datenbank ständig: Jede Bestellung, jede Zahlung, jede Bestandsänderung landet dort. Ein Backup, das für eine reine Unternehmenswebsite genügt, reicht für einen Shop deshalb oft nicht. Wer nach einem missglückten Update die Datenbank von heute Nacht zurückspielt, verliert alle Bestellungen seitdem, und der Lagerbestand stimmt nicht mehr. Diese Anleitung zeigt, welche Daten ein WooCommerce-Shop wirklich braucht, wie Sie ein konsistentes Backup erstellen, wie häufig Sie sichern sollten und wie Sie im Ernstfall wiederherstellen, ohne Bestellungen zu verlieren.
Voraussetzungen
- WordPress 7.1 mit WooCommerce, im Test Version 11.1.2 mit der Bestellspeicherung „Leistungsstarke Speicherung von Bestellungen“ (HPOS), die laut WooCommerce seit Version 8.2 für neue Shops Standard ist.
- Ein Benutzerkonto mit der Rolle Administrator.
- SSH-Zugang mit WP-CLI für die Befehle in dieser Anleitung. Ohne SSH übernimmt ein Backup-Plugin die Sicherung, die Überlegungen zu Häufigkeit und Wiederherstellung gelten trotzdem.
- Ein Speicherort außerhalb des Webservers, etwa ein NAS, ein SFTP-Server oder ein Objektspeicher.
- Eine Testumgebung oder Kopie des Shops für die Wiederherstellungsprobe.
Schritt 1: Verstehen, wo WooCommerce Bestellungen speichert
Früher lagen Bestellungen als Beiträge in den WordPress-Tabellen wp_posts und wp_postmeta. Mit HPOS nutzt WooCommerce eigene Tabellen. Laut Entwicklerdokumentation sind das wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data und wp_wc_orders_meta. Die Bestellpositionen stehen weiterhin in wp_woocommerce_order_items und wp_woocommerce_order_itemmeta, dazu kommen Nachschlagetabellen für Statistiken. Den Lagerbestand speichert WooCommerce am Produkt, also in den Beitragstabellen.
Welche Speicherung Ihr Shop nutzt, sehen Sie unter „WooCommerce“, „Einstellungen“, „Erweitert“, „Funktionen“ im Bereich „Datenspeicher für Bestellungen“ oder per WP-CLI:
wp wc hpos statusHPOS aktiviert?: yes
Kompatibilitätsmodus aktiviert?: no
Nicht synchronisierte Bestellungen: 0
Zu bereinigende Bestellungen: 0Wichtig für jede Sicherung: Eine Bestellung verteilt sich auf viele Tabellen, und selbst mit HPOS legt WooCommerce für jede Bestellung einen Platzhalter in wp_posts an. Im Test standen dort nach zwei Bestellungen zwei Einträge vom Typ shop_order_placehold mit denselben IDs wie die Bestellungen. Bestelldaten, Bestand und Kundenkonten hängen also zusammen. Sichern Sie deshalb immer die ganze Datenbank auf einmal.
Verifizieren: Sie wissen, ob Ihr Shop HPOS nutzt, und wp db tables 'wp_wc_order*' --all-tables-with-prefix listet die Bestelltabellen auf.
Schritt 2: Die Datenbank konsistent sichern
Läuft eine Bestellung ein, während die Sicherung schreibt, kann ohne Vorkehrung ein Teil der Bestellung im Backup landen und ein anderer nicht. Die Option --single-transaction von mariadb-dump bzw. mysqldump liest alle Tabellen als einen Zeitpunkt, ohne den Shop zu sperren. Das funktioniert für Tabellen mit der Speicher-Engine InnoDB. Prüfen Sie das einmal:
wp db query "SELECT ENGINE, COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = DATABASE() GROUP BY ENGINE"Im Test waren alle 51 Tabellen InnoDB. Steht dort MyISAM, gilt die Zusage für diese Tabellen nicht. Die Sicherung selbst gibt WP-CLI an das Dump-Programm weiter:
mkdir -p ~/backups
wp db export ~/backups/shop-$(date +%F-%H%M).sql --single-transaction --path=/var/www/htmlSpeichern Sie die Datei außerhalb des Webverzeichnisses. Im Test lag eine Sicherung zur Probe unter wp-content/, und der Webserver lieferte sie auf Anfrage mit Status 200 aus, samt Kundendaten und Adressen. Bei einem Shop ist das eine Datenpanne. Mehr zu den Befehlen finden Sie in WordPress-Datenbank mit WP-CLI sichern und wiederherstellen.
Verifizieren: Die Datei existiert außerhalb des Webverzeichnisses, ist größer als null Byte und enthält CREATE TABLE `wp_wc_orders`, was Sie mit grep -c prüfen.
Schritt 3: Die richtigen Dateien mitnehmen
Neben der Datenbank braucht ein Shop einige Ordner unter wp-content/uploads/:
| Ordner | Inhalt | Warum wichtig |
|---|---|---|
uploads/ (Jahresordner) | Produktbilder, Medien | ohne sie fehlen Bilder im Shop |
uploads/woocommerce_uploads/ | Dateien für herunterladbare Produkte | gekaufte Downloads funktionieren sonst nicht mehr |
uploads/wc-logs/ | Protokolle von WooCommerce und Zahlungsanbietern | hilft bei der Klärung strittiger Zahlungen |
Der Ordner woocommerce_uploads enthielt im Test eine .htaccess mit deny from all. Diese Sperre wirkt nur unter Apache. Nehmen Sie die Datei mit ins Backup, und prüfen Sie nach einem Umzug auf nginx, ob der Ordner dort eigens gesperrt ist. Dazu kommen wie bei jeder Website wp-config.php, Themes und Plugins. Welche Aufbewahrung sinnvoll ist, beschreibt Backup-Strategie für WordPress.
Verifizieren: Ihr Dateibackup enthält woocommerce_uploads mit allen Download-Dateien und die .htaccess darin.
Schritt 4: Häufigkeit nach Bestellaufkommen festlegen
Die entscheidende Frage lautet: Wie viele Bestellungen können Sie verlieren? Ein nächtliches Backup bedeutet, dass bis zu 24 Stunden Bestellungen fehlen, wenn Sie am Abend darauf zurückgreifen müssen. Für einen Shop mit wenigen Bestellungen pro Woche ist das vertretbar, weil Sie die Lücke aus E-Mails und Zahlungsanbieter nachvollziehen können. Bei vielen Bestellungen am Tag sichern Sie die Datenbank stündlich oder häufiger, die Dateien genügen oft täglich.
Eine stündliche Sicherung per Cron sieht so aus. Das %-Zeichen muss in Crontab-Zeilen mit Backslash maskiert werden:
15 * * * * cd /var/www/html && wp db export ~/backups/shop-$(date +\%F-\%H).sql --single-transaction --quietHäufige Sicherungen erzeugen viele Dateien. Löschen Sie stündliche Sicherungen nach einigen Tagen und behalten Sie tägliche länger. Denken Sie an die Speicherfrist: Die Sicherungen enthalten personenbezogene Kundendaten und gehören in Ihr Löschkonzept. Automatisieren lässt sich das mit einem Backup-Skript per Cronjob.
Backups sind nur so gut wie ihre letzte erfolgreiche Ausführung, und ihre Kontrolle ist eine dauerhafte Aufgabe. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung und wöchentliche Backups auf externen Speicher mit vier Wochen Aufbewahrung. Für einen Shop mit vielen Bestellungen täglich ergänzen Sie eine eigene, häufigere Datenbanksicherung.
Verifizieren: Nach einem Tag liegen im Sicherungsordner so viele Dateien, wie Ihr Zeitplan vorsieht, und die neueste ist nicht älter als das geplante Intervall.
Schritt 5: Wiederherstellen, ohne Bestellungen zu verlieren
Im Test haben wir den typischen Ernstfall nachgestellt: Sicherung erstellt, danach eine neue Bestellung über zwei Artikel, dann die Sicherung zurückgespielt. Die neue Bestellung war weg, und der Lagerbestand stand wieder bei 6 statt 4 Stück. Der Shop hätte also Ware verkauft, die nicht mehr da ist. Gehen Sie deshalb in dieser Reihenfolge vor:
- Shop schließen. Unter „WooCommerce“, „Einstellungen“, „Sichtbarkeit der Website“ wählen Sie „Demnächst verfügbar“ und dazu „Nur auf Shop-Seiten anwenden“. So gehen während der Arbeit keine neuen Bestellungen ein.
- Lücke dokumentieren. Sichern Sie den aktuellen, fehlerhaften Stand zusätzlich als Datei, und notieren Sie alle Bestellungen nach dem Zeitpunkt des Backups:
Das Datum ersetzen Sie durch den Zeitpunkt Ihres Backups,wp db export ~/backups/vor-restore.sql --single-transaction wp wc shop_order list --user=1 --after=2026-09-30T02:00:00 --fields=id,status,date_created,total--userdurch die ID eines Administrators. - Zurückspielen.
wp db importmit der Sicherung, danach Dateien zurückspielen, falls nötig. - Lücke schließen. Erfassen Sie die notierten Bestellungen erneut oder gleichen Sie sie mit dem Zahlungsanbieter ab, und korrigieren Sie den Lagerbestand der betroffenen Produkte.
- Shop öffnen. Sichtbarkeit wieder auf „Live“ stellen.
Verlockend wirkt der Gedanke, nach dem Zurückspielen nur die Bestelltabellen aus der neueren Sicherung einzuspielen. Im Test war danach die jüngste Bestellung zwar wieder sichtbar, doch ihr Platzhalter in wp_posts fehlte, wp wc hpos status meldete nicht synchronisierte Bestellungen, und der nächste neu angelegte Beitrag erhielt dieselbe ID wie die Bestellung. Solche Überschneidungen führen später zu schwer erklärbaren Fehlern. Nutzen Sie diesen Weg nur mit Fachkenntnis auf einer Kopie, nicht im laufenden Shop.
Verifizieren: wp wc hpos status zeigt „Nicht synchronisierte Bestellungen: 0“, alle Bestellungen aus Ihrer Liste sind wieder vorhanden, und die Bestände stimmen mit dem Lager überein.
Schritt 6: Wiederherstellung regelmäßig proben
Spielen Sie die Sicherung mindestens einmal im Quartal in eine Testumgebung ein und prüfen Sie dort Bestellübersicht, eine Bestelldetailseite, einen Download und den Bestand eines Produkts. Achten Sie darauf, dass die Testumgebung keine E-Mails an Kunden verschickt und keine Zahlungen auslöst. Wie so eine Probe abläuft, zeigt Restore-Probe: Backup-Wiederherstellung testen.
Verifizieren: In der Testumgebung erscheint die letzte Bestellung aus dem Backup mit Adresse und Positionen, und ein Download aus einem Testkauf lässt sich öffnen.
Typische Fehler
Sicherung im Webverzeichnis. Eine SQL-Datei unter wp-content war im Test öffentlich abrufbar. Legen Sie Sicherungen immer außerhalb des Document Root ab.
Falscher Speicherort beim Export. WP-CLI übergibt den Pfad an das Dump-Programm. Existiert der Zielordner nicht oder fehlen Schreibrechte, lautet die Meldung zum Beispiel mariadb-dump: Can't create/write to file '/tmp/bk/shop.sql' (Errcode: 2 "No such file or directory"). Legen Sie den Ordner vorher an und prüfen Sie die Rechte des ausführenden Benutzers.
Bestand nach Wiederherstellung falsch. Der Bestand stammt aus dem Zeitpunkt des Backups. Ohne Abgleich verkaufen Sie Artikel doppelt.
Kompatibilitätsmodus lässt sich nicht umschalten. Nach einem teilweisen Einspielen meldet WooCommerce unter „Funktionen“, dass Sie den Datenspeicher nur wechseln können, wenn Beitrags- und Bestellungstabelle synchronisiert sind. Stellen Sie in diesem Fall die vollständige Sicherung wieder her statt nachzubessern.
Häufige Fragen
Reicht das Backup meines Hosters?
Prüfen Sie, wie oft es läuft, wie lange es aufbewahrt wird und ob Sie einzelne Stände selbst zurückholen können. Ein tägliches Hoster-Backup ist eine gute Grundlage, ersetzt bei einem aktiven Shop aber keine häufigere Datenbanksicherung.
Kann ein Backup-Plugin das übernehmen?
Ja. Achten Sie darauf, dass es die komplette Datenbank und den Ordner woocommerce_uploads sichert und Datenbank und Dateien mit unterschiedlichem Zeitplan erlaubt. Die Einrichtung eines verbreiteten Plugins beschreibt UpdraftPlus für automatische Backups einrichten.
Muss ich vor jedem WooCommerce-Update sichern?
Ja. Updates von WooCommerce ändern oft die Datenbankstruktur. Eine Sicherung direkt vor dem Update ist der sicherste Rückweg.
Testumfang
Wir haben das Zurückspielen einer Sicherung auf einer WooCommerce-Testinstallation mit WordPress 7.1.2 und mehreren Testbestellungen durchgespielt. Dabei drehte die Sicherung Bestellungen und Lagerbestand zurück, und eine Sicherungsdatei im Webverzeichnis war sogar öffentlich abrufbar. Echte Zahlungsanbieter und Abonnements haben wir nicht getestet, prüfen Sie diese deshalb in Ihrer eigenen Restore-Probe auf einer Kopie mit.
Fazit
Ein Shop-Backup ist erst dann vollständig, wenn die ganze Datenbank konsistent, häufig genug und außerhalb des Webservers gesichert wird und die Wiederherstellung mit geschlossenem Shop und dokumentierter Lücke abläuft. So verlieren Sie im Ernstfall keine Bestellung, die Sie nicht nachtragen können. Wenn Sie Updates und wöchentliche Backups Ihrer WordPress-Installation abgeben möchten, übernimmt das die WordPress-Wartung von Marcel Schönfelder.
