Kategorie:Backup: Unterschied zwischen den Versionen

IES Backup (ab Version 2.1.1)

Konzept

Das hier beschriebene Verfahren garantiert konsistente Datensicherungen des IES zur Laufzeit. Auf diesen Mechanismen basiert auch das Verfahren für ein sog. IES StandBy. Dabei wird ein Mandant auf einem anderen IES synchron gehalten und kann im Notfall aktiviert werden. IES StandBy Mechanismen sind jedoch noch in der frühen Entwicklungsphase.

Ausgeführt werden die Operationen zum Backup über IES-Admin.

Grundsätzlich werden beim IES Backup drei Aktionen unterschieden:

• backup

  vollständiges Backup aller Daten und Konfigurationen eines Mandanten

• snapshot

  inkrementelle Sicherung aller Daten eines Mandanten basierend auf dem letzten vollen Backup

• recover

  reaktivieren von Sicherungen eines Mandanten inkl. aller Daten ohne automatische Übernahme der Konfiguration

Das Backup und allle Snapshots liegen in einem $SITEPARK_BACKUP Verzeichnis. Dieses Verzeichnis kann entweder ein Netzwerklaufwerk sein, oder auf einem Backup-Server gesichert werden. Der Status der Sicherungen wird in einer XML-Datei unterhalb dieses Verzeichnisses gesichert und kann somit zusammen mit den Daten und unabhängig vom IES archiviert werden.

In der Konfiguration des IES kann das Verzeichnis, welches standardmäßig $SITEPARK_HOME/backup ist, über die Property "backupDir" gesetzt werden.

Technische Voraussetzungen

Da das IES Backup auf den binären Logs von MySQL basiert sind mind. die MySQL-Tools

• mysql
• mysqldump
• mysqlbinlog

lokal zu installieren.

Weiterhin sind auf dem MySQL-Server noch folgende Konfigurationen vorzunehmen:

log_bin

muss aktiviert sein

server-id

muss auf einen Wert >1 gesetzt sein

expire_logs_days

sollte bei Einsatz von Replikation gesetzt sein.

Ein großer Teil an SQL-Statements, die der IES lesend auf die Datenbank vornimmt, erfolgt über sog. temporäre Tabellen. Diese sind ein notwendiges und performantes Mittels um Abfragen auf unserem generischen Datenmodell vorzunehmen. Da temp. Tabellen nicht repliziert werden sollten, müssen diese noch entsprechend in der Konfiguration des MySQL-Systems ausgenommen werden.

Hier entsprechende Anweisungen für die MySQL-Konfiguration:

replicate-wild-do-table = %
replicate-ignore-table= %.result
replicate-ignore-table = %.result
replicate-ignore-table = %.Channel%
replicate-ignore-table = %.GeneratableFile%
replicate-ignore-table = %.tmpcheckcon
replicate-ignore-table = %.checkcon
replicate-ignore-table = %.vtmp
replicate-ignore-table = %.queryTmp
replicate-ignore-table = %.historyTmp
replicate-ignore-table = %.templateTmp
replicate-ignore-table = %.contentTmp

Backup

Ein Backup wird pro Mandant ausgeführt und erstellt einen vollständigen MySQL-Dump, eine komplette Kopie der BinDB des Mandanten, optionale, spezifische Daten und die aktuellen Serverdaten.

• vollständig
• konsistent mit BinDB (Inkonsistent mit DocumentRoots, diese müssen über klassische Mechanismen gesichert oder bei Bedarf neu generiert werden)
• benötigen je nach Serverleistung und Datenumfang relativ viel Zeit und Resourcen
• sollte in regelmäßigen Abständen erstellt werden, wenn der Server nur gering beansprucht wird (z.B. einmal die Woche um 1:00 Uhr Nachts)
• optional können beim Backup alte MySQL-BINLOG automatisch gelöscht werden (Achtung bei Replikation von MySQL!)

Weitere Information hierzu unter: Backup - Vollständige Sicherung von Mandanten

Snapshot

In regelmäßigen Abständen werden alle Änderungen der Datenbank und der BinDB seit dem letzten Backup bzw. seit dem letzten Snapshot gesichert. Als Basis eines Snapshots dienst aber immer ein vollständiges Backup, da Snapshot auf der Basis von BINLOG-Mechanismen von MySQL aufbauen.

• inkrementell (nur Differenzen in der Datenbank und der BinDB)
• konsistent mit BinDB (Inkonsistent mit DocumentRoots)
• benötigen je nach Zeit zwischen den Snapshots nur geringe Resourcen
• sollten mehrmals täglich erfolgen

Weitere Information hierzu unter: Snapshot - Inkrementelle Sicherung von Mandanten

Recover

Ein Recover kann jeden gesicherten Stand des IES wieder herstellen. Dabei wird die gewünschte Version interaktiv ausgewählt. Die Summe der Aktionen kann je nach Datenumfang zu einer relativ langen Zeitspanne führen in der der Mandant nicht aktiv ist. Es gelten dabei folgende Regeln:

• der Mandant wird für die Wiederherstellung vorübergehend deaktiviert
• es wird stets immer erst das vollständige Backup einspielt (ist u.U. relativ zeitaufwendig!)
• optional kann die BinDB wieder hergestellt werden (nur notwendig, wenn das Filesystem defekt war)
• alle Snapshots, bis zu dem gewünschten Zeitpunkt werden nacheinander eingespielt
• nach einem Wiederherstellung einer alten Version werden mit dem nächsten Snapshot alle Versionen die "zurückgegangen" wurden gelöscht
• es ist optional möglich einen anderen Ordner mit Daten zum Backup anzugeben
• im Anschluss werden alle Templates des Mandanten für den Generator neu kompiliert
• evtl. vorhandene Lucene-Indices werden vollständig neu erzeugt

Weitere Information hierzu unter: Recover - Wiederherstellung einer Sicherung eines Mandaten

Gesicherte Daten

Bei Sicherung eines Mandant werden stets folgende Daten berücksichtigt:

• SQL-Zugangsdaten über die Konfiguration
• optionale, mandantenspezifische Daten unterhalb von $SITEPARK_HOME/clients/$CLIENT_ID ($CLIENT_ID ist analog zur BinDB)
• alle Daten (bei Snapshots Änderungen) der BinDB
• alle Daten der jeweiligen Datenbank (auch Remote) als gezippte, (bei Snapshots inkrementelle) SQL-Anweisungen

Bei Backups oder Snapshots werden neben den oben genannten Daten stets auch folgende Daten gesichert:

• Die IES-Konfiguration: ies-server.xml (alle weiteren Daten der Konfiguration können nicht zur Laufzeit verändert werden und sind somit in der Sicherung von $SITEPARK_HOME enthalten)
• Alle Moduldaten unterhalb von $SITEPARK_DATA/modules

Regeln für das Backup

Auf dem IES-Server

• Das Verzeichnis $SITEPARK_HOME muss unabhängig von den IES-Datensicherungen regelmäßig erfolgen
• Das Verzeichnis $SITEPARK_DATA (i.d.R. $SITEPARK_HOME/data) sollte vom Backup ausgenommen werden
• Das Verzeichnis $SITEPARK_BACKUP (i.d.R. $SITEPARK_HOME/backup) sollte entweder direkt auf einem externen System liegen, oder zusammen mit dem Verzeichnis $SITEPARK_HOME gesichert werden.
• Das Verzeichnis $SITEPARK_BACKUP (und evtl. auch $SITEPARK_HOME) sollten nach jedem Snapshot oder Vollbackup gesichert werden
• Weiterhin wird empfohlen folgende Konfigurationen regelmäßig zu sichern:
  • Cronjobs
  • Apache-Konfiguration (und Module)
  • MySQL-Konfiguration
  • weitere System-relevante Informationen

Nach dem Einspielen von Backups oder Snapshots werden zunächst alle SQL-Zugangsberechtigungen pro Mandat wieder hergestellt bzw. aktualisiert. Danach werden alle Templates neu kompiliert und die Indices neu generiert.

Auf den Webservern

• Das Verzeichnis data der Webnodes (i.d.R. $SITEPARK_HOME/ies-webnode/data) sollte regelmäßig gesichert werden
• Das Verzeichnis config der Webnodes (i.d.R. $SITEPARK_HOME/ies-webnode/data) sollte regelmäßig gesichert werden
• Cronjobs
• Apache-Konfiguration (und Module)
• weitere System-relevante Informationen

Beispiel für Konfiguration des Backups via CRON

• Vollständige Sicherung jeden Sonntag um 2:00 Uhr
• Inkrementelle Sicherung täglich zu jeder halben Stunde

Der Ordner mit den Sicherungen (hier: /srv/sitepark/backup) sollte spätestens Sonntags vor 1:40 Uhr auf ein externes Laufwerk gesichert werden, da das vollständige Backup alle vorhandenen Sicherungen löscht.

Struktur von Cronjobs unter Linux:

* * * * * auszuführender Befehl
┬ ┬ ┬ ┬ ┬
│ │ │ │ │
│ │ │ │ └──── Wochentag (0-7) (Sonntag =0 oder =7)
│ │ │ └────── Monat (1-12)
│ │ └──────── Tag (1-31)
│ └────────── Stunde (0-23)
└──────────── Minute (0-59)

Vollständiges Beispiel:

# m h  dom mon dow   command

# ies backup
0   2   *   *   0   /usr/bin/iesadmin backup --all --purge --force > /dev/null

# ies snapshots
30   *   *   *   *  /usr/bin/iesadmin snapshot --all --force > /dev/null