Warum Ihr WordPress-Backup langsam ist oder fehlschlägt (und wie Sie es beheben können)

Ihr WordPress-Backup läuft seit 45 Minuten. Nichts ist kaputt, aber eine Fortschrittsanzeige bewegt sich weiter. Oder sie ist vor einer Stunde bei 63 % stehen geblieben und hat sich seitdem nicht bewegt.

Oder vielleicht verlangsamt sich Ihre Website jede Nacht um 3 Uhr morgens bis zum Stillstand, und Sie können nicht herausfinden, warum. Sie überprüfen Ihre Plugin-Einstellungen, führen einen Geschwindigkeitstest durch, und nichts Offensichtliches taucht auf. Dann erwähnt jemand Backups, und es klickt.

Langsame und fehlgeschlagene WordPress-Backups sind dasselbe Problem in unterschiedlicher Verkleidung. Der Backup-Prozess selbst könnte zu lange dauern oder stillschweigend fehlschlagen, bevor er abgeschlossen ist. Andererseits könnte Ihr Backup erfolgreich abgeschlossen werden, aber die Ressourcen, die es während der Ausführung verbraucht, verlangsamen Ihre Live-Website.

Die Lösung unterscheidet sich je nachdem, welches Problem Sie haben. Dieses Tutorial behandelt beide.

Am Ende haben Sie sich mit langsamen Website-Backup-Geschwindigkeiten befasst, die Duplicator Pro-Einstellungen durchgearbeitet, die diese beheben, und einen Backup-Zeitplan eingerichtet, der nicht mit Ihrem tatsächlichen Traffic konkurriert.

Hier sind die wichtigsten Erkenntnisse:

• Es gibt zwei verschiedene Probleme mit der Backup-Geschwindigkeit: Ein Backup-Prozess, der langsam (oder kaputt) ist, und ein Backup, das Ihre Live-Website während des Backup-Fensters verlangsamt. Die Behebung ist für jedes unterschiedlich, und dieser Beitrag behandelt beide.
• Ein Backup, das vollständig aussieht, aber nicht wiederhergestellt werden kann, ist ein PHP-Timeout-Problem, kein Korruptionsproblem. Das DupArchive-Format von Duplicator Pro verhindert dies, indem Dateien in Blöcken anstatt in einem kontinuierlichen Vorgang verarbeitet werden.
• Die Reduzierung Ihrer Archivgröße ist der mit Abstand schnellste Hebel. Cache-Verzeichnisse, Protokolldateien und übrig gebliebene Backup-Archive anderer Plugins können sicher ausgeschlossen werden und machen oft den Großteil des unnötigen Backup-Gewichts aus.
• Tägliche vollständige Website-Backups sind normalerweise übertrieben. Ein tägliches reines Datenbank-Backup in Kombination mit einem wöchentlichen vollständigen Website-Backup reduziert die Erstellungszeit und die Serverlast, ohne die Wiederherstellungsabdeckung zu beeinträchtigen.
• WordPress Cron läuft nicht nach einem echten Zeitplan. Backups, die für 3 Uhr morgens geplant sind, können lautlos in Spitzenverkehrszeiten verschoben werden. Der Ersatz von WP-Cron durch einen echten Server-Cronjob macht geplante Backups tatsächlich zuverlässig.
• Testen Sie eine Wiederherstellung, bevor Sie eine benötigen. Die meisten Leute entdecken ein kaputtes Backup während einer echten Katastrophe. Die Überprüfung einer Wiederherstellung auf einer Staging-Website dauert nur wenige Minuten und ist der einzige Schritt, der eine schnelle Wiederherstellung von einer schmerzhaften trennt.

Inhaltsverzeichnis

Wie lange sollte ein WordPress-Backup dauern?

Auf einer gut konfigurierten Website mit anständigem Hosting sollte ein vollständiges Backup in zwei bis zehn Minuten abgeschlossen sein. Große Websites auf Shared Hosting könnten 30 bis 45 Minuten dauern, manchmal länger. Und die Zeit variiert nicht nur nach Website-Größe, sondern auch danach, wie das Backup ausgeführt wird, was Ihr Host zulässt und ob Ihr Server unter Last steht, wenn der Prozess beginnt.

Vier Faktoren treiben die meisten Variationen an.

• Host I/O-Limits

Shared Hosting drosselt, wie viele Lese- und Schreibvorgänge Ihr Konto pro Sekunde ausführen kann. Ein Backup liest jede Datei auf Ihrer Website und schreibt sie in ein Archiv. Auf einem gedrosselten Server verlangsamt sich dieser Vorgang bis zum Stillstand und kann die Antwortzeit Ihrer Website während der Ausführung beeinträchtigen.

• Website-Größe

Eine große Mediathek, eine aufgeblähte Datenbank oder jahrelang angesammelte Plugin-Dateien verlängern die Build-Zeit. Eine 500 MB große Website und eine 5 GB große Website werden nicht gleich gesichert.

• Backup-Methode

Vollständige Backups komprimieren jedes Mal alles von Grund auf neu. Inkrementelle Backups speichern nur, was sich seit dem letzten Lauf geändert hat, was sie nach Abschluss des ersten Backups schneller macht.

Duplicator führt keine echten inkrementellen Backups durch, aber die Zwei-Zeitplan-Strategie in diesem Tutorial bietet Ihnen die meisten Vorteile: Tägliche reine Datenbank-Backups erfassen, was sich auf einer typischen Website tatsächlich ändert, und der aufwendige vollständige Website-Build läuft wöchentlich.

• PHP-Timeouts

Die meisten Shared-Hosting-Anbieter legen PHP-Ausführungszeitlimits zwischen 30 und 60 Sekunden fest. Ein Backup, das dieses Limit überschreitet, wird mitten im Prozess beendet. Die Datei sieht vollständig aus. Das ist sie nicht. Dies ist eine der häufigsten Ursachen für Backups, die scheinbar erfolgreich sind, aber bei der Wiederherstellung fehlschlagen.

Was Sie vor dem Start benötigen

Bevor Sie Einstellungen ändern, stellen Sie sicher, dass Sie Folgendes zur Verfügung haben.

• Ein installiertes und aktives WordPress-Backup-Plugin. Dieses Tutorial verwendet Duplicator, ein WordPress-Backup-, Migrations- und Disaster-Recovery-Plugin, das von mehr als 1,5 Millionen WordPress-Profis verwendet wird. Es kümmert sich um Backups, Website-Migrationen, Staging und Wiederherstellungen – einschließlich eines blockbasierten Archivformats, das speziell entwickelt wurde, um die auf Shared Hosting üblichen PHP-Timeout-Limits zu überstehen.
• WordPress-Admin-Zugang (Sie benötigen ihn, um auf die Einstellungen Ihres Backup-Plugins zuzugreifen)
• Zugang zum Hosting-Kontrollpanel (cPanel oder das Äquivalent Ihres Hosts – benötigt für die Einrichtung von Server-Cronjobs und PHP-Limit-Änderungen)
• Ihre aktuelle Backup-Größe (finden Sie im Paket Ihres Backup-Plugins oder auf dem Bildschirm mit der Backup-Historie)
• Ihr Hosting-Typ: Shared, VPS, Managed WordPress oder Dedicated. Dies ist wichtig, da einige Korrekturen in diesem Tutorial die Kooperation Ihres Hosts erfordern. Bei Shared Hosting können Sie PHP-Einstellungen nicht immer selbst ändern.
• Zugang zum Hosting-Support (Live-Chat oder ein Ticket-System – Sie benötigen ihn möglicherweise für die Schritte 3 und 8)

Wenn Sie Ihren Hosting-Typ vor Beginn kennen, sparen Sie Zeit. Erhöhungen von Shell Exec und PHP-Speicherlimits werden auf Serverebene gesteuert. Was Sie selbst ändern können, hängt vollständig von Ihrem Plan ab.

So beschleunigen Sie Ihre Website-Backups

Wenn Sie diese Schritte durcharbeiten, erzielen Sie die schnellsten Ergebnisse. Der erste Schritt ist eine Diagnose, damit Sie wissen, welche Korrekturen tatsächlich auf Ihre Situation zutreffen, bevor Sie mit der Änderung von Einstellungen beginnen.

Hier ist, was Sie tun werden:

• Schritt 1: Identifizieren Sie Ihr Backup-Leistungsproblem: Diagnostizieren Sie, ob Ihr Backup-Prozess langsam oder fehlerhaft ist oder ob abgeschlossene Backups Ihre Live-Website verlangsamen, da die Korrektur für jede Situation unterschiedlich ist
• Schritt 2: Reduzieren Sie, was gesichert wird: Schließen Sie Cache-Verzeichnisse, Protokolldateien und übrig gebliebene Plugin-Archive aus, um die Archivgröße zu verringern. Dies ist der schnellste Weg, um die Build-Zeit zu verkürzen.
• Schritt 3: Wechseln Sie zu einer schnelleren Archivierungs-Engine: Ersetzen Sie PHP-basierte ZipArchive durch Shell Exec für Geschwindigkeit oder DupArchive für Ausfallsicherheit auf Hosts mit engen PHP-Ausführungslimits.
• Schritt 4: Beheben Sie langsame Datenbank-Backups: Wechseln Sie den SQL-Modus zu PHP-Code und führen Sie eine Datenbankbereinigung durch, um die Exportzeit bei Datenbanken über 20 MB zu verkürzen.
• Schritt 5: Ersetzen Sie den WordPress-Cron durch einen echten Server-Cronjob: Lassen Sie geplante Backups zur von Ihnen festgelegten genauen Zeit ausführen, anstatt sie jedes Mal auszulösen, wenn der erste Besucher ankommt.
• Schritt 6: Richten Sie eine Zwei-Zeitplan-Backup-Strategie ein: Führen Sie täglich nur Datenbank-Backups und wöchentlich vollständige Website-Backups separat durch, damit rechenintensive Builds so selten wie möglich stattfinden.
• Schritt 7: Fordern Sie höhere Server-Ressourcenlimits an: Erhöhen Sie die PHP-Speicher- und Ausführungszeitlimits als letzte Option, wenn alle anderen Einstellungen bereits optimiert sind.

Starten Sie hier: Lassen Sie AutoTune Ihre Einstellungen finden

Bevor Sie Einstellungen auf Ihrer Website ändern, lassen Sie Duplicator diese für Sie testen.

Duplicators AutoTune führt echte Test-Backups auf Ihrem Server durch. Es beginnt mit der schnellsten Konfiguration, und wenn ein Test fehlschlägt, ändert es nur die Einstellung, die den Fehler verursacht hat, und versucht es erneut, bis ein Backup erfolgreich ist.

Das ist derselbe Prozess, den Sie manuell durchführen würden, nur dass er Minuten statt eines Nachmittags mit Raten und Überprüfen dauert.

Klicken Sie oben auf Ihrer Backup-Seite auf AutoTune oder gehen Sie zu Tools » AutoTune. Es arbeitet sich durch:

• Archivierungs-Engine und Komprimierung
• ZIP-Modus und Chunks-Größe
• Datenbank-Engine und PHP-Dump-Modus
• Reduzierung der Serverlast

Sie erhalten auch ein Serverübersicht-Panel, das den Worker-Modus, Loopback-Anfragen, HTTP-Authentifizierung, Prozesssperren sowie Ihre PHP-Zeit- und Speicherlimits überprüft.

Jeder Punkt besteht oder schlägt fehl, mit Ratschlägen, wenn etwas Ihre Aufmerksamkeit erfordert. Einige Probleme liegen auf Serverebene, wo kein Plugin-Einstellung sie beheben kann – AutoTune kennzeichnet diese und sagt Ihnen, wonach Sie Ihren Host fragen sollen.

Wenn Sie geplante Backups ausführen, werden diese während der Tests von AutoTune pausiert und nach Abschluss fortgesetzt, sodass ein Tuning-Lauf nicht mit Ihrem nächtlichen Build kollidiert.

Für die meisten Leute ist das die ganze Lösung. Lesen Sie weiter, wenn das Ergebnis von AutoTune immer noch nicht schnell genug ist, wenn Sie verstehen möchten, was es geändert hat, oder wenn Sie jede Option lieber selbst einstellen möchten.

Schritt 1: Identifizieren Sie Ihr Backup-Leistungsproblem

Es verbergen sich zwei verschiedene Probleme hinter „Mein Backup ist langsam“.

• Problem A: Der Backup-Prozess selbst ist langsam oder fehlerhaft. Anzeichen dafür sind Builds, die 20+ Minuten dauern, eine Fortschrittsanzeige, die bei einem bestimmten Prozentsatz einfriert, oder ein Backup, das scheinbar abgeschlossen wird, aber während der Wiederherstellung fehlschlägt.
• Problem B: Ihre Backups verlangsamen Ihre Live-Website. Anzeichen dafür sind Besucher oder Administratoren, die während eines wiederkehrenden Zeitfensters eine Verlangsamung melden, oder ein Überwachungstool, das einen Anstieg der Antwortzeit zeigt, der nach einem vorhersehbaren Zeitplan auftritt.

Um sie zu unterscheiden, beginnen Sie mit dem Build-Protokoll Ihres Backup-Plugins. Gehen Sie für Duplicator zu Duplicator Pro » Tools » Duplicator Logs. Suchen Sie das Protokoll für Ihr letztes Backup.

Andere Plugins haben ähnliche Protokolle – überprüfen Sie die erweiterten Einstellungen Ihres Plugins.

Scrollen Sie nach unten. Wenn Sie eine Timeout-Fehlermeldung, eine Speicherfehlermeldung oder eine Zeile sehen, die mitten im Prozess abbricht, handelt es sich um Problem A. Wenn das Protokoll zeigt, dass es abgeschlossen wurde, Ihre Website aber immer noch langsam ist, handelt es sich um Problem B.

Wenn Ihr Build-Log besagt, dass das Backup abgeschlossen ist, aber das Backup während einer Wiederherstellung fehlschlägt, hat ein PHP-Ausführungszeitlimit den Build wahrscheinlich stillschweigend abgebrochen, bevor er beendet wurde.

Die Datei existiert, aber sie wurde abgeschnitten. Es sieht aus wie Problem A, aber die Ursache sind Hosting-Ressourcenlimits. Schritt 3 behandelt dies direkt.

Wenn Sie Hilfe beim Lesen der Duplicator-Backup-Protokolle benötigen, lesen Sie diese Anleitung.

Schritt 2: Reduzieren Sie, was gesichert wird

Jeder zusätzliche Megabyte in Ihrem Backup verlängert die Build-Zeit. Bei Shared Hosting, wo CPU und Disk I/O bereits eingeschränkt sind, macht ein aufgeblähtes Archiv Backups langsamer und bringt Sie näher an die Timeout-Schwelle.

Der schnellste Weg, Ihr Backup zu verkleinern, ist, keine Dateien mehr einzuschließen, die nicht dort sein müssen.

Die häufigsten Übeltäter:

• Cache-Verzeichnisse
• Protokolldateien
• Temporäre Dateien
• Backup-Archive, die von anderen Plugins zurückgelassen wurden
• Große Mediendateien wie Videos, die Sie auch auf einem CDN oder einem externen Dienst speichern

Nichts davon beeinträchtigt Ihre Fähigkeit, eine funktionierende Website wiederherzustellen. Caches werden automatisch neu generiert, wenn Besucher Seiten laden. Protokolle sind kein Teil Ihrer Website. Alte Backup-Archive von anderen Plugins sind nur unnötige Ballast.

Hier erfahren Sie, wie Sie Backups in Duplicator Pro anpassen. Erstellen Sie ein neues Backup, indem Sie zu Duplicator Pro » Backups » Neu hinzufügen gehen.

Im Abschnitt Backup sehen Sie Voreinstellungen und Filter.

Aktivieren Sie die Dateifilter. Schließen Sie zuerst Ihr Cache-Verzeichnis aus, indem Sie den Cache-Filter auswählen.

Wenn Sie ein Caching-Plugin wie WP Rocket oder W3 Total Cache verwenden, gibt es möglicherweise auch einen plattformeigenen Unterordner innerhalb von wp-content. Fügen Sie den vollständigen Pfad für jeden hinzu.

Fügen Sie dann alle Protokollverzeichnisse hinzu. Gängige Speicherorte sind wp-content/debug.log und plattformspezifische Protokollordner.

Schließen Sie wp-content/uploads nicht aus, es sei denn, Sie speichern alle Ihre Medien in einem separaten CDN und haben eine bestätigte, aktuelle Kopie jeder Datei. Schließen Sie nur bestimmte Dateierweiterungen aus, von denen Sie sicher sind, dass sie woanders gesichert werden. Wenn Sie Ihre Medien hier falsch machen, bedeutet dies eine erfolgreiche Wiederherstellung, bei der die Hälfte Ihrer Bilder fehlt.

Sobald Sie Ihre Filter hinzugefügt haben, fahren Sie mit dem Backup fort. Duplicator Pro scannt Ihre Website und meldet andere große Dateigrößen.

Schritt 3: Wechseln Sie zu einer schnelleren Backup-Engine

Sobald Ihre Backup-Datei so schlank wie möglich ist, ist die nächste Variable, wie das Backup erstellt wird. Standardmäßig verwendet es die integrierte ZipArchive von PHP. Das funktioniert, aber es läuft vollständig innerhalb von PHP, was bedeutet, dass es allen Ressourceneinschränkungen unterliegt, die Ihr Hoster festlegt: Ausführungszeit, Speicher und CPU-Drosselung.

Auf einem leistungsfähigen Server ist es wahrscheinlich in Ordnung. Auf Shared Hosting kann es zu Engpässen führen.

Sie haben zwei Alternativen, und welche Sie verwenden, hängt von Ihrem Hoster ab.

Option A: Shell Zip

Dies schaltet die Backup-Archiv-Engine von PHP auf das native System-Zip-Binary Ihres Servers um. Das Zip-Tool des Betriebssystems ist für die meisten Komprimierungsaufgaben schneller als PHP und zählt nicht auf die gleiche Weise gegen Ihr PHP-Ausführungszeitlimit.

Um zu wechseln, gehen Sie zu Duplicator Pro » Einstellungen » Backups » Archiv und wählen Sie Shell Zip.

Bevor Sie den Wechsel vornehmen, sollten Sie Folgendes wissen: Einige günstige Shared-Hoster deaktivieren shell_exec auf Serverebene. Wenn Sie die Einstellung ändern und Ihr nächster Build sofort bei 0 % fehlschlägt, ist das der Grund.

Wechseln Sie auf demselben Einstellungsbildschirm zurück zu ZipArchive und kontaktieren Sie dann Ihren Hoster und bitten Sie ihn, shell_exec für Ihr Konto zu aktivieren. Wenn er nicht helfen kann, gehen Sie zu Option B.

Option B: DupArchive

DupArchive ist Duplicators eigenes Archivformat und funktioniert anders als Standard-ZIP. Anstatt eines kontinuierlichen Komprimierungsvorgangs verarbeitet DupArchive Ihre Dateien in kleineren Blöcken. Jeder Block wird abgeschlossen, bevor der nächste beginnt.

Auf Shared-Hosting-Plänen mit PHP-Ausführungszeitlimits von 30 bis 60 Sekunden wird ein Standard-ZIP-Backup, das länger als dieses Limit dauert, mitten im Build abgebrochen. Der Vorgang stoppt, aber die Datei wurde bereits auf die Festplatte geschrieben.

Ihr Backup sieht vollständig aus. Wenn Sie dann versuchen, es wiederherzustellen, schlägt es fehl. Die Datei wurde abgeschnitten, bevor sie fertig war.

DupArchive vermeidet dies vollständig. Da jeder Chunk die PHP-Ausführungszeit zurücksetzt, übersteht das Backup Limits, die eine Standard-ZIP-Erstellung zum Absturz bringen würden. Ich habe gesehen, dass dies bei Shared-Hosting-Umgebungen bereits mehrfach Probleme gelöst hat.

Um zu wechseln, gehen Sie zu Duplicator Pro » Einstellungen » Backups » Archiv und wählen Sie DupArchive.

Führen Sie nach dem Wechsel zu einer der Optionen ein Test-Backup durch. Erstellen Sie ein kleines Backup und überprüfen Sie anschließend das Protokoll. Scrollen Sie zum Ende des Protokolls und bestätigen Sie, dass es erfolgreich abgeschlossen wurde.

Schritt 4: Langsame Datenbank-Backups beheben

Eine große Datenbank verlangsamt den gesamten Backup-Prozess, nicht nur den Teil, in dem die Datenbank exportiert wird. Wenn Ihre Datenbank aufgebläht ist, werden Sie dies während des gesamten Vorgangs spüren.

Um die Größe Ihrer Datenbank zu ermitteln, starten Sie ein neues Backup in Duplicator Pro und lassen Sie den Einrichtungsassistenten den Scan durchlaufen. Er listet die Größe Ihrer Datenbank auf, bevor Sie mit der Erstellung des Backups beginnen.

Wenn sie über 20 MB liegt, können diese Korrekturen eine spürbare Verbesserung bewirken.

Korrektur 1: SQL-Modus auf PHP-Code umstellen

Gehen Sie zu Duplicator Pro » Einstellungen » Backups » SQL-Modus und ändern Sie die Einstellung von MySQL dump auf PHP Code. Dies ändert die Methode, die Duplicator zum Exportieren Ihrer Datenbanktabellen verwendet.

Die PHP-Code-Methode ist auf Shared-Hosting-Umgebungen im Allgemeinen zuverlässiger, da sie seltener Timeouts bei Tabellensperren auslöst, die den Export ins Stocken bringen. Es ist eine kleine Änderung mit einer bedeutenden Auswirkung auf größere Datenbanken.

Korrektur 2: Datenbank vor dem nächsten Backup bereinigen

Dies dauert ein paar Minuten, ist aber vor jedem wichtigen Backup lohnenswert.

Installieren Sie DB Optimizer und führen Sie es aus, um Beitragsrevisionen, Spam-Kommentare, abgelaufene Transienten und verwaiste Metadaten zu entfernen. Diese sammeln sich auf aktiven Websites leise an und können 30 bis 50 Prozent des Datenbank-Bloats ausmachen, ohne etwas zu enthalten, das Sie tatsächlich wiederherstellen müssen.

DB Optimizer ist kostenlos bei Duplicator Pro enthalten!

Bereinigen Sie jedoch nicht Ihre Datenbank und führen Sie sofort zum ersten Mal ein kritisches Backup durch. Führen Sie die Bereinigung durch, durchsuchen Sie dann Ihre Website und überprüfen Sie, ob alles normal funktioniert. Sichern Sie dann.

Bereinigungen sind mit einem seriösen Tool sicher, aber Sie möchten bestätigen, dass Ihre Website gesund ist, bevor Sie diesen Zustand in ein Backup sperren.

Nachdem Sie beide Änderungen vorgenommen haben, führen Sie ein neues Backup durch und vergleichen Sie die Erstellungszeit mit Ihrer vorherigen Basislinie. Bei Datenbanken über 20 MB ist der Unterschied normalerweise sichtbar.

Schritt 5: Ersetzen Sie WordPress Cron durch einen echten Server-Cronjob

Wenn Ihre Backups geplant sind, aber immer zur falschen Zeit ausgeführt werden, oder wenn Ihre Website während der Geschäftszeiten und nicht im von Ihnen festgelegten ruhigen Zeitfenster langsamer wird, ist wahrscheinlich der WordPress-Cron schuld.

WP-Cron läuft nicht nach einem echten Zeitplan. Es wird nur ausgelöst, wenn jemand Ihre Website besucht.

Wenn Traffic ankommt, prüft WordPress, ob überfällige geplante Aufgaben vorhanden sind, und führt sie in diesem Moment aus. Ein Backup, das Sie für 3 Uhr morgens geplant haben, wird ausgeführt, wenn der erste Besucher erscheint, was mitten in Ihrem Hauptverkehrsfenster sein kann.

Der Ersatz von WP-Cron durch einen Server-Cronjob stellt sicher, dass Ihre Backups jedes Mal zur exakt festgelegten Zeit ausgeführt werden, unabhängig vom Traffic.

Erstellen Sie zunächst ein Konto auf https://cron-job.org/. Erstellen Sie dann einen neuen Cronjob.

Benennen Sie den neuen Cronjob. Legen Sie dies als URL fest und ersetzen Sie sie durch die Domain Ihrer Website: https://example.com/wp-admin/admin-ajax.php?action=duplicator_process_worker

Stellen Sie den Ausführungsplan auf Jede 1 Minute.

Sobald der Server-Cronjob aktiv und gespeichert ist, fügen Sie diese Zeile zu Ihrer wp-config.php-Datei hinzu, oberhalb der Zeile, die lautet "That's all, stop editing!":

define('DISABLE_WP_CRON', true);

Dies weist WordPress an, sein eigenes Cron-System nicht mehr auszuführen.

Fügen Sie die define-Zeile nur dann zu wp-config.php hinzu, wenn der Server-Cronjob bestätigt und gespeichert wurde. Wenn Sie WP-Cron zuerst deaktivieren, werden alle geplanten Aufgaben auf Ihrer Website sofort pausiert. Geplante Backups, geplante Beiträge, alles, was von WP-Cron abhängt, stoppt, bis der Server-Cron aktiv ist.

Wenn Sie bei einem Managed-WordPress-Hoster wie WP Engine, Kinsta oder Flywheel sind, lesen Sie die Dokumentation Ihres Hosters, bevor Sie wp-config.php bearbeiten. Einige Managed-Hoster verwalten Server-Cron anders oder kümmern sich auf Ihren Wunsch darum.

Kehren Sie nach der Einrichtung zu Duplicator Pro » Einstellungen » Geplante Backups zurück und überprüfen Sie, ob die nächste geplante Ausführungszeit genau dem von Ihnen konfigurierten entspricht. Diese Bestätigung ist Ihr Signal, dass die Übergabe funktioniert hat.

Schritt 6: Richten Sie eine Zwei-Zeitplan-Backup-Strategie ein

Tägliche vollständige Website-Backups sind eine der häufigsten Ursachen für sowohl langsame Backups als auch langsame Websites auf Shared Hosting. Für die meisten WordPress-Websites sind sie außerdem mehr, als Sie tatsächlich benötigen.

Ihre Datenbank ändert sich ständig mit neuen Beiträgen, Bestellungen, Formulareingaben, Kommentaren und Plugin-Aktivitäten. Im Gegensatz dazu werden Ihre Dateien, Themes, Plugins und Uploads gelegentlich aktualisiert.

Täglich ein vollständiges Backup durchzuführen bedeutet, Gigabytes an Dateien zu komprimieren und zu archivieren, die sich kürzlich nicht geändert haben.

Die Lösung sind zwei separate Backup-Zeitpläne.

• Zeitplan A: Tägliches Backup nur der Datenbank. Ein Backup nur der Datenbank erfasst jede Änderung an Ihren Inhalten, Bestellungen und Einstellungen, ohne Ihre Dateien zu berühren. Auf den meisten Websites ist dies in unter 30 Sekunden erledigt. Führen Sie dies täglich aus.
• Zeitplan B: Wöchentliches Backup der gesamten Website. Inklusive Dateien, einmal pro Woche während Ihres tatsächlichen Zeitfensters mit dem geringsten Traffic. Dies ist das Backup, das Sie wiederherstellen, wenn etwas schiefgeht.

Bevor Sie den Zeitplan festlegen, ermitteln Sie Ihr tatsächliches Zeitfenster mit geringem Traffic. Suchen Sie nach dem zweistündigen Block mit den wenigsten Sitzungen über eine typische Woche.

Bei den meisten Websites liegt dies irgendwo zwischen 2 und 5 Uhr morgens, aber überprüfen Sie dies mit Ihren eigenen Daten. Ihr Traffic-Muster ist nicht dasselbe wie das jedes anderen.

Gehen Sie dann zu Duplicator Pro » Geplante Backups » Neu hinzufügen. Benennen Sie den Zeitplan beispielsweise Datenbank-Backup. Fügen Sie eine neue Backup-Vorlage hinzu.

Benennen Sie die Vorlage. Wählen Sie die Voreinstellung Nur Datenbank und speichern Sie sie.

Gehen Sie zurück zum neuen Zeitplan und wählen Sie die gerade erstellte Datenbank-Backup-Vorlage aus. Wählen Sie einen Speicherort und stellen Sie ihn auf tägliche Ausführung ein.

Speichern Sie es. Erstellen Sie dann einen zweiten Zeitplan und wiederholen Sie den Vorgang, aber mit einer Vorlage für vollständige Website-Backups. Lassen Sie es wöchentlich laufen.

Beide Zeitpläne werden unter Duplicator Pro » Zeitpläne für Backups mit ihren nächsten Ausführungszeiten angezeigt.

Fehlerbehebung: Wenn Backups immer noch langsam oder fehlerhaft sind

Die Durchführung der obigen Schritte löst die meisten Probleme mit der Geschwindigkeit von Website-Backups. Wenn immer noch etwas nicht stimmt, sehen Sie hier, was Sie höchstwahrscheinlich sehen und wie Sie es überwinden können.

Backup wird abgeschlossen, aber die Wiederherstellung schlägt fehl

Sie sehen ein Backup, das Build-Protokoll zeigt keine offensichtlichen Fehler, aber wenn Sie den Installer ausführen, schlägt er fehl oder stellt eine leere Website wieder her.

Dies geschieht, weil ein PHP-Ausführungszeitlimit den Build abgebrochen hat, bevor er tatsächlich abgeschlossen war. Die Datei wurde bis zu diesem Punkt auf die Festplatte geschrieben und dann gestoppt.

Wechseln Sie zu DupArchive (siehe Schritt 3), löschen Sie dann das fehlgeschlagene Backup und erstellen Sie ein neues. Führen Sie den Installer aus und überprüfen Sie, ob die Wiederherstellung abgeschlossen ist, bevor Sie sich darauf verlassen.

Das Backup wird erstellt, erreicht aber nie Ihren Speicher

Das Build-Protokoll besagt, dass das Archiv abgeschlossen ist, aber die Datei erscheint nie in Dropbox, Google Drive oder Ihrem S3-Bucket. Das Backup existiert lokal; die Übergabe ist fehlgeschlagen.

Drei Ursachen decken die meisten dieser Fälle ab.

• Ihr Speicher-Account ist voll, sodass der Upload beginnt und auf halbem Weg abbricht.
• Das Verbindungstoken ist abgelaufen, was nach einer Passwortänderung oder einer widerrufenen App-Berechtigung geschieht.
• Das Archiv ist größer, als das Ziel in einem einzigen Upload akzeptiert.

Überprüfen Sie zuerst den freien Speicherplatz des Speicher-Accounts und verbinden Sie dann das Ziel in Duplicator erneut, um das Token zu aktualisieren. Wenn beides in Ordnung zu sein scheint, ist die Dateigröße der wahrscheinliche Schuldige. Verkleinern Sie das Archiv mit den Ausschlussfiltern aus Schritt 2 oder teilen Sie Ihren Zeitplan auf, sodass der tägliche Lauf nur die Datenbank enthält.

Backup bleibt bei einem bestimmten Prozentsatz hängen

Der Fortschrittsbalken friert an einem bestimmten Punkt ein und bleibt dort mehr als zehn Minuten lang ohne Bewegung.

Führen Sie zuerst Duplicators AutoTune aus. Es testet Chunk-Größen und Engines auf Ihrem Server, ohne dass Sie raten müssen.

Wenn es immer noch stockt, blockiert eine große Datei oder eine gesperrte Datenbanktabelle den Prozess an genau dieser Stelle im Build. Gehen Sie zum Backup-Protokoll und scrollen Sie, um die letzte Datei oder Tabelle zu finden, die aufgelistet ist, bevor das Protokoll abbricht. Das ist Ihr Schuldiger.

Wenn es sich um eine Datei handelt, fügen Sie sie zu Ihren Ausschlussfiltern hinzu (Schritt 2) und erstellen Sie sie neu. Wenn es sich um eine Datenbanktabelle handelt, wechseln Sie den SQL-Modus zu PHP-Code (Schritt 4) und versuchen Sie es erneut.

Website verlangsamt sich jeden Abend zur gleichen Zeit

Besucher oder Ihr Überwachungstool melden Verlangsamungen während eines bestimmten Zeitfensters. Die Zeitplanung stimmt mit Ihrem geplanten Backup überein.

Ihr Backup läuft während einer Zeit mit aktivem Datenverkehr und konkurriert um die gleichen CPU- und Festplattenressourcen, die Ihre Besucher bedienen. Überprüfen Sie Ihr tatsächliches Zeitfenster mit geringem Datenverkehr in Google Analytics und planen Sie das Backup für diese Zeit neu.

Wenn Sie tägliche vollständige Website-Backups durchführen, wechseln Sie zur Zwei-Zeitplan-Strategie aus Schritt 6. Datenbank-Backups allein werden schnell genug abgeschlossen, sodass die Leistungsauswirkungen auch bei moderatem Datenverkehr minimal sind.

Shell Exec verursacht sofortiges Build-Fehlgeschlagen

Sie haben die Archivierungs-Engine auf Shell Exec umgestellt, und der nächste Build schlägt bei 0 % mit einem sofortigen Fehler fehl.

Ihr Hoster hat shell_exec auf Serverebene deaktiviert. Wechseln Sie zurück zu ZipArchive oder DupArchive. Kontaktieren Sie dann Ihren Hoster und fragen Sie speziell, ob shell_exec für Ihr Konto aktiviert werden kann.

Wenn sie nein sagen, ist DupArchive Ihre langfristige Archivierungs-Engine. Es behandelt die gleichen Timeout-Probleme, die Shell Exec gelöst hätte, nur über eine andere Methode.

Backups funktionieren im Staging, schlagen aber auf dem Live-Server fehl

Ihre Backups sind auf Staging- oder lokalen Websites erfolgreich, aber auf Produktionsumgebungen treten Timeouts auf oder es werden beschädigte Dateien erstellt.

Ihr Live-Server hat strengere PHP-Limits oder unterliegt einer aktiven CPU-Drosselung, die Ihre Staging-Umgebung nicht hat. Vergleichen Sie die PHP-Einstellungen zwischen den Umgebungen: Überprüfen Sie memory_limit und max_execution_time in beiden. Fordern Sie höhere Limits von Ihrem Live-Hoster an (Schritt 7) oder wechseln Sie zu DupArchive, um innerhalb der bestehenden Limits zu arbeiten.

Wenn keine der oben genannten Lösungen Ihr Problem behebt, ist das Support-Team von Duplicator Pro der richtige nächste Schritt. Gehen Sie zu duplicator.com und eröffnen Sie ein Support-Ticket. Fügen Sie Ihr Build-Protokoll, Ihre PHP-Einstellungen und Ihre Hosting-Umgebung hinzu. Diese drei Informationen bringen Sie schneller zu einer Lösung als eine allgemeine Beschreibung des Problems.

Häufig gestellte Fragen (FAQs)

Ein Standard-ZIP-Build, der länger als das Limit Ihres Hosts dauert, wird mitten im Prozess abgebrochen und erzeugt ein fehlerhaftes Paket. DupArchive übersteht diese Limits, da jeder Block die Uhr zurücksetzt.

Es ist nicht immer schneller als ZIP auf leistungsfähigen Servern, aber es ist auf eingeschränkten Shared-Hosting-Umgebungen deutlich zuverlässiger.

Die wichtigere Frage ist, ob Sie kürzlich einen Wiederherstellungstest durchgeführt haben. Ein Backup, das Sie noch nie getestet haben, ist ein Backup, von dem Sie nicht wirklich wissen, ob es funktioniert. Wählen Sie eine Staging-Umgebung, stellen Sie Ihr letztes Backup wieder her und überprüfen Sie, ob die Website korrekt geladen wird.

Führen Sie Ihr nächstes Backup durch, ohne sich zu fragen, ob es funktioniert

Ein langsames Backup ist eine Unannehmlichkeit. Ein Backup, das vollständig aussieht, aber nicht wiederhergestellt werden kann, ist ein ganz anderes Problem, und es ist häufiger, als die meisten Leute erwarten.

Die Einstellungen in diesem Tutorial existieren, weil Shared Hosting nicht für WordPress-Backups entwickelt wurde. Duplicator Pro schon.

Mehr als 1,5 Millionen WordPress-Profis nutzen Duplicator Pro für Backups, Migrationen, Staging und Disaster Recovery auf Websites jeder Größe. Das DupArchive-Format, die Zwei-Zeitplan-Strategie und die Dateiausschlussfilter helfen Ihnen, langsame oder ressourcenintensive Backups zu vermeiden.

Wenn dieses Tutorial hilfreich war, sind diese Anleitungen auch lesenswert.

• Wie sich WordPress-Backups auf die Website-Leistung auswirken (und wie Sie das beheben)
• Hören Sie auf zu raten, warum Backups fehlschlagen (prüfen Sie stattdessen diese Protokolle)
• Website gerade abgestürzt? Hier ist Ihr vollständiger Plan zur Wiederherstellung Ihrer Website
• Warum Ihre WordPress-Site Backup-Überwachung benötigt (nicht nur Backups)
• So zeigen Sie Ihr WordPress-Backup als funktionierende Website an