Was WordPress-Backups zum Scheitern bringt: Lektionen aus über 1.400 Support-Tickets

Ein Backup, das fehlschlägt, während Sie zusehen, ist ärgerlich. Ein Backup, das vor Wochen leise aufgehört hat zu funktionieren, ist dasjenige, das Sie die Website kostet.

Die meisten Leute finden heraus, welche Art von Backup sie haben, zur ungünstigsten Zeit.

Duplicator ist ein WordPress-Backup- und Migrations-Plugin, das auf mehr als 1,5 Millionen Websites läuft. Wenn Leute Probleme mit Backups haben, erzählen sie uns im Detail, in ihren eigenen Worten.

Wir haben mehr als 1.400 Backup-bezogene Supportanfragen überprüft, um zu sehen, wo Backups fehlschlagen. Das Muster ist klarer als erwartet und teilt sich sauber in zwei Teile.

Backups geraten entweder in Schwierigkeiten, wenn ein Hoster-Limit den Build stoppt, oder wenn die Datei erstellt wird, aber der separate Schritt des externen Versendens nicht abgeschlossen wird.

Hier ist, was uns diese Tickets erzählt haben.

Diese Zahlen spiegeln das Volumen der Support-Tickets wider, nicht die Anzahl der Kunden, Installationen oder Verkäufe.

Inhaltsverzeichnis

Wichtigste Erkenntnisse

Für alle, die das Muster vor den Details wollen, hier ist, was die Tickets darüber sagen, wo WordPress-Backups fehlschlagen. Jede Zahl stammt aus den eigenen Support-Aufzeichnungen von Duplicator.

• Backup-Probleme teilen sich in zwei Cluster auf: ein Hoster-Limit, das den Build stoppt, und der externe Upload-Schritt, der nach der Erstellung der Datei nicht abgeschlossen wird.
• Ein Hostlimit, das den Build auf halbem Weg stoppt, ist das häufigste Problem bei der Backup-Erstellung, etwa 1 von 4 Tickets. Es ist dasselbe Host-Limit-Muster, das WordPress-Migrationen belastet, und der Build wird fast immer abgeschlossen, sobald das Limit erhöht wird.
• Unter den Tickets für Speicherverbindungen sind etwa 4 von 10 ein Authentifizierungs- oder Verbindungsfehler mit dem Cloud-Anbieter. Die Verbindung zum Speicher wird im Laufe der Zeit auf der Seite des Anbieters deautorisiert.
• Bei fehlgeschlagenen geplanten Backups gibt es zwei Ursachen: der Offsite-Upload bricht zwischen den Läufen ab (etwa 1 von 4) und alte Backups füllen die Festplatte des Servers, wenn kein Aufbewahrungslimit festgelegt ist (etwa 1 von 7).
• Die meisten Probleme mit geplanten Backups treten nach einer funktionierenden Einrichtung auf, nicht währenddessen. Der Zeitplan war am ersten Tag in Ordnung, und die Verbindung brach später ab.

TL;DR: Die Backup-Engine erledigt normalerweise ihre Arbeit. Was Probleme verursacht, ist, dass der Host den Build einschränkt oder die Verbindung zum Offsite-Speicher nach der Einrichtung abbricht. Beides ist vermeidbar, sobald man weiß, wo man suchen muss.

Eine Einschränkung, die die Interpretation all dessen beeinflusst. Dies sind Support-Tickets, daher zeigen sie, wo Backups auf Probleme stoßen, nicht wie oft.

Sie können auch nicht die Probleme erfassen, die niemand bemerkt hat, da jeder in diesen Daten ein Problem erkannt und ein Ticket eingereicht hat. Die stillen Fälle, die ein Website-Besitzer nie sieht, liegen vollständig außerhalb dieses Datensatzes.

Die zwei Arten, wie Backups fehlschlagen können

Fast jede Backup-Schwierigkeit, die wir sehen, ist eine von zwei Geschichten. Sobald Sie sie unterscheiden können, sind die Lösungen offensichtlich.

Das erste Problem liegt beim Server. Der Build beginnt, läuft eine Weile, und der Host stoppt ihn, bevor er fertig ist, normalerweise im schwierigsten Schritt.

Beim zweiten Problem geht es um die Offsite-Kopie. Die Backup-Datei wird erstellt, aber der separate Schritt, sie an den Speicher zu senden, wird nicht abgeschlossen, da dieser Schritt von einer Verbindung außerhalb von WordPress abhängt.

Problem Eins: Wenn ein Hoster-Limit den Build stoppt

Sie starten ein Backup, beobachten es und es schlägt fehl, bevor es abgeschlossen ist.

Dies ist das häufigste Backup-Problem, das wir sehen, und es ist fast immer der Webhost, nicht das Backup, der aufgegeben hat. Der Build beginnt, dann schneidet der Server ihn auf halbem Weg ab, normalerweise am Punkt der größten Arbeitsbelastung.

Diese Builds werden fast immer abgeschlossen, sobald das Host-Limit erhöht wird. Die Engine ist nicht die Variable; die Obergrenze des Servers ist es.

Ein Fehler sticht weit über den Rest hinaus. Bei etwa 1 von 4 Backup-Tickets stockt der Build auf halbem Weg, weil der Host den Prozess in seinem schwierigsten Moment abgebrochen hat. Der Rest der Liste sind Variationen desselben Themas:

Wo der Build stoppt	Ungefähre Häufigkeit	Was normalerweise dahinter steckt	Wie es gelöst wird
Host-Limit stoppt den Build auf halbem Weg	1 von 4	Ein PHP-Timeout oder eine Speicherbegrenzung des Hosts während des schwierigsten Schritts	Erhöhen Sie die PHP-Limits oder verwenden Sie ein Installationsprogramm, das für große Archive entwickelt wurde (DupArchive)
Archivschritt schlägt auf einem eingeschränkten Host fehl	Etwa 1 von 8	Begrenzter Speicherplatz oder PHP-Limits während der Komprimierung	Schaffen Sie Speicherplatz frei, erhöhen Sie die PHP-Limits und versuchen Sie es dann mit einem gechunkten Build erneut
Website zu groß für den Host, um sie zu verarbeiten	Etwa 1 von 12	Eine große Datenbank oder Mediathek übersteigt die Serverlimits	Teilen Sie den Build und schließen Sie große Dateien aus, die Sie nicht im Backup benötigen
PHP-Timeout auf dem Server	Etwa 1 von 20	Das Ausführungslimit ist für die Seitengröße zu niedrig eingestellt	Erhöhen Sie max_execution_time auf dem Server
Server-Ordnerberechtigungen	Etwa 1 von 22	Das Archiv kann nicht auf die Festplatte geschrieben werden	Ordnerberechtigungen auf dem Server korrigieren
Server-Speicherlimit erschöpft	Etwa 1 von 25	Der Build geht mitten in der Ausführung der Speicher aus	Erhöhen Sie memory_limit

Die gleiche Ursache taucht immer wieder auf: der Host. Der Build stoppt, weil der Server ihn im Moment der größten Arbeit, wenn das Archiv zusammengestellt wird, begrenzt hat, nicht weil die Engine aufgegeben hat.

Das ist auch der Grund, warum die Seitengröße so wichtig ist. Eine große Datenbank oder Medienbibliothek drängt den Build an die Grenze des Hosts.

Duplicator Pros eigenständiger Installer und das DupArchive-Format sind für große Website-Backups konzipiert. DupArchive hat keine theoretische Dateigrößenbeschränkung und hat echte Backups bis zu 400 GB verarbeitet.

Für schrittweise Hilfe bei der Lösung der Ressourcenprobleme Ihrer Website lesen Sie unseren Leitfaden zum Thema Sichern einer großen WordPress-Website.

Problem Zwei: Wenn der Off-Site-Upload nicht abgeschlossen wird

Monatelang sah alles gut aus. Dann möchten Sie das Backup der letzten Woche von Google Drive abrufen, und der Ordner ist leerer als erwartet.

Die Backups wurden erstellt. Sie sind nur nicht dort gelandet, wo Sie dachten.

Die Backup-Datei wird auf Ihrem Server erstellt. Das Senden an einen externen Speicherort ist ein separater Schritt, und dieser Schritt hängt von einer Verbindung zu Ihrem Cloud-Speicher oder Remote-Server außerhalb von WordPress ab.

Wenn diese Verbindung abbricht, existiert die Datei, aber die externe Kopie nicht. Sie werden die Lücke erst bemerken, wenn Sie sie brauchen.

Es läuft auf drei Dinge hinaus.

Die Speicherverbindung ist auf der Seite des Anbieters abgelaufen

Etwa 4 von 10 Tickets für Speicherverbindungen betreffen die Authentifizierung beim Cloud-Anbieter. Die Verbindung funktionierte bei der Einrichtung, dann hat der Anbieter sie nicht mehr anerkannt.

Cloud-Speicherverbindungen basieren auf Zugriffen, die im Laufe der Zeit ablaufen oder widerrufen werden, und das wird vom Speicheranbieter kontrolliert, nicht von WordPress.

OAuth-basierte Verbindungen wie Google Drive, Dropbox und OneDrive verwenden Tokens, die eine periodische Neuautorisierung erfordern.

Schlüsselbasierte Verbindungen wie Amazon S3 hängen von Anmeldeinformationen ab, die rotiert oder abgelehnt werden können. FTP und SFTP brechen ab, wenn sich ein Passwort oder Pfad ändert.

Die Datei wird erstellt. Die Anbieterverbindung ist es, die abbricht.

Autorisieren Sie die Verbindung neu und überprüfen Sie sie dann regelmäßig. Jede Verbindung, die ein Token verwendet, muss irgendwann neu autorisiert werden. Behandeln Sie dies also als routinemäßige Wartung, nicht als einmalige Einrichtung.

Alte Backups haben die Festplatte des Servers gefüllt

Etwa 1 von 7 fehlgeschlagenen geplanten Backups sind auf eine volle Festplatte zurückzuführen, und die Lösung ist eine Einstellung, die Sie kontrollieren.

Backups sammeln sich an, es sei denn, Sie legen ein Aufbewahrungslimit fest. Ohne eines davon wird jedes geplante Backup aufbewahrt, bis dem Server der Speicherplatz ausgeht, und der nächste Lauf hat keinen Platz zum Schreiben.

Duplicator ermöglicht es Ihnen, die Anzahl der aufbewahrten Backups zu begrenzen, sodass alte automatisch gelöscht werden und die Festplatte frei bleibt.

Das Festlegen eines klaren Aufbewahrungslimits stoppt das langsame Anschwellen, das einen Server füllt.

Die Verbindung ist zwischen den Läufen abgelaufen

Eine Verbindung, die am ersten Tag funktionierte, bricht Wochen später leise zusammen, und der geplante Lauf bricht mit ihr zusammen.

Zwei Dinge verursachen dies normalerweise. Manchmal ist es Verwirrung über Zeitzonen oder Häufigkeit. Ein anderes Mal tötet der Host den Hintergrundjob, bevor er ausgelöst werden kann.

Auf jeden Fall möchten Sie davon hören. Duplicator benachrichtigt Sie, wenn ein geplantes Backup oder Upload fehlschlägt, sodass ein fehlerhafter Lauf Sie erreicht, anstatt still zu bleiben.

Bestätigen Sie, dass die Planung noch verbunden ist, und verwenden Sie eine echte Server-Cron, wo Ihr Host dies unterstützt. Server-Cron ist zuverlässiger als die Standard-WordPress-Cron, die nur ausgelöst wird, wenn jemand die Website besucht.

Regelmäßige Backup-Updates helfen Ihnen, genau zu erkennen, wann Ihre Zeitpläne fehlschlagen. Richten Sie E-Mail-Zusammenfassungen ein für tägliche, wöchentliche oder monatliche Benachrichtigungen von Duplicator.

So erkennen Sie, ob Ihr Backup gerade sicher ist

Sie müssen Ihre Backups nicht beaufsichtigen. Sie müssen nur die fünf Dinge erkennen, die leise schiefgehen, und Sie können alle fünf in etwa zwei Minuten überprüfen.

• Bestätigen Sie, dass Ihr letztes geplantes Backup abgeschlossen wurde, nicht nur, dass ein Zeitplan existiert.
• Bestätigen Sie, dass eine Kopie extern gespeichert ist, nicht nur auf demselben Server, auf dem sich Ihre Website befindet.
• Bestätigen Sie, dass die Speicherverbindung noch autorisiert ist, insbesondere wenn seit der Einrichtung Monate vergangen sind.
• Bestätigen Sie, dass ein Aufbewahrungslimit festgelegt ist, damit die Festplatte nicht voll wird.
• Schalten Sie Fehlerbenachrichtigungen ein, damit jeder fehlerhafte Lauf Sie erreicht.

Wenn Sie dies zum ersten Mal einrichten oder einen vorhandenen Zeitplan straffen möchten, führt Sie unser Leitfaden zu automatischen WordPress-Backups durch die Einrichtung.

Dieser Bericht handelt davon, was danach zu beachten ist und wie man ein Problem frühzeitig erkennt.

Duplicator Pro hilft in den beiden Bereichen, in denen diese Daten auftauchen. Es sendet Fehlerbenachrichtigungen, wenn ein Backup oder Upload fehlschlägt. Es stellt auch direkt aus dem Cloud-Speicher wieder her, sodass Sie Änderungen rückgängig machen können, ohne Backup-Dateien auf Ihren Server hochladen zu müssen.

Häufig gestellte Fragen (FAQs)

Das Backup, das Sie nie überprüfen, ist dasjenige, das fehlschlägt

Der Wert dieser Daten ist keine einzelne Statistik. Es ist das, worauf sie Ihre Aufmerksamkeit lenken.

Probleme bei der Sicherung treten an zwei Stellen auf: eine Host-Beschränkung, die den Build stoppt, und die externe Kopie, die nicht abgeschlossen wird. Die erste ist laut und Sie werden sie bemerken. Die zweite ist leise und sie ist diejenige, die dazu führt, dass Leute keine externe Sicherung haben, wenn sie sie brauchen.

Wir werden das Limit noch einmal angeben, weil es die Ehrlichkeit wahrt. Dies ist eine Aufzeichnung von Problemen, die Leute gemeldet haben, nicht von jeder Sicherung, die ausgeführt wurde. Es kann die Fälle nicht sehen, die niemand bemerkt hat. Aber es ist real und es ist aus erster Hand.

Hier ist die eine Gewohnheit, die all das übertrifft. Stellen Sie einmal eine Sicherung auf einer Staging-Site wieder her und bestätigen Sie, dass die Site zurückkommt. Eine Sicherung, die Sie noch nie wiederhergestellt haben, ist eine Vermutung. Eine Sicherung, die Sie einmal wiederhergestellt haben, ist ein Plan.

Stellen Sie vor Ihrer nächsten Sicherung sicher, dass sie im Speicher ankommt

Eine Sicherung, die ins Stocken gerät oder ihren externen Upload nie abschließt, wird zu einem Problem, wenn Sie sie wiederherstellen müssen. Das ist der schlimmste Zeitpunkt, um es herauszufinden.

Duplicator Pro wird von mehr als 1,5 Millionen WordPress-Profis verwendet, um ihre Websites zu sichern, zu migrieren und wiederherzustellen. Es sendet Benachrichtigungen über Sicherungsfehler und stellt direkt aus dem Cloud-Speicher wieder her, sodass die Kopie, die Sie erstellt haben, die Kopie ist, die Sie zurückbekommen können.

Während Sie hier sind, sind diese anderen WordPress-Ressourcen einen Blick wert:

• Was 8.000+ Support-Tickets über die Gründe für den Abbruch von WordPress-Migrationen verraten
• HÖREN SIE AUF, DIESE WEBSITE-BACKUP-FEHLER ZU MACHEN (SIE GEFÄHRDEN IHRE WEBSITE)
• Wie oft sollten Sie Ihre WordPress-Website sichern?
• So erhalten Sie sicheren Backup-Speicher für Ihre WordPress-Site
• Warum Ihre WordPress-Site Backup-Überwachung benötigt (nicht nur Backups)