Backup funktioniert einfach nicht

Posted: 2007-03-01, 11:16 Backup funktioniert einfach nicht

Moin moin,
also erst mal ich war ja schon mal hier und hab nach langer Zeit endlih geschafft den Dumper richtig in Gange zu bekommen.
Auf jeden Fall genau das gute Teil, welches ich suche.

Und ich hab auch seit Tagen versucht, hier in den Topics Hinweise auf das Nichtgelingen der Backups zu bekommen, ohne Erfolg.

Ich bin bei Allinkl. auf nem Server mit insgasamt 50 Kunden, also son Shared Server oder wie die das nennen.
Betrieben wird WBB 2.3.2, 102 Tabellen, Größe der DB: zur Zeit 60,4 MB!

Mein Problem:
Dumper installiert, Test erfelgreich. Very Happy

Backup php läuft durch und sendet die Datei auch an mein Homi, was ich auch will. Leider ist diese nicht zu gebaruchen, weil crc-Fehler in gepackter Datei. Der Ausgabe-Text:

Fertig!

Es wurden 102 Tabellen mit insgesamt 425.180 Datensätzen gesichert.

Datei v104527_2007_03_01_09_35.sql.gz (6.63 MB) wurde erfolgreich erstellt.
Die E-Mail wurde erfolgreich verschickt an `xxxxxx@xxxxxxxxxxx.xxx.xxx`
versende File via FTP... bitte habe etwas Geduld. (xxxxxxx.xxxxxxxxxx.xx - Name)
Verbunden mit xxxxxxxxx.xxxxxxxxxx.xx als Benutzer Name
Datei v104527_2007_03_01_09_35.sql.gz auf xxxxxxxx.xxxxxxxxx.xx geschrieben
file sent via FTP (v104527_2007_03_01_09_35.sql.gz => xxxxx.xxxxx.xx)

5 min. 0 sec, 2162 pages

So, Suppport Allinkl. durch die Zeitbegrenzung auf den Servern würde er das abbrechen und dadurch wäre eben der crc-Fehler.

Jetzt das Backup in Perl:
Da fängt er an macht etwa 5-10 Sek. und bricht sofort ab und zwar bestenfalls bei bb1_languages, das ist nicht mal bei der Hälfte der Tabellen.

Erklärung von Allinkl.: (ZITAT)
Das Problem ist einfach die Größe der Datenbank. Die Datenbank umfasst hier eine Größe von 60,4 MB. Das Sichern per Script dauert daher derartig lange dass der Server an seine Restriktionen in Bezug auf Arbetisspeicher (40MB) sowie Ausführbarzeit stößt. Shocked

Eine so große Datenbank ist realisv aussichtslios per Script zu sichern, hier sollten Sie von Zeit zu Zeit per externem Tool eine Sicherung ziehen.
Zitat Ende
....

Also ich hab die Speichergrenze ermittelt, die liegt bei 37748736 Bytes.
Des weiteren hab ich das Multipart-backup versucht, das geleiche Ergebniss. Mir gehen jetzt endgültig die Ideen aus.
Wenns nix hilft, werde ich auf jeden Fall den hoster wechseln, aber ich hoffe, ihr habt vielleicht noch paar Ideen, ich kann mir auch nich vorstellen, das ich alles richtig gemacht habe... Confused

Gruß
..::PiTBuLL::..

**MSD-God** Joined: 21 Mar 2006 Posts: 564

1)
Zu all-inkl gibts hier schon umfangreiches:
das grösste Problem ist das sehr niedrige Zeitlimit für perlscripte (ca 10 sek).
Ich persönlich hab eigentlich gute Erfahrungen - insbesondere mit dem Support und der Performance.
Also fällt Perl für Deine DB aus (nur der Vollständigkeit halber)

2) Wie stellst Du den crc Fehler in der gemailten Datei fest??
Sagt Deine Ent-/Packer Dir das? (dann ist er nicht aktuell)

Posted: 2007-03-01, 13:10 (No subject)

Hast Du das hier beachtet?
http://forum.mysqldumper.de/viewtopic.php?t=1471

Posted: 2007-03-01, 13:17 (No subject)

Warum meinst Du denn überhaupt, dass das Archiv CRC-Fehler hat?
Das wird oft geglaubt, liegt aber letztlich an einer nicht aktuellen Version des Entpackers.
Ich könnte wetten, dass die Datei in Ordnung ist und nur Dein Entpacker ein Problem mit dem GZ-Format hat. Das hatten wir hier schon häufig.
Nimm eine aktuelle WinRar-Version und entpacke es erneut.

Posted: 2007-03-02, 13:31 (No subject)

Halo und danke ers mal für die schnellen Antworten.
@ coolsoft:
Leider scheints du da echt Recht zu haben, Support am telefon usw. einfach super, da mecker ich auch nicht.
Servereinstellungen bei allinkl. das Gegenteil: 10 Sek ist ein Witz, weiß nicht warum die dann überhaupt den Dumper empfehlen, aber das nur nebenher, zu den 10 sek. kommen noch max. 40 MB abgegrenzter RAM für Scripte...
Und das Backup per php dauert über 5 min und läuft inkl. FTP-Versand durch *Grübel*

So der crc-fehler kam, nachdem ich das File per FTP gedownloaded hab!
"Fehler in gepackter Datei" oder so stand denn bei WinRAR.
Habe das File natürlich gelöscht....

@DSB:
Also ich hab den Dumper auch bei einem noch kleinen 2. Board am laufen, da funzt das ganze , besser kanns nicht gehen, selber hoster, nur ein Unteraccount, also dieselben Bedingungen.
Denn kommt die besagte Änderung für mich nicht in Frage.

Und der packer ist WinRAR 3.62, also sollte "recht" aktuell sein.

Übrigens habe ich das auch bei Dateien, die so auf den Server liegen, auch hier scheint das en Allinkl-Prob zu sein, habe ich jetzt festgestellt.

Fazit:
Ich werde mit denen telefonieren, mir stinkt es gewaltig, das man nicht mal ein DB vom 60 MB sichern kann. Hinzu kommt, das ich zB die Sicherung per php nicht zurückspielen kann, da kommt dann wieder dieser Fatal-Error 30 sek. grrrrrrrrrr!!!
Denn muß ich sagen, brauche ich die nicht und muß den hoster wechseln...

Wenn ich nach dem Telefonat was neues weiß, häng ich das mal an...

THX
..::PiTBuLL::..

Posted: 2007-03-03, 12:12 (No subject)

So, habe noch mal ausführlich mit Allinkl. gesprochen:

Tatsache ist wohl das folgende Begrenzungen auf den Shared Servern vorliegen:
1) Timeout für php-scripte 30 sec.
2) Timeout für Perl-scripte 10sec.
3) Arbeitsspeicherbegrenzung für Scriptausführungen 40 MB

Somit kann eine DB mit 60 MB oder mehr einfach nicht automatisch gesichert werden!
Wie das mit dem php-script ging vom dumper kann er sich nicht erklären, ich hätte da wohl unheimlich Glück gehabt etc.

Einzige Möglichkeit, ich müßte mir einen eigenen Server mieten, da geb es dann auch keine Begrenzung, da ich ja alleine da drauf wäre.
Der günstigste liegt bei 99,95 € monatl., was, da ich nicht Lotto King Karl bin, einfach zu teuer!!!

Posted: 2007-03-03, 12:22 (No subject)

Arbeitsspeicherbegrenzung und PHP-Timeout sind für den Dumper kein Problem.
Das berücksichtigt er problemlos.
Wenn Du ein Backup aus dem Web-Frontend startest (also per PHP), klappt das hervorragend.

Posted: 2007-03-05, 14:14 (No subject)

Ja, nur das problem ist ja ich kann ja nicht mal update zurückspielen, auch wegen der 30 sec. php Begrenzung,,,das ist echt zum Mäusemelken oder sowas!

Solange ich die Backups nicht zurückspielen kann weil php nur 30 Sek. macht bzw. das php-Backup auch zerstört ist weil nicht immer vollständig, bringt mir das ja leider nix, es scheint, die beste Lösung ist eben woanders ein Root-Server mieten, wo ich alleine drauf bin, schätze ich.

Allinkl. bot mir ein einmaliges Kopieren der Datenbank auf ne andere URL an, das haben die heute Nacht gemacht, und selbst das ist nicht fehlerfrei gelungen....

Gruß
..::PiTBuLL::..

Posted: 2007-03-05, 14:17 (No subject)

Posted: 2007-11-14, 20:33 (No subject)

So...großes Sorry für meine lange Abwesendheit -hatte viel familieren Schei.... die letzten Monate.

Also @ DSB - du hast völlig Recht, per Weboberfläche startet das Backup "php" und läuft ohne Probs durch !!

Meine Frage, wie kann ich das per Cron starten ( Befehl ), weil ich möchte es nach wie vor automatisch haben das ganze :=))

MfG
PiT

Posted: 2007-11-15, 00:09 (No subject)

Das PHP-Backup kann man nicht per Cron starten.
Das funktioniert nur mit dem Perl-Skript, welches aber bei Dir in einen Timeout rennt.