MySQL-DB Backup per php

[Martin Hein]

Hallo Forum,

ich hatte mal auf einem Kunden(Linux-)server ein php-Script
('db_export.php') geschrieben, dass einen Dump erzeugt und
als dump.<datum>.sql auf eben diesem Server abgelegt hatte.

Das funktionierte hervorragend, um die DB zu backupen.

Ich komme an diese 'export.php' nun nicht mehr ran und bin
mir auch nicht mehr sicher, wie ich die geschrieben hatte.

Im Grunde so:
-------------

exec ("mysqldump.exe -u <username> > test.sql");

Aber wie war das noch genau ? Auf meinem Windows-System
muss ich den Pfad zu 'mysqldump.exe' absolut angeben.
Auf dem Linuxserver habe ich den sicher nicht gehabt.
Kann man vielleicht auch aus mysql diesen Dump erzeugen ?

Es gibt ja so etwas wie:

SELECT * INTO OUTFILE dateiname

Das ist aber dann kein kompletter Dump.

Wie macht man das am besten ?
Bzw. Wie macht phpmyadmin das?

danke und

beste gruesse,
martin

[Martin Hein]

funktioniert schon:

$reply = shell_exec('mysqldump --add-drop-table -c -n -h localhost --user=bkkdigm1 --pass=ot3VNayM digmdb1 content_offline > test.sql');

[Michael]

Hallo

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?

liebe Grüße
Michael

[Tom]

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

[Michael]

Hallo Tom!

Danke für deine ausführliche Antwort.

herzliche Grüße
Michael