Backup lässt sich nicht einspielen

Nobby

Nobby

Unwichtig
Hallo ihr da draussen,

aktuell habe ich ein Problem mit einem SQL-Backup einer Joomlaseite und dem SQL-Dumper.

System Debian 5 und ispCP, der Dumper ist korrekt installiert und eigentlich funktioniert auch alles so wie es soll.

Blöderweise bricht die Wiederherstellung des Backups immer ab, zwischen 60 und 68 Prozent. Das Backup selbst ist gerade mal knapp 21 MB gross.

Eingespielt werden soll es auf einem Stratoserver, seltsamerweise funktioniert das auf dem alten 1&1-Server völlig korrekt, sprich gleiche Joomlainstallation, gleiches Backup, blos der 1&1 war Suse 10.irgendwas und Plesk 9.3.

Irgendjemand Tips was das sein könnte, da ich vor einem Rätsel stehe und nicht weiterkomme!
Ich weiss auch leider nicht ob es an SQL selbst liegt, da es korrekt mit ispCP ohne Fehlermeldung installiert wurde, oder am Dumper.

Danke und Gruss Nobby
 
Versuchs mit dem mysqldumper, phpmyadmin (vorher in der php.ini von ispcp die max_execution, max upload, max post size etc erhöhen) oder am einfachsten per shell.



Grüße
 
Mit dem Dumper versuche ich es ja seit Stunden, und da bricht er halt immer ab/bis einer gewissen Prozentzahl ab.
Über phpMyAdmin habe ich es auch schon versucht, selbes Ergebnis, ausser dass damit gar keine Tabellen wiederhergestellt werden, der Dumper schafft immerhin 38 von 80 Tabellen. Und welche php.ini müsste ich nehmen? Die globale oder die, die ispCP beim anlegen einer Domain herstellt?

Über die Schell muss ich gestehen, weiss ich leider nicht wie das funktioniert.
In meinem schlauen Buch steht

Code: 
mysql -u root -p DATENBANKNAME < BACKUPNAME.sql.gz

Aber das haut nicht hin, ich weiss nicht wohin ich das Backup laden müsste, das steht clevererweise nicht darin:o
 
Nobby said:
Code: 
mysql -u root -p DATENBANKNAME < BACKUPNAME.sql.gz

Aber das haut nicht hin, ich weiss nicht wohin ich das Backup laden müsste, das steht clevererweise nicht darin:o
Click to expand...

Wie meinst Du das, "haut nicht hin"?
Lade Deinen SQL-Dump mal auf Deinen Server hoch, egal wohin.
Dann mal den Datenbank-Backup entpacken!
Und anschließend führst Du einfach o.g. Befehl aus. Ein SQL-Dump ist übrigens normalerweise Klartext (=SQL-Befehle), also schadet es auch nicht, da mal reinzuschauen und z.B. zu überprüfen, ob sich der Dump auf den richtigen Datenbanknamen bezieht. ;)

Achso: Im Zweifelsfall auch mal schauen, ob Dein Datenbank-User überhaupt "root" heißt. Wenn nicht, ggf. anpassen.
Und hinter den Parameter "-p" gehört eigentlich das Datenbank-Passwort (passend zum User) und dahinter erst der Datenbankname:

Code: 
gunzip BACKUPNAME.sql.gz
mysql -u root -p geheimesPasswort Datenbankname < BACKUPNAME.sql
 
Last edited by a moderator:
siradlib said:
Und hinter den Parameter "-p" gehört eigentlich das Datenbank-Passwort (passend zum User) und dahinter erst der Datenbankname
Click to expand...

Ist kein Passwort angegeben, fragt er nach. Das Passwort dort direkt anzugeben kann unter Umständen für die Sicherheit nachteilig sein. ;)
 
Wenn man es per Console versucht einzuspielen, kann es sein, dass es dir deine Sonderzeichen zerstört je nach codierung der Daten.

Ich würde lieber analysieren, warum er bei 60 - 68 % abbricht. Ich tippe hier auf php.ini Datei - max_execution_time zu niedrig oder Livetime des Prozesses.
 
IP-Projects.de said:
Wenn man es per Console versucht einzuspielen, kann es sein, dass es dir deine Sonderzeichen zerstört je nach codierung der Daten.
Click to expand...

Gibts das wirklich? Kannst Du dazu mal ein Beispiel nennen oder konstruieren?
Ich hatte nämlich per Kommandozeile noch nie Probleme- ganz im Gegensatz zum Einspielen per phpMyAdmin.

neugierige Grüße,
siradlib
 
Wir haben schon Datenbanken importiert, die Ich glaube ISO Codiert waren, ist schon ein paar Tage her, hier hat es dann nach dem Import über die Console die Umlaute zerschossen, warum auch immer. Per PHPMyAdmin hatte es problemlos funktioniert. Vielleicht hat der Kunde an dieser Stelle auch einen Fehler beim Export der Daten gemacht, das kann ich so leider nicht mehr nachvollziehen.
 
Sodele, mal eben kurz eine Rückmeldung:

die max_execution_time in der php.ini war tatsächlich schuld, dort stand ein Wert von 15, was, glaube ich, Sekunden sind. Nach etwas testen wie hoch der Wert sein muss bin ich bei 90 stehengeblieben und et vóila, das Backup lies sich tadellos einspielen;)

Ich habs jeweils einmal direkt über die Konsole und einmal über den Dumper versucht, beides ging und Umlautprobleme habe ich dadurch Gott sei Dank nicht bekommen!

Nochmals Danke für die Tipps, schon wieder etwas dazu gelernt:p

Gruss Nobby
 
siradlib said:
Gibts das wirklich? Kannst Du dazu mal ein Beispiel nennen oder konstruieren?
Click to expand...

Das ganze nennt sich eigentlich charset.
Der Character Set ist auschlagebend, was tatäschlich angezeigt wird, was in die DB kommt, was aus der DB kommt und was sich letzendlich im dump befindet.

Ja, das ist keine exostische Sache sondern sehr lästiges Thema eine z.B. latin1 utf8 charset Konvertierung.

Und min. 3 Sachen können einem dabei das Leben zu hölle machen.
Die lokale Zeichensatzeinstellung, die auf dem Zielsystem, und natürlich auch die "Anwednungen" wie Datenbank, Perl oder PHP usw..
 
You must log in or register to reply here.
Back
Top