Kategorie:Backup

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.

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.

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 (aus $SITEPARK_DATA/clients/$CLIENT-ID) und die aktuellen Serverdaten (Konfiguration und optionale Moduldaten).

• 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!)

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

Recover

Ein Recover kann jeden gesicherten Stand des IES wieder herstellen. Dabei wird die gewünschte Version interaktiv ausgewählt. 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

Regeln für das Backup

• 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