WordPress-Backup: Der umfassende Leitfaden für Agenturen (2026)

Stellen Sie sich eine einzige Frage zu Ihrer größten Kundenwebsite: Können Sie sie innerhalb einer Stunde in den Zustand von gestern um 8 Uhr morgens zurückversetzen, ohne den Host anrufen zu müssen? Wenn die Antwort „wahrscheinlich“ lautet, haben Sie keine Backup-Strategie . Sie haben ein Backup-Plugin und eine Hoffnung.

Ein WordPress-Backup ist kein Plugin, das man installiert.

Es handelt sich um eine Infrastruktur, die Sie betreiben. Sie verfügt über ein Frequenzziel, ein Wiederherstellungsziel, eine Speichertopologie, ein Verschlüsselungsmodell, eine Aufbewahrungsrichtlinie und einen Überprüfungsplan. Wenn einer dieser Punkte versagt, existiert Ihr Backup nicht – ganz gleich, was Ihr Dashboard anzeigt.

Dieser Leitfaden richtet sich an Agenturinhaber und leitende Techniker, die 20 bis 500 Kundenstandorte betreuen. Er nennt Anreize dort, wo sie entscheidend sind (Fristen für die Kundenbindung bei Hosting-Anbietern, Paywalls für Plugins, SaaS-Lösungen von Automattic), ohne dabei Anbieter anzugreifen.

Das Ziel ist ein Konzept, das Sie Ihrem Team, Ihren Kunden und Ihrem zukünftigen Ich um 3 Uhr morgens während einer Wiederherstellung gegenüber verteidigen können. Am Ende werden Sie Backups wie ein Infrastrukturingenieur bewerten – und nicht wie jemand, der einfach nur nach Plugins sucht.

Was ein WordPress-Backup eigentlich ist (und was es nicht ist)

Was ein vollständiges WordPress-Backup enthält

Ein WordPress-Backup ist eine vollständige, wiederherstellbare Kopie der Dateien, der Datenbank und der Laufzeitkonfiguration, mit deren Hilfe Sie eine WordPress-Produktionsseite auf einem neuen Server ab einem bestimmten Zeitpunkt wiederherstellen können. Eine WordPress-Seite ist mehr als /wp-content/ und einen MySQL-Dump. Eine Sicherung gilt erst dann als vollständig, wenn allein anhand dieser Daten ein neuer Server ohne Vorabdaten auf der aktuellen Produktionsumgebung wiederhergestellt werden kann.

Diese Checkliste:

• Der vollständige /wp-content/ Verzeichnis, einschließlich Uploads, Themes, Plugins und aller mu-plugins.
• Die vollständige Datenbank, einschließlich aller nicht-wp_ Tabelle (WooCommerce-Bestellungen, ACF-Beziehungen, benutzerdefinierte Plugin-Tabellen).
• wp-config.php, mit dem richtigen Tabellenpräfix, den Salts und den Datenbankzugangsdaten.
• .htaccess oder nginx.conf Umschreibungsregeln sowie alle .user.ini PHP-Überschreibungen.
• SSL-Zertifikate, DNS-Einträge (einschließlich MX, SPF, DKIM, DMARC) und API-Schlüssel von Drittanbietern (Stripe, Mailgun, CDN-Token).

Die meisten Plugin-Backups decken die ersten beiden Punkte ab. Eine echte Notfallwiederherstellung deckt alle fünf Punkte ab. Die offizielle WordPress-Dokumentation zum Thema Backups behandelt die Datei- und Datenbankebene; der Rest liegt in Ihrer Verantwortung.

Sicherung vs. Migration vs. Staging vs. Versionskontrolle

Diese vier sind keine Ersatzlösungen. Migrationspakete dienen dazu, Hosts zu verschieben. Staging dient zum Testen. Die Versionskontrolle umfasst den Code, nicht die Datenbank, Uploads oder die Laufzeitkonfiguration. Ein Backup beantwortet eine Frage: „Kann ich die Produktion in den Zustand zum Zeitpunkt T zurückversetzen?“ Wenn Ihre Antwort eine der anderen ist, haben Sie keine Backup-Strategie.

Warum WordPress-Backups öfter fehlschlagen, als man denkt

WordPress-Backups schlagen aus vier wiederkehrenden Gründen fehl: Eine unbemerkte Beschädigung des Archivs bleibt bis zur Wiederherstellung unentdeckt, PHP-basierte Batch-Jobs stoßen bei großen Websites an ihre Grenzen hinsichtlich Speicherplatz oder Zeit, das Backup befindet sich im selben „Blast Radius“ wie die Website, und die Aufbewahrungsfristen der Hosts stimmen selten mit dem SLA einer Agentur überein.

Auf jeden einzelnen wird im Folgenden eingegangen.

Das Problem der stillen Ausfälle

Ein stiller Backup-Fehler liegt vor, wenn ein Backup-Vorgang zwar als erfolgreich gemeldet wird, das resultierende Archiv jedoch nicht wiederherstellbar ist. Dies ist die Kategorie, die den meisten WordPress-Agenturen zum Verhängnis wird.

Das Backup-Protokoll meldet „Erfolgreich“. Die ZIP-Datei ist vorhanden. Die Größe stimmt in etwa. Niemand hat versucht, sie wiederherzustellen. Monate später, während eines tatsächlichen Vorfalls, schlägt die Wiederherstellung fehl, weil das Archiv aufgrund einer PHP-Speicherbegrenzung abgeschnitten wurde, der Datenbankexport mitten in einer Tabelle abgebrochen ist oder die hochgeladene ZIP-Datei während der Übertragung beschädigt wurde und kein Hash-Wert überprüft wurde.

Die einzige Lösung ist eine planmäßige Wiederherstellungsübung (siehe unten). Eine Sicherung, die noch nie wiederhergestellt wurde, ist nur ein Wunschtraum, keine echte Sicherung.

Bevor wir diesen Artikel verfasst haben, haben wir die meisten der auf dem Markt erhältlichen Backup-Plugins getestet. Es gibt einige wenige Plugins, denen man vertrauen kann (WP Umbrella, ManageWP, Blogvault), und andere, die einen im Stich lassen und die man dringend überprüfen sollte (ModularDS, UpdraftPlus, WP Vivid, BackWPup).

Das Problem mit dem Ausfall auf Serverseite

Die meisten WordPress-Backup-Plugins laufen direkt auf der Website. Sie belegen PHP-Speicher, komprimieren Dateien in eine ZIP-Datei und übertragen dieses Archiv auf einen externen Server. Bei einer 500-MB-Präsentationswebsite funktioniert das. Bei einem 12-GB-WooCommerce-Shop auf Shared Hosting mit einer PHP-Speicherbegrenzung von 256 MB schlägt dies jedoch stillschweigend fehl, oft monatelang, bevor es jemand bemerkt. Die architektonische Lösung (Streaming vs. Batching) wird weiter unten in einem eigenen Abschnitt behandelt. Sie ist der wichtigste Faktor für die Zuverlässigkeit von Backups in der Praxis bei großem Umfang.

Das Problem des Explosionsradius

Wenn Ihr Backup-Plugin Archive in /wp-content/uploads/backups/… und ein Angreifer, ein fehlerhaftes Plugin-Update oder ein außer Kontrolle geratener Cron-Job Schreibzugriff auf das Dateisystem hat, ist Ihr Backup in demselben Moment verloren, in dem Ihre Website ausfällt. Wenn Ihr externes Speicherziel einen einzigen API-Schlüssel verwendet, der in wp-config.php… dieselben Anmeldedaten, mit denen die Website Backups erstellen kann, ermöglichen es jedem auf der Website, diese zu löschen.

Eine Sicherung innerhalb derselben Ausfalldomäne wie der Standort ist keine Sicherung. Es handelt sich um eine zweite Kopie, die demselben Risiko ausgesetzt ist.

Die Diskrepanz bei der Host-Bindung

Managed-Hosts bewahren Backups für einen festgelegten Zeitraum auf – in der Regel 14 bis 30 Tage, je nach Tarif und Anbieter. Dieser Zeitraum entspricht selten den Service-Level-Vereinbarungen (SLAs) von Agentur-Support-Tarifen, die die Wiederherstellung von Daten aus den „letzten 60 Tagen“ versprechen. Er entfällt zudem vollständig, wenn der Host das Konto aufgrund eines Zahlungsstreits, eines Verstoßes gegen die Nutzungsbedingungen oder einer Übernahme bzw. Einstellung des Dienstes sperrt. Backups von Hosts dienen als praktische Möglichkeit für eine schnelle Wiederherstellung, nicht als Strategie.

Warum Angreifer ein Auge auf Ihre Backups geworfen haben (und warum das weniger schlimm ist, als Sie denken)

Moderne Ransomware-Angriffe zielen zuerst auf Backups ab – die Zerstörung des Wiederherstellungspunkts ist der erste Schritt, die Verschlüsselung der Produktionsumgebung der zweite. Für WordPress-Agenturen lässt sich daraus eine wichtige Erkenntnis darüber ableiten, wo Backups gespeichert werden sollten: außerhalb des Bereichs, in dem Produktionsausfälle auftreten können, und hinter Zugangsdaten, über die die Website selbst nicht verfügt. Das ist eine architektonische Vorgabe, nicht der Rahmen für den gesamten Leitfaden. Wenn die Architektur richtig ausgelegt ist (extern, separate Zugangsdaten, nach Möglichkeit unveränderlich), schrumpft die Angriffsfläche auf einen einzigen Punkt.

Die 3-2-1-Regel, angewendet auf WordPress

3 Exemplare, 2 Datenträger, 1 außerhalb des Standorts

Die 3-2-1-Backup-Regel ist eine Speicherstrategie, die vorsieht, dass drei Kopien Ihrer Daten auf zwei verschiedenen Medientypen gespeichert werden, wobei mindestens eine Kopie außerhalb des Unternehmens aufbewahrt wird. Sie wird von der CISA und der US-amerikanischen Cybersicherheits-Community empfohlen und bildet die Grundlage, auf der jede ernsthafte Speicherstrategie aufbaut.

Auf die WordPress-Realität übertragen:

• Kopie 1: die eigentliche Live-Produktionsumgebung. Dies ist Ihre Hauptumgebung, kein Backup.
• Kopie 2: Ein aktueller Snapshot, der vom Host (Kinsta, WP Engine, Pressable, Cloudways) gespeichert wird. Schnelle Wiederherstellung, jedoch auf derselben Infrastruktur wie die Produktionsumgebung.
• Kopie 3: Ein unabhängiger, extern gelegener, verschlüsselter Speicherort, der von Ihnen oder Ihrer Verwaltungsplattform verwaltet wird. Nach Möglichkeit sollte es sich um einen anderen Anbieter, andere Anmeldedaten und einen anderen Standort handeln.

„Zwei Medien“ bedeutet bei cloud-nativem WordPress in der Regel zwei verschiedene Speicher-Backends (Objektspeicher plus ein repliziertes Sekundärsystem), nicht Band und Festplatte. Der springende Punkt ist die Unabhängigkeit der Ausfalldomänen.

Ein konkreter 3-2-1-Stack für ein Portfolio mit 50 bis 100 Websites

Auf Portfolioebene ändert sich die Struktur des Stacks nicht. Der operative Aufwand hingegen schon. Der 3-2-1-Stack über 50 bis 100 Standorte hinweg sieht wie folgt aus:

1. Host-Snapshots pro Standort, die ausschließlich für schnelle Rollbacks verwendet werden.
2. Eine einzige verwaltete Plattform für alle Standorte, mit täglichen oder stündlichen Backups je nach Standorttyp, zentral verwalteten Anmeldedaten und standortspezifischen Aufbewahrungsfristen.
3. Mindestens zweimal jährlich eine Wiederherstellungsübung pro Standort
4. Ein Leitfaden für bestimmte Vorfälle, den jedes Teammitglied befolgen kann, ohne den leitenden Ingenieur zu konsultieren.

Ohne Zentralisierung würde eine Kombination aus 50 Host-Dashboards, 50 Plugin-Dashboards und 50 Speicherkonten schon vor Ablauf des ersten Jahres unüberschaubar werden.

RTO und RPO: Die beiden Kennzahlen, die Ihre Backup-Häufigkeit bestimmen

Was RTO und RPO im Klartext bedeuten

RTO (Recovery Time Objective): Wie schnell muss der Betrieb nach einem Vorfall wieder aufgenommen werden? Wenn eine Website ausfällt und das RTO eine Stunde beträgt, haben alle Beteiligten (Sie, Ihr Team, Ihr Kunde) vereinbart, dass die Website innerhalb von 60 Minuten wieder verfügbar sein muss.

RPO (Recovery Point Objective): Die Datenmenge, deren Verlust Sie in Kauf nehmen, gemessen in Zeit. Ein RPO von 24 Stunden bedeutet, dass Sie den Verlust von Änderungen aus bis zu einem Tag akzeptieren. Ein RPO von einer Stunde bedeutet, dass Sie dies nicht tun.

Der RTO bestimmt Ihre Wiederherstellungswerkzeuge und die Überwachung der Betriebszeit. Der RPO bestimmt die Häufigkeit Ihrer Backups. Ein RPO von einer Stunde bei nächtlichen Backups ist mathematisch unmöglich, egal wie gut das Plugin auch sein mag.

Zuordnung von RTO/RPO zu WordPress-Seitentypen

Standorttyp	RTO-Ziel	RPO-Ziel	Frequenz	Kundenbindung
Statische Broschüre	6 Stunden	24 Stunden	Täglich	50 Tage
Inhaltsblog	4 Stunden	24 Stunden	Täglich	50 Tage
Mitgliederseite	1 Stunde	6 Stunden	Alle 6–12 Stunden	50 Tage
WooCommerce, geringes Volumen	1 Stunde	1 Stunde	stündlich	50 Tage
WooCommerce, hohes Volumen	30 Minuten	1 Stunde	Stündlich	50 Tage
SaaS / maßgeschneiderte App	15 Minuten	15 Minuten	Kontinuierlich / auf Blockebene	90 Tage und mehr

Jede Zeile entspricht einem Geschäftsmodell, nicht einer Plugin-Einstellung. Erstellen Sie für jeden Kunden eine eigene Zeile, bevor Sie sich für ein Tool entscheiden.

Methoden zur Sicherung von WordPress (ehrliche Vor- und Nachteile der einzelnen Methoden)

Backups auf Host-Ebene

Ein WordPress-Backup auf Host-Ebene ist ein serverseitiger Snapshot, der vom Managed-Host (Kinsta, WP Engine, Pressable, Cloudways usw.) erstellt und auf derselben Infrastruktur wie die Produktionsumgebung gespeichert wird. Die Aufbewahrungsdauer beträgt in der Regel 7 bis 14 Tage, bei Tarifen höherer Preisklassen gelegentlich bis zu 60 Tage.

Host-Backups eignen sich hervorragend für eine schnelle Rücknahme nach einer fehlgeschlagenen Bereitstellung. Sie stellen jedoch keine eigenständige Backup-Strategie dar. Wenn der Host das Konto sperrt, gehen die Snapshots ebenfalls verloren. Der Speicherort der Daten richtet sich nach den Vorgaben des Hosts. Die Aufbewahrungsfristen stimmen selten mit den SLA-Vorgaben Ihres Wartungsvertrags überein, und der Speicher ist nicht vor Ausfällen der Produktionsumgebung geschützt.

Außerdem müssen Sie eine aktuelle und gesicherte Liste der Anmeldedaten führen, damit Websites wiederhergestellt werden können, was den Wiederherstellungsprozess langsamer macht als bei WordPress-Verwaltungstools.

Plugin-basierte Backups

Der Bereich der Plugins ist überfüllt und von kommerziellen Interessen geprägt. Ein kurzer, ehrlicher Überblick:

• UpdraftPlus: die am häufigsten installierte Option. Auf der Seite zum Versionsvergleich wird deutlich, dass inkrementelle Backups, Verschlüsselung und viele externe Speicherorte nur in der Premium-Version enthalten sind. Wenn Sie die Premium-Version nicht erworben haben, handelt es sich bei Ihrem externen Archiv um eine Klartextkopie der Produktionsdaten Ihres Kunden.
• BlogVault: Zuverlässiger Managed-SaaS-Dienst mit site-spezifischer Preisgestaltung und externem Speicher.
• Solid Backups: Früher BackupBuddy, nach der Zusammenführung von iThemes, SolidWP und StellarWP umbenannt. Dies ist bei der Auswertung älterer Bewertungen unter dem früheren Namen zu beachten.
• Duplicator: wird häufig für Migrationen eingesetzt und oft als Backup-Tool genutzt. Seine Stärke liegt in der Portabilität, nicht in der geplanten Ausfallsicherheit.

Plugin-basierte Backups funktionieren – bis sie es nicht mehr tun. Wenn sie nicht mehr funktionieren, liegt das Problem meist an einer Speicherbegrenzung oder einer Zeitüberschreitung; beides wird im Folgenden behandelt. Wenn Sie einen ausführlicheren Vergleich wünschen, finden Sie in unserem detaillierten Plugin-Vergleich eine vollständige Übersicht.

Manuelle Backups über phpMyAdmin + SFTP

Ein Export aus phpMyAdmin sowie ein SFTP-Download von /wp-content/ ist der letzte Ausweg um 2 Uhr morgens. In großem Maßstab ist das nicht umsetzbar, aber nützlich, um zu überprüfen, was Ihre „Automatisierung“ tatsächlich ersetzt hat.

Wir haben einen ausführlichen Artikel darüber verfasst, wie man eine manuelle Sicherung und Wiederherstellung durchführt.

SSH-/WP-CLI-Backups

Skriptbasiert wp db export plus rsync ist eine zuverlässige Funktion für benutzerdefinierte Pipelines. WP-CLI’s db check ist für die Überprüfung der Konsistenz unerlässlich. Der Preis dafür ist der eigene Aufwand: Sie müssen sich um das Skript, den Cron-Job, den Speicherplatz, die Verschlüsselung, die Aufbewahrungsfristen, die Benachrichtigungen und die Wiederherstellungstools kümmern.

Für eine Agentur ist das ein Vollzeit-Hobby, kein Produkt.

Verwaltete Plattform-Backups (SaaS)

Dies ist die Kategorie, die auf Portfolioebene entscheidend ist. Verwaltete Plattformen führen die Datensicherung außerhalb des Servers durch, speichern die Daten separat und stellen ein einheitliches Dashboard für alle Kundenstandorte bereit. Bekannte Anbieter:

• WP Umbrella: Streaming-Architektur, native AES-Verschlüsselung, DSGVO-konforme Speicherung in der EU, 50-tägige Aufbewahrungsfrist, Überwachung der Backup-Integrität, pauschale Preise pro Website.
• BlogVault: Streaming-Architektur, leistungsstarkes Managed-SaaS-Angebot.
• VaultPress / Jetpack Backup: Im Besitz von Automattic und im Jetpack-Paket enthalten. Der Anreiz, Websites stärker in das Jetpack-Ökosystem einzubinden, ist struktureller Natur und sollte offengelegt werden.

Abwägung auf Kategorieebene: Man tauscht direkte Kontrolle gegen operative Hebelwirkung ein. Bei mehr als 50 Standorten hat die Hebelwirkung jedes Mal die Oberhand.

Inkrementell vs. differentiell vs. vollständig: die technische Realität

Bei einer vollständigen Sicherung werden jedes Mal alle Dateien und alle Datenbankzeilen kopiert. Bei einer differentiellen Sicherung werden alle Daten kopiert, die sich seit der letzten vollständigen Sicherung geändert haben. Bei einer inkrementellen Sicherung werden nur die Daten kopiert, die sich seit der letzten Sicherung – unabhängig von deren Art – geändert haben.

Inkrementelle Backups sind schlanker, kostengünstiger und schneller, bergen jedoch das Risiko einer Kettenanfälligkeit: Ist auch nur ein Glied in der Kette beschädigt, sind alle nachfolgenden Backups unbrauchbar. Aus diesem Grund erstellen seriöse inkrementelle Systeme wie WP Umbrella ein neues vollständiges Backup und überprüfen beim Schreiben die Integrität der Kette.

Ein Plugin, das „inkrementell“ als Auswahlfeld ohne Kettenüberprüfung anbietet, verspricht Ihnen Geschwindigkeit, nicht Sicherheit.

Wie oft sollte man WordPress sichern? Ein Entscheidungsrahmen

Wie oft Sie ein Backup von WordPress erstellen, hängt von Ihrem RPO ab: täglich für Broschüren- und Content-Websites, alle 12 Stunden für Mitglieder-Websites, stündlich für WooCommerce-Websites. Die folgende Tabelle zeigt die Zuordnung von Website-Typ zu Häufigkeit, Aufbewahrungsdauer und empfohlener Methode.

Standorttyp	Frequenz	Kundenbindung	Empfohlene Methode
Statische Broschüre	Täglich	50 Tage	Tägliche Verwaltung der Plattform
Inhaltsblog	Täglich	50 Tage	Tägliche Verwaltung der Plattform
Mitgliedschaft	Zweimal täglich	50 Tage	Verwaltete Plattform, Zusatzmodul für zweimal tägliche Aktualisierung
WooCommerce	Stündlich	50 Tage	Verwaltete Plattform, stündliche Snapshots + Host-Snapshots
SaaS / maßgeschneiderte App	Kontinuierlich / auf Blockebene	90+ Tage	Maßgeschneiderte Infrastruktur + verwaltete Plattform für die Anwendungsebene

Warum nächtliche Updates für WooCommerce nicht ausreichen

Ein nächtliches WooCommerce-Backup bedeutet: Wenn die Website um 23:30 Uhr gehackt wird und das Problem erst um 9:00 Uhr morgens entdeckt wird, gehen alle Bestellungen eines ganzen Geschäftstages verloren – ebenso wie Kundenkonten und Bestandsbewegungen. Die Rekonstruktion dieser Daten anhand von Stripe-Protokollen, Exporten der Versanddienstleister und E-Mail-Bestätigungen erfordert realistisch gesehen eine Woche Arbeitszeit einer Agentur, selbst mit Claude Code.

Durch eine stündliche Datensicherung beschränkt sich der Verlust auf eine Stunde an Bestellungen. Dies lässt sich innerhalb eines Nachmittags ausgleichen.

Wenn Sie stündliche Backups für ein Portfolio mit 50 Websites wünschen, ohne Ihren Stack selbst neu aufbauen zu müssen, dann ist WP Umbrella genau das Richtige WP Umbrella . Starten Sie Ihre 14-tägige kostenlose Testphase. Keine Kreditkarte erforderlich.

Backup-Technologie: Streaming vs. Batching (warum die meisten Backups gerade dann versagen, wenn man sie am dringendsten braucht)

Bei Streaming-Backups werden Dateiänderungen und Datenbankblöcke stückweise auf einen externen Server übertragen, ohne dass auf dem Quellserver ein Archiv erstellt wird. Bei Batch-Backups wird die gesamte Website auf dem Quellserver in eine ZIP-Datei komprimiert, und das fertige Archiv wird anschließend auf einen externen Speicher hochgeladen. Durch Streaming entfallen die Speicher- und Ausführungszeitbeschränkungen von PHP, die bei Batch-Backups im großen Maßstab zu Problemen führen.

Dies ist der tragende Teil dieser Anleitung.

Batch-Architektur (ZIP): So funktionieren die meisten Plugins

UpdraftPlus, BackWPup, Duplicator, ModularDS und Solid Backups basieren alle auf demselben Grundprinzip. Diese Plugins komprimieren die gesamte Website in ein ZIP-Archiv auf Ihrem eigenen Server und laden das fertige Archiv anschließend auf einen externen Speicherort hoch.

Dafür sind ausreichend RAM für die Komprimierungspuffer, genügend Speicherplatz für das Archiv während der Erstellung und genügend PHP-Ausführungszeit erforderlich, damit der Vorgang abgeschlossen werden kann, bevor der Prozess beendet wird. Bei Shared Hosting, in WooCommerce-Shops oder bei Medienbibliotheken mit mehr als 5 GB geht einer dieser drei Faktoren zur Neige. PHP wird beendet, das Archiv ist beschädigt oder unvollständig, und das Backup-Protokoll meldet entweder einen Erfolg oder einen vagen Fehler, den niemand liest.

Bei der Batch-Architektur verbleiben zwischen den einzelnen Durchläufen zudem ZIP-Dateien auf dem Server. Diese sammeln sich an, belegen Speicherplatz und sind manchmal öffentlich zugänglich unter /wp-content/uploads/, was ein Problem für sich ist.

Streaming-Architektur: Was Managed-Plattformen leisten

WP Umbrella, BlogVault und ManageWP übertragen Dateiänderungen und Datenbankblöcke stückweise außerhalb des Servers. Auf dem Quellserver wird kein Archiv erstellt. Es gibt keinen einzelnen Prozess, der innerhalb des Ausführungsfensters von PHP abgeschlossen werden muss. Es gibt keine Speichergrenze, die erreicht werden könnte. Es bleiben keine Dateien zurück.

Inkrementelle Daten werden auf Blockebene berechnet, sodass nur der geänderte Teil eines 4-GB-Upload-Verzeichnisses übertragen wird und nicht das gesamte Verzeichnis. Die Überprüfung kann auf der Empfängerseite erfolgen, unabhängig vom Betriebszustand des Quellservers.

Warum dies für die Zuverlässigkeit im großen Maßstab entscheidend ist

Eine Backup-Methode, die bei einer 5-GB-Website regelmäßig mitten im Ablauf fehlschlägt, ist keine Strategie, sondern reine Wunschvorstellung. Bei einer einzelnen Website ist der Unterschied nur eine Fußnote. Bei einem Portfolio von 50 Websites entscheidet dieser Unterschied jedoch darüber, wie oft man von einer Warnmeldung geweckt wird, dass „das Backup der letzten Nacht nicht abgeschlossen wurde“. Bei 500 Websites ist das Batch-Modell betrieblich nicht mehr tragbar.

Aus diesem Grund können verwaltete Plattformen „Backup-Ausführung“ als SLA und nicht nur als Wahrscheinlichkeit anbieten. Die Architektur beseitigt die Fehlerarten, mit denen Batch-Backups ständig zu kämpfen haben.

Extern, verschlüsselt, unabhängig: die drei Eigenschaften, die ein Backup in Krisensituationen unverzichtbar machen

Unveränderlichkeit, Versionsverwaltung und Air-Gapping

Ein Backup, auf das jeder auf der Website Ihres Kunden zugreifen und löschen kann, wird einen echten Vorfall nicht überstehen. Drei praktische Eigenschaften sorgen für die Sicherheit der gespeicherten Kopie:

• Einmalig beschreibbarer Speicher (Unveränderlichkeit): Sobald eine Sicherung geschrieben wurde, kann sie während eines festgelegten Aufbewahrungszeitraums (z. B. 50 Tage) nicht gelöscht oder überschrieben werden – auch nicht von dem System, das sie erstellt hat. Selbst wenn ein Angreifer die Anmeldedaten stiehlt, die Ihre Website zum Hochladen von Sicherungen verwendet, kann er damit keine bereits vorhandenen Daten entfernen.
• Versionsverlauf (Versionierung): Jede Änderung an einer gespeicherten Datei erzeugt eine neue Version. „Löschen“ bedeutet „die aktuelle Version ausblenden“, nicht „die Daten vernichten“. Du kannst jederzeit auf den letzten Dienstag zurückgreifen, selbst wenn jemand heute Morgen versucht hat, den Speicher zu löschen.
• Separater Speicher (Air-Gapping): Der Backup-Speicher befindet sich hinter einer Passwortschutzbarriere und in einem Netzwerk, auf das Ihre WordPress-Installation keinen Zugriff hat. Ihre Website verfügt über einen Schlüssel, mit dem Backups geschrieben werden können; nur eine Person mit einem separaten Login kann diese löschen. Selbst bei einer vollständigen Kompromittierung der Website können die gespeicherten Kopien nicht erreicht werden.

Bei selbstverwalteten Stacks sind dies Funktionen, die Sie beim Speicheranbieter selbst konfigurieren. Bei verwalteten Plattformen hat der Betreiber dies bereits übernommen – Sie nutzen die garantierte Leistung, statt sie selbst aufzubauen. Das ist der Hauptgrund, warum es sich auf Portfolioebene lohnt, für „verwaltete“ Lösungen zu bezahlen.

Was „Verschlüsselung im Ruhezustand“ bedeutet und wer dies tatsächlich anbietet

Ihr Backup ist eine vollständige Kopie der Website Ihres Kunden. Jede Kunden-E-Mail, jede Bestellung, jedes Passwort, jede hochgeladene Datei.

Diese Kopie muss an zwei Stellen gesichert werden: während sie an den Speicher übertragen wird und während sie dort gespeichert ist. Wenn eine der beiden Stellen ungesichert ist und eine Kopie in die falschen Hände gerät, kann derjenige, der sie besitzt, alles auf der Website Ihres Kunden lesen, ohne die Website selbst jemals zu berühren.

Diese Sicherung wird als Verschlüsselung bezeichnet. Zwei Fragen, die man sich bei jedem Backup-Tool stellen sollte:

1. Ist das Backup während des Hochladens gesperrt? Dann sieht jeder, der die Verbindung beobachtet, nichts Nützliches.
2. Ist das Backup gesichert, sobald es im Speicher liegt? Das heißt, wenn es bei dem Speicheranbieter zu einem Sicherheitsverstoß kommt oder ein Laufwerk aus dem Haus verschwindet, ist die Datei unlesbar.

Bei jeder Website, die Kundendaten speichert, sollten beide Fragen mit „Ja“ beantwortet werden. Ein wichtiger Hinweis: Es gibt fast kein Backup-Produkt, das Ihnen eine Kopie liefert, die nur Sie entsperren können.

Der Backup-Anbieter verfügt ebenfalls immer über einen Schlüssel. Das bedeutet, dass er – oder jeder, der sich unbefugt Zugang zu seinen Systemen verschafft – theoretisch Ihre Daten einsehen könnte. Dies ist der Kompromiss, den Sie eingehen, wenn Sie einen Managed Service nutzen, anstatt einen eigenen Speicher zu betreiben. Für die meisten Agenturen lohnt sich dies, da Daten in einem Managed-SaaS-Dienst, der Zeit und Geld in die Sicherheit investiert, immer noch besser geschützt sind als in einer selbst gehosteten Lösung, die von jemandem mit geringen Sicherheitskenntnissen betrieben wird.

Eine neutrale Bewertung der gängigen Optionen:

• UpdraftPlus: Die Verschlüsselung der Datenbank ist eine Premium-Funktion, die im kostenlosen Plugin nicht enthalten ist. Wenn Sie die kostenlose Version von UpdraftPlus verwenden, um Backups auf Dropbox oder Google Drive zu übertragen, liegen diese Dateien dort im Klartext vor.
• VaultPress / Jetpack Backup: Die Verschlüsselung im Ruhezustand ist als Teil des Dienstes dokumentiert.
• BlogVault: Verschlüsselung im Ruhezustand und während der Übertragung.
• WP Umbrella: Verschlüsselung im Ruhezustand, Verschlüsselung während der Übertragung, Speicherung in der EU, keine kostenpflichtige Stufe erforderlich, um die Funktion zu aktivieren.

Die praktische Konsequenz: Wenn die Verschlüsselungsfunktion Ihres Plugins nur in einer kostenpflichtigen Version verfügbar ist und Sie diese nie erworben haben, besteht Ihr externes Backup aus einer Kopie der Website Ihres Kunden im Klartext: Kunden-E-Mails, gehashte Passwörter, Bestelldaten – einfach alles.

Sollte diese Kopie jemals an die Öffentlichkeit gelangen, sind Sie gemäß der DSGVO verpflichtet, jede betroffene Person zu benachrichtigen. Das ist ein Nachmittag, auf den Sie sicher verzichten möchten.

Überprüfen Sie Ihre Backups, oder lassen Sie es lieber ganz bleiben

Sie überprüfen ein WordPress-Backup, indem Sie es herunterladen oder in einer sauberen Staging-Umgebung wiederherstellen, Integritätsprüfungen für die Datenbank und die Kern-Dateien durchführen und die kritischen Pfade einem Smoke-Test unterziehen. Ein Backup, das noch nie wiederhergestellt wurde, ist nur eine Hoffnung, kein Backup.

Die Wiederherstellungsübung

Die WordPress-Wiederherstellungsübung ist ein 8-stufiger Verifizierungsprozess:

1. Richten Sie eine saubere Staging-Umgebung ein (leere Datenbank, Standard-PHP-Konfiguration).
2. Laden Sie die aktuellste Sicherung vom externen Speicherort herunter.
3. Dateien und Datenbank in die Staging-Umgebung wiederherstellen.
4. Laufen wp db check zur Gewährleistung der Tabelleneigenschaften.
5. Laufen wp core verify-checksums um zu überprüfen, ob die WordPress-Kern-Dateien mit der offiziellen Version übereinstimmen.
6. Führen Sie Smoke-Tests für die kritischen Pfade durch: Anmeldung, Bezahlung, Formularübermittlung, Suche.
7. Dokumentieren Sie die verstrichene Zeit vom Zeitpunkt, an dem eine Wiederherstellung erforderlich wurde, bis zur funktionsfähigen Bereitstellung.
8. Erfassen Sie das Ergebnis im Vergleich zum RTO-Ziel der Website.

Führen Sie die Bohrungen abwechselnd über das gesamte Portfolio durch, sodass jede Bohrstelle innerhalb eines Zeitraums von 30 bis 60 Tagen bearbeitet wird. Bei 50 Bohrstellen sind das etwa zwei Bohrungen pro Arbeitstag, was sich über jede verwaltete Plattform mit einer Wiederherstellungs-API automatisieren lässt.

Was ein „erfolgreiches“ Backup-Protokoll nicht belegt

Ein grüner Protokolleintrag belegt, dass der Sicherungsvorgang ohne unbehandelte Ausnahme beendet wurde. Er belegt jedoch nicht, dass das Archiv lesbar ist. Er belegt nicht, dass der Datenbank-Dump konsistent ist. Er belegt nicht, dass das Verzeichnis „uploads“ vollständig ist. Er belegt nicht, dass der Zielspeicher das Objekt noch enthält. Das Einzige, was belegt, dass eine Sicherung funktioniert, ist ihre Wiederherstellung.

Bei WP Umbrella führen WP Umbrella täglich Integritätsprüfungen der Datenbank und der Ordner durch, um sicherzustellen, dass Ihr Backup zuverlässig ist.

Realistische Zeitpläne für die Wiederherstellung

Zahlen, die man im Kopf behalten sollte:

• Import einer 2-GB-Datenbank über phpMyAdmin: 20 bis 60 Minuten, vorausgesetzt, der Gastgeber max_execution_time und upload_max_filesize Beenden Sie den Prozess nicht vorher.
• Wiederherstellung einer 5-GB-Website mit UpdraftPlus: 30 bis 90 Minuten an einem guten Tag, wobei es bei Shared Hosting häufig zu Ausfällen kommt.
• Wiederherstellung per Ein-Klick auf der verwalteten Plattform: 5 bis 15 Minuten, abhängig von der Netzwerkgröße und der Datenbankgröße.
• Rollback des Hosts auf einen Snapshot: 2 bis 10 Minuten; schnellste Option, jedoch an den Host gebunden.

Legen Sie Ihre Wiederherstellungs-SLA in der Mitte dieser Bereiche fest, nicht auf der Grundlage des Best-Case-Szenarios.

Fehlerbehebung bei den drei Problemen, die die meisten WordPress-Backups zum Scheitern bringen

PHP-Speichergrenzen und Zeitüberschreitungen

Batch-Backups schlagen meist fehl, weil PHP nicht mehr genügend Speicherplatz oder Zeit zur Verfügung hatte. Eine Erhöhung WP_MEMORY_LIMIT und WP_MAX_MEMORY_LIMIT in wp-config.php hilft, bis der Gastgeber php.ini Die Obergrenze greift.

Wenn Ihr Backup 512 MB benötigt, um abgeschlossen zu werden, und die Obergrenze des Hosts bei 256 MB liegt, hilft keine noch so ausgefeilte WordPress-Konfiguration. Die strukturelle Lösung ist eine Streaming-Architektur, bei der der Quellserver das Archiv nicht im Arbeitsspeicher vorhalten muss.

Ausfälle bei großen Websites (Medienbibliotheken über 20 GB, Multisite)

Sobald die Uploads 20 GB überschreiten, schlagen Batch-Backups fast immer fehl. Bei Multisite-Installationen vervielfacht sich dieses Problem durch die Anzahl der Unterseiten. Die Lösung besteht entweder in inkrementellen Backups auf Dateiebene im rsync-Stil (WP-CLI + rsync oder eine verwaltete Plattform) oder darin, große Mediendateien bewusst aus dem WordPress-Backup auszuschließen und separat zu sichern, beispielsweise auf einem CDN-Origin-Server, in einem versionierten S3-Bucket oder in einem dedizierten Medienarchiv.

Datenbankkonsistenz auf Live-Websites

Ein naiver mysqldump Bei einer Live-WooCommerce-Datenbank werden Tabellen zu unterschiedlichen Zeitpunkten erfasst. Bestellungen in Tabelle A, Zahlungsdatensätze in Tabelle B und Kundendatensätze in Tabelle C können voneinander abweichen.

Die Lösung lautet mysqldump --single-transaction für InnoDB-Tabellen, die innerhalb einer einzigen Transaktion einen konsistenten Snapshot erstellen. Jede Sicherungsmethode, die dies bei einem stark frequentierten WooCommerce-Shop nicht berücksichtigt, führt unbemerkt zu beschädigten Datenbanken.

Wenn der Patch das Problem ist: Der „Really Simple Security“-Rollback

Im November 2024 dokumentierte Wordfence eine Sicherheitslücke in Really Simple Security, die die Authentifizierung umging und 4 Millionen Installationen betraf. WordPress.org führte ein erzwungenes automatisches Update durch, um das Problem flächendeckend zu beheben. Bei den meisten Websites wurde das Problem problemlos behoben. Bei einigen Websites, insbesondere solchen mit benutzerdefinierten 2FA-Abläufen oder Sicherheits-Plugins, die auf dieselben Filter zugreifen, kam es zu Problemen bei der Anmeldung, sodass ein Rollback erforderlich war.

Dies ist das unterschätzte Backup-Szenario.

Es ist kein Angreifer, der Ihre Website verschlüsselt.

Es handelt sich um einen legitimen, notwendigen Patch, der zufällig an einem Freitagnachmittag mit benutzerdefiniertem Code in Konflikt geraten ist.

Das Einzige, was den Dienst innerhalb der SLA des Kunden wiederherstellen kann, ist ein Backup, das vor dem Update innerhalb der letzten Stunden erstellt, überprüft und ohne Rücksprache mit dem Host wiederhergestellt werden kann.

Die Durchführung von Backups vor Updates in Verbindung mit visuellen Regressionstests ist die Standardlösung der Agentur für diese Art von Vorfällen. Das ist auch der Grund, warum Ihr Backup-Rhythmus nicht „nächtlich“ sein darf – zumindest nicht für Websites, bei denen Sie es sich nicht leisten können, dass sie zehn Stunden lang nicht erreichbar sind, während Sie auf den nächsten geplanten Snapshot warten.

DSGVO, Datenstandort und der rechtlich zulässige Speicherort Ihrer Backups

Schrems II und warum der Speicherort eine Rolle spielt

„Schrems II“ ist das Urteil des EuGH aus dem Jahr 2020, mit dem das EU-US-Datenschutzschild für ungültig erklärt wurde und das zusätzliche Maßnahmen für die Übermittlung personenbezogener Daten außerhalb der EU vorschreibt, wenn am Bestimmungsort kein gleichwertiger Schutz besteht. Für WordPress-Agenturen mit Kunden in der EU stellt die Datensicherung bei einem Anbieter mit Sitz in den USA ohne diese Maßnahmen ein Compliance-Risiko dar. Dies gilt selbst dann, wenn die Daten auf EU-Servern dieses Anbieters gespeichert sind.

Eine vertretbare Vorgehensweise für eine EU-Behörde besteht darin, einen in der EU ansässigen Backup-Anbieter zu wählen, dessen Speicherkapazitäten sich in der EU befinden und dessen Verträge keine Weiterleitung personenbezogener Daten an US-amerikanische Auftragsverarbeiter vorsehen. „DSGVO-konform“ als Marketingbegriff ist leicht zu verwenden. Was tatsächlich zählt, ist die zugrunde liegende Kette von Verantwortlichen und Auftragsverarbeitern.

Recht auf Löschung (Artikel 17) und Aufbewahrung von Sicherungskopien

Artikel 17 der DSGVO räumt den betroffenen Personen das Recht auf Löschung ihrer personenbezogenen Daten ein. Dies steht in direktem Widerspruch zu unveränderlichen Backups mit langer Aufbewahrungsdauer.

Die pragmatische und von den Aufsichtsbehörden akzeptierte Position lautet, dass die Löschung in Live-Systemen unverzüglich erfolgt, während die Aufbewahrungsfristen für Backups dokumentiert und zeitlich begrenzt sind und nach ihrem eigenen Zyklus gelöscht werden. In den Bestimmungen Ihres Pflegeplans sollte ausdrücklich auf die Aufbewahrungsfrist für Backups Bezug genommen werden. 50 Tage stellen einen vertretbaren Kompromiss zwischen Wiederherstellungs- und Löschpflichten dar.

Backups im Agenturmaßstab: ein Anwendungsbeispiel

Das Handbuch für 50 Standorte

Nehmen wir ein Portfolio von 50 Websites an: 30 Broschüren- oder Content-Websites, 15 Mitglieder-Websites und 5 stark frequentierte WooCommerce-Websites.

• Gestaffelte Aktualisierungshäufigkeit: täglich für Broschüren und Inhalte, zweimal täglich für Mitgliedschaften, stündlich für WooCommerce-Seiten mit hohem Datenaufkommen.
• Gestaffelte Aufbewahrungsfrist: 50 Tage.
• Externe Ziele: eine einzige verwaltete Plattform, Speicherung in der EU, AES-Verschlüsselung im Ruhezustand, TLS bei der Übertragung.
• Kundenberichterstattung: monatlicher White-Label-Bericht im PDF-Format mit Angaben zur Erfolgsquote der Backups sowie Informationen zum Speicherort der Backups.

Das ist das Konzept einer „Agency-First“-Infrastruktur, nicht ein Backup-Plugin pro Website.

Was ändert sich an über 200 Standorten?

Bei 200 Standorten ist nicht die Datensicherung der entscheidende Faktor, sondern das Team. Zentralisierte Zugangsdaten sind nicht mehr nur ein nettes Extra. Der rollenbasierte Teamzugang wird zu einer gesetzlichen Vorschrift, sobald Sie Nachwuchstechniker einstellen. Der 1-Klick-Administratorzugang ersetzt gemeinsame Zugangsdaten in Bitwarden. White-Label-Kundenberichte sind kein Alleinstellungsmerkmal mehr, sondern dienen der Kundenbindung. Die meisten Agenturen erreichen diesen Wendepunkt zwischen 120 und 180 Standorten.

Der WP Umbrella für die Backup-Infrastruktur

WP Umbrella der führende Anbieter im Bereich zuverlässiger WordPress-Backups – und das nicht aufgrund von Marketing, sondern dank seiner Architektur. Die Plattform nutzt Streaming-Backups: keine serverseitige Archivierung, keine Daten, die zwischen den Durchläufen auf dem Server Ihres Kunden verbleiben, keine Speicherbegrenzung, an die man stoßen könnte, und kein PHP-Timeout, das auslösen könnte.

Im Jahr 2025 haben wir über 8.500.000 Backups an mehr als 60.000 Standorten durchgeführt. Diese Zuverlässigkeitskennzahl ist keine bloße Behauptung, sondern eine operative Grundvoraussetzung.

Darüber hinaus:

• Native, AES-verschlüsselte inkrementelle Backups sind im Lieferumfang enthalten und nicht kostenpflichtig.
• Tages-, Wochen- und Monatspläne sowie ein stündliches Zusatzmodul für Websites mit hohem Schreibaufkommen.
• 50-Tage-Aufbewahrungsfrist für alle Tarife.
• Wiederherstellung von Dateien und Datenbanken mit einem Klick.
• DSGVO-konformer Speicher in der EU mit Standort in Frankreich.
• Dashboard für mehrere Standorte mit rollenbasiertem Teamzugriff.
• Pauschalpreis pro Standort.

In diesem pauschalen Preis pro Standort sind Updates, Verfügbarkeitsüberwachung, Schwachstellenerkennung und White-Label-Berichterstellung enthalten, sodass die Backup-Lösung Teil einer umfassenderen Infrastruktur für Wartungspläne ist und nicht von einem separaten Anbieter stammt.