WordPress mit Wupz sichern, ohne dass im Backup etwas fehlt

Ein Backup-Plugin für WordPress ist schnell installiert. Ein Klick, und im Admin steht eine ZIP-Datei mit Datum. Ob man daraus die Seite wiederherstellen kann, sieht man dem ZIP aber nicht an. Das merkt man meistens erst, wenn man es braucht.

Wupz ist mein eigenes Backup-Plugin für WordPress. Es sichert die Datenbank und den Ordner wp-content in eine ZIP-Datei, auf Knopfdruck oder täglich bzw. wöchentlich über WP-Cron, und lädt die Datei auf Wunsch zusätzlich in einen S3-Bucket. Ob so ein Backup im Notfall reicht, hängt an ein paar Einstellungen und an zwei Dateien, die gar nicht erst im ZIP landen. Dieser Text bezieht sich auf Version 0.0.4.

Installieren

Du lädst wupz.zip aus den Releases auf GitHub und installierst es unter Plugins → Installieren → Plugin hochladen. Vorausgesetzt werden WordPress ab 5.0, PHP ab 8.1 und die PHP-Erweiterung ZipArchive. Danach gibt es im Admin den Menüpunkt „Wupz“ mit dem Knopf für ein manuelles Backup, den Einstellungen und einer Seite für den Speicher.

Was im ZIP landet

Ein Backup heißt zum Beispiel wupz-backup-2026-10-27_09-30-00.zip und enthält zwei Dinge:

• database.sql mit Struktur und Inhalt aller Tabellen, deren Name mit dem Tabellenpräfix deiner Installation beginnt, meistens wp_
• den Ordner wp-content mit Themes, Plugins und Uploads

Was nicht drin ist: die wp-config.php, die .htaccess im Hauptverzeichnis und der WordPress-Kern. Den Kern lädst du im Notfall frisch herunter, das ist kein Verlust. Die wp-config.php dagegen enthält die Zugangsdaten zur Datenbank, das Tabellenpräfix und die Salts. Ohne sie musst du beim Wiederherstellen alles neu eintragen. Lege von dieser Datei deshalb selbst eine Kopie an einen sicheren Ort und aktualisiere sie, wenn du dort etwas änderst.

Auch Tabellen ohne das Präfix fehlen. Teilen sich WordPress und eine andere Anwendung eine Datenbank, sichert Wupz nur den WordPress-Teil.

Was ausgelassen wird

Welche Dateien aus wp-content nicht ins Backup kommen, steht unter Wupz → Settings in zwei Feldern.

„Exclude File Patterns“ enthält ein Muster pro Zeile. Ab Werk sind das cache/, tmp/, temp/, *.log, *.tmp und wupz-backups/. Ein Muster mit Schrägstrich am Ende meint einen Ordner dieses Namens, egal wie tief er liegt. * und ? sind Platzhalter, die nicht über einen Schrägstrich hinweg greifen. *.log trifft so jede Datei, die auf .log endet. Den eigenen Backup-Ordner lässt Wupz immer aus, auch wenn du die Zeile löschst. Sonst stünden alte Backups im neuen.

„Maximum File Size“ gibst du in MB an. Voreingestellt sind 100, und alles darüber bleibt draußen. Mit 0 gibt es keine Grenze.

Beides gilt still. Eine Meldung, welche Dateien übersprungen wurden, gibt es nicht. Schau die Liste deshalb einmal durch: Legt ein Plugin echte Daten in einem Ordner namens temp ab oder hast du ein großes Video in der Mediathek, nimmst du das Muster raus oder setzt die Grenze hoch.

Wer die Grenze aufhebt, sollte den Speicher im Blick haben. Den Datenbank-Dump baut Wupz komplett im Arbeitsspeicher zusammen, bevor es ihn schreibt, und der Download eines lokalen Backups liest die ganze ZIP-Datei auf einmal ein. Bei einer großen Datenbank oder einem großen Archiv kann das am memory_limit von PHP scheitern.

Wo die Backups liegen

Lokal landen die Dateien in wp-content/wupz-backups/. Beim Aktivieren legt Wupz dort eine .htaccess an, die den Zugriff von außen sperrt. Das wirkt aber nur, wenn der Webserver .htaccess-Dateien liest. Apache tut das, sofern es erlaubt ist, nginx ignoriert sie komplett. Die Dateinamen folgen einem festen Muster aus Datum und Uhrzeit.

Ob die Sperre greift, prüfst du mit einem Aufruf von außen. Nimm dafür den Namen eines echten Backups aus der Liste im Admin:

curl -I https://deine-seite.de/wp-content/wupz-backups/wupz-backup-2026-10-27_09-30-00.zip

Kommt 200 zurück, kann jeder dieses Backup herunterladen, samt Datenbank. Dann sperrst du den Pfad in der Konfiguration des Webservers und prüfst noch einmal. Bei 403 kommt von außen niemand an die Datei.

Selbst gut gesperrt bleibt ein Haken: Ein Backup auf demselben Server hilft dir nicht, wenn genau dieser Server ausfällt oder gehackt wird. Dafür gibt es den Upload nach S3.

Nach S3 hochladen

Unter Wupz → Storage trägst du Access Key, Secret Key, Bucket und Region ein. Mit einem eigenen Endpoint funktioniert das auch mit S3-kompatiblen Anbietern statt AWS. Nach jedem Backup lädt Wupz die ZIP-Datei unter ihrem Dateinamen in den Bucket. Setzt du dort zusätzlich den Haken bei „Delete Local Backup“, löscht Wupz die lokale Datei, sobald der Upload geklappt hat. Dann liegt das Backup nur noch im Bucket.

„Maximum Backups to Keep“, Standard 5, gilt lokal und im Bucket. Im Bucket zählt und löscht Wupz dabei nur Dateien, die wie seine eigenen Backups heißen, also wupz-backup-JJJJ-MM-TT_HH-MM-SS.zip. Andere Dateien im selben Bucket lässt es in Ruhe. Klappt das Auflisten nicht oder bleibt die Liste unvollständig, löscht es gar nichts. Einen eigenen Bucket oder wenigstens einen Zugang, der nur dorthin schreiben darf, würde ich trotzdem einrichten. Dann reichen die Schlüssel in der WordPress-Datenbank nicht weiter als bis zu den Backups.

Zeitplan und Update auf 0.0.4

Wie oft automatisch gesichert wird, legst du unter Wupz → Settings bei „Backup Schedule“ fest: „Daily“, „Weekly“ oder „Disabled“. Nach dem Speichern läuft das nächste Backup ein Intervall später und danach in diesem Abstand weiter. „Disabled“ entfernt den geplanten Termin.

Wenn du von einer älteren Version auf 0.0.4 aktualisierst, schau dir diese Einstellung direkt an. Der gespeicherte Wert gilt jetzt wirklich. Hast du die Einstellungen früher gespeichert, während dort „Disabled“ stand, bleiben automatische Backups jetzt aus, bis du „Daily“ oder „Weekly“ wählst. Wer den Zeitplan nie gespeichert hat, bleibt bei wöchentlich. Das erste automatische Backup nach dem Update kommt ein Intervall später. Ob ein Termin geplant ist, zeigt die Wupz-Seite im Admin unter „Next Scheduled Backup“.

Neu ist außerdem, dass *.log- und *.tmp-Dateien ab 0.0.4 standardmäßig fehlen. Brauchst du sie, löschst du die beiden Zeilen aus den Ausschlussmustern.

Wann du von Fehlern erfährst

Schlägt ein geplantes Backup fehl, schickt Wupz eine E-Mail an die Admin-Adresse von WordPress. Das ist standardmäßig aus und wird in den Einstellungen unter „Email Notifications“ eingeschaltet. Für erfolgreiche Backups kommt keine Nachricht.

Eine Lücke bleibt durch WP-Cron selbst. Geplante Aufgaben laufen nur, wenn jemand die Seite aufruft. Auf einer Seite mit wenig Besuch läuft das wöchentliche Backup also später als gedacht, und eine Fehlermail kommt nicht, weil nichts fehlgeschlagen ist. Schau deshalb ab und zu auf das Datum unter „Last Backup“ auf der Wupz-Seite im Admin. Wer Zugriff auf den Server hat, kann WP-Cron mit define('DISABLE_WP_CRON', true); in der wp-config.php abschalten und wp-cron.php stattdessen von einem echten Cron-Job aufrufen lassen.

Wiederherstellen

Eine Funktion zum Wiederherstellen hat Wupz nicht. Das geht von Hand:

1. ZIP herunterladen und entpacken.
2. WordPress frisch installieren oder die vorhandenen Kerndateien behalten und deine gesicherte wp-config.php einsetzen.
3. database.sql in die Datenbank importieren, zum Beispiel über phpMyAdmin oder mit WP-CLI über wp db import database.sql. Der Dump enthält für jede Tabelle DROP TABLE IF EXISTS. Vorhandene Tabellen mit demselben Namen werden also ersetzt.
4. Den Ordner wp-content aus dem ZIP zurückkopieren.

Probier das einmal auf einer Testumgebung aus, bevor du dich auf ein Backup verlässt. Erst danach weißt du, ob alles drin ist, was die Seite braucht.

Wofür es reicht

Wupz ist für kleine WordPress-Seiten gedacht: Zeitplan nach dem Update geprüft, die Ausschlussmuster einmal angesehen, die wp-config.php von Hand gesichert, die Wiederherstellung einmal ausprobiert und ab und zu ein Blick auf das Datum des letzten Backups. Bei großen Seiten mit vielen Medien oder einer großen Datenbank stößt es an die Speichergrenzen von oben. Dort sind Backups auf Server-Ebene die bessere Wahl, zum Beispiel Snapshots beim Hoster.

Fragen und Fehler zu Wupz gehören in die Issues auf GitHub.