Tom: MySQL-DB Backup per php - und bei safemode?

Beitrag lesen

Hello,

ich hoffe es ist ok, wenn ich mich an diesen thread dranhänge.
Die Funktion shell_exec steht ja im SafeMode nicht zur Verfügung.
Gibt es trotzdem einen Weg?

Bei einem Backup sind die verschiedensten Dinge zu beachten.
So dürfen z.B. während eines allgemeinen Backups keine referenziellen Veränderungen mehr am Datenbestand vorgenommen werden.

Das heißt:

Datei_1 steht                   in Relation                    mit Datei_20

^
                         |
 --+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-->

Während die Sicherung läuft und von Datei_1 bis Datei_20 alle Daten kopiert, wird eine
Veränderung in Datei_1 vorgenommen, die auch Auswirkungen auf Datei 20 hat. Nun ist die Sicherung aber schon bei Datei_6 angekommen, also mit Datei_1 schon lange fertig. Die Veränderung in Datei_20 bekommt die Sicherung aber noch mit.

Im Backup befindet sich jetzt also die Datei_1 vom Zeitpunkt T1 und die Datei_20 vom Zeitpunkt T1+deltaX. Beide gehören nicht zusammen, da sie den Zustand des Datenbestandes nicht zum selben Zeitpunkt abbilden. Der Originaldatenbestend ist noch konsistent. Das Baclup ist es aber nicht, da die gesicherten Daten gar nicht zusammen gehören. Durch das Einspielen des Backups wird der Datenbestand also inkosistent und damit ungültig.

Ein Backup kann daher entweder nur in geschlossenen Teilmengen aus der Applikation heraus vorgenommen werden, wohl wissend, dass dann die unterschiedlichen Teilmengen für die unterschiedlichen Sicherungsblöcke nicht mehr zusammenpassen. Dies kann man dann in Kauf nehmen, wenn die Referenzbrüche an bekannten Grenzen stattfinden. Dann kann die Sicherung oft mit den Rechten des "Applikationsbeauftragten" durchgeführt werden, also des Stellvertreters, der an alle Daten der Applikation zu jedem Zeitpunkt (lesend) heran kommt.

Eigentlich müssen die Rechte für Datensicherung aber auf Systemebene angesiedelt werden, weil es z.B. praktischer ist, einen "Snapshot" der gesamten MySQL-Datenbank vorzunehmen. Hierzu  muss der Daemon entweder "heruntergefahren" werden, oder aber zumindest Veränderungen am Datenbestand währende des Sicherungslaufes unterbinden. Eine Vollsicherung des gesamten Datenkomplexes "MySQL" dauert mit copy und targz auf Systemeben z.B. 30 Sekunden, während sie auf Applikationsebene über 30 Minuten verschlingt.

Zur Vermeidung von "Offtimes" und Integritätsverletztungen sollte die Datensicherung so hoch angesetzt werden, wie möglich, also in der Obhut eines Systemverantwortlichen liegen.

In großen (dynamischen) Datenbeständen ist selten noch eine "Offtime" möglich. Die statische Vollsicherung wird daher nur selten (z.B. einmal monatlich) durchgeführt. Ausgehend von dieser Vollsicherung werden dann "Change Logs" geschrieben, also täglich oder sogar während des Betriebes nur die Veränderungen des Datenbestandes protokolliert. Diese sind meistens weniger umfangreich, als der seit Jahen gewachsene Kernbestand der Daten. Es wird also so eine Art "doppelte Datenführung" betrieben. Der neue Datenzustand wird hergestellt (das ist das statische Abbild) und die Veränderung zur letzten Vollsicherung wird protokolliert. Das ist das dynamsiche Abbild der Daten. Aus der Vollsicherung und dem Change-Log lassen sich so die Daten zu jedem Moment nach der Vollsicherung wieder herstellen.

In der Praxis gibt es noch wesentlich komplexere Modelle.

Auf Deine Frage zurück: Mit eingeschaltetem Safe-Mode lassen sich aus der Applikationsebene heraus noch nicht einmal alle Applikationsdaten (Dteien des PHP-Bereiches) sichern, geschweige denn übergeordnete Datenbestände (Datenbank, Systemdaten, ...). Du würdest immer nur ein unvollständiges Bild erhalten. Grenze also den lesbaren Bereich genau ab. Dies ist der Bereich, in dem Du "Daten sichern" kannst. Anderenfalls müssen die Sicherungsstrategien in die Applikation integriert werden, denn nur die weiß für ihren Bereich, welches Teilabbild jeweils geschlossen (also als Snapshot) gezogen werden muss und welches ohne Integritätsbrüche zu einem anderen Zeitpunkt durchgeführt werden kann.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)