{"id":1111,"date":"2026-03-03T08:54:57","date_gmt":"2026-03-03T05:54:57","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=1111"},"modified":"2026-08-04T21:56:23","modified_gmt":"2026-08-04T21:56:23","slug":"wordpress-website-dateien-datenbank-sichern","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/wordpress-website-dateien-datenbank-sichern\/","title":{"rendered":"WordPress-Website sichern: Dateien und Datenbank richtig zusammenf\u00fchren"},"content":{"rendered":"

Vor einem Theme-Update l\u00e4dt eine Administratorin wp-content<\/code> herunter und geht davon aus, die Website damit vollst\u00e4ndig gesichert zu haben. Im Archiv liegen Plugins, Themes und Uploads. Beitr\u00e4ge, Benutzerkonten, Einstellungen und Bestellungen befinden sich jedoch in der Datenbank. Auch wp-config.php<\/code>, Serverregeln oder Verzeichnisse au\u00dferhalb des \u00fcblichen Pfads k\u00f6nnen fehlen. Die Kopie ist n\u00fctzlich, aber kein vollst\u00e4ndiges Website-Backup.<\/p>\n

Dieser Beitrag zeigt, wie Sie WordPress-Dateien und Datenbank zu einem gemeinsamen Wiederherstellungspunkt verbinden. Sie erfahren, was in beide Teile geh\u00f6rt, wie sie zeitlich zusammenpassen und warum erst ein Restore-Test aus einem Backup einen belastbaren R\u00fcckweg macht.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was ein vollst\u00e4ndiges Website-Backup enth\u00e4lt<\/a><\/li>\n
  2. Ein Beispiel aus der Praxis<\/a><\/li>\n
  3. Warum und wann Sie sichern sollten<\/a><\/li>\n
  4. Der einfache Weg<\/a><\/li>\n
  5. Die technische Variante<\/a><\/li>\n
  6. H\u00e4ufige Fehler und sichere R\u00fcckkehr<\/a><\/li>\n
  7. AIOWS Backup Manager einsetzen<\/a><\/li>\n
  8. Passende AIOWS-Artikel<\/a><\/li>\n
  9. Empfohlener Weg<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was ein vollst\u00e4ndiges Website-Backup enth\u00e4lt<\/h2>\n

    Ein vollst\u00e4ndiges WordPress-Backup besteht aus zwei aufeinander abgestimmten Teilen. Das Dateiarchiv enth\u00e4lt WordPress selbst, Themes, Plugins, Uploads, Konfigurationsdateien, Must-use-Plugins, Sprachdateien und relevante Serverregeln. Im Datenbankexport stecken Beitr\u00e4ge, Seiten, Benutzerkonten, Einstellungen, Kommentare sowie Daten von Shops, Mitgliederbereichen und anderen Erweiterungen.<\/p>\n

    Manche Websites nutzen zus\u00e4tzlich Objektspeicher, eigene Verzeichnisse oder Konfigurationen, die der Hoster bereitstellt. Solche Abh\u00e4ngigkeiten geh\u00f6ren ausdr\u00fccklich in die Bestandsaufnahme. Ein Archiv kann vollst\u00e4ndig aussehen und trotzdem unbrauchbar sein, wenn beim Restore ein externer Speicherort oder eine entscheidende Einstellung fehlt.<\/p>\n

    Ein Beispiel aus der Praxis<\/h2>\n

    Ein WooCommerce-Shop exportiert jede Nacht die Datenbank und kopiert sonntags wp-content<\/code>. Werden die Dateien vom Sonntag mit der Datenbank vom Mittwoch wiederhergestellt, k\u00f6nnen neuere Produktbilder fehlen. Die Datenbank vom Sonntag w\u00fcrde dagegen die Bestellungen der folgenden Tage verwerfen. Ben\u00f6tigt wird deshalb ein Datei- und Datenbankpaar, das denselben Zeitpunkt beschreibt. Au\u00dferdem muss gekl\u00e4rt sein, wie Bestellungen behandelt werden, die w\u00e4hrend der Sicherung eingehen.<\/p>\n

    Warum und wann Sie sichern sollten<\/h2>\n

    Erstellen Sie einen solchen Wiederherstellungspunkt vor Updates von WordPress, Themes oder Plugins, vor einem Umzug und vor \u00c4nderungen an Konfiguration oder Serverregeln. Auch f\u00fcr die Reaktion auf Sicherheitsvorf\u00e4lle bildet er die Grundlage. Entscheidend sind nicht zwei neue Download-Dateien, sondern ein bekannter Zustand, der sich innerhalb der zul\u00e4ssigen Ausfallzeit und des akzeptierten Datenverlusts wiederherstellen l\u00e4sst.<\/p>\n

    Bei einer aktiven Website ist die zeitliche Abstimmung besonders wichtig. \u00c4ndern sich Dateien w\u00e4hrend des Datenbankexports, passen beide Teile m\u00f6glicherweise nicht mehr zusammen. F\u00fcr eine kleine Website gen\u00fcgt oft ein ruhiges Wartungsfenster. Stark frequentierte Shops oder Mitgliederseiten ben\u00f6tigen unter Umst\u00e4nden einen transaktionskonsistenten Snapshot, eine kurze Schreibsperre oder einen dokumentierten Umgang mit \u00c4nderungen w\u00e4hrend der Sicherung.<\/p>\n

    Der einfache Weg<\/h2>\n
      \n
    1. Notieren Sie Datenbank, WordPress-Stammverzeichnis, Uploads, eigene Verzeichnisse und gegebenenfalls externe Medienspeicher.<\/li>\n
    2. W\u00e4hlen Sie einen ruhigen Zeitpunkt, exportieren Sie die Datenbank und sichern Sie alle erforderlichen Dateien. Behalten Sie das bisherige, gepr\u00fcfte Backup.<\/li>\n
    3. Legen Sie beide Teile unter einem gemeinsamen Datum oder Namen ab, m\u00f6glichst au\u00dferhalb des Hostingkontos.<\/li>\n
    4. \u00d6ffnen Sie die Archive testweise, pr\u00fcfen Sie die erwarteten Tabellen im SQL-Export und sch\u00fctzen Sie sensible Dateien vor unbefugtem Zugriff.<\/li>\n
    5. Stellen Sie das Paar in einer isolierten Umgebung wieder her und testen Sie Anmeldung, Seiten, Medien, Formulare, geplante Aufgaben und gegebenenfalls Shop- oder Mitgliederfunktionen.<\/li>\n<\/ol>\n

      Die technische Variante<\/h2>\n

      F\u00fcr reproduzierbare Restores erh\u00e4lt jedes Datei- und Datenbankpaar eine eindeutige Kennung. Ein Manifest h\u00e4lt WordPress- und PHP-Version, Datenbankversion, Tabellenpr\u00e4fix, aktives Theme und Plugins, aufgel\u00f6ste Dateipfade, Sicherungszeiten, Pr\u00fcfsummen und Ausschl\u00fcsse fest. Dateirechte und der Umgang mit symbolischen Links m\u00fcssen ebenfalls definiert sein.<\/p>\n

      Vergleichen Sie dieses Manifest bei einer Restore-Probe zuerst mit dem Zielsystem. Versionen, Kollation, Multisite-Konfiguration, Upload-Pfade und umgebungsspezifische Geheimnisse k\u00f6nnen bewusste Anpassungen erfordern. Mischen Sie keine Artefakte verschiedener Wiederherstellungspunkte: Zwei f\u00fcr sich g\u00fcltige Archive ergeben nicht automatisch ein kompatibles Paar.<\/p>\n

      H\u00e4ufige Fehler und sichere R\u00fcckkehr<\/h2>\n