Zielgruppe BetriebVersion: GSB10.0Backup und Recovery
Dieses Dokument stellt Ansätze zum Backup und Recovery der persistenten Daten einer GSB Infrastruktur vor.
1 Einleitung
An dieser Stelle werden insbesondere die aus GSB Sicht zu sichernden Daten und Dateien und Ansätze und es wird ein Sicherungsverfahren für die verschiedenen Service-Typen skizziert.
Diese Dokumentation ist somit als allgemeine Dokumentation zu verstehen, macht aber keine konkreten Vorgaben für Datensicherungskonzepte, -verfahren und -tools, da diese in der Hoheit und Verantwortung des jeweiligen Plattformbetreibers liegen.
Diese Dokumentation ist somit Grundlage und Ausgangspunkt für die Erarbeitung und Etablierung eines Datensicherungsverfahrens einer Hostingplattform.
2 Statische Daten
In einer GSB Hostinginfrastruktur sind eine Reihe von statischen Dateien bzw. Sammlungen von statischen Dateien vorhanden, die bei der Definition eines plattformspezifischen Datensicherungskonzeptes zur berücksichtigen sind.
Unter statischen Daten werden an dieser Stelle Dateien verstanden, die zur Laufzeit der GSB Komponenten unverändert bleiben, so dass für die Sicherung dieser Daten keine Besonderheiten aufgrund von sich dynamisch ändernden Daten zu berücksichtigen sind.
2.1 GSB Releases
Grundlage für die Installation der GSB Komponenten sind die GSB-Releases. Hierbei kann es sich sowohl um GSB Produktreleases als auch Mandantenreleases handeln. Diese Releases sollten üblicherweise zentral abgelegt und bereitgestellt werden.
Die exemplarische Infrastrukturdefinition des GSB Produktrelease sieht vor, dass diese im Ordner releases des Benutzers gsbos abgelegt werden, so dass in diesem Fall die Sicherung des entsprechenden Ordners hinreichend ist, um alle GSB Releases zu sichern.
| Hinweis: |
|---|
| Sollten die Releases aus organisatorischen Gründen auf verschiedenen Servern bereitgestellt bzw. gespiegelt werden, dann ist eine einmalige Sicherung hinreichend. Ein Recovery auf einem beliebigen Server kann in diesem Fall aus der zentral erstellten Sicherung der GSB Releases durchgeführt werden. |
2.2 Platform-Bundle
Aus den GSB Releases werden als Installationsvorbereitung die Platform-Bundles erzeugt. Die Platform-Bundles werden ausschließlich auf Basis der GSB Releases erstellt, so dass sich für die Erstellung und Bereitstellung der Bundles ebenfalls eine zentrale Ablage anbietet.
Die exemplarische Infrastrukturdefinition des GSB Produktrelease sieht vor, dass die Platform-Bundles im Ordner platformBundle des Benutzers gsbos abgelegt werden, so dass in diesem Fall die Sicherung des entsprechenden Ordners hinreichend ist, um alle Platform-Bundles zu sichern.
Die Platform-Bundles auf Basis von Konfigurationsdateien (gsbos_global.cfg, platformBundle.cfg, serviceTypes.cfg) generiert, die in der exemplarischen Infrastrukturdefinition im Verzeichnis config des Benutzers gsbos abgelegt sind. Diese Dateien sollten auf einer Hostingplattform zusätzlich gesichert werden ,da diese quasi das "Gedächtnis" für die Erstellung der Platform-Bundles sind.
| Hinweis: |
|---|
| Sollten die Platform-Bundles aus organisatorischen Gründen auf verschiedenen Servern erstellt werden, dann ist eine einmalige Sicherung (bei gleicher Bundledefinition) hinreichend. Ein Recovery auf einem beliebigen Server kann in diesem Fall aus der zentral erstellten Sicherung der Platform-Bundles durchgeführt werden. |
2.3 GSB Installation
Die GSB-Komponenten werden auf den einzelnen Servern installiert. Die exemplarische Infrastrukturdefinition und die Empfehlung sieht vor, dass die Installation der GSB Komponenten auf den einzelnen Servern unterhalb des Ordners /opt/gsbos/software durchgeführt wird.
Eine Datensicherung des software-Ordners erscheint nicht erforderlich, da im Falle eines Recovery einfach eine erneute GSB Installation des aktuellen Platform-Bundle durchgeführt werden kann.
2.4 Laufzeitkonfiguration
Die Laufzeitkonfiguration der einzelnen GSB Instanzen (Service-Typen) wird in der exemplarischen Infrastrukturdefinition im Ordner /opt/gsbos/runtime abgelegt. Dieser Ordner sollte gesichert werden, da hier jeweils die individuellen Konfigurationen der einzelnen GSB Service-Typen definiert sind.
| Hinweis: |
|---|
Wenn die Laufzeitkonfigurationen der GSB Server einer Hostingplattform aus einem Konfigurationsmanagementsystem (CMDB), o.ä. generiert werden können, dann kann an dieser Stelle auch auf die Sicherung der Laufzeitkonfiguration verzichtet werden. |
2.5 Beistellungen
Die Beistellungen des Systembetriebs für den Start und Betrieb der GSB Komponenten auf einer Hostingplattform werden an dieser Stelle nicht gesondert berücksichtigt, da diese üblicherweise über die vorhandenen Automatisierungs- und Provisionierungstools der Hostingplattform automatisch auf die Server verteilt und installiert werden. Ein Recovery der Beistellungen kann dann ebenfalls durch die erneute Provisionierung der Tools auf die Server durchgeführt werden.
3 Dynamische Daten
Im Gegensatz zu den im vorherigen Kapitel vorgestellten (statischen) Daten ändern sich die dynamischen Daten zur Laufzeit der GSB Komponenten. Eine Datensicherung der dynamischen Daten erfordert somit Maßnahmen, um einen konsistenten und in sich abgeschlossenen Stand der jeweiligen dynamischen Daten zu sichern.
3.1 Datenbanken
Eine Reihe von GSB Komponenten nutzt eine relationale Datenbank zur Speicherung der komponentenspezfischen Daten. Für jede Komponente (bspw. Adminportal, Site) bzw. jede Instanz (bspw. Preview-Repository, Master-Repository) wird eine dedizierte Datenbank bzw. Datenbanknutzer eingesetzt.
Die Sicherung der einzelnen Datenbanken für die jeweiligen GSB Dienste sollte jeweils pro Dienst erfolgen, da so eine einfachere Kontrolle des Sicherungsprozesses eines Dienstes durchgeführt werden kann.
In den folgenden Unterkapiteln werden Tools bzw. Hinweise zur Sicherung der beiden unterstützten Datenbanken MySQL und Oracle vorgestellt. Alternativ können natürlich auch die auf einer Hostingplattform etablierten Tools und Verfahren zur Datenbanksicherung eingesetzt werden.
3.1.1 MySQL-Datenbank Sicherung
Die für MySQL zur Verfügung stehenden Backup-Methoden sind in der MySQL-Dokumentation im Detail beschrieben (s.a. https://dev.mysql.com/doc/refman/5.7/en/backup-methods.html). Insbesondere bei Einsatz der MySQL Enterprise Edition kann mit dem Enterprise Backup eine Online-Sicherung der MySQL-Datenbanken durchgeführt werden, so dass für ein Backup einer Datenbank oder aller Datenbanken des Servers kein Stop des Servers durchgeführt werden muss.
Die GSB Datenbanken werden als InnoDB im MySQL-Server eingerichtet, so dass eien Sicherung auch mit Hilfe der Methoden auf https://dev.mysql.com/doc/refman/5.7/en/innodb-backup.html durchgeführt werden kann. Ein Cold-Backup ermöglicht bei gestopptem Datenbank-Server bspw. eine explizite Sicherung einer Datenbank (s.a. Kapitel Cold Backups).
Eine Alternative zu MySQL Enterprise Edition ist der Einsatz des Open-Source Tools Percona Xtra Backup, welches ebenfalls eine Online-Sicherung ermöglicht. Details zum Backup finden sich in der Dokumentation auf der Seite https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html.
3.1.2 Oracle-Datenbank Sicherung
Eine Sicherung von Oracle-Datenbanken kann mit dem Oracle Tool RMAN durchgeführt werden. Eine gute Einführung in Konfiguration und Nutzungsmöglichkeiten von RMAN findet sich bspw. auf http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/rman_i_backup/index.html.
3.1.3 Datenbankinstanzen
Die folgenden Datenbankinstanzen sind unter dem Gesichtspunkt des Backups und Recovery relevant.
3.1.4 Repository
Das Repository persistiert die redaktionellen Inhalte in einer relationalen Datenbank. Jede Repository-Instanz verfügt hier über eine eigene Instanz, so dass für die Sicherung aller Repositories die einznen Instanzen zu sichern sind.
Die exemplarische Infrastrukturdefinition sieht folgende Datenbankinstanzen vor:
repo_preview: Content-Repository des Redaktionssystems. D.h. in dieser Datenbank werden die aktuellen Stände der GSB-Dokumente sowie deren Bearbeitungshistorie gespeichert.repo_master: Content-Repository des Master-Livesystems. In dieses Repository werden die publizierten Inhalte aus dem Redakionssystem übertragen. Das Master-Repository verteilt diese anschließend an die angebundenen Replication-Livesysteme/-Repositories weiter. Das Master-Repository enthält ausschließlich publizierte Dokumente im publizierten Stand. D.h. eine Dokumenthistorie ist im Master-Repository nicht verfügbar.repo_replicationContent-Repository des Replication-Livesystems. Replication-Server werden in einer GSB Infrastruktur zur Erhöhung der Redundanz und/oder Performancesteigerung in der Live-Auslieferung eingesetzt. Der Inhalt des Replication-Repositories entspricht damit dem des Master-Repositories. Auf eine dedizierte Sicherung der Replication-Repositories kann an dieser Stelle daher verzichtet werden, da diese aus der Sicherung des Master-Repositories wiederhergestellt werden können.
3.1.4.1 Vorgehen zur Sicherung
Um sicherzustellen, dass das zu sichernde Contentrepository in einem konsistenten Zustand ist empfiehlt es sich, das betreffende Repository zunächst zu stoppen. D.h. das Content-Repository (Datenbank repo_preview) wird bspw. mit dem folgenden Kommando gestoppt:
sudo systemctl stop repository@repository-preview
Nachdem das Repository gestoppt worden ist, kann die Sicherung der Repository-Datenbank (im Beispiel repo_preview) mit den auf der Hostingplattform zur Verfügung stehenden Tools gesichert werden. Nachdem die Sicherung abgeschlossen ist, wird das Repository wieder gestartet:
sudo systemctl start repository@repository-preview
| Hinweis: |
|---|
Für eine zusätzliche Sicherung des aktuellen Standes eines Content-Repositories bietet sich eine Sicherung des Contents über einen vollständigen Content-Export an. Ein Export des publizierten Contents des Master-Repositories kann bspw. mit dem folgenden curl-Kommando durchgeführt werden:path=/`) des lokal auf dem System laufenden Content-Repositories (localhost:7001). Der Port 7001 entspricht dem Port auf dem das Master-Content-Repository läuft. |
3.1.5 Adminportal
Die Sicherung des Adminportals kann ausschließlich durch Sicherung der Datenbank adminportal durchgeführt werden. Der Solr-Suchindex und Timestamp des zugehörigen Service-Tomcats müssen nicht gesichert werden, da diese im Falle eines Recovery aus einfach durch Index Neuaufbau wiederhergestellt werden können.
3.1.6 Maildistributor
Der Maildistributor verwaltet seine Informationen ausschließlich in der zugrundeliegenden Datenbank maildistributor, so dass an dieser Stelle eine Sicherung der Datenbank durchgeführt werden sollte.
Neben der Sicherung der Maildistributor-Datenbank sollte auch der Timestamp des zugehörigen EventDispatchers gesichert werden.
Vor dem Auslesen des Zeitstempels sollte die EventDispatcher-Webapplikation außer Betrieb. gesetzt werden, bzw. in den Offline-Modus versetzt werden, damit die weitere Event-Verarbeitung gestoppt wird und der Zeitstempel nicht mehr geändert wird. Die außer Betrieb Setzung wird per JMX mit dem folgenden MBean durchgeführt:
ObjectName: de.bund.gsb.eventdispatcher:name=Status ClassName: de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatus Method: void setOffline();
Nachdem der EventDispatcher in den Offline-Modus versetzt worden ist, wird die Datenbank mit dem Namen maildistributor gesichert.
Zur Sicherung des EventDispatcher-Status wird der Zeitstempel des zuletzt verarbeiteten Content-Events ausgelesen. Das Auslesen des Zeitstempels erfolgt per JMX.
ObjectName:de.bund.gsb.eventdispatcher:name=StatusClassName:de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatusMethod:long getTimestamp();
Die Wiederherstellung des EventDispatcher-Status im Zuge des Recovery erfolgt erneut per JMX, indem der zuvor gesichert Timestamp wieder eingespielt wird (Methode setTimestamp).
Auch für das Recovery sollte die EventDispatcher-Webappliktions in den Offline-Modus versetzt worden sein (s.o.). Nach der Einspielung des gesicherten Timestamps kann die Webapplikations wieder in den Online-Modus versetzt werden, damit der EventDispatcher seinen Betrieb wiederaufnimmt und mit der Event-Verarbeitung ab dem Zeitpunkt des wiederhergestellten Timestamps startet.
Für das Setzen des Online-Modus wird das folgende MBean gentutzt:
ObjectName:de.bund.gsb.eventdispatcher:name=StatusClassName:de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatusMethod:void setOnline();
3.1.7 Workflow
Die redaktionellen Workflow-Instanzen der Camunda-Applikation werden unabhängig vom Content-Repository der Redaktion in einer dedizierten relationellen Datenbank gespeichert. Die in der Datenbank verwalteten Informationen umfassen ausschließlich Camunda-Metadaten und Informationen zu den GSB Workflows, so dass das Volumen der zugrundeliegenden Datenbank sehr überschaubar sein ist und eine Sicherung der Datenbank somit kein größeres Problem darstellen sollten.
Da die Publikationsmengen, die sogenannten ChangeSets, der Publikationsworkflows im Redaktions-Repository gespeichert werden, empfiehlt es sich die Sicherung der Datenbank der Workflow-Instanzen im Zuge der Backups des Redaktions-Repositories durchzuführen.
Die Workflow-Instanzen sollten während der Sicherung gestoppt sein, da ansonsten per Zeitsteuerung laufende Workflows Veränderungen an den Daten vornehmen könnten.
Bei der zu sichernden Workflow-Datenbank handelt es sich um die Datenbank mit dem Namen workflow.
3.2 Solr-Suchindeces
Die Sicherung der Solr-Suchindices sollte als Offline-Sicherung durchgeführt werden, um Inkonsistenzen aufgrund von Änderungen im Suchindex während des Backups ausschließen zu können. Zunächst wird daher der Indexer in den Offline-Modus versetzt. Dies kann entweder über die Administrationsoberfläche der Indexer-Webapplikationen erfolgen oder per JMX.
Im Offline-Modus werden von dem Indexer keine weiteren Content-Events empfangen und verarbeitet, wodurch auch keine Veränderungen am Solr-Suchindex vorgenommen werden.
Nach der Offline-Setzung des Indexers kann der Status (der Timestamp) des Indexers per JMX abgefragt und gesichert werden. Das folgende MBean kann für das Setzen des Online-Status verwendet werden.
ObjectName:de.bund.gsb.indexer:name=StatusClassName:de.bund.gsb.indexer.mbeans.IndexerOnlineStatusMethod:void setOffline();
Im Anschluss wird die Solr-Instanz gestoppt. Hierbei ist zu beachten, dass die Solr-Instanz noch Informationen, die zu einer Veränderung des Suchindex beitragen, in der Verarbeitungswarteschleife vorhält. Diese Informationen können durch das Stoppen verloren gehen. Ob dies der Fall ist kann innerhalb der Übersicht eines Solr-Kerns über den Status „Current“ überprüft werden (siehe Abbildung).
Zur Sicherung der auf dem Dateisystem gespeicherten Suchindizes wird von diesen zunächst eine Kopie angelegt werden. Diese Kopie kann dann zur Sicherung verwendet werden, um die Solr-Instanz zeitnah wieder in Betrieb nehmen zu können.
Die zu sichernden Daten der Suchindizes sind im Datenverzeichnis der Solr-Tomcat-Instanz im „solr-data“-Verzeichnis zu finden (Verzeichnis /space/gsbos/data/solr-master). Das „solr-data“-Verzeichnis ist wie folgt aufgebaut:
solr-data|-- standardlsg| |-- index| |-- spellchecker| |-- tlog|-- standardlsg_editor| |-- index| |-- spellchecker| |-- tlog|-- standardlsg_functions| |-- index| |-- spellchecker| |-- tlog|-- customer2| |-- index| |-- spellchecker| |-- tlog|-- ...
Jeder Solr-Kern eines Mandanten, bzw. eines funktionalen Mandanten (<CUSTOMER>_editor, <CUSTOMER>_functions), liegt in einem separaten Verzeichnis.
Im Rahmen der Sicherung der Solr-Suchindizes wird ebenfalls der Indexer-Status berücksichtigt. Der Indexer, welcher die Suchindizes einer Solr-Instanz befüllt, hält seinen Status in Form eines Timestamps, der den zuletzt verarbeiteten Content-Event entspricht. Für eine konsistente Sicherung der Solr-Indizes muss daher der zum Zeitpunkt der Sicherung aktuelle Timestamp mit gesichert werden. Dieser kann mit dem folgenden MBean per JMX ermittelt und mit gesichert werden:
ObjectName:de.bund.gsb.indexer:name=StatusClassName:de.bund.gsb.indexer.mbeans.IndexerOnlineStatusMethod:long gestTimestamp();
Nachdem die Sicherung der Solr-Indices durchgeführt worden ist, wird der zugehörige Indexer mit dem folgenden MBean wieder gestartet:
ObjectName:de.bund.gsb.indexer:name=StatusClassName:de.bund.gsb.indexer.mbeans.IndexerOnlineStatusMethod:void setOnline();
Wird der von Solr bereitgestellte Replikationsmechanismus eingesetzt, reicht es die Master-Solr-Instanz zu sichern. Die Indexe der Replikationsinstanzen werden dann nach dem Recovery eines Master-Solr-Indexes automatisch von der Master-Instanz befüllt.
3.3 Service-Tomcat
Im Service-Tomcat der Redaktion werden die beiden Webapplikationen Indexer und EventDispatcher betrieben. Die Sicherung des Indexers (Timestamp) wird bei der Sicherung der Solr-Indices betrachtet (s.a. Kapitel „Solr-Suchindex“), so dass an dieser Stelle eine Sicherung des EventDispatcher-Status dokumentiert wird.
Vor dem Auslesen des Zeitstempels sollte die EventDispatcher-Webapplikation außer Betrieb. gesetzt werden, bzw. in den Offline-Modus versetzt werden, damit die weitere Event-Verarbeitung gestoppt wird und der Zeitstempel nicht mehr geändert wird.
Die außer Betrieb Setzung wird per JMX mit dem folgenden MBean durchgeführt:
ObjectName:de.bund.gsb.eventdispatcher:name=StatusClassName:de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatusMethod:void setOffline();
Zur Sicherung des EventDispatcher-Status wird der Zeitstempel des zuletzt verarbeiteten Content-Events ausgelesen. Das Auslesen des Zeitstempels erfolgt per JMX.
ObjectName:de.bund.gsb.eventdispatcher:name=StatusClassName:de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatusMethod:long getTimestamp();
Die Wiederherstellung des EventDispatcher-Status im Zuge des Recovery erfolgt erneut per JMX, indem der zuvor gesichert Timestamp wieder eingespielt wird (Methode setTimestamp).
Auch für das Recovery sollte die EventDispatcher-Webappliktions in den Offline-Modus versetzt worden sein (s.o.). Nach der Einspielung des gesicherten Timestamps kann die Webapplikations wieder in den Online-Modus versetzt werden, damit der EventDispatcher seinen Betrieb wiederaufnimmt und mit der Event-Verarbeitung ab dem Zeitpunkt des wiederhergestellten Timestamps startet.
Für das Setzen des Online-Modus wird das folgende MBean genutzt:
ObjectName:de.bund.gsb.eventdispatcher:name=StatusClassName:de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatusMethod:void setOnline();