Datenbank Backup nicht vollständig

Posted: 2009-01-24, 20:00 (No subject)

@Bernd und Sven
Sprecht ihr vom Backup per PHP oder vom Backup per Perlskript?

Posted: 2009-01-24, 21:37 (No subject)

Bestätigt:

bei Nutzung des PHP-Backups und der Option Multidump werden die Daten der letzten Tabelle der Datenbank tatsächlich übersprungen. Per Perl funktioniert es ordnungsgemäß.

Da muss ich was tun....

Bugfix folgt.

**Donator** Age: 44 Joined: 23 Jan 2009 Posts: 5

Ja, PHP, ich habe bisher nur dies verwendet.

Danke schonmal!

MfG
Sven

**knows MySQLDumper** Age: 42 Joined: 05 Apr 2009 Posts: 9

ich habe das selbe problem (mit PHP backup)...

allerdings nutze ich kein multidump und es fehlt auch bei weitem nicht nur die letzte tabelle. das direktbackup ist knapp 90MB groß (plain/text), das von msd ist gerade einmal 14MB groß (plain/text). es wurden zwar alle tabellen korrekt erkannt, aber gesichert wurde gerade einmal die hälfte davon. es kam keinerlei hinweis, dass das script abgebrochen wird und auch im backup selbst steht nichts. statt dem abschließenden kommentar am tabellenende wurde nur eine leere letzte zeile erstellt, mehr nicht.

Posted: 2009-04-05, 21:19 (No subject)

Das glaube ich ehrlich gesagt nicht. Smile

Ich tippe eher darauf, dass Dein Entpacker nicht mit dem GZ-Format klarkommt und das Backup nicht richtig entpackt.

**knows MySQLDumper** Age: 42 Joined: 05 Apr 2009 Posts: 9

das darfst du mir ruhig glauben Wink

ich seh doch a) in msd schon wie groß das archiv ist, b) ist der download lokal ebenfalls nur 14MB groß und c) habe ich es sowohl unter xp mit 7zip als auch unter fedora mit bzip2 probiert. ergebnis bleibt das gleiche: inhalt ist eine 14MB große textdatei.

€
btw kann es auch nicht am speicherplatz liegen, auf dem FTP sind ~8GB frei und es gibt keine quotas...

€2
kurioserweise zeigt msd als report am ende des backups aber die korrekte tabellenanzahl an. gesichert wird aber wie schon geschrieben nicht einmal die hälfte der tabellen. zusätzlich werden sie während dem backups beim "fortschritt" aber durchlaufen!

**knows MySQLDumper** Age: 42 Joined: 05 Apr 2009 Posts: 9

so, nun habe ich die version 1.22 nebenher installiert, um das nachzuprüfen. die datenbank war während den backups von sämtlichen scripten getrennt.

die backups beider versionen sind quasi identisch und scheinen auch vollständig zu sein, die backups aus den ersten beiden versuchen mit v1.23 (db war live) sind aber tatsächlich unvollständig, wie oben geschrieben und wurden trotz erfolgsmeldung abgebrochen oder nicht vollständig abgespeichert - was evtl. auch erklären würde, warum die archive gleich groß sind (dateiheader)...?

das problem ist insofern also erledigt, da es nicht mehr auftritt und auch nicht mehr reproduzierbar ist - "fixed" Wink

eine frage habe ich aber dennoch: der direktexport via phpmyadmin ist mit 90MB deutlich kleiner als der von msd mit 140MB, was natürlich auch daran liegt, dass jeder datensatz die tabellenstruktur einzeln serviert bekommt. phpmyadmin exportiert die tabellenstuktur je tabelle nur einmal, direkt in den tabelleneigenschaften - wäre das nicht die einfachere und "sauberere" lösung, zumal auch deutlich weniger speicherplatzextensiv?

Posted: 2009-04-07, 07:57 (No subject)

**knows MySQLDumper** Age: 42 Joined: 05 Apr 2009 Posts: 9

mit den parametern habe ich selbst schon gespielt, aber danke für den link, wirklich ein gelungenes video. habe selten ein derart gut verständliches how-to gesehen! Smile

ok, verstehe. ich nehme an diese neue syntax bewirkt, dass man das backup ab einer beliebigen zeile aufrufen kann, nachdem es zuvor abgebrochen wurde, da man so die tabellenstruktur nicht schon im vorhinein kennen muss, oder?

habe jetzt eine ganze weile mit msd "herumgespielt" und mir fällt eigentlich nur ein kritikpunkt auf: die logs werden nicht config-bezogen gespeichert. beispiel: ich habe eine "user-config" und eine "cron-config". mit ersterer experimentiere ich oder ziehe manuell backups bei bedarf. die zweite config ist, wie der name bereits verrät, für einen cronjob gedacht und per se bereits relativ konservativ ausgelegt, was das "feintuning" anbelangt. dennoch würde ich natürlich gerne wissen, wenn das backup irgendwelche fehler aufwirft, nicht zuletzt weil meine backups nicht "anhalten", wie in der config einstellbar.
erstelle ich nun aber manuell ein backup via "user-config" via perl, werden die logs meiner cronjob-sicherung überschrieben und ich kann nichts mehr kontrollieren. hier wäre eventuell eine unterteilung a) in config-bezogene logs und unter umständen sogar b) eine aufteilung in config und manuell oder per cronjob aufgerufene backups sinnvoll. dies wäre aus sicht des anwenders zumindest sehr begrüßenswert Wink

Posted: 2009-04-08, 20:14 (No subject)

Du könntest die Größe des Logfiles einfach erhöhen, so dass es mehr Einträge aufnehmen kann. Eine Notwendigkeit jetzt auch noch die Logs nach Konfigurationsdateien zu splitten sehe ich nicht. Das Log kommt ja nur im Fehlerfall zum Einsatz. Sobald einmal alles korrekt eingerichtet ist, braucht man es eigentlich ja nicht mehr.

**knows MySQLDumper** Age: 42 Joined: 05 Apr 2009 Posts: 9

im log steht doch auch jeweils die erfolgsmeldung, "... finished". wenn ich nun aber das perl-backup manuell starte, werden alle vorherigen einträge überschrieben, im log steht also jeweils nur die ausgabe des letzten backups. oder seh ich das verkehrt?

apropos logs: ich stelle gerade fest, dass mein cronjob nicht die config nimmt, die ich vorgebe. laut beschreibung muss es ja mit "crondump.pl config=forenDB.conf" funktionieren, allerdings habe ich auch irgendwo die variante "crondump.pl -config=forenDB.conf" gesehen, ähnlich den startparametern unter windows...

Posted: 2009-04-09, 21:59 (No subject)

Posted: 2009-04-09, 22:10 (No subject)