So erstellen Sie manuell ein Backup von WordPress ohne Plugin (2026)

Es gibt verschiedene Möglichkeiten, eine WordPress-Seite zu sichern: ein Backup-Plugin, den integrierten Dienst Ihres Hosts, eine Managed-Plattform oder die manuelle Sicherung in Eigenregie. In dieser Anleitung geht es um die letzte Möglichkeit: die Sicherung von WordPress ohne Plugin, also manuell, mithilfe von SFTP für die Dateien und phpMyAdmin für die Datenbank.

Manuelle Backups bieten Ihnen volle Kontrolle und sind völlig unabhängig von Plugins. Sie eignen sich besonders gut, wenn Sie vor einem Update ein Sicherheitsnetz benötigen, vor einer Migration einen einmaligen Snapshot erstellen möchten oder ein überprüfbares Archiv benötigen, bei dem Sie sich nicht darauf verlassen müssen, dass ein Plugin es korrekt erstellt.

Wo sie jedoch Schwächen zeigen, sind wiederkehrende Zeitpläne über mehrere Websites hinweg, und sie sind definitiv nicht schneller als ein Klick. Rechnen Sie damit, beim ersten Mal 15 bis 60 Minuten zu benötigen, je nach Größe Ihrer Website und Ihren Kenntnissen im Umgang mit SFTP.

Im Folgenden erfährst du, warum man die manuelle Methode einem Plugin vorziehen könnte, wie der vollständige Vorgang für Dateien und Datenbank abläuft, welche Schritte zur Wiederherstellung erforderlich sind und findest eine Checkliste zur Überprüfung, damit du sicher sein kannst, dass dein Backup tatsächlich funktioniert.

Was sind WordPress-Backups?

Ein WordPress-Backup ist einfach eine vollständige Kopie von allem, was Ihre Website zum Betrieb benötigt. Dazu gehören alle WordPress-Kerndateien, Ihre Plugins, Themes und die Datenbank, in der Ihre Inhalte gespeichert sind.

Stellen Sie sich vor, Sie machen einen Schnappschuss Ihrer Website zu einem bestimmten Zeitpunkt. Wenn Hacker Ihre Website angreifen oder Ihr Server abstürzt, können Sie mit diesem Backup alles wiederherstellen, anstatt alles von Grund auf neu aufzubauen. Mit Ihrem Backup können Sie schnell wieder online gehen und Ihre Kunden zufrieden stellen.

Vollständige Website-Sicherung vs. partielle Website-Sicherung

Es gibt zwei Hauptarten von WordPress-Backups. Ein vollständiges Backup erfasst alles (Kern, Themes, Plugins, Uploads, Datenbank), sodass Sie die gesamte Website aus einem einzigen Archiv wiederherstellen können; dies geht jedoch mit höherem Speicherbedarf und längeren Übertragungszeiten einher. Ein Teil-Backup erfasst nur die Dateien oder nur die Datenbank; dies ist schneller und weniger speicherintensiv, doch die Wiederherstellung dauert länger, da Sie Teile aus verschiedenen Datensätzen zusammenfügen müssen.

Bei manuellen Backups ist eine vollständige Sicherung fast immer die richtige Wahl: Die Speicherkosten sind verschwindend gering im Vergleich zu den Kosten, die entstehen, wenn man unter Zeitdruck bei der Wiederherstellung raten muss, was fehlt.

Warum regelmäßige Backups wichtig sind

Regelmäßige WordPress-Backups sind das einzige zuverlässige Sicherheitsnetz gegen Datenverlust, Sicherheitsverletzungen, fehlgeschlagene Updates und Serverausfälle. Ohne eine aktuelle, wiederherstellbare Kopie Ihrer Dateien und Ihrer Datenbank kann jedes dieser Ereignisse dazu führen, dass Ihre Website auf unbestimmte Zeit offline geht.

Das Theme Ihrer Website, die Dateien (wie Plugins) und die Datenbank (einschließlich Beiträgen, Benutzern, Kommentaren usw.) sollten alle gesichert werden.

Backups sind vergleichbar mit dem Speichern wichtiger Dokumente auf Google Drive, Dropbox oder dem Desktop.

Generell ist es immer ratsam, wichtige Daten mehrfach und auf verschiedenen Geräten wie einer externen Festplatte, einem USB-Stick oder Ihrem Computer zu speichern. Das Gleiche gilt für Ihre Website. Hier sind die Gründe, warum Sie Ihre Website sichern sollten:

Schutz vor Datenverlust: Mit Backups sind Sie geschützt, wenn jemand versehentlich Ihre Homepage löscht oder wichtige Inhalte überschreibt. Dies ist besonders wichtig, wenn mehrere Teammitglieder Zugriff auf Ihre Website haben.

Sicherheitsverletzungen: Wenn Hacker in Ihre Website eindringen, hinterlassen sie oft Schadcode oder löschen Inhalte. Mit einem sauberen Backup aus der Zeit vor dem Angriff können Sie die Folgen des Hackerangriffs beseitigen, ohne Ihre Website zu verlieren.

Laut Patchstacks Bericht „State of WordPress Security in 2025“ wurden 33 % der im Jahr 2024 bekannt gewordenen WordPress-Sicherheitslücken nicht rechtzeitig vor ihrer Veröffentlichung behoben. Wenn ein Drittel der bekannt gewordenen Schwachstellen ohne einen Patch des Anbieters ausliefert wird, betreibt jeder Betreiber mindestens eine Website, auf der bekanntermaßen ausnutzbarer Code läuft, für den keine Lösung verfügbar ist. Das einzige realistische Sicherheitsnetz ist ein aktuelles, wiederherstellbares Backup.

Aktualisierungen und Änderungen: Aktualisierungen von Plugins und Themes können manchmal zu einem Absturz Ihrer Website führen oder das Design beeinträchtigen. Mit einem Backup können Sie schnell auf die funktionierende Version zurückgreifen, während Sie herausfinden, was schiefgelaufen ist. Das bedeutet weniger Ausfallzeiten und weniger panische Anrufe von Kunden.

Serverausfälle: Wenn Ihr Hosting-Server abstürzt oder Ihr Provider Probleme hat, kann Ihre Website komplett verschwinden. Mit einem eigenen Backup sind Sie nicht auf das Backup-System Ihres Hosts angewiesen (das ebenfalls ausfallen könnte). Sie können schnell auf einen neuen Server umziehen und Ihre Website wiederherstellen – oft innerhalb von Stunden statt Tagen.

Warum nicht ein Backup-Plugin verwenden?

Backup-Plugins sind für die meisten WordPress-Nutzer der einfachste Weg, und das aus gutem Grund: installieren, konfigurieren, planen, fertig.

Warum also sollte man auf das Plugin verzichten und stattdessen manuell sichern? Fünf gute Gründe dafür.

1. Plugin-Kompatibilitätsprobleme treten immer zum ungünstigsten Zeitpunkt auf. Backup-Plugins versagen häufig nach Updates des WordPress-Kerns, von PHP oder von anderen Plugins. Genau dann, wenn Ihr Backup am wertvollsten ist – unmittelbar nach einem risikobehafteten Update –, ist die Wahrscheinlichkeit am größten, dass das Plugin nicht mehr funktioniert.
2. Zeitüberschreitungen beim Server auf großen Websites. Bei Shared Hosting gelten in der Regel Ausführungszeitlimits von 30 bis 60 Sekunden für PHP. Backup-Plugins, die mysqldump ausführen oder ZIP-Dateien erstellen wp-content stossen regelmässig an diese Grenzen, was zu Teilarchiven führt, die zwar erfolgreich erscheinen, aber nicht wiederherstellbar sind. Manuelle SFTP- und SSH-Backups unterliegen dieser Einschränkung nicht.
3. Verbot von Backup-Plugins von Drittanbietern bei Hosting-Anbietern. Managed-WordPress-Hosts wie WP Engine, Kinsta und Pagely schränken Backup-Plugins von Drittanbietern ein oder deaktivieren sie gänzlich, da diese die Server-E/A stark belasten. Wenn Ihr Hosting-Anbieter Backup-Plugins verbietet, bleibt Ihnen nur die manuelle Sicherung oder die Nutzung von WP-CLI.
4. „Erfolgreiche“ Backups, die es gar nicht sind. Ein Plugin, das zwar einen Erfolg meldet, aber nur einen unvollständigen Datenbank-Dump erstellt, ist schlimmer als gar kein Backup, da es ein falsches Gefühl der Sicherheit vermittelt. Bei manuellen Exporten haben Sie direkten Einblick in die Dateigröße und die Zeilenanzahl, bevor Sie dem Archiv vertrauen.
5. Einmalige Fälle, in denen ein Plugin übertrieben wäre. Ein Snapshot vor der Migration, eine einmalige Absicherung vor einem größeren Update, das Einfrieren einer Website vor der Übergabe an den Kunden. Manuell geht es schneller, als ein Plugin zu installieren und zu konfigurieren, das man eine Stunde später wieder deinstalliert.

Wann ist manuelles Schalten die falsche Entscheidung?

Regelmäßige Backups für Portfolios mit mehreren Standorten, WooCommerce-Shops mit stündlichen Transaktionsdaten oder einfach für alle, die das Erstellen von Backups oft vergessen. Wenn das auf Sie zutrifft, ist ein Backup-Plugin oder eine verwaltete Plattform die bessere Wahl. Einen Überblick über alle Optionen finden Sie in unserem umfassenden Leitfaden zu WordPress-Backups.

Und wenn Sie regelmäßige Backups über mehrere Standorte hinweg mit nachprüfbarer Wiederherstellung benötigen, bieten Plattformen wie WP Umbrella genau dafür da.

Wie Sie Ihre Website ohne Plugin sichern

Der einfachste Weg, ein Backup einer WordPress-Website zu erstellen, ist die Nutzung einer Managed-Plattform oder eines Backup-Plugins. Für die oben genannten Sonderfälle und einmaligen Szenarien bietet Ihnen ein manueller Ansatz jedoch eine Kontrolle, die kein Plugin bieten kann. Regelmäßige Backups Ihrer Website sind unerlässlich. Sie können diesen Vorgang manuell durchführen, wenn Sie kein spezielles Plugin installieren möchten oder keines finden, das Ihren Anforderungen entspricht.

So sichern Sie Ihre gesamte WordPress-Website ohne ein Plugin.

Schritt 1: Sichern Sie Ihre WordPress-Dateien (über SFTP)

Ihre WordPress-Website besteht aus vielen Dateien: den Installationsdateien des WordPress-Kerns, Plugins, Themes, hochgeladenen Medien, benutzerdefiniertem Code und wp-config.php (die Stammkonfigurationsdatei, in der Ihre Datenbank-Anmeldedaten und Sicherheitsschlüssel gespeichert sind).

Die tägliche Arbeit beschränkt sich meist auf Plugins, Themes und Uploads. Sichern Sie die gesamte Website trotzdem: Bei einer Teil-Sicherung müssen Sie unter dem Druck der Wiederherstellung herausfinden, was fehlt – und genau dann wollen Sie nicht raten müssen.

So sichern Sie die Dateien Ihrer WordPress-Website:

1. Laden Sie den FileZilla-Client herunter und installieren Sie ihn (kostenlos und Open Source, verfügbar für macOS, Windows und Linux).
2. Erstellen Sie im Site-Manager von FileZilla eine neue Site. Stellen Sie das Protokoll auf „SFTP – SSH File Transfer Protocol“ und den Port auf 22 ein und geben Sie Ihre Hosting-Anmeldedaten ein.
3. Stellen Sie eine Verbindung zu Ihrem Server her. Im Remote-Panel wird die Verzeichnisstruktur Ihrer Website angezeigt.
4. Wechseln Sie in Ihr WordPress-Stammverzeichnis (in der Regel public_html/, www/oder htdocs/ (je nach Host). Es handelt sich um den Ordner, der wp-config.php, wp-content/und wp-includes/.
5. Klicken Sie mit der rechten Maustaste auf den Stammordner und wählen Sie „Herunterladen“. FileZilla kopiert alle Ihre Dateien auf Ihren lokalen Rechner. Bei Websites mit umfangreichen Medienbibliotheken kann dies zwischen 30 Minuten und einigen Stunden dauern.
6. Sobald die Übertragung abgeschlossen ist, überprüfen Sie das Übertragungsprotokoll von FileZilla auf fehlgeschlagene Dateien. Eine Sicherung mit übersprungenen Dateien ist keine vollständige Sicherung. Übertragen Sie alle fehlgeschlagenen Dateien erneut.

Ihre SFTP-Zugangsdaten finden Sie in der Regel in Ihrem Hosting-Control-Panel unter „SFTP-Konten“ oder „SSH-Zugang“. Sollten Sie sie nicht finden können, kann Ihnen der Support Ihres Hosting-Anbieters den Host, den Port, den Benutzernamen und die Authentifizierungsmethode mitteilen.

Sobald der Download überprüft wurde, haben Sie Ihre Dateisicherung. Damit ist die Hälfte der Arbeit erledigt, nun geht es an die Datenbank.

Schritt 2: Sichern Sie Ihre WordPress-Datenbank

Es reicht nicht aus, lediglich die Dateien Ihrer Website zu sichern. WordPress speichert alle Ihre Beiträge, Seiten, Kommentare, Benutzer, Einstellungen, Plugin-Konfigurationen und fast alles, was Ihre Website ausmacht , in einer MySQL-Datenbank. Würden Sie nur Ihre Dateien sichern, bliebe eine leere Website zurück: keine Beiträge, keine Seiten, keine Einträge in der Medienbibliothek.

So geht’s richtig mit phpMyAdmin, dem webbasierten MySQL-Verwaltungstool, das in den meisten Hosting-Control-Panels enthalten ist.

Vorbereitender Schritt: Die richtige Datenbank finden. Beim Shared Hosting verfügt Ihr Hosting-Konto oft über mehrere Datenbanken. Die falsche Datenbank zu sichern, ist der häufigste Fehler bei manuellen Backups. Öffnen wp-config.php (die Sie bereits aus Schritt 1 haben) in einem beliebigen Texteditor und suchen Sie nach folgenden Zeilen:

define( 'DB_NAME', 'your_database_name_here' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' )
define( 'DB_HOST', 'localhost' );
$table_prefix = 'wp_';

Beachten Sie die DB_NAME Wert: Das ist die Datenbank, die Sie exportieren müssen. Hinweis DB_USER, DB_PASSWORDund DB_HOST auch; du wirst sie für die Wiederherstellung brauchen. Die $table_prefix Diese Zeile gibt an, welche Tabellen in dieser Datenbank zu dieser WordPress-Installation gehören (relevant, wenn sich mehrere WordPress-Seiten eine Datenbank teilen).

Exportieren mit phpMyAdmin (benutzerdefiniert, nicht „Quick“). Melden Sie sich bei Ihrem Hosting-Control-Panel an und öffnen Sie phpMyAdmin. Dann:

1. Klicken Sie in der linken Seitenleiste auf den Namen der Datenbank, der DB_NAME von wp-config.php. Vergewissere dich, dass es das richtige ist.
2. Klicken Sie oben auf die Registerkarte „Exportieren “.
3. Wählen Sie unter „Exportmethode“ die Option „Benutzerdefiniert – alle möglichen Optionen anzeigen“ aus. Bei der Standardoption „Schnell“ wird eine wichtige Einstellung ausgelassen, was dazu führt, dass der Export nicht in eine bestehende Datenbank wiederhergestellt werden kann.
4. Bestätigen Sie unter „Tabellen“ alle Tabellen, die Ihren Kriterien entsprechen $table_prefix werden ausgewählt.
5. Behalten Sie unter „Ausgabe“ die Option „Ausgabe in einer Datei speichern“ bei und aktivieren Sie die Komprimierung (bei großen Datenbanken wird zip oder gzip empfohlen).
6. Wählen Sie unter „Format“ die Option „SQL“ aus.
7. Aktivieren Sie unter „Optionen zur Objekterstellung“ die Option „DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER-Anweisung hinzufügen“. Dies ist die wichtigste Einstellung, die in den meisten Tutorials übersehen wird.
8. Behalten Sie die Standardeinstellungen unter „Optionen zur Datenerstellung“ bei (INSERT-Anweisungen, Hexadezimal für BLOB).
9. Klicken Sie auf „Los“. Die Datei wird auf Ihren Computer heruntergeladen.

Warum „DROP TABLE“ wichtig ist. Wenn Sie diesen Export später in eine Datenbank wiederherstellen, die bereits Tabellen enthält, löscht der Import zunächst die vorhandenen Tabellen, bevor er sie neu anlegt. Ohne DROP TABLE, schlägt die Wiederherstellung mit der Fehlermeldung „Tabelle existiert bereits“ fehl oder führt im schlimmsten Fall zu einer unvollständigen Zusammenführung alter und neuer Daten.

Häufige Fehler von Bedienern:

• Unter Verwendung des „Schnell“-Exports und unter der Annahme, dass die Daten in einer Datenbank mit vorhandenen Tabellen wiederhergestellt werden können.
• Die Auswahl der falschen Datenbank, wenn bei Shared Hosting mehrere WordPress-Installationen auf einem MySQL-Server gehostet werden. Immer gegenprüfen DB_NAME.
• Dabei wird oft vergessen, dass dadurch lediglich die Datenbank exportiert wird. Dateien (Themes, Plugins, Uploads, wp-config.php) sind für eine vollständige Sicherung weiterhin erforderlich.
• Abweichung bei Zeichensatz oder Sortierreihenfolge. Wenn die Quelldatenbank utf8mb4 und das Ziel ist utf8… Sonderzeichen werden beim Wiederherstellen beschädigt. Überprüfen Sie vor dem Import unter der Registerkarte „Operationen“ in phpMyAdmin, ob der Zeichensatz übereinstimmt.

Wenn Ihre Datenbank größer als 500 MB ist, wird phpMyAdmin Schwierigkeiten haben. Die offizielle phpMyAdmin-Dokumentation empfiehlt stattdessen die Verwendung direkter MySQL- oder MariaDB-Befehle. Siehe dazu den Abschnitt zu WP-CLI weiter unten. Ausführlichere Informationen finden Sie im „Advanced Administration Handbook“ auf WordPress.org zum Thema Datenbanksicherungen, in dem die verschiedenen Optionen detailliert behandelt werden.

Schritt 3: Wiederherstellung aus Ihrem Backup

Ein Backup, das man nicht wirklich wiederherstellen kann, ist kein richtiges Backup. Hier erfährst du, wie du deine Dateien und deine Datenbank wiederherstellst, und welche Fallstricke die meisten Administratoren bei ihrer ersten Wiederherstellung erwarten.

Stellen Sie die Dateien über SFTP wieder her. Stellen Sie mit FileZilla eine Verbindung zum Zielserver her (gleiche SFTP-Einstellungen wie in Schritt 1). Navigieren Sie zum WordPress-Stammverzeichnis. Ziehen Sie Ihren lokalen Sicherungsordner per Drag & Drop in das Remote-Stammverzeichnis. Bestätigen Sie eventuelle Überschreibungen. Bei einem neuen Server kann dies eine Weile dauern; das Übertragungsprotokoll von FileZilla zeigt Ihnen an, wann jede Datei an ihrem Platz ist.

Stellen Sie die Datenbank über phpMyAdmin wieder her. Wählen Sie im phpMyAdmin Ihres Ziel-Hostings die Zieldatenbank in der linken Seitenleiste aus. Klicken Sie auf die Importieren Registerkarte. Wählen Sie Ihre .sql (oder .sql.gz) Datei. Wählen Sie unter „Format“ die Option „SQL“ aus. Klicken Sie auf Los. Die Wiederherstellung wird ausgeführt, wobei alle vorhandenen Tabellen gelöscht und anhand Ihres Exports neu erstellt werden. Aus diesem Grund wird die DROP TABLE Die Einstellung aus Schritt 2 war entscheidend.

Aktualisieren Sie die Datei „wp-config.php“ auf dem neuen Server. Wenn Sie die Wiederherstellung auf einem anderen Host durchführen, bearbeiten Sie wp-config.php und aktualisieren DB_NAME, DB_USER, DB_PASSWORDund DB_HOST um sie an die neue Datenbank anzupassen. Bei Shared Hosting, DB_HOST ist selten nur localhost. Den genauen Wert finden Sie im Hosting-Panel.

Die fünf Fallstricke, in die jeder tappen kann:

1. Ersetzen der URL/Domain bei der Wiederherstellung auf einer Staging-Umgebung oder einer neuen Domain. WordPress speichert die URL Ihrer Website in der Datenbank, häufig in serialisierten PHP-Arrays, die beschädigt werden, wenn Sie sie einfach per SQL-Update bearbeiten. Der sichere Weg ist WP-CLI:

wp search-replace 'old.com' 'new.com' --all-tables --precise --dry-run

1. Überprüfen Sie die Ausgabe des Testlaufs und führen Sie den Vorgang dann erneut aus, ohne --dry-run. Die --precise flag verarbeitet serialisierte Daten korrekt.
2. Zeichensatz-/Sortierreihenfolge-Konflikt (utf8 vs. utf8mb4). Wenn Ihre Quell- und Zieldatenbanken unterschiedliche Zeichensätze verwenden, werden Sonderzeichen bei der Wiederherstellung beschädigt. Passen Sie vor dem Import entweder die Zeichensätze auf der Registerkarte „Operationen“ in phpMyAdmin an, oder öffnen Sie Ihre .sql Datei und Suchen/Ersetzen utf8mb4 mit utf8 (oder umgekehrt), damit es passt.
3. Falsche Dateiberechtigungen nach dem SFTP-Upload. Verzeichnisse sollten die Berechtigung 755 haben, Dateien 644, und wp-config.php 600 oder 640. Über SSH:find /path/to/wp -type d -exec chmod 755 {} \; find /path/to/wp -type f -exec chmod 644 {} \; chmod 600 /path/to/wp/wp-config.php
4. Schöne Permalinks funktionieren nicht oder .htaccess fehlt. Melden Sie sich nach der Wiederherstellung bei wp-admin an und gehen Sie zu Einstellungen → Permalinksund klicken Sie auf Änderungen speichern ohne etwas zu bearbeiten. WordPress generiert .htaccess.
5. Cache und Opcache liefern veraltete Inhalte. Leeren Sie Ihren Seiten-Cache (über das Host-Cache-Panel, WP Rocket oder W3 Total Cache – „Purge All“). Leeren Sie den Browser-Cache. Wenn Sie Cloudflare oder ein anderes CDN verwenden, leeren Sie auch dessen Cache. Über WP-CLI: wp cache flush.

Wenn die Website geladen wird, der Admin-Bereich funktioniert und auf der Startseite kein Datenbankfehler angezeigt wird, bist du fast fertig. Teste nun das Backup gründlich.

Gehen Sie vorsichtig vor. Stellen Sie sicher, dass Ihre WordPress-Version, Ihre PHP-Version und das Backup, das Sie wiederherstellen, miteinander kompatibel sind. Testen Sie Ihre Website nach der Wiederherstellung gründlich, um sicherzustellen, dass alles ordnungsgemäß funktioniert.

Wie oft sollten Sie manuelle Backups durchführen?

Die Häufigkeit richtet sich nach der Änderungsrate. WooCommerce-Shops oder andere Websites, auf denen Transaktionen abgewickelt werden, benötigen stündliche oder Echtzeit-Backups; Websites mit häufig aktualisierten Inhalten sollten täglich oder wöchentlich gesichert werden; bei reinen Informationsseiten und archivierten Seiten reicht eine monatliche Sicherung aus.

Wie lange dauert eine manuelle Sicherung tatsächlich? Bei einem kleinen Blog (unter 1 GB) sollten Sie mit 15 bis 30 Minuten von Anfang bis Ende rechnen. Bei einer inhaltsreichen Website mit einer umfangreichen Medienbibliothek oder einem WooCommerce-Shop mit Tausenden von Produkten ist eine Stunde oder mehr realistisch. Der SFTP-Download ist der Engpass, nicht phpMyAdmin.

Beste Praktiken für die Sicherung einer WordPress-Website

Regelmäßige Backups einrichten

Führen Sie Backups nach einem Zeitplan durch, der der Aktualisierungshäufigkeit Ihrer Website entspricht. Wenn Sie täglich neue Inhalte veröffentlichen, sollten Sie täglich ein Backup erstellen. Wenn Sie nur selten Aktualisierungen vornehmen, reicht ein wöchentliches Backup aus. Manuelle Backups sind nur dann sinnvoll, wenn sie auch tatsächlich durchgeführt werden. Tragen Sie sie daher in Ihren Kalender ein oder wechseln Sie zu einer automatisierten Lösung.

Sicheres Speichern von Backups

Speichern Sie Backups nicht auf demselben Server, auf dem die Live-Website gehostet wird, und verwenden Sie dafür Zugangsdaten, die sich von denen für Ihr Hosting-Konto unterscheiden. Damit soll ein Single Point of Failure vermieden werden: Sollte Ihr Hosting-Konto kompromittiert werden, sollte das Backup davon unberührt bleiben.

Verschlüsseln Sie Ihre Sicherungsdateien

Sicherungsdateien enthalten eine vollständige Kopie Ihrer Website, einschließlich aller sensiblen Kundendaten in Ihrer Datenbank. Verschlüsseln Sie diese während der Speicherung und Übertragung. Für lokale Archive empfiehlt sich VeraCrypt oder gpg (in den meisten Linux-Distributionen und unter macOS integriert) bewältigen dies problemlos. Verwenden Sie für Cloud-Speicher einen Anbieter, der standardmäßig serverseitige Verschlüsselung unterstützt.

Wende die 3-2-1-Regel an

Die 3-2-1-Regel ist die einfachste Methode zur Datensicherung, die auch bei tatsächlichen Ausfällen Bestand hat: drei Kopien Ihrer Website auf zwei verschiedenen Speichermedien, wobei eine Kopie außerhalb des Standorts aufbewahrt wird. Die Anforderung, dass sich eine Kopie „außerhalb des Standorts“ befinden muss, stellt für die meisten Betreiber die größte Hürde dar. Eine Sicherungskopie, die sich /home/user/backups auf demselben Server, auf dem Ihre Live-Website gehostet wird, gilt nicht als extern, da ein einziger Hosting-Vorfall (Kontosperrung, Ransomware, Brand im Rechenzentrum) beide betrifft.

Eine realistische 3-2-1-Konfiguration für einen WordPress-Betreiber:

• 3 Kopien: der Produktionsserver + ein nächtliches Backup auf dem Hosting-Server + ein wöchentliches Archiv auf Ihrem Laptop
• 2 Speichermedien: Server-Dateisystem + Cloud-Objektspeicher (Backblaze B2, Wasabi oder AWS S3)
• 1 extern: ein monatliches Cold-Archiv in einem anderen Cloud-Konto oder auf einem externen Laufwerk an einem separaten physischen Standort

Diese letzte Kopie ist diejenige, die erhalten bleibt, wenn Ihr Hosting-Konto selbst gelöscht wird.

Testen Sie Ihre Backups regelmäßig

Schritt 4 befasst sich mit dem Verifizierungsablauf. Das Wichtigste dabei: eine vierteljährliche Wiederherstellungsübung nach festem Zeitplan. Nicht getestete Backups versagen unbemerkt, und man bemerkt es erst an dem Tag, an dem eine echte Wiederherstellung erforderlich ist.

Kennen Sie Ihren Restaurierungsprozess

Führen Sie die Wiederherstellungsschritte aus Schritt 3 einmal durch, bevor Sie sie tatsächlich benötigen. Zwei Kompatibilitätsprobleme stellen für die meisten Betreiber eine Falle dar: Versionsunterschiede bei WordPress (die Wiederherstellung eines Backups von Version 6.4 auf Version 6.6 funktioniert problemlos; umgekehrt kann es jedoch zu Fehlern kommen) und Versionsunterschiede bei PHP (ein Backup von PHP 7.4 kann unter PHP 8.2 fehlschlagen, wenn ein Plugin Funktionen verwendet, die entfernt wurden). Vergewissern Sie sich vor dem Import, dass beide Versionen mit denen des Zielservers übereinstimmen.

WP-CLI / SSH-Methode (für Entwickler)

Wenn Sie SSH-Zugriff auf Ihren Server haben (die meisten hochwertigen Hosting-Pakete bieten diesen an), ist WP-CLI (die offizielle WordPress-Befehlszeilenschnittstelle) für Datenbankaufgaben deutlich schneller und zuverlässiger als phpMyAdmin. Die folgenden Code-Blöcke setzen voraus, dass Sie eine SSH-Verbindung hergestellt und sich in Ihr WordPress-Stammverzeichnis gewechselt haben. Überprüfen Sie, ob WP-CLI installiert ist, mit wp --info; falls nicht, finden Sie Informationen zur Installation in der Dokumentation Ihres Hosting-Anbieters.

Datenbankexport mit DROP TABLE (entspricht dem oben beschriebenen benutzerdefinierten Ablauf in phpMyAdmin):

wp db export --add-drop-table db-backup-$(date +%Y-%m-%d).sql

Export einer komprimierten Datenbank:

wp db export - | gzip > db-backup-$(date +%Y-%m-%d).sql.gz

Dateisicherung mit sinnvollen Ausschlüssen:

tar --create --gzip \
  --exclude='wp-content/cache' \
  --exclude='wp-content/uploads/cache' \
  --exclude='wp-content/debug.log' \
  --exclude='*.log' \
  --file=files-backup-$(date +%Y-%m-%d).tar.gz \
  /var/www/html

Kombiniertes Backup-Skript (Speichern unter /usr/local/bin/wp-backup.sh, dann chmod 700):

#!/bin/bash
SITE_PATH="/var/www/html"
BACKUP_DIR="/var/backups/wp"
DATE=$(date +%Y-%m-%d-%H%M)
cd "$SITE_PATH" || exit 1
wp db export "$BACKUP_DIR/db-$DATE.sql" --add-drop-table
tar --create --gzip \
  --exclude='wp-content/cache' \
  --exclude='*.log' \
  --file="$BACKUP_DIR/files-$DATE.tar.gz" \
  "$SITE_PATH"

Täglicher Cron-Job um 3 Uhr morgens (crontab -e):

0 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

Ein wissenswerter Hinweis zu Crontab: der % Das Zeichen hat in Crontab-Dateien eine besondere Bedeutung. Indem man die Datumslogik in ein Skript einbindet (wie oben), umgeht man das Problem. Wenn man schreibt $(date +%Y-%m-%d) direkt in einer Crontab-Zeile, setze ein Escape-Zeichen vor \%Y-\%m-\%d.

Bei größeren Websites (über 2 GB) sollte der Arbeitsspeicher tar+gzip für pigz (paralleles gzip) oder verwenden Sie rsync für inkrementelle Übertragungen. Die vollständige Referenz für wp db export befindet sich auf der WordPress.org-Entwicklerhandbuch.