Kategorie:Backup: Unterschied zwischen den Versionen

Aus SiteparkWiki
Zur Navigation springen Zur Suche springen
Zeile 4: Zeile 4:
  
 
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.
 
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 [[:Kategorie:Administration|IES-Admin]].
  
 
Grundsätzlich werden beim '' IES Backup'' drei Aktionen unterschieden:
 
Grundsätzlich werden beim '' IES Backup'' drei Aktionen unterschieden:
Zeile 17: Zeile 19:
  
  
===Backup===
+
==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 <code>$SITEPARK_DATA</code>/clients/$CLIENT-ID) und die aktuellen Serverdaten (Konfiguration und optionale Moduldaten).
+
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
 
* vollständig
Zeile 26: Zeile 28:
 
* optional können beim Backup alte MySQL-BINLOG automatisch gelöscht werden (Achtung bei Replikation von MySQL!)
 
* optional können beim Backup alte MySQL-BINLOG automatisch gelöscht werden (Achtung bei Replikation von MySQL!)
  
===Snapshot===
+
 
 +
==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.
 
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.
  
Zeile 35: Zeile 38:
  
  
===Recover===
+
==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:
 
Ein Recover kann jeden gesicherten Stand des IES wieder herstellen. Dabei wird die gewünschte Version interaktiv ausgewählt. Es gelten dabei folgende Regeln:
  
Zeile 57: Zeile 60:
 
** weitere System-relevante Informationen
 
** weitere System-relevante Informationen
  
<!--
+
 
===Sicherung des Backup===
+
==Daten==
Das IES-Backup sichert beim Bakcup folgende Daten:
+
Bei Sicherung eines Mandant werden stets folgende Daten berücksichtigt:
 +
* SQL-Zugangsdaten
 +
* optionale, mandantenspezifische Daten unterhalb von <code>$SITEPARK_HOME/clients/$CLIENT_ID</code> ($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
 +
 
 +
Beim Backup werden neben den mandantenspezifischen Daten auch folgende Daten gesichert:
 
* Die IES-Konfiguration: <code>ies-server.xml</code> (alle weiteren Daten der Konfiguration können nicht zur Laufzeit verändert werden und sind somit in der Sicherung von <code>$SITEPARK_HOME</code> enthalten)
 
* Die IES-Konfiguration: <code>ies-server.xml</code> (alle weiteren Daten der Konfiguration können nicht zur Laufzeit verändert werden und sind somit in der Sicherung von <code>$SITEPARK_HOME</code> enthalten)
 
* Alle Moduldaten unterhalb von <code>$SITEPARK_DATA/modules</code>
 
* Alle Moduldaten unterhalb von <code>$SITEPARK_DATA/modules</code>
  
Pro Mandant werden folgende Daten gesichert:
 
** SQL-Zugangsdaten
 
** Optionale, mandantenspezifische Daten unterhalb von <code>$SITEPARK_HOME/clients/$CLIENT_ID</code> ($CLIENT_ID ist analog zur BinDB)
 
** Alle Änderungen der BinDB seit dem letzten Snapshot bzw. Backup
 
** Alle Daten der jeweiligen Datenbank (auch Remote) als gezippte, inkrementelle SQL-Anweisungen seit dem letzten Snapshot bzw. Backup
 
  
'''Nach dem Einspielen von Vollbackups oder Snapshots werden zunächst alle SQL-Zugangsberechtigungen wieder hergestellt bzw. aktualisiert. Danach werden alle Templates neu kompiliert und alle Indices neu generiert.'''
+
'''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.'''
-->
 
  
 
<noinclude>
 
<noinclude>
 
[[Kategorie:Administration| 300]]
 
[[Kategorie:Administration| 300]]
 
</noinclude>
 
</noinclude>

Version vom 21. Oktober 2009, 12:21 Uhr

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.


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


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


Daten

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

  • SQL-Zugangsdaten
  • 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

Beim Backup werden neben den mandantenspezifischen Daten 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


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.

Diese Kategorie enthält zurzeit keine Seiten oder Medien.