---
title: "WooCommerce-Shop sichern: Backups und Wiederherstellung ohne Bestellverlust"
date: 2026-09-30T22:58:43+02:00
modified: 2026-11-10T15:02:51+01:00
category: wordpress
type: how_to
author: Marcel Schönfelder
canonical: https://s-edv.com/anleitungen/wordpress-woocommerce-backup-bestellungen-ohne-datenverlust
keywords:
  - WordPress
  - WooCommerce
  - Backup
  - Datenbank
  - WP-CLI
reading_time: 8
---

# WooCommerce-Shop sichern: Backups und Wiederherstellung ohne Bestellverlust

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.

**Kurzfassung:** Sichern Sie die komplette Datenbank mit `--single-transaction`, damit Bestellungen während der Sicherung nicht halb im Backup landen. Sichern Sie die Datenbank eines aktiven Shops deutlich häufiger als die Dateien und nehmen Sie den Ordner `woocommerce_uploads` mit. Legen Sie Sicherungen nie im Webverzeichnis ab. Vor einer Wiederherstellung schalten Sie den Shop auf „Demnächst verfügbar“ und notieren alle Bestellungen seit dem Backup. Einzelne Bestelltabellen in eine ältere Datenbank einzuspielen führt zu Konflikten, im Test überschnitten sich dabei Bestellnummern und Beitrags-IDs.

## Voraussetzungen

- [ ] WordPress 7.1 mit WooCommerce und der Bestellspeicherung „Leistungsstarke Speicherung von Bestellungen“ (HPOS), die laut WooCommerce seit Version 8.2 für neue Shops Standard ist. Getestet mit WordPress 7.1 und WooCommerce 11.1.2. Im Test läuft das Update auf WordPress 7.1.3 und WooCommerce 11.2.1 ohne Fehler. Die Testbestellung bleibt dabei erhalten.
- [ ] 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:

```bash
$ wp wc hpos status
```

```plaintext
HPOS aktiviert?: yes
Kompatibilitätsmodus aktiviert?: no
Nicht synchronisierte Bestellungen: 0
Zu bereinigende Bestellungen: 0
```

Wichtig 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.

> **Prüfen:** 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:

```bash
$ 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:

```bash
$ mkdir -p ~/backups
$ wp db export ~/backups/shop-$(date +%F-%H%M).sql --single-transaction --path=/var/www/html
```

Speichern 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](https://s-edv.com/anleitungen/wordpress-datenbank-wp-cli-sichern-wiederherstellen).

> **Prüfen:** 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](https://s-edv.com/anleitungen/wordpress-backup-strategie-dateien-datenbank-aufbewahrung).

> **Prüfen:** 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:

```plaintext
15 * * * * cd /var/www/html && wp db export ~/backups/shop-$(date +\%F-\%H).sql --single-transaction --quiet
```

Hä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](https://s-edv.com/anleitungen/wordpress-backup-server-cronjob-shell-skript).

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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=125) ü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.

> **Prüfen:** 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:

1. **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.
2. **Lücke dokumentieren.** Sichern Sie den aktuellen, fehlerhaften Stand zusätzlich als Datei, und notieren Sie alle Bestellungen nach dem Zeitpunkt des Backups:

   ```bash
   $ 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
   ```

   Das Datum ersetzen Sie durch den Zeitpunkt Ihres Backups, `--user` durch die ID eines Administrators.
3. **Zurückspielen.** `wp db import` mit der Sicherung, danach Dateien zurückspielen, falls nötig.
4. **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.
5. **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.

> **Prüfen:** `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](https://s-edv.com/anleitungen/wordpress-restore-probe-backup-wiederherstellung-testen).

> **Prüfen:** 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](https://s-edv.com/anleitungen/wordpress-updraftplus-automatische-backups-externer-speicher).

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

## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=125).

## Weiterführende Anleitungen und Quellen

- [Backup-Strategie für WordPress](https://s-edv.com/anleitungen/wordpress-backup-strategie-dateien-datenbank-aufbewahrung)
- [WordPress-Datenbank mit WP-CLI sichern und wiederherstellen](https://s-edv.com/anleitungen/wordpress-datenbank-wp-cli-sichern-wiederherstellen)
- [Restore-Probe: Backup-Wiederherstellung testen](https://s-edv.com/anleitungen/wordpress-restore-probe-backup-wiederherstellung-testen)
- [WooCommerce-Entwicklerdokumentation: High Performance Order Storage](https://developer.woocommerce.com/docs/features/orders/high-performance-order-storage/)
- [WP-CLI-Handbuch: wp db export](https://developer.wordpress.org/cli/commands/db/export/)
- [MariaDB-Dokumentation: mariadb-dump](https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump)