Seite 2 von 2
Verfasst: 08.08.2004 22:16
von Dennis63
Dann mußt Du Dir nen besseren Hoster suchen.
Entweder Du hast ne "kleine" Datenbank und kommt mit Hostern aus, die keinen System() Befehl erlauben und machst Backups mit phpMyAdmin.
Oder Du hast ne "größere" Datenbank und suchst Dir nen gutne Hoster, der system() erlaubt.
Grüße
Dennis
Verfasst: 08.08.2004 22:37
von Alexey
BigDump kann man leider nicht so einfach "modifizieren", dass es statt Daten importiren, Datenexport macht. Beim Datenexport stellen sich ganz andere Fragen. Erstaunlicherweise kommt das Problem mit Datenexport viel seltener als das mit dem Datenimport. Liegt wohl in erster Linie an der max_upload Beschränkung und an der schlechten Performance der INSERTs bei MySQL.
Max:
Da gibt es zwar Scripte, aber die machen die Sicherung mit DROPTABLE und das funzt irgendwie nicht via BIGDUMP - warum auch immer.
IMHO sollte mit oder ohne DROP TABLEs für BigDump egal sein. Was definitiv nicht geht, sind nur die erweiterten INSERTs. Beschreib mir bitte dieses Problem bei Gelegenheit etwas ausführlicher. Ich versuche dann, soweit möglich das Bigdump-Script entsprechend zu verbessern.
LG Alexey
--
http://www.ozerov.de/bigdump
Verfasst: 09.08.2004 12:44
von Gumfuzi
Hi Alexey!
Ich werde das mal ohne den erweiterten Inserts testen, ist ja dann auch kleiner die Datei - oder?
Daß das mit dem Export nicht so leicht funzt, hatte ich nicht gewusst, dachte, daß es ähnlich sein müsste *schäm*
Naja, wir haben nun einen Hoster, der hat Confixx Pro und da funzt das Backup dort super per Confixx!
Naja, ich melde mich, falls es wieder aktuell ist - danke!
Verfasst: 09.08.2004 12:49
von Max
Hallo,
mit diesem Script habe ich einen DB-Dump erstellt:
Code: Alles auswählen
<?php
// Bitte hier Ihre Daten eintragen
$host= 'localhost';
$user= 'USER';
$pass= 'mein_PW';
$db= 'DB-NAME';
// Befehl ausführen und in Zipfile speichern
system(sprintf(
'mysqldump --opt -h %s -u %s -p%s %s | gzip > /www/htdocs/ordner/back/dump.sql.gz',
$host,
$user,
$pass,
$db,
getenv('/www/htdocs/ordner/2.ordner/')
));
echo '+DONE';
?>
das geht megaschnell und ist alles i.O. wenn ich dann das entstandene ZIP-File herunterlade und auf den anderen Server hochlade, kann ich das zwar via BIGDUMP in dem Ordner finden, aber nicht in die DB einfügen, DB war neu und leer, lediglich die DROPTABLE waren in dem DUMP enthalten, es kam nämlich die Fehlermeldung (sinngemäß) dass DROPTABLE nicht ausführbar ist, also habe ich per phpMyAdmin einen Dump OHNE Droptable erstellt und damit war das kein Problem, den mit BIGDUMP einzuspielen.
Meine Reaktion ist ganz einfach, da BigDump ideal ist, sichere ich die DB jetzt immer ohne DropTable und das ist ok für mich. Schöne wäre natürlich, wenn BigDump das könnte.
Vielleicht liegt es ja auch am Hoster? Es ist allincl.com
Gruß,
Max
Verfasst: 09.08.2004 13:12
von musashi
Auch ein sehr gutes Tool ist Bigdump von Richsoft.
Verfasst: 09.08.2004 13:23
von fido
musashi hat geschrieben:Auch ein sehr gutes Tool ist Bigdump von Richsoft.
Welchen Richsoft? Google bietet da einige an. Bigdump hab ich dabei nicht gefunden. Kannst du den Link mal bitte posten?
Verfasst: 09.08.2004 13:26
von musashi
Sorry, meinte Dumptimer ...
Verfasst: 09.08.2004 17:48
von Gumfuzi
Max hat geschrieben:das geht megaschnell und ist alles i.O. wenn ich dann das entstandene ZIP-File herunterlade und auf den anderen Server hochlade, kann ich das zwar via BIGDUMP in dem Ordner finden, aber nicht in die DB einfügen, DB war neu und leer, lediglich die DROPTABLE waren in dem DUMP enthalten, es kam nämlich die Fehlermeldung (sinngemäß) dass DROPTABLE nicht ausführbar ist, also habe ich per phpMyAdmin einen Dump OHNE Droptable erstellt und damit war das kein Problem, den mit BIGDUMP einzuspielen.
Gruß,
Max
Wenn Du es auf einem anderen Server einspielen willst, dann musst Du im Dump ev. den "USE"-Befehl umändern, sodaß er die neue DB fürs einfügen nimmt (hat bei mir geholfen) - außerdem musste ich bei manchen Anbietern die Infoteste aus dem Dump rausnehmen (die mit "--" beginnen.
(sind nur meine Erfahrungen, nicht schlagen, falls es bei Dir nicht funzt)

Verfasst: 09.08.2004 18:45
von Alexey
Ja, mysqldump produziert Kommentare, die nicht dem
mySQL Standard entsprechen und mit drei Minuszeichen --- anfangen. Um diese Zeilen rauszufiltern muss man im Bigdump Script diese Zeile aktivieren:
Code: Alles auswählen
// $comment[2]="---"; // Uncomment this line if using proprietary dump created by mysqldump
Dazu die ersten beiden Schrägstriche löschen. Man könnte dies vielleicht standardmäßig so einstellen, das wäre jedoch inkorrekt, da nach mySQL Standard dürfen die Kommentarzeilen
so nicht anfangen.
Das Problem mit dem DROP TABLE kann ich leider noch nicht nachvollziehen.

Da bräuchte ich die genaue Fehlermeldung und ein Dump-Beispiel. Ich mache meine Dumps zwar immer noch mit phpMyAdmin und immer mit DROP TABLEs, und es ist bisher alles ok. Wenn also jemandem was Ähnliches wieder passiert, bitte melden!
Wenn der Dump
enthält, muss man das natürlich erst auf den neuen Datenbanknamen anpassen. Bigdump könnte das machen, das wäre allerdings Willkür, denn evtl. will der Benutzer wirklich gleichzeitig mehrere Datenbanken rücksichern. Da müssen sie natürlich erst (mit den gleichen Namen wie vorher) angelegt werden.
Max:
Wenn system('mysqldump ...') auf deinem System funktioniert, kann man damit ja auch die größere Datenbank (mit den entsprechenden Optionen in der Kommandozeile) wieder einspielen oder geht das wegen Timeout nicht?
--
http://www.ozerov.de/bigdump
Verfasst: 09.08.2004 20:14
von Max
Hallo,
das war nur ein einmaliges Problem, als ich einen Serverumzug gemacht habe.
Die Fehlermeldung habe ich mir nicht gemerkt und es ist auch schon 2 Monate her.
Wie gesagt, es war ja nicht schlimm, ich brauchte ja nur die DB per phpMyAdmin zu sichern und habe es dann ohne Probleme einspielen können.
Das mit dem oben genannten Script hat so nicht funktioniert - leider, weil das am bequemsten gewesen wäre.
Es war aber alles andere als ein Beinbruch. Für die Zukunft muss ich mir mal die Tipps merken, weil ich in ca 4 Wochen mit einer ca. 35mb-DB umziehen werde. aber auch da ist es nicht wirklich wichtig, wenn ich die gleich so sichere.
Vielleicht werde ich aber zuerst einmal genau den Fehler provozieren, um ihn dann hier zu posten.
Gruß,
Max