Kennt sich jemand gut mit PHP aus?

[Anselm Rapp]

Hallo,

ich tüftle gerade. Ich habe mir (R. I. P. MySQLDumper) aus dem Netz folgendes Skript kopiert:

<?

exec("mysqldump -u MEINDATENBANKBENUTZER -pMEINDATENBANKPASSWORT --add-drop-table MEINDATENBANKNAME >dump" . date('Ymd_g_i') . ".sql");

exec("gzip dump" . date('Ymd_g_i') . ".sql");

echo "Backup der Datenbank für MEINESEITE wurde im Ordner backup erstellt!";

?>

Ich möchte die Datei im tar-Format packen lassen. Meines Wissens geht das ohne großen Aufwand sehr elegant. Aber meine PHP-Kenntnisse sind stark eingerostet. Kann mir jemand helfen bitte?

Danke im Voraus und Gruß, Anselm

[timo]

Hallo Anselm.

um erst einmal die Frage im Betreff wahrheitsgemäß zu beantworten: Bestimmt, aber ich nicht.

So wie ich es bar fast jeder PHP-Kenntnisse verstehe, tut das Skript folgendes: Es erzeugt einen (zunächst unkomprimierten) Extrakt der Datenbank mit der Endung .sql und komprimiert ihn anschließend mit gzip. Herauskommen müsste eine Datei mit der Doppelendung .sql.gz.

Jetzt erst mal ein Punkt, den ich nicht verstehe: Es handelt sich bei dem Extrakt um eine einzelne Datei. Warum willst Du die mit tar packen? Das dient ja normalerweise dazu, aus mehreren Dateien eine zu machen, um sie (meist) anschließend zu komprimieren (tar selbst komprimiert nicht). Bei einer Datei reicht gzip doch eigentlich.

Falls es aus irgendwelchen Gründen trotzdem sein soll, würde ich einfach den Aufruf von gzip...

Code:

exec("gzip dump" . date('Ymd_g_i') . ".sql");

... durch einen von tar ersetzen:

Code:

exec("tar -czf dump" . date('Ymd_g_i') . ".sql.tar.gz dump" . date('Ymd_g_i') . ".sql");

Das würde eine (komprimierte) .tar.gz-Datei erzeugen. Für unkomprimiertes tar müsste es irgendwie so aussehen:

Code:

exec("tar -cf dump" . date('Ymd_g_i') . ".sql.tar dump" . date('Ymd_g_i') . ".sql");

Nicht ausprobiert, muss also natürlich nicht funktionieren, aber vielleicht mal einen Versuch wert.

Gruß,
Timo

[Anselm Rapp]

Hallo Timo,

danke, dass Du Dich opferst.

So wie ich es bar fast jeder PHP-Kenntnisse verstehe, tut das Skript folgendes: Es erzeugt einen (zunächst unkomprimierten) Extrakt der Datenbank mit der Endung .sql und komprimiert ihn anschließend mit gzip. Herauskommen müsste eine Datei mit der Doppelendung .sql.gz.

Jetzt erst mal ein Punkt, den ich nicht verstehe: Es handelt sich bei dem Extrakt um eine einzelne Datei. Warum willst Du die mit tar packen? Das dient ja normalerweise dazu, aus mehreren Dateien eine zu machen, um sie (meist) anschließend zu komprimieren (tar selbst komprimiert nicht). Bei einer Datei reicht gzip doch eigentlich.

Also - da muss ich ausholen: Mein Hoster stellt im Adminpanel die Möglichkeit bereit, MySQL-Dateien manuell zu sichern. Ich bin sonst sehr angetan von ihm, aber täglich eine Sicherung von Hand anzustoßen und herunterzuladen, ist suboptimal. Bisher habe ich das mit dem MySQLDumper und Cronjob gemacht, aber der ist eingegangen. Auf der Suche nach Ersatz habe ich das Skript gefunden. Damit will ich die MySQL-Sicherungen künftig automatisieren.

Die Dateien kommen in diesem Format an: mysql_db_backup_20180519154258.tar (den Dateinamen muss ich noch anpassen) und enthalten das da: benutzer_db1_1_20180519154257.gz - keine Ahnung warum; so ist es und dem muss ich mich anpassen. Die per Skript erzeugte .tar ist übrigens 10 Byte größer als die .gz und enthält nur Binäres; da kann etwas nicht stimmen. Die .gz soll gar nicht heruntergeladen werden, nur die .tar, das scheint ein Zwischenschritt zu sein.

Wenn ich das schaffe, erzeuge ich per Skript eine .tar und versuche, die im Adminpanel zu "restoren". Wenn es klappt, habe ich ein erhebliches Problem gelöst.

Soweit klar, meine Erklärungen?

Gruß, Anselm

[timo]

Die Dateien kommen in diesem Format an: mysql_db_backup_20180519154258.tar (den Dateinamen muss ich noch anpassen) und enthalten das da: benutzer_db1_1_20180519154257.gz - keine Ahnung warum; so ist es und dem muss ich mich anpassen.

Es könnte Sinn ergeben, wenn u.U. auf dem gleichen Weg auch mehrere MySQL-Datenbanken in einer tar-Datei gesichert werden. Meist wird zwar (wie schon geschrieben) erst aus den Einzeldateien eine große gemacht und die anschließend komprimiert, was den Vorteil einer geringeren Dateigröße hat (Stichwort "Solides Archiv"), aber auch der hier offenbar beschrittene umgekehrte Weg (erst alle Einzeldateien komprimieren, und dann aus allen resultierenden *.gz-Dateien ein Tar-Archiv erzeugen) kann sinnvoll sein. Wenn man nur die Sicherung einer der Datenbanken bräuchte, müsste man bei der zweiten Methode nicht (wie bei der ersten) das ganze Tar-Archiv dekomprimieren, sondern nur gezielt die eine Datei, die man braucht. Das geht (je nach Anzahl der enthaltenen Dateien) vermutlich deutlich schneller.

Das Erzeugen ist generell nicht das Problem. Müsste in zwei Schritten erfolgen und irgendwie so aussehen:

Code:

exec("gzip dump" . date('Ymd_g_i') . ".sql");

Also erst mal das Komprimieren der SQL-Datei, wie schon vorhanden. Und dann das tar-Archiv:

Code:

exec("tar -cf mysql_db_backup_" . date('Ymd_g_i') . ".tar *.sql.gz");

Die Dateinamen sind dann allerdings anders als in Deinem Beispiel. Ob das Admintool die Datei so importieren kann, weiß ich nicht.

[Anselm Rapp]

Danke, Timo. Ich gönne uns erst mal etwas Pfingstruhe, aber dann ...

Gruß, Anselm

[Anselm Rapp]

Hallo Timo,

ich habe noch nicht aufgegeben.

Es könnte Sinn ergeben, wenn u.U. auf dem gleichen Weg auch mehrere MySQL-Datenbanken in einer tar-Datei gesichert werden. Meist wird zwar (wie schon geschrieben) erst aus den Einzeldateien eine große gemacht und die anschließend komprimiert, was den Vorteil einer geringeren Dateigröße hat (Stichwort "Solides Archiv"), aber auch der hier offenbar beschrittene umgekehrte Weg (erst alle Einzeldateien komprimieren, und dann aus allen resultierenden *.gz-Dateien ein Tar-Archiv erzeugen) kann sinnvoll sein. Wenn man nur die Sicherung einer der Datenbanken bräuchte, müsste man bei der zweiten Methode nicht (wie bei der ersten) das ganze Tar-Archiv dekomprimieren, sondern nur gezielt die eine Datei, die man braucht. Das geht (je nach Anzahl der enthaltenen Dateien) vermutlich deutlich schneller.

Richtig ist jedenfalls, wie ich mich inzwischen überzeugt habe, dass man beim Vorhandensein mehrerer MySQL-Datenbanken alle markieren und herunterladen kann. Man erhält dann eine .tar-Datei, welche alle Sicherungen im .gz-Format enthält.

Dann habe ich noch etwas über die Dateinamen nachgedacht. Zum Probieren will ich künftig in meinem Einflussbereich simple Dateinamen verwenden, also beispielsweise db.tar, db1.gz usw. Wenn alles richtig läuft, kann ich Datum und Uhrzeit in den Dateinamen aufnehmen. Weiterhin müsste bei Deinem Skript nach Erstellen der .tar-Datei noch die .gz-Datei löschen, denn sonst nimmt die unnötig Platz in Anspruch. (Expertenmodus: Es sollten nur die letzten drei Dateien aufgehoben werden. Das stelle ich erst mal zurück.) Aber: Die Dateien, die heruntergeladen werden, haben ja tatsächlich Dateinamen wie mysql_db_backup_20180522115635.tar. Also müsste die heruntergeladene Datei im ersten Schritt immer gleich heißen und dann erst bei der Komprimierung nach .tar mit Datum versehen werden - stimmt's?

Mein Script sieht ohne Datumsumwandlungen jetzt so aus:

Code:

<?php

echo "MySQL sichern ...<br />";

echo "Lade MySQL herunter ...<br />";
exec("mysqldump -u MEINDATENBANKBENUTZER -pMEINDATENBANKPASSWORT --add-drop-table MEINDATENBANKNAME >dump.sql");
echo "MySQL heruntergeladen.<br />";

echo "Erzeuge .gz-Datei ...<br />";
/* exec("gzip dump" . date('Ymd_g_i') . ".sql"); */
exec("gzip dump.sql");
echo ".gz-Datei erzeugt.<br />";

echo "Erzeuge .tar-Datei ...<br />";
/* exec("tar -cf mysql_db_backup_" . date('Ymd_g_i') . ".tar *.sql.gz"); */
exec("tar -cf dump.tar *.sql.gz");
echo ".tar-Datei erzeugt.<br />";

echo "Loesche .gz-Datei ...<br />";
/* unlink('dump.sql.gz'); */
echo ".gz-Datei geloescht.<br />";

echo "Ende.<br />";

?>

Morgen teste ich weiter. Ich wollte heute nur noch meinen aktuellen Stand melden.

Gruß, Anselm

[Anselm Rapp]

Jetzt habe ich festgestellt, dass die manuelle Sicherung mit mysqldump erfolgen kann, das Restore aber nicht über das Adminpanel erfolgen muss, sondern über phpMyAdmin möglich ist. Das entsprechende Skript sollte einfacher sein, aber ich muss das erst probieren. Zuerst mache ich mal eine Pause, sonst werden meine Augen rechteckig. Ich melde mich bei Bedarf wieder.

Gruß, Anselm

[Anselm Rapp]

Meine getestete Lösung:

PHP-Code:

<?php

$dbuser = 'MEINDATENBANKBENUTZER';
$dbpassword = 'MEINDATENBANKPASSWORT';
$dbname = 'MEINDATENBANKNAME';
$dumpfile = 'MEINDUMPFILENAME.sql'; /* mit Pfad */

echo "Sichere " . $dumpfile . " ...<br />";
exec("mysqldump --user=$dbuser --password=$dbpassword --add-drop-table  $dbname > $dumpfile");
echo "MySQL gesichert.<br />";

echo "Erzeuge .gz-Datei ...<br />";
exec("gzip -f $dumpfile"); /* Loescht Originaldatei; fuer Behalten Parameter -k */
echo ".gz-Datei erzeugt.<br />";

?>

Fertig sieht es ganz einfach aus. Datum und Uhrzeit im Dateinamen erzeuge ich lokal (muss ich noch programmieren, kann ich aber), damit das Dumpfile auf dem Server jeweils denselben Namen hat und überschrieben wird.

Anselm

[timo]

Hallo Anselm,

also jetzt doch ohne tar?

Eigentlich ist das bei einer einzelnen Datei ja auch sinnvoll (wie ich schon oben schrieb). Ich hatte es allerdings so verstanden, als bräuchte das Admintool dieses "gzip in tar"-Format, um die Sicherung importieren zu können.

Gruß,
Timo

[Anselm Rapp]

Hallo Timo,

also jetzt doch ohne tar?

Eigentlich ist das bei einer einzelnen Datei ja auch sinnvoll (wie ich schon oben schrieb). Ich hatte es allerdings so verstanden, als bräuchte das Admintool dieses "gzip in tar"-Format, um die Sicherung importieren zu können.

Man kann die Dumpfiles nicht nur mit dem Admintool, sondern auch mit MySQLAdmin importieren; das wusste ich anfangs nicht. Da habe ich erst mal die einfachere Methode gewählt. Tatsächlich musste ich noch nie eine MySQL-Dateri wiederherstellen, aber man weiß halt nicht.

Gruß, Anselm

[Anselm Rapp]

Hallo Timo,

ich hatte noch eine harte Nuss zu knacken. Obiges Skript funktionierte bei einem meiner Internetauftritte, bei zwei anderen bei denen ich MySQL verwende, nicht. Die Dump-Dateien wurden angelegt, waren aber leer (0 Bytes). Ich habe gesucht und gesucht und nichts gefunden. Sämtliche Konfigurationen und Bedingungen identisch. Schließlich fiel mir auf, dass bei einem der Internetauftritte eine zusätzliche Datei mit kryptischem Dateinamen angelegt wurde, ohne Typ (.sql, .php o. dgl.). Schließlich fiel mir auf, dass dieser Dateiname ein Teil des Passworts war. Dann war es nicht mehr schwierig. Das Passwort enthielt, bei der Eingabe vom Hoster-Adminpanel klaglos akzeptiert, das Umleitungszeichen (>). Das wurde, obwohl mitten im Passwort, auch als Umleitung interpretiert. Beim anderen Internetauftritt, wo das Skript ohne "Hinweis" nur streikte, war es einfach; das Passwort enthielt das Befehlsverkettungszeichen (&). Jemand anderes hätte mir da kaum helfen können, weil ich mit dem Skript nicht die Original-Passwörter, sondern nur Platzhalter gesandt hätte. "Bessere" Passwörter vergeben, und es lief, auch heute Nacht per Cronjob.

Mich freut es, wenn ich in meinen fortgeschrittenen Jahren noch solche Tüfteleien erfolgreich absolvieren kann. :-)

Gruß, Anselm

[timo]

Mich freut es, wenn ich in meinen fortgeschrittenen Jahren noch solche Tüfteleien erfolgreich absolvieren kann. :-)

Respekt, find' ich gut!

Hast Du eigentlich schon aus Deinem Berufsleben Erfahrung mit Unix-artigen Betriebssystemen, oder erst durch die Betreuung Deines Internet-Auftritts?

[Anselm Rapp]

Hast Du eigentlich schon aus Deinem Berufsleben Erfahrung mit Unix-artigen Betriebssystemen, oder erst durch die Betreuung Deines Internet-Auftritts?

Schon. Bei Siemens gab es das Unix-Derivat Sinix, an dem ich nicht vorbeikam, und auch mit dem BS2000 hatte ich zu tun. Aber am meisten habe ich mich mit MS-DOS und Windows – bei Siemens anfangs verlacht – befasst, denn da kamen Beruf und Hobby zusammen. Viele Ideen habe ich von daheim in die Firma eingebracht und mir damit Meriten erworben. Begeistert habe ich diese drei, nein, mit dem Siemens Bürosystem 5800, das kaum den Kinderschuhen entwachsen ist, vier Welten miteinander verbunden. LAN, WAN und Internet waren noch Zukunftsmusik, aber ich habe Wege gefunden, Daten hin und her zu transferieren. Als dann aus dem Siemens-DV-Bereich halb Siemens Nixdorf (SNI) wurde und wir auf "Synergie" (sprich: Personalabbau wegen Redundanzen) machen mussten, wurden Disketten und später CDs hin- und hergeschickt. Wen wundert's, dass ich die Paderborner Kollegen motivierte, mit Modems Dfü zu machen, was gemessen an heute langsam ging, aber viel schneller als per Post.

Mein erster privater Computer war der Commodore_VC 20. Meine ersten Internet-Erfahrungen habe ich gesammlt, als CompuServe erstmals die Erstellung privater Homepages ermöglichte. In meiner SNI-Umgebung war ich wohl der Einzige, der schon etwas über das Internet wusste und damit anfangen konnte. Beim Aufbau des Intranets unseres SNI-Bereichs habe ich dann Pionierarbeit geleistet.

Na ja, alte Herren schwärmen gerne von ihrer großartigen Vergangenheit. Es gab jedenfalls ein Leben nach UHER für mich, und kein schlechtes. Mein Herz hängt trotzdem an UHER.

Gruß, Anselm

[timo]

Ich verzweige mal, weiter hier.