Website-Backup-Geschwindigkeit: Warum Ihre Backups langsam sind und wie Sie sie beheben können

Ihr Backup läuft seit 45 Minuten. Nichts ist kaputt, aber eine Fortschrittsanzeige bewegt sich weiter.

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 Website-Backups sind ein echtes Problem. Der Backup-Prozess selbst könnte zu lange dauern oder stillschweigend fehlschlagen, bevor er abgeschlossen ist. Andererseits kann Ihr Backup zwar 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 fehlerhaft ist, und ein Backup, das Ihre Live-Website während des Backup-Fensters verlangsamt. Die Lösung ist für jede anders, 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 Chunks statt in einem kontinuierlichen Vorgang verarbeitet werden.
• Die Reduzierung Ihrer Archivgröße ist der 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 (unter 30 Sekunden), gepaart 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. Für 3 Uhr morgens geplante Backups können lautlos auf 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 defektes Backup während einer echten Katastrophe. Die Überprüfung einer Wiederherstellung auf einer Staging-Site dauert 20 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 der letzten Ausführung geändert hat, was sie nach Abschluss des ersten Backups erheblich schneller macht. Duplicator Pro unterstützt beide Ansätze, und die Zwei-Zeitplan-Strategie in diesem Tutorial bietet Ihnen die meisten Geschwindigkeitsvorteile inkrementeller Backups ohne die Komplexität.

• 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 WordPress-Backup-Plugin installiert und aktiv. Dieses Tutorial verwendet Duplicator Pro für alle spezifischen Schritte und UI-Referenzen. Duplicator Pro ist 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 Chunk-basierten Archivformats, das speziell entwickelt wurde, um die PHP-Timeout-Limits zu überstehen, die bei Shared Hosting üblich sind.
• WordPress-Admin-Zugang (Sie benötigen ihn, um auf die Einstellungen Ihres Backup-Plugins zuzugreifen)
• Zugang zum Hosting-Control-Panel (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- oder Backup-Verlauf Ihres Backup-Plugins)
• 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 Support-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, was der schnellste Weg ist, 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 genauen von Ihnen festgelegten Zeit ausführen, anstatt jedes Mal auszulösen, wenn der erste Besucher eintrifft.
• 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 aus, damit aufwändige 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.

Schritt 1: Identifizieren Sie Ihr Backup-Leistungsproblem

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

• 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 einer 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 vorhersagbaren Zeitplan auftritt.

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

Andere Plugins haben ähnliche Logs – ü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, ist das Problem A. Wenn das Log zeigt, dass es abgeschlossen wurde, Ihre Website aber immer noch träge ist, ist das Problem B.

Ein weiteres Szenario, das es wert ist, genannt zu werden, bevor Sie fortfahren: Wenn Ihr Build-Log besagt, dass das Backup abgeschlossen ist, aber das Backup während einer Wiederherstellung fehlschlägt, hat wahrscheinlich ein PHP-Ausführungszeitlimit den Build stillschweigend abgebrochen, bevor er beendet wurde.

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

Wenn Sie Hilfe beim Lesen der Backup-Logs von Duplicator 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. Auf Shared-Hosting, wo CPU und Festplatten-I/O bereits eingeschränkt sind, macht ein aufgeblähtes Archiv Backups langsamer und bringt Sie näher an die Timeout-Schwelle, bei der Backups fehlschlagen.

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

Dies ist das eigene Archivformat von Duplicator, und es 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 WP-Optimize oder ein ähnliches Datenbankbereinigungs-Plugin und führen Sie es aus, um Beitragsrevisionen, Spam-Kommentare, abgelaufene Transienten und verwaiste Metadaten zu entfernen. Diese sammeln sich auf aktiven Websites unbemerkt an und können 30 bis 50 Prozent des Datenbank-Bloats ausmachen, ohne etwas zu enthalten, das Sie tatsächlich wiederherstellen müssen.

Auf meiner persönlichen Website habe ich vor und nach einer schnellen Datenbankbereinigung mit WP-Optimize ein Backup durchgeführt. Dies verkürzte meine Backup-Zeit um 30 Sekunden und reduzierte die Dateigröße.

Bereinigen Sie Ihre Datenbank jedoch nicht 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 sicherstellen, dass Ihre Website gesund ist, bevor Sie diesen Zustand in einem Backup festhalten.

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.

Schritt 7: Fügen Sie inkrementelle Backups hinzu

Vollständige Backups komprimieren Ihre gesamte Website jedes Mal von Grund auf neu. Das ist in Ordnung für wöchentliche vollständige Website-Backups, aber es ist mehr als die meisten Websites für den täglichen Schutz benötigen.

Inkrementelle Backups verfolgen einen anderen Ansatz: Nach dem ersten vollständigen Backup speichern sie nur, was sich seit der letzten Ausführung geändert hat. Das Backup ist schneller abgeschlossen, da keine Dateien neu verarbeitet werden, die sich nicht geändert haben.

Duplicator Pro führt keine echten inkrementellen Backups aus, aber die Zwei-Zeitplan-Strategie aus Schritt 6 bietet Ihnen den größten Teil des gleichen Vorteils. Tägliche reine Datenbank-Backups erfassen alles, was sich auf einer typischen WordPress-Website ändert, und sind in weniger als 30 Sekunden abgeschlossen. Das wöchentliche vollständige Website-Backup kümmert sich um alles andere.

Für die meisten Websites deckt diese Aufteilung den praktischen Bedarf ab, den inkrementelle Backups lösen sollen.

Wenn Ihre Website groß genug ist, dass selbst wöchentliche vollständige Website-Backups durchweg langsam sind oder fehlschlagen, können inkrementelle Dateisicherungen sinnvoll sein. Tools wie BlogVault verarbeiten Backups auf ihren Servern anstelle von Ihren, wodurch das Problem der Serverlast entfällt.

Schritt 8: Fordern Sie höhere Serverressourcenlimits an

PHP-Speicher- und Ausführungszeitlimits sind reale Einschränkungen, aber deren Änderung erfordert die Kooperation Ihres Hosts und behebt keine zugrunde liegenden Probleme wie ein aufgeblähtes Archiv oder einen schlecht getimten Zeitplan.

Arbeiten Sie zuerst die vorherigen Schritte durch. Wenn Backups immer noch Zeitüberschreitungen aufweisen, könnten die Ressourcengrenzen Ihres Hosting-Plans die Ursache sein.

Zwei Einstellungen sind für die Backup-Geschwindigkeit am wichtigsten: memory_limit und max_execution_time.

memory_limit steuert, wie viel RAM PHP während eines einzelnen Prozesses verwenden kann. Backups sind speicherintensiv. Wenn Ihr Limit auf 64 MB oder 128 MB eingestellt ist, geht der Speicher für große Builds aus und sie sterben, bevor sie fertig sind.

Fordern Sie mindestens 256 MB an. Wenn Ihr Host 512 MB anbietet, fordern Sie stattdessen diese an.

max_execution_time steuert, wie lange ein PHP-Prozess laufen kann, bevor der Server ihn beendet. Der Standardwert auf vielen Shared-Hosts beträgt 30 bis 60 Sekunden. Ein großes Backup benötigt deutlich mehr als das. Fordern Sie 300 Sekunden an.

Kontaktieren Sie das Support-Team Ihres Hosts und seien Sie bei Ihrer Anfrage spezifisch. Fordern Sie einen memory_limit von 512 MB und eine max_execution_time von 300 Sekunden an.

Wenn Ihr Host diese Limits nicht erhöhen kann oder will, ist DupArchive aus Schritt 3 Ihr praktischer Weg nach vorn. Es wurde speziell entwickelt, um innerhalb enger PHP-Grenzen zu arbeiten, indem der Prozess in Blöcke aufgeteilt wird. Es ist langsamer als Shell Exec auf einem fähigen Server, aber es schließt ab, wo ein Standard-ZIP-Build nicht fertig werden würde.

Führen Sie nach jeder Limitänderung ein Test-Backup durch und öffnen Sie das Build-Protokoll. Bestätigen Sie, dass das Backup ohne Zeitüberschreitung oder Speicherfehler abgeschlossen wurde.

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.

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.

Eine große Datei oder eine gesperrte Datenbanktabelle blockiert den Prozess an genau diesem Punkt im Build. Gehen Sie zum Backup-Protokoll und scrollen Sie, um die letzte Datei oder Tabelle zu finden, die vor dem Abbruch des Protokolls aufgeführt ist. 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. Nur-Datenbank-Backups 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 deutlich zuverlässiger in eingeschränkten Shared-Hosting-Umgebungen.

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