Eine vollständige WordPress-Sicherung umfasst Datenbank, wp-content, wp-config.php und relevante Webserver-Regeln. Erfolg bedeutet nicht nur eine Archivdatei, sondern erfolgreiche Extraktion, Import und Funktionstests in einer sauberen Umgebung.
wp db export backup.sql --add-drop-table
tar -czf wordpress-files.tar.gz public_html
sha256sum backup.sql wordpress-files.tar.gz
wp search-replace old.example new.example --dry-runDie Datenbank enthält Beiträge, Benutzer, Einstellungen, Bestellungen und Plugin-Daten; wp-content enthält Uploads, Themes und Plugins. wp-config.php enthält Datenbankzugang, Salts und eigene Konstanten. Webserver-Regeln, Cronjobs, PHP-Einstellungen und externe Speicheranbindungen müssen bei Bedarf ebenfalls gesichert werden.
SQL-Export sichert Beiträge, Benutzer, WooCommerce-Bestellungen, Einstellungen und Plugin-Tabellen.
Mindestens wp-content, wp-config.php und eigene Serverdateien archivieren. Der Core ist neu ladbar, vollständige Dateien vereinfachen jedoch die Wiederherstellung.
Archiv entpacken, SQL importieren und Frontend, Admin, Formulare, Cron, E-Mail und Zahlungen testen.
Erstellt einen SQL-Export anhand der WordPress-Konfiguration. Bei aktiven WooCommerce-Shops Wartungsfenster oder konsistente Snapshots planen.
wp db export ../backup-$(date +%F-%H%M).sql --add-drop-tableCache, temporäre Dateien und alte Sicherungen ausschließen, um die Archivgröße zu reduzieren.
tar --exclude=wp-content/cache --exclude=wp-content/upgrade --exclude="*.log" -czf ../wordpress-$(date +%F-%H%M).tar.gz .Prüfen Sie, dass SQL nicht leer ist, das tar-Archiv lesbar ist und Hashwerte nach dem Transfer gleich bleiben.
test -s ../backup.sql
tar -tzf ../wordpress.tar.gz >/dev/null
sha256sum ../backup.sql ../wordpress.tar.gzWP-CLI search-replace statt einfachem SQL-Ersetzen verwenden, um serialisierte Daten zu schützen.
wp search-replace "https://old.example" "https://new.example" --all-tables-with-prefix --precise --dry-runVor der Sicherung freien Speicher, WordPress-Version, Datenbankgröße, PHP-Version und aktive Plugins dokumentieren.
Datenbank per WP-CLI, mysqldump, cPanel phpMyAdmin oder Plesk exportieren und prüfen, dass die SQL-Datei nicht leer ist.
WordPress-Dateien archivieren; Sicherungen nicht in public_html belassen, sondern außerhalb des Webzugriffs speichern.
SHA-256-Hashes erzeugen, Dateien auf einen anderen Server oder Objektspeicher übertragen und Hashes danach vergleichen.
Für die Wiederherstellung leere Datenbank und sauberes Document Root vorbereiten, Dateien entpacken, SQL importieren und wp-config.php prüfen.
Bei Domainwechsel zuerst WP-CLI search-replace als Dry-Run, danach real ausführen und Cache, Rewrite-Regeln sowie Permalinks erneuern.
Frontend, wp-admin, Medien, Login, Formulare, Cron, E-Mail, Zahlungen und Sicherung testen und Wiederherstellung dokumentieren.
wp-config.php, DB_HOST oder MySQL-Rechte passen nicht zur Zielumgebung.
wp-content/uploads fehlt, liegt im falschen Pfad oder hat falsche Eigenalleerrechte.
home/siteurl, Plugin-Einstellungen oder serialisierte Daten enthalten noch die alte URL.
Unterbrochener Transfer, voller Speicher oder Verbindungsabbruch kann den Dump gekürzt haben.
Nein. wp-content enthält Dateien; Beiträge, Benutzer, Bestellungen und Einstellungen liegen in der Datenbank. Beides sichern.
Die Häufigkeit hängt von Änderungen ab. Aktive Shops benötigen häufige Datenbanksicherungen, statische Seiten eher täglich oder wöchentlich. RPO definieren.
Ein Plugin ist möglich, aber Sicherungen sollten extern, geschützt und regelmäßig getestet sein; zusätzlich braucht es eine Methode ohne funktionierendes WordPress.
Einfaches Ersetzen kann serialisierte Werte beschädigen. Verwenden Sie WP-CLI search-replace oder ein geeignetes Werkzeug.
Dateigröße und Archivtest reichen nicht. Der beste Nachweis ist eine erfolgreiche Wiederherstellung mit Funktionstest in sauberer Umgebung.
Kontaktieren Sie Eka Software- und Informationssysteme für Installation, Server, Skripte und technischen Support.