WordPress-Backup hängt oder schlägt fehl: Ursachen und Lösungen

Ein WordPress-Backup, das bei 45 Prozent hängt, hängt meistens gar nicht. Den Balken zeichnet Ihr Browser. Der Auftrag, den er beschreibt, läuft auf Ihrem Server — und wenn beide den Kontakt verlieren, bleibt Ihr Balken stehen, während die Arbeit ohne ihn weitergeht.

Drei völlig verschiedene Zustände sehen auf diesem Bildschirm gleich aus: ein Auftrag, der noch arbeitet, ein Auftrag, der fertig wurde, während niemand hinsah, und ein Auftrag, der nie gestartet ist. Diese Anleitung unterscheidet sie. Jeder braucht einen anderen nächsten Schritt, und nur einer davon verlangt etwas von Ihnen.

Arbeitet es noch, oder erfährt die Seite es nur nicht?

Bevor Sie irgendetwas abbrechen, beantworten Sie eine Frage: Gibt es überhaupt noch einen Auftrag?

Schließen Sie das Fortschrittsfenster und öffnen Sie die Backup-Liste.Diese Liste schreibt Ihr Server, sobald ein Paket fertig ist. Den Balken zeichnet Ihr Browser, während er wartet. Steht Ihr Backup in der Liste, ist es fertig — egal, was der Balken zuletzt angezeigt hat.

Das ist der normale Ausgang, nicht der seltene. Ein Fenster, das bei 45 Prozent im Datenbankschritt stehen bleibt, sich lange nicht bewegt und dann 100 Prozent erreicht, nachdem Sie längst aufgegeben und den Tab geschlossen haben: Das Ende sehen Sie nie. Sie finden das Backup in der Liste, nicht auf dem Bildschirm.

Prüfen Sie, ob sich überhaupt noch etwas ändert.Zwei Anzeichen, die sich nützlich widersprechen:

• Ihre Paketdatei auf der Festplatte wächst, oder die verstrichene Zeit läuft weiter — dann arbeitet etwas;
• Dateigröße, Schritt und verstrichene Zeit stehen seit vielen Minuten still — dann ist Ihr Worker vermutlich gestoppt.

Drücken Sie nicht einfach noch einmal auf Start.Ein zweiter Auftrag ersetzt den ersten nicht. Er konkurriert mit ihm um dieselbe Festplatte, dieselbe Datenbank und dieselben PHP-Prozesse — und macht den ersten Fehler schwerer lesbar.

Was die Prozentzahl auf dem Bildschirm wirklich ist

Die Zahl misst nicht Ihren Auftrag. Sie ist die letzte Meldung, die Ihr Browser noch abholen konnte.

Ihr Backup läuft als abgekoppelter Worker auf dem Server. Dieser Worker schreibt seinen Zustand mit — Schritt, Fortschritt, verstrichene Zeit. Die Seite, auf die Sie schauen, fragt diesen Zustand alle paar Sekunden ab und zeichnet den Balken aus der Antwort. Zwei getrennte Dinge, verbunden durch eine HTTP-Anfrage, die für sich allein scheitern kann.

Bleibt diese Anfrage aus, friert Ihr Balken bei der letzten Zahl ein, und der Worker erfährt nie, dass Sie nicht mehr zuhören. Ein Notebook, das in den Ruhezustand geht, reicht schon. Ebenso ein Tab, den Ihr Browser im Hintergrund drosselt, ein Proxy, der eine untätige Verbindung schließt, oder ein Sicherheits-Plugin, das den Endpunkt zu drosseln beginnt.

Das Plugin sagt es selbst. Sein Fehlerkatalog führt AIOWS-BK-E2000als „Der Browser hat den Kontakt zum Fortschritts-Endpunkt des Backups verloren. Das Backup läuft möglicherweise noch auf dem Server — prüfen Sie die Backup-Liste in Kürze.“Diese Meldung spricht über Ihre Seite, nicht über Ihr Backup.

Lange Schritte halten Sie auf derselben Zahl fest, und das ist kein Fehler. Ein Datenbankschritt, der viele Tabellen leert, oder ein Dateischritt, der ein Verzeichnis mit Tausenden kleiner Dateien durchläuft, meldet selten, weil jede Arbeitseinheit klein ist. Ihr Balken darf minutenlang stillstehen und trotzdem völlig gesund sein.

Die Prozentzahl beantwortet also, was Ihre Seite zuletzt gehört hat. Die Backup-Liste beantwortet, ob Sie ein Paket haben. Nur die zweite Frage lohnt sich.

Das geplante Backup, das nie gestartet ist

Dieser Fall sieht anders aus und kommt weit häufiger vor, als er sollte. Sie speichern den Zeitplan, der nächste Termin kommt und geht, und nichts passiert. Nicht verspätet. Nie.

WP-Cron ist kein Cron.Es hat keinen Zeitgeber. WordPress prüft fällige Aufgaben erst, wenn jemand Ihre Seite besucht, und schickt dann eine Anfrage an die eigene wp-cron.php, um sie auszuführen. Ist Ihre Seite ruhig, kommt dieser Moment womöglich nie.

In WordPress erzeugen vier verschiedene Ursachen dieselbe Stille, und jede braucht eine andere Lösung:

• Ihr Hoster weist die Anfrage ab.wp-cron.phpantwortet mit 401 oder 403, also läuft nichts Geplantes.
• Ihre Seite erreicht sich selbst nicht.Die Loopback-Anfrage scheitert vollständig — eine DNS- oder Firewall-Konstellation, die Ihren Server daran hindert, den eigenen Hostnamen aufzurufen.
• Nichts ist kaputt, und trotzdem läuft nichts.wp-cron.phpantwortet normal; Ihre Seite hatte schlicht zu wenige Besuche.
• DISABLE_WP_CRONist gesetzt, ohne dass etwas dahintersteht.Jemand hat den eingebauten Planer abgeschaltet, um einen System-Cronjob einzurichten — und der Cronjob kam nie oder läuft nicht mehr.

Mit installiertem Backup Manager und aktivem Zeitplan stoppt die vierte Ursache Ihre Sicherungen nicht.Das Modul achtet darauf, ob sein eigener Termin überfällig ist, und ruft wp-cron.phpdann selbst auf, höchstens alle fünf Minuten. Die Konstante allein lässt Sie also nicht ohne Backups zurück.

Die anderen drei Ursachen behebt das nicht, und eine stille Seite rettet es ebenso wenig: Dieser Aufruf geschieht, während eine Seite ausgeliefert wird — kommt niemand vorbei, löst auch nichts aus. Und antwortet wp-cron.phpmit 401 oder 403, läuft der Aufruf des Moduls in dieselbe Abweisung wie der von WordPress.

Unter Werkzeuge → Website-Zustandtrennt der Test Geplante Aufgabendes Backup Managers alle vier Fälle und nennt Ihnen den zutreffenden. Er sagt Ihnen außerdem das, was währenddessen zählt: „Selbst gestartete Sicherungen sind nicht betroffen.“Ein Zeitplan, der nie auslöst, bricht keine Sicherung, die Sie von Hand anstoßen.

Die Lösung ist ein echter Cronjob.Richten Sie ihn auf Ihrem Server ein, alle fünfzehn Minuten:

*/15 * * * * cd /pfad/zu/wordpress && /pfad/zu/php -q wp-cron.php >/dev/null 2>&1

Danach sagen Sie WordPress in der wp-config.php, dass es den Versuch bei jedem Besuch lassen soll:

define('DISABLE_WP_CRON', true);

Die Reihenfolge zählt. Setzen Sie die Konstante erst, wenn der Cronjob läuft — sonst schalten Sie den besuchsgesteuerten Planer ab und haben nichts an seiner Stelle.

Wohin diese Zeile gehört, hängt von Ihrem Panel ab. Zwei Familien decken den größten Teil des europäischen Shared Hostings ab, und ein Hoster mit eigener Oberfläche benutzt dieselben zwei Begriffe — danach suchen Sie.

cPanel: Erweitert → Cron-Jobs.Unter Neuen Cronjob hinzufügenkommt die ganze Zeile in das Befehlsfeld, Zeitplan und Befehl zusammen.

Plesk: Geplante Aufgaben → Aufgabe hinzufügen.Plesk trennt beides: Der Zeitplan hat ein eigenes Feld (Cron style, die fünf Cron-Felder), also tragen Sie dort nur den Befehl ein. Nehmen Sie Run a command. Diese Maske bleibt auch auf einer deutschen Installation meist englisch — Sie suchen also Scheduled Tasks, Add Taskund Run a command. Fetch a URLauf Ihre eigene wp-cron.phpspart den PHP-Pfad, läuft aber über HTTP und trifft damit genau die Abweisung aus der ersten Ursache oben.

Den Fehlercode lesen

Wenn Ihr Auftrag doch stehen bleibt, bleibt er mit einem Code stehen. Die Codes sind feste Zeichenketten: Einer, den Sie in einem Jahr in einem Protokoll finden, bedeutet dann noch dasselbe.

Zwei davon sind keine Fehlschläge. E2000ist Ihre Seite, die den Faden verliert, und E4000sind Sie selbst. Die übrigen sagen Ihnen, wo Sie nachsehen — dafür sind Codes da.

Wo welcher Schritt an seine Grenze stößt

Ihr Backup ist kein einzelner Vorgang. Es sind vier, und sie scheitern an verschiedenen Ressourcen.

Wenn Sie den Schritt kennen, ist die Ursache auf eine Spalte dieser Tabelle eingegrenzt, bevor Sie irgendetwas ändern. Ein Lauf, der im Datenbankschritt endet, ist kein Platzproblem, und ein höheres memory_limithilft Ihnen nicht, wenn der Auftrag beim Hochladen abbrach.

Steht Ihr Schritt auf Datenbank und ist Ihre Website groß, ist meist eine einzelne Tabelle die Antwort und nicht das Limit — sehen Sie sich vorher an, warum eine WordPress-Datenbank wächst. Geht es um Speicherplatz, fangen Sie bei der Paketgröße an: Backup scheitert wegen vollem Speicher.

Abbrechen, ohne die Spuren zu verlieren

Abbrechen ist oft richtig. Zuerst abbrechen und danach nachsehen ist es nicht: Ihr erster Fehlschlag ist der aussagekräftige, und ein zweiter Lauf überschreibt genau die Bedingungen, die ihn verursacht haben.

Das Fortschrittsfenster zeigt zwei Dinge, die sich zu notieren lohnen — und genau die beiden verschwinden mit dem Fenster:

1. die Phase, in der es stehen blieb;
2. die verstrichene Zeit, die es erreicht hatte.

Notieren Sie außerdem die Uhrzeit, von Ihrer eigenen Uhr — das Fenster zeigt keine —, damit Sie später die passenden Zeilen in den Serverprotokollen finden.

Drei Angaben, die Sie dort vermuten würden, stehen schlicht nicht da: die Backup-ID, die verarbeitete Menge und die Größe des halben Pakets. Das Fenster führt eine Phase und eine Uhr, sonst nichts — rechnen Sie also nicht damit, eine ID daraus abzuschreiben.

Brechen Sie dann ab und lassen Sie die temporären Dateien in Ruhe. Ein Teilpaket, das noch einem Worker gehört, dürfen Sie nicht löschen: Das macht aus einem langsamen Auftrag einen fehlgeschlagenen und beseitigt zugleich Ihre Spuren. Die Aufbewahrung räumt alte Pakete von selbst weg.

Der eine Wiederholungslauf und was Sie vorher ändern

Ein Wiederholungslauf nach einer Änderung. Nicht drei Läufe auf gut Glück.

Schaffen Sie zuerst Platz.Vergleichen Sie Ihren freien Speicher mit der Größe Ihres letzten erfolgreichen Pakets. Ihr Backup braucht Platz für das neue Paket, während Ihre Website weiterläuft.

Grenzen Sie dann den Auftrag ein.Starten Sie ein Backup Nur Datenbank, danach eines Nur Dateien. Welches von beiden scheitert, ist die Hälfte mit Ihrem Problem — und jede Hälfte ist klein genug, um durchzulaufen, wo Ihr Vollbackup es nicht schafft. Die Einzelheiten stehen in den Anleitungen zum Datenbank-Backupund zum Dateien-Backup.

Schließen Sie aus, was Sie nicht sichern müssen.Alte Archive innerhalb von wp-contentsind der klassische Fall: Ihr Backup sichert die Backups des letzten Monats mit und wächst bei jedem Lauf, bis es nicht mehr durchkommt. Cache-Verzeichnisse und erzeugte Medienordner können Sie meist ebenfalls weglassen.

Ändern Sie ein Limit, nicht alle.Lautete Ihr Code E5000oder E5001, erhöhen Sie memory_limitoder max_execution_time— eines davon, um eine Stufe, und starten Sie erneut. Alles gleichzeitig zu erhöhen verdeckt, welches Limit das entscheidende war, und belastet Ihren Server ohne Gegenwert. Beides einzeln behandeln Memory-Limit sicher erhöhenund Maximale Ausführungszeit überschritten.

Behalten Sie Ihren letzten geprüften Wiederherstellungspunkt.Lassen Sie ein frisches Paket das letzte Backup, das Sie tatsächlich wiederhergestellt haben, erst ersetzen, wenn Sie auch das frische wiederhergestellt haben. Ein Paket, das existiert, ist kein Paket, das funktioniert.

Überprüfung

Ihr Backup ist fertig, wenn Sie es irgendwo wiederhergestellt haben — nicht, wenn eine Meldung 100 Prozent sagt.

Diese vierte Zeile wurde durchgeführt, und zwei Dinge daran sollten Sie wissen, bevor Sie sie selbst ausprobieren.

Das lokale Paket übersteht eine gescheiterte Übertragung.Mit einem Übertragungsziel wird das Paket zuerst auf der Festplatte gebaut und danach verschickt. Eine abgewiesene Anmeldung kostet Sie also die Kopie am Zielort, nicht die Sicherung. Das ist so gebaut, und deshalb ist eine gescheiterte Übertragung kein gescheitertes Backup.

Die zweite Hälfte der Meldung kommt auf Englisch, weil sie aus der Übertragungsschicht stammt und in der Sprache gespeichert wird, in der die Seite zum Zeitpunkt des Fehlers lief. Nur der vordere Teil wird beim Anzeigen übersetzt.

Und die Spur hält nicht.Der Fehler erscheint als schwebender Hinweis und ist beim nächsten Seitenaufruf verschwunden. In der Backup-Liste steht er nicht, und die Liste der Remote-Backups führt keine Zeile dazu. Auch ein AIOWS-BK-E-Code wird nicht gezeigt, obwohl der Katalog elf davon hat. Lesen Sie die Meldung also, solange sie auf dem Bildschirm steht — danach sagt Ihnen die Oberfläche nicht mehr, dass es passiert ist.

Eine Prüftabelle, in der jede Zeile bestehen soll, beweist nur, dass Sie lesen können.

Geht nicht Ihr Backup schief, sondern die Wiederherstellung, ist das ein eigenes Thema: Wiederherstellung hängt oder schlägt fehl. Und wenn Sie noch nie eine geprüft haben, fangen Sie hier an: WordPress-Backup prüfen.

Wie AIOWS unterstützt:

AIOWS Backup Manager

Der Backup Manager erstellt Ihr Backup und sagt Ihnen, was hier mehr zählt, in welcher der drei Lagen von oben Sie gerade sind.

Er nennt Phase und Code.Das Fortschrittsfenster zeigt die Phase und die verstrichene Zeit — die beiden Angaben, die vor einem Abbruch zählen, und die beiden, die mit dem Fenster verschwinden. Bleibt Ihr Auftrag stehen, endet er mit einem der elf festen AIOWS-BK-E-Codes aus der Tabelle oben statt mit einer allgemeinen Fehlermeldung.

Er prüft den Planer, statt ihm zu vertrauen.Der Backup Manager meldet einen Test Geplante Aufgabenunter Werkzeuge → Website-Zustandan. Der Test hält die vier Ursachen von oben auseinander und nennt Ihnen Ihre, dann gibt er eine Cron-Zeile für Ihre Installation aus, mit dem PHP-Binary, das er geprüft hat. Lässt sich das nicht prüfen, sagt er es und setzt einen Platzhalter, statt Ihnen einen Befehl zu geben, der um drei Uhr morgens stumm fehlschlägt.

Er meldet die vierte Ursache nicht nur, er fängt sie ab.Bei aktivem Zeitplan ruft er wp-cron.phpselbst auf, sobald sein eigener Termin überfällig ist — eine gesetzte Konstante ohne Cronjob dahinter stoppt Ihre Sicherungen damit nicht stillschweigend.

Er grenzt den Auftrag für Sie ein.Vollbackup, Nur Datenbankund Nur Dateiensind ein Auswahlfeld. Ihre Ausschlusspfade sind ein Kasten, ein Pfad pro Zeile. Lokal, Google Drive, OneDrive und FTP/SFTP sind Ziele, die Sie ohne neuen Zeitplan hinzufügen oder entfernen.

Er zeigt Ihnen, was eine Wiederherstellung wirklich getan hat.Das Wiederherstellungs-Centerhält für jede Wiederherstellung einen Beleg und einen Bericht bereit, den Sie hinterher lesen können. „Es wurde wiederhergestellt“ wird damit zu einem Nachweis statt zu Ihrer Erinnerung daran.

Seine Grenzen, klar gesagt. Das Modul kann weder die PHP-Limits Ihres Hosters noch Ihr Speicherkontingent anheben. Sein Aufruf an den Planer geht hinaus, während eine Seite ausgeliefert wird, und kann deshalb auf einer Seite, die niemand besucht, nicht auslösen; dort kann es Ihnen nur sagen, dass genau das passiert, und Ihnen die Cron-Zeile geben. Und es kann keinen Shared Host daran hindern, einen lang laufenden Worker zu beenden. Diese drei Dinge gehören Ihrem Hosting-Anbieter.

AIOWS Backup Manager ansehenAIOWS-Tarife vergleichen

Häufige Fragen

Der Balken bewegt sich seit zehn Minuten nicht. Ist das Backup tot?Nicht unbedingt. Schließen Sie das Fenster und sehen Sie in Ihrer Backup-Liste nach. Steht Ihr Paket dort, ist es fertig. Steht es nicht dort, prüfen Sie, ob die Datei auf der Festplatte noch wächst, bevor Sie abbrechen.

Darf ich den Tab schließen, während ein Backup läuft?Ja. Der Worker läuft auf Ihrem Server, nicht in Ihrem Browser. Das Schließen stoppt Ihren Fortschrittsbalken, nicht Ihr Backup.

Warum ist mein geplantes Backup überhaupt nicht gelaufen?Vermutlich hat niemand Ihre Seite um die geplante Zeit herum besucht, denn der eingebaute Planer von WordPress läuft auf Besuche und nicht auf die Uhr. Der Test Geplante Aufgabenunter Werkzeuge → Website-Zustandsagt Ihnen, welche der vier Ursachen bei Ihnen vorliegt.

Darf ich die Reste eines fehlgeschlagenen Backups löschen?Nur, wenn kein Worker sie mehr besitzt. Könnte noch ein Auftrag laufen, lassen Sie sie liegen — die Aufbewahrung räumt Ihre alten Pakete von selbst weg.

Das Backup wurde fertig, aber die Datei ist riesig. Ist das ein Fehler?Nein, aber meist sichern Sie damit etwas doppelt, und alte Archive innerhalb von wp-contentsind der häufigste Fall. Schließen Sie sie aus und starten Sie erneut.

Quellen

• WP-Cron — WordPress Developer Resources
• WP-Cron an den System-Taskplaner hängen
• WordPress-Dateien sichern — WordPress-Dokumentation
• PHP-Laufzeitkonfiguration: memory_limitund max_execution_time