wp-Backup&Restore

Backup- & Restore-Plugin für aktuelle WordPress-Versionen (6.x, PHP 8.1+).

Funktionen

• Komplett-Backup: Datenbank + wp-content + wp-config.php als ZIP mit Zeitstempel im Namen ({host}-{YYYYMMDD-HHMMSS}-{full|db}.zip), inkl. manifest.json zur Validierung
• Nur-DB-Backup als schlanke Alternative
• Restore komplett oder nur Datenbank — die DB wird zuerst vollständig in temporäre Tabellen importiert und dann atomar getauscht; bricht der Import ab, bleibt die Live-DB unberührt
• Restore per ZIP-Upload (Chunked-Upload, umgeht PHP-Upload-Limits)
• Zeitgesteuerte Backups (stündlich/2× täglich/täglich/wöchentlich) über WP-Cron
• Speicherziele: Lokal, WebDAV, SFTP (phpseclib), S3-kompatibel (IONOS S3, AWS, …) mit eigenem Signature-V4-Client
• Retention: max. N Backups pro Ziel, automatische Bereinigung nach jedem Lauf
• Mail-Benachrichtigung bei Fehler und/oder Erfolg (einstellbar); Teilerfolge (Upload zu einem Ziel fehlgeschlagen) zählen als Fehler
• Updates über GitHub-Releases direkt auf der WordPress-Plugins-Seite
• Job-Engine: Backups/Restores laufen als resumierbarer Zustandsautomat in kurzen Ticks (~15 s) und überleben damit jedes max_execution_time; Fortsetzung per Loopback-Request auch ohne offenes Browserfenster

Installation

1. Repository nach wp-content/plugins/wp-backup-restore klonen bzw. Release-ZIP installieren
2. Für SFTP-Support einmalig im Plugin-Verzeichnis: composer install (ohne phpseclib funktioniert alles außer SFTP)
3. Plugin aktivieren, Menüpunkt Backup&Restore öffnen

Sicherheit

• Backups liegen in wp-content/uploads/wpbr-{zufallstoken}/ mit .htaccess-Schutz; Download nur authentifiziert mit Nonce
• Remote-Zugangsdaten werden mit libsodium verschlüsselt gespeichert (Schlüssel aus den WP-Salts abgeleitet)
• Wichtig: Die Backup-ZIPs enthalten wp-config.php samt DB-Zugangsdaten — Speicherziele entsprechend absichern

Zeitplan zuverlässig machen

WP-Cron feuert nur bei Seitenaufrufen. Für verlässliche Zeitpläne:

# crontab
*/5 * * * * curl -s https://DEINE-SITE/wp-cron.php?doing_wp_cron >/dev/null

und in wp-config.php: define('DISABLE_WP_CRON', true);

Release-Workflow (für Updates über GitHub)

Updates erscheinen in WordPress nur für getaggte Releases:

1. Version im Plugin-Header von wp-backup-restore.php und in WPBR_VERSION erhöhen
2. Committen, taggen (git tag v1.0.1), pushen
3. Auf GitHub ein Release aus dem Tag erstellen (Release-Notes = Changelog im Update-Popup)
4. Optional ein gebautes ZIP als Release-Asset anhängen — sonst wird der automatische GitHub-Zipball verwendet. Deshalb muss vendor/ (phpseclib) mit committet werden, sonst fehlt SFTP nach einem Update.

Die Update-Prüfung ist 12 h gecacht (GitHub-Rate-Limit). Ein optionales GitHub-Token kann in den Einstellungen hinterlegt werden.

Bekannte Grenzen (v1)

• Kein Multisite-Support, keine inkrementellen Backups, keine Migration auf andere Domains (Site-URL-Abgleich mit Erzwingen-Option, aber ohne URL-Rewriting)
• Der DB-Dump ist nicht transaktional über die gesamte Laufzeit (kein Snapshot wie mysqldump --single-transaction); bei stark schreibenden Sites Backup in verkehrsarme Zeiten legen
• Beim Full-Restore werden alle Sessions abgemeldet (DB-Tausch) — die Wiederherstellung läuft serverseitig weiter, danach neu anmelden
• Uploads zu den Speicherzielen laufen als einzelner Stream (kein Multipart); bei sehr großen Archiven (>2–3 GB) Timeout-Limits des Hosters beachten