Website sichern und wiederherstellen

Eine vollständige Sicherung verbindet einen passenden Datenbankstand mit den Dateien und der Konfiguration der Website. Stellen Sie den Sicherungssatz zuerst in einer getrennten Umgebung wieder her, bevor Sie sich bei einem Ausfall darauf verlassen.

Für: Administration · Version: ConcreteCMS 9.5.7

Seitenversion und Sicherung unterscheiden

Die Seitenversionen helfen, einen früheren Stand einer Seite anzusehen und gegebenenfalls erneut zu veröffentlichen. Sie ersetzen keine Sicherung der Website. Benutzer, Express-Einträge, globale Konfiguration, Erweiterungsdateien und Dateispeicher werden damit nicht gemeinsam auf einen früheren Zeitpunkt zurückgesetzt.

Der native Bereich Versionen zeigt die veröffentlichte Fassung einer einzelnen Dokumentationsseite mit ihrem Status Live.

Abbildung 1: Die Versionsliste gehört zu einer einzelnen Seite. Eine dort vorhandene Seitenversion ist keine vollständige Website-Sicherung.

Für eine vollständige Wiederherstellung benötigen Sie zusammenpassende Datenbank- und Dateistände. Ein ZIP mit dem Theme-Paket enthält beispielsweise Code und Ausgangsinhalte; es enthält nicht automatisch Ihre später geschriebenen Artikel, Benutzer oder gespeicherten Anfragen.

Ältere Concrete5-Anleitungen zeigen teilweise eine Verwaltungsseite „Backup & Restore“. Diese Funktion gehört nicht zur hier geprüften aktuellen Verwaltung. Die vollständige Sicherung erfolgt über die dafür vorgesehenen Werkzeuge des Hostings oder einen abgestimmten Serverablauf.

Datenbestand prüfen

Halten Sie vor der Sicherung fest, welche Installation betroffen ist: Website-Adresse, Dokumentenverzeichnis, Datenbankname, Core-Version, PHP-Version und installierte Erweiterungen. Die aktuelle Core-Version finden Sie unter Verwaltung → System & Einstellungen → Concrete aktualisieren → Aktualisierung anwenden. Erweiterungen prüfen Sie unter Funktionen hinzufügen.

Kontrollieren Sie außerdem System & Einstellungen → Dateien → Dateispeicherorte. ConcreteCMS kann Dateien an unterschiedlichen Speicherorten verwalten. Ein externer Speicher ist nicht allein deshalb im Website-Verzeichnis enthalten, weil seine Bilder auf den Seiten erscheinen.

Die Verwaltung Dateispeicherorte zeigt die vorhandenen Speicherorte und die getrennte Möglichkeit, einen weiteren Speicherort hinzuzufügen.

Abbildung 2: Prüfen Sie jeden verwendeten Speicherort. Die Liste zeigt die Speicherorte, die in die Sicherung einbezogen werden müssen.

Notieren Sie für zusätzliche Speicherorte, wie deren Dateien gesichert und wiederhergestellt werden. Zugangsdaten und Schlüssel gehören in eine geschützte Ablage. Sie gehören weder in einen öffentlich erreichbaren Download noch in einen Screenshot der Dokumentation.

Datenbank, Dateien und Konfiguration zusammen sichern

Vereinbaren Sie für eine vollständige Sicherung einen geeigneten Zeitpunkt. Während laufender Bearbeitung oder neuer Formularanfragen können Datenbank und Dateien auseinanderlaufen. Für einen geplanten Umzug oder Eingriff müssen deshalb auch Uploads, Aufgaben und weitere schreibende Prozesse berücksichtigt werden. Ein Wartungsmodus allein hält nicht automatisch jeden Hintergrundprozess an.

Eine vollständige Sicherung umfasst mindestens:

  1. Die gesamte Datenbank: Seiten, Versionen, Blockwerte, Benutzer, Rechte, Express-Daten, Datei-Zuordnungen und gespeicherte Konfiguration.
  2. Die Originaldateien aller Speicherorte: beim Standardspeicher insbesondere die Dateien unter application/files, einschließlich benötigter versteckter Dateien und Zugriffsschutzregeln.
  3. Anwendung und Erweiterungen: eigene Dateien unter application, installierte Pakete und der tatsächlich eingesetzte Core samt seinen Abhängigkeiten.
  4. Betriebskonfiguration: passende Zugangskonfiguration, Umgebungsvariablen, Webserver-Regeln sowie dokumentierte Cron-, Worker- und Mail-Einstellungen.

Bei Composer-Installationen gehören auch die passende Abhängigkeitsdefinition und der gesperrte Versionsstand in composer.lock dazu. Bei einem Core aus dem Verzeichnis updates müssen die verwendete Core-Version und der zugehörige Verweis in application/config/update.php zusammenpassen. Welche Variante vorliegt, klärt Updates vorbereiten und durchführen.

Lassen Sie die Datenbank mit dem zum Server passenden Exportwerkzeug konsistent exportieren. Das Hosting muss auch eine Sicherung großer Tabellen zuverlässig abschließen können. Zugangsdaten sollten dabei nicht als sichtbare Kommandozeilenargumente oder in allgemein lesbaren Protokollen stehen.

Bewahren Sie die Sicherung außerhalb des öffentlich erreichbaren Website-Verzeichnisses auf. Ein Datenbankexport kann Formulareinträge, persönliche Daten und technische Geheimnisse enthalten. Eine zweite getrennte Ablage schützt außerdem davor, dass eine Deinstallation oder ein Serverfehler Website und einzige Sicherung zugleich trifft.

Sicherung prüfen

Eine vorhandene Datei beweist noch keine vollständige Sicherung. Kontrollieren Sie Zeitpunkt, Größe und Abschlussmeldung jedes Exports. Öffnen Sie den Datenbankexport mit einem geeigneten lokalen Werkzeug und prüfen Sie, ob Tabellendefinitionen und Daten enthalten sind. Eine abgebrochene Teilsicherung darf nicht als Rückweg für ein Update eingeplant werden.

Prüfen Sie Dateiarchive auf Lesbarkeit und Fehler. Vergleichen Sie bei einer Übertragung die Prüfsumme der empfangenen Datei mit dem ursprünglichen Wert. Eine passende Prüfsumme bestätigt die unveränderte Übertragung; sie beweist für sich allein noch nicht, dass die ursprüngliche Sicherung alle benötigten Bestandteile enthält.

Halten Sie zu jeder Sicherung fest: Herkunft, Zeitpunkt, Core- und Paket-Versionen, betroffene Speicherorte, zuständige Person und Ergebnis der Wiederherstellungsprüfung. Regeln Sie auch Zugriff und Aufbewahrung. Ein regelmäßiger Sicherungsplan braucht zusätzlich eine erkennbare Meldung, wenn ein Lauf ausfällt.

Eine getrennte Wiederherstellung vorbereiten

Richten Sie eine geschützte Testumgebung mit eigener Adresse, eigenem Dateiverzeichnis und eigener Datenbank ein. Sie soll technisch zur gesicherten Website passen. Verwenden Sie nicht versehentlich die produktiven Datenbankzugänge oder dieselben externen Dateispeicher zum Schreiben.

Vor dem ersten Website-Aufruf müssen produktiver Mailversand, geplante Aufgaben, Importe und externe Schnittstellen in der Kopie kontrolliert werden. Eine Kopie mit echten Anfrageadressen darf nicht ungeplant Benachrichtigungen verschicken. Sichern Sie auch den Zugriff auf die Testumgebung; eine schwer zu erratende Adresse ist kein ausreichender Schutz.

Übernehmen Sie beim Anlegen der Zieldatenbank den passenden Zeichensatz und die passende Kollation. Diese bestimmen unter anderem, wie Zeichen gespeichert und verglichen werden. Lassen Sie nach dem Import prüfen, ob alle Tabellen und Daten übernommen wurden und ihre Definitionen stimmen. Eine erfolgreiche Importmeldung allein belegt noch keine vollständige Wiederherstellung.

Den gesicherten Stand wiederherstellen

Stellen Sie die Dateien aus dem gewählten Sicherungssatz in der Testumgebung bereit. Importieren Sie dessen vollständigen Datenbankexport in die dafür vorgesehene Zieldatenbank. Ändern Sie anschließend nur die für die Kopie notwendigen Verbindungen und Adressen. Bewahren Sie die unveränderte Sicherung zusätzlich auf.

Die Konfiguration muss auf die neue Datenbank und die vorgesehenen Speicherorte zeigen. Prüfen Sie kanonische Website-Adressen und die Webserver-Konfiguration. Führen Sie keine pauschale Textersetzung über sämtliche Datenbankfelder aus: Native Seitenverweise, strukturierte Daten und externe Adressen sind unterschiedliche Werte.

Starten Sie zunächst mit derselben Core- und Paket-Version wie im Sicherungssatz. Eine gleichzeitige Neuinstallation mit neuerem Core erschwert die Fehlersuche und kann eine zusätzliche Datenbankmigration auslösen. Einen Versionswechsel testen Sie erst, wenn der wiederhergestellte Ausgangsstand funktioniert.

Wiederherstellung prüfen

Prüfen Sie als Besucher und mit einem geeigneten Redaktionsbenutzer:

  1. Öffnen sich Startseite, Unterseiten und interne Links unter der Adresse der Kopie?
  2. Sind Texte, Originalbilder, Downloads und globale Bereiche vorhanden?
  3. Stimmen Anmeldung, Seitenrechte und wichtige Benutzergruppen?
  4. Lassen sich vorhandene Seiten und Bilder normal bearbeiten?
  5. Sind Express-Einträge und andere wichtige Datenbestände vollständig?
  6. Funktionieren Formulare und Aufgaben mit den ausdrücklich vorgesehenen Testzielen?

Kontrollieren Sie auch technische Fehlermeldungen und Protokolle. Eine erfolgreiche Anmeldung allein genügt nicht. Dokumentieren Sie die Wiederherstellungsdauer und gefundene Abweichungen; daraus lässt sich ableiten, ob der geplante Rückweg im Ernstfall rechtzeitig funktioniert.

Bei Fehlern zurückkehren

Bei einem fehlgeschlagenen Update brauchen Sie den gemeinsamen Stand vor dem Eingriff. Nur alte PHP-Dateien zurückzukopieren stellt eine bereits migrierte Datenbank nicht automatisch wieder her. Klären Sie vor dem Rückspielen auch, ob seit der Sicherung neue Anfragen oder redaktionelle Änderungen eingegangen sind. Ein älterer Datenbankstand enthält diese neuen Daten nicht.

Beginnen Sie einen Rückweg deshalb mit einer zusätzlichen Sicherung des fehlerhaften Iststands. Halten Sie Zeitpunkt und Ursache fest und stimmen Sie ab, welche zwischenzeitlichen Inhalte erhalten werden müssen. Die praktische Aktualisierung beschreibt Updates vorbereiten und durchführen. Für geplante Sicherungsabläufe lesen Sie ergänzend Aufgaben regelmäßig ausführen.

Weiterlesen

Quelle: Concrete CMS Dokumentation (EN) · Stand: ConcreteCMS 9.5.7