Problem mit FullBackup

Hallo zusammen,

bei mir macht die FullBackup Erweiterung Probleme:

Zunächst bekomme ich seit langer Zeit den Status "Läuft gerade" angezeigt. So lange, dass ich sicher sein kann, dass es hängen geblieben ist.

Also habe ich das tmp-Verzeichnis von FullBackup geleert und es manuell angestoßen.

Dann hagelt es Seitenweise Fehlermeldungen folgeder Art:

Zitat:

---

Warning: mysql_real_escape_string() [function.mysql-real-escape-string]: Can't connect to local MySQL server through socket '/tmp/mysqld.sock' (2) in /homepages/12/d113424971/htdocs/contao-2.10.0/system/modules/FullBackup/FullBackup_DB.php on line 536
#0 [internal function]: __error(2, 'mysql_real_esca...', '/homepages/12/d...', 536, Array)
#1 /homepages/12/d113424971/htdocs/contao-2.10.0/system/modules/FullBackup/FullBackup_DB.php(536): mysql_real_escape_string('1')
#2 /homepages/12/d113424971/htdocs/contao-2.10.0/system/modules/FullBackup/FullBackup_DB.php(95): FullBackup_DB->createDataSql('tl_article', 1326356881)
#3 /homepages/12/d113424971/htdocs/contao-2.10.0/system/modules/FullBackup/FullBackup.php(435): FullBackup_DB->extractUntil(1326356881, 'data')
#4 /homepages/12/d113424971/htdocs/contao-2.10.0/system/modules/FullBackup/FullBackup.php(100): FullBackup->nextStep(3)
#5 /homepages/12/d113424971/htdocs/contao-2.10.0/system/modules/FullBackup/FullBackup_Batch.php(90): FullBackup->heartbeat()
#6 /homepages/12/d113424971/htdocs/contao-2.10.0/system/drivers/DC_Table.php(200): FullBackup_Batch->keepAlive(Object(DC_Table))
#7 /homepages/12/d113424971/htdocs/contao-2.10.0/system/modules/backend/Backend.php(210): DC_Table->__construct('tl_fullbackup')
#8 /homepages/12/d113424971/htdocs/contao-2.10.0/contao/main.php(101): Backend->getBackendModule('FullBackup')
#9 /homepages/12/d113424971/htdocs/contao-2.10.0/contao/main.php(286): Main->run()
#10 {main}

---

Da ich dieses Problem unabhängig bei zwei verschiedenen Providern habe, gehe ich davon aus, dass es kein temporäres Serverproblem ist.

Natürlich habe ich schon einiges probiert: Neuinstallation von Fullbackup, Update von Fullbackup und Contao.
Leider erfolglos.

Weiß jemand Rat?

Gruß

Martin

hallo martin,

also: "Can't connect to local MySQL server through socket" ist ziemlich eindeutig ein datenbank-problem...

aber ich geh mal davon aus, dass contao läuft und daher die datenbank-verbindung eigentlich ok sein sollte. manche server benutzen für die funktion (mysql_real_escape_string) anscheinend die default daten, die hier natürlich nicht funktionieren...

also, es gibt 2 möglichkeiten, das zu reparieren:
1) benutze: mysql_escape_string statt mysql_real_escape_string (kommt nur einmal vor in dem modul). das ist aber nicht 100% sicher gegen SQL injection angriffe!
2) vor dem funktionsaufruf (mysql_real_escape_string) eben mysql_connect() aufrufen, um sicherzustellen, dass die richtige verbindung benutzt wird. das ist aber unelegant, weil du dann die db-daten, also server/user/password nochmal an der stelle hardkodieren musst...

hilft dir das weiter?

Hallo baumstark,

zunächst einmal danke für die Antwort.

Am Quellcode rumzuspielen hebe ich mir mal noch auf, erst recht wenn dadurch Sicherheitslücken entstehen...

Was mich wundert: Es hat ja in diesen beiden Installation bereits einige Zeit funktioniert.

Also muss sich doch irgendwas geändert haben. Dass es an der Konfiguration des Servers liegt (neue PHP Version oder so was) glaube ich nicht, da ich das Problem bei zwei verschiedenen Providern habe.

OK ich habe vor einiger Zeit Contao aktualisiert von 2.10.13 auf 2.10.14. Aber: In einer dritten Installation habe ich es mit 2.10.14 erfolgreich am laufen! Also ist Fullbackup doch prinzipiell contao 2.10.14 tauglich.
Vor allem: Diese (noch) funktionierende dritte Installation ist beim selben Provider wie eine der beiden anderen, die Probleme machen.

Hängen geblieben ist es schon mal - normalerweise leere ich das tmp Verzeichnis und gut ist es.
Nun bekomme ich aber trotz geleertem tmp Verzeichnis ein Häkchen in "läuft gerade", wenn ich dann trotzden "jetzt sichern" wähle, dann erhalte ich nach der Weiterleitung die besagten Fehler.

Zitat:

---

Zitat von baumstark

also: "Can't connect to local MySQL server through socket" ist ziemlich eindeutig ein datenbank-problem...

aber ich geh mal davon aus, dass contao läuft und daher die datenbank-verbindung eigentlich ok sein sollte.

---

Ja, alles andere läuft einwandfrei.

Hat noch jemand eine Idee oder gar das selbe Problem?

Viele Grüße

Martin

hallo martin,

das ist allerdings sehr seltsam, dass es bei verschiedenen providern der fall ist...

das kann aber durchaus sein, soweit ich weiss greift die php-funktion mysql_real_escape_string auf die einstellung in der php.ini zurück und dann in der my.cnf falls keine verbindung zur datenbank verfügbar ist. viele provider bieten ja die möglichkeit an, eigene php.ini dateien zu verwenden. vielleicht ist die ja vorhanden und die funktion denkt deswegen, sie müsse die verwenden? ist jetzt aber nur geraten ;-)

es hat aber definitiv nix mit der contao version o.ä. zu tun, ist mehr eine ebene 'tiefer'...

und die 2. lösung (vor dem funktionsaufruf (mysql_real_escape_string) eben mysql_connect() aufrufen, um sicherzustellen, dass die richtige verbindung benutzt wird) ist auch sicher, nur halt unelegant...

Hallo baumstark,

danke für die Antwort.

Ich habe jedenfalls nichts besonderes konfiguriert oder irgendwelche *ini editiert. Schon gar nicht nach der Installation und anfangs lief es ja.
Die Provider sind Strato und 1und1, da muss man eh nicht viel konfigurieren.

Könnte es etwas mit dem Datum zu tun haben?
Die beiden Installationen, die jetzt defekt sind, habe ich letztes Jahr installiert und da liefen sie auch noch. Die dritte, die jetzt noch funktioniert habe ich erst dieses Jahr installiert - sie hat also noch keinen Jahreswechsel mitgemacht.

Vermutlich ist das Quatsch, aber man lässt ja nichts unversucht...


Noch was: Wie kommt es, dass "läuft gerade" markiert ist, obwohl das tmp Verzeichnis geleert ist?
Hat das auch mit dem nicht funktionierenden "mysql_real_escape_string" zu tun?

Gruß

Martin

"läuft gerade" ist ein feld in der datenbank, das müsstest du auf 0 setzen, wenn es dich stört...

das mit dem datum kann eigentlich nicht sein, soweit ich weiss hat mysql_real_escape_string nix mit dem datum zu tun. theoretisch kann es natürlich sein, dass 1und1 oder strato zum jahresende was umgestellt haben, aber ich hab fullbackup mehrfach auf beiden anbietern laufen, soweit ich weiss ohne probleme...

hi martin,

ich hab nun in der letzten version mysql_real_escape_string durch addcslashes ersetzt. kannst ja mal testen, ob es nun bei dir läuft.

gruss

Hallo,

ich habe leider ein kleines Problem mit der Erweiterung FullBackup. So wie ich es verstanden habe wird immer wieder eine kleine Datei Namens lock.txt erstellt, die nach kurzer Zeit wieder verschwindet und das Backup weiter läuft. Das macht sie auch brav bis zu einem bestimmten Zeitpunkt. Dann bleibt sie einfach da und das Backup läuft nicht weiter. Habe schon deinstalliert und neu installiert, leider das gleiche. Wie kann ich denn herausfinden, warum das Backup nicht richtig läuft? So wie es mir scheint, werden immer die gleiche Anzahl von Dateien gesichert und dann hängt es. Wo finde ich denn die Datei mit der er nicht klar kommt?

Vielen Dank und viele Grüße

hallo erdpferd,

versuch doch mal den debug-modus und dann manuell mit 'jetzt sichern' laufen lassen.

in der config.php gibt es eine variable, die du dafür auf TRUE setzen musst, dann bekommst du viel mehr feedback. ich tippe mal, dass irgendwann ein limit erreicht von deinem host erreicht ist, meist ist es ein memory-limit, dann muss man die datei kleiner halten, o.ä.

Hallo,

ich habe es mal ausprobiert. Wenn ich den Debugmodus einschalte, dann wird mir eine Menge auf dem Bildschirm angezeigt. Was alles gesichert wurde, dann die Timeouts und die Weideleitungen. Das läuft eine ganze Weile, bis der Bildschirm einfach weiß bleibt. Auch das Einschalten der Fehlermeldungen hilft nichts. Nur ein weißer Bildschirm. Das passiert in etwa immer, wenn 530 von den Rund 9800 Dateien gespeichert sind. Die Datenbank läuft also durch und bei den Dateien setzt es aus.

Ich habe auch versucht, die zip-Dateien klein zu halten und zu spliten. Das gleiche Ergebnis. In der Log-Datei finde ich folgende Meldungen:

[15-Jun-2012 08:44:48] PHP Fatal error: Uncaught exception 'Exception' with message 'not chmoddable: /www/htdocs/.../system/modules/FullBackup/tmp/' thrown in /www/htdocs/.../system/modules/FullBackup/FullBackup.php on line 290

und

[17-Jun-2012 17:52:09] PHP Warning: filesize() [<a href='function.filesize'>function.filesize</a>]: stat failed for /www/htdocs/.../system/modules/FullBackup/tmp/FullBackup.zip in /www/htdocs/.../system/modules/FullBackup/FullBackup.php on line 460

Wegen der zweiten Meldung habe ich die zip-Dateien auf 50MB verkleinert und gesplitet. Jetzt hält es wieder an der gleichen Stelle. Diesmal keine Fehlermeldung.

Es ist zum Verzweifeln. Kann es an all-inkl liegen?

bevor ich länger antworte: du hast aber schon die Provider-spezifischen Einstellungen gelesen und angewendet für all-inkl, oder?
zu finden hier: http://www.contao.org/de/configuring...ve-server.html

gruss

Alles was dort steht ist, dass "AddHandler php-fastcgi .php" in Verbindung mit dem Safe-Hack Mode schneller ist. Den Safe-Hack Mode muss ich laut contao-check.php nicht verwenden. Die Zeile in der htaccess führt auch zu einem Totalausfall der Seite. Wenn ich mir die php-info anschaue, dann sagt diese zudem "Server API: CGI/FastCGI".

Mir scheint also alles nach den Vorgaben eingestellt. Die Seite und alle anderen Erweiterungen laufen auch tadellos. Oder verstehe ich hier etwas falsch?

hmm, nö, dann scheint das so ok zu sein, wollte nur sichergehen ;-)

dann würde ich evtl. auf ein paar sehr grosse dateien tippen, vielleicht ein paar sehr grosse videos?

also wenn du es wirklich wissen, bzw. zum laufen bringen willst oder musst, müsstest du wahrscheinlich den ordner oder die dateien finden, die 'schuld' sind.

also ich würd's dann wahrscheinlich so machen (auf einem testserver, wenn irgendwie möglich, versteht sich):

1. erstmal nur die DB sichern, nur um 100% sicher zu sein, dass die ok ist.
2. dann nur die dateien sichern, erstmal alle. das müsste dann ja hängen.
3. dann mit dem 50/50 verfahren den ordner finden, der das problem verurscht. also die erste hälfte der ordner markieren und laufen lassen. wenn das funktioniert, die andere hälfte. bei absturz dann die hälfte davon markieren und so weiter und so weiter. so kann man eigentlich (relativ) schnell das problem lokalisieren...
4. falls 1-3 problemlos durchlaufen, könnte es noch sein, dass eben erst die kombination von dem allen (db + alle dateien) zu einem memory limit error führen, dann kannst du es auf diesem server für diese website wohl eher nicht benutzen.

sorry, dass das so nervig ist, aber die beiden fehlermeldungen, die du gepostet hast sind eigentlich was anderes (die erste ist ein rechteproblem, die zweite scheint eine datei zu sein, die nicht da ist, was allerdings auch komisch ist, weil das fang ich immer ab...)

ich hoffe, das hilft dir ein wenig?

gruss

Hallo baumstark,

danke für deine Tipps. Eigentlich ja eine logische Fehlereingrenzung. Das Problem scheint mir zu sein, dass die zip-Dateien nicht zerteilt werden. Oder passiert das durch den Debugmodus sowieso nicht? Ich habe eine Grenze von 50.000.000 eingestellt,w as ja 50 MB entspricht. Die Zip-Dateiist aber schon über 200 MB groß, wenn er abbricht.

Woran kann das liegen?

Bei einer anderen (kleinen) Instalation bei einem anderen Hoster läuft es einwandfrei. Dort kommt die Zerteilung in einzelne Zip-Dateien aber auch nicht zum Einsatz.

oh ja, 200 MB im arbeitsspeicher ist für wohl fast jeden host zu viel...

vielleicht kannst du, nur um sicher zu gehen, mal eine kleinere grösse versuchen, 1MB zum beispiel. weil wenn das nicht funktioniert, wäre es definitiv ein bug, den ich gerne weiter untersuchen würde...

Ich habe es jetzt mal mit der DAteigröße von 1000000 versucht. Das müsste doch 1MB entsprechen.

Ich hatte zunächst nur einen Teil der Datein laufen lassen, da hat es funktioniert, sobald ich aber alle Einbeziehe, bricht er ab. Es wird eine Zip-Datei im backups-Ordner hinterlegt, die eine Größe von 262806817 Bytes hat. Die zweite im Temp-Ordner liegt bei 14137158 Bytes. Er bricht gerne direkt nach dem erstellen einer Zip-Datei ab.

Falls noch mehr Infos nötig sind, kann ich schauen was ich machen kann.

Viele Grüße

das hört sich schwer danach an, dass irgendwo eine riesen-datei dabei ist, vielleicht ein film oder ein ordner mit vielen grossen filmen?

Ich hab den Server jetzt mal nach großen Dateien durchforstet. Die größten haben so um die 12MB. Wenn ich alles in kleinen Häppchen auswähle, dann läuft es auch durch. Nur im Gesamten oder in größeren Brocken läuft es nicht. Es gibt insgesamt zwei Ordner mit vielen Dateien. System und tl_files. Beide zusammen scheinen sich aufzuhängen.

Es bleibt bei allen Tests aber dabei, dass das Beackup nicht in mehrere Dateien gesplitet wird. Sollte das eigentlich während des Backups oder erst ganz am Ende passieren?

Trotz meiner Angabe der zip-Größe von 1000000 werden die Resultate am Ende locker bis zu 64MB groß.

ja, das ist dann leider ziemlich eindeutig ein bug ;-(

genau für solche fälle hab ich die funktion ja geschrieben, damit beim backup eben keine riesigen .zip dateien entstehen...

ist denn irgendwas ungewöhnlich oder anders bei diesem host, vielleicht anderer server, windows, kein apache, oder ähnliches?

Ich habe jetzt nochmal an den Einstellungen probiert und die Anzahl der Dateien,d ie gleichzeitig verwendet werden auf 25 runtergesetzt. Die Dateigröße bei 500000. Er teilt auch brac eine zip-Datei ab, die rund 76MB hat und kommt direkt danach aus dem Tritt. Die Zip im Temp-Ordner bleibt bei 35MB stehen.

Der Hoster ist all-inkl. Was den Server angeht, denke ich nicht, dass es dort irgendwelche Merkwürdigkeiten gibt.

stimmt, all-inkl, hattest du ja auch schonmal erwähnt.

der sollte eigentlich gar nicht bis 75MB kommen, wenn du 50 eingestellt hast...

hmm, bei diesen blöden timeouts tappt man immer ziemlich im dunkeln, weil ja auch keine fehlermeldung ausgegeben wird und ich kann ja auch schlecht eine kopie der ganzen site von dir anfragen...

ich kuck nochmal wie die datei grösse ermittelt wird und vielleicht kann ich dir ein kleines test script schicken, o.ä. aber ich weiss nicht ob ich da heute noch zu komme...

Vielen Dank.

Stress dich nicht. Auf einen Tag mehr oder wneiger kommt es bei dem Projekt nicht an.

hallo erdpferd,

so, dann müssen wir wohl mal ein wenig in den code tauchen. als erstes würde ich das folgende mal in einer kleinen test.php auf dem server laufen lassen, also einfach neue datei, die zeile reinkopieren und im browser aufrufen, da sollte dann "49" stehen, oder ähnliches:

PHP-Code:

---

<?php echo filesize($_SERVER['SCRIPT_FILENAME']);

---

wenn das funktionieren sollte, musst du dir die zeile 460 in der datei FullBackup.php ansehen, ist eigentlich super easy:

PHP-Code:

---

if (filesize($old_zip_path) >= $max_size) { 


---

also wenn oben in der testdatei die funktion filesize läuft, dann gibt es ja eigentlich nicht mehr viele möglichkeiten, versuch dann mal bitte vor dieser zeile die folgenden sachen bei einem laufenden backup (natürlich alles nicht auf einem produktiv-system):

1. die(var_dump($old_zip_path));
2. die(var_dump($max_size));
3. die(var_dump(filesize($old_zip_path)));
4. die(var_dump(filesize($old_zip_path) >= $max_size));

einer davon müsste dann einen komischen wert ausgeben...

gruss

Da bei mir die Backups auch wesentlich größer werden (153 MB) habe ich

im php folgendes abgefragt. (unten die echo's, oben ist dein Quellcode)

PHP-Code:

---

                //check if max size has been reached
                $max_size = $this->getMaxSize($backup_id);
                $max_old_zips = $this->getMaxOldZips($backup_id);

                if ($max_size > 0) {
                    $old_zip_path =
                            TL_ROOT
                            . '/'
                            . $GLOBALS['TL_CONFIG']['fullbackup_tmp_path']
                            . $GLOBALS['TL_CONFIG']['fullbackup_archive_name']
                            . '.zip';
                    if (filesize($old_zip_path) >= $max_size) {
                        $email_address = $this->getEmail($backup_id);
                        $fb_files = new FullBackup_Files;
                        $attach_path = $fb_files->moveToDownloadFolder($backup_id);

                        if ($this->useEmail($backup_id)) {
                            $obj_msg = new FullBackup_Msg();
                            $obj_msg->mailOutDownloadlink($email_address, $attach_path, $max_old_zips);
                        }

                    }
                }
                Echo 'Ausgabe --> ';
                Echo 'old_zip_path --> ',(var_dump($old_zip_path)),' <-- ';
                Echo 'MaxSize --> '  ,(var_dump($max_size)),' <-- ';
                Echo 'old_zip_path filesize --> ' ,(var_dump(filesize($old_zip_path))),' <-- ';
                echo ' Ende'; 


---

als Ergebnis im laufenden Backup habe ich folgemdes erhalten

Ausgabe --> old_zip_path --> NULL <-- MaxSize --> string(1) "0" <-- old_zip_path filesize --> bool(false) <-- Ende

Mit der Ausgabe mache ich sicher doch etwas falsch.

hallo fips0705,

bei dir auch? ohoh, das hört sich nicht gut an...

also bei dir scheint es ganz einfach zu sein, die $max_size ist 0 (null), also teilt er die zip dateien gar nicht erst auf. wenn du dir sicher bist, dass du in dem feld maximale dateigrösse etwas eingetragen hast, dann lass doch bitte mal die backup id ausgeben ($backup_id), wenn die tatsächlich mit der id des backups übereinstimmt, dann ist das definitiv ein bug.

danke schonmal

hallo baumstark,
mit der id hat sich geklärt,
siehe ausgabe.

Ausgabe --> old_zip_path --> string(53) "/var/www/system/modules/FullBackup/tmp/FullBackup.zip" <-- MaxSize --> string(8) "10000000" <-- old_zip_path filesize --> bool(false) <-- Backup_id --> 2 Ende

jetzt ist max-größe 10mb eingestellt, das ergebnis sind aber 6 Dateien mit unterschiedlicher größe (siehe bild). weiterhin bekomme ich 6 mails über das backup, dies ist sicher auch richtig. bei maximale anzahl alter zip dateien (5) würden ja etliche fehlen, einstellung auf 10 mb und gesamtgröße ca. 150 mb.

habe ich hier einen denkfehler?

vielen dank

hi fips,

ja, die maximale anzahl der dateien sollte schon grösser sein als die anzahl der backup-teile, sonst werden welche gelöscht.

und die maximale dateigrösse ist immer nur so ungefähr, ich kann ja schlecht dateien mitten durchschneiden. aber dass die soweit drübergehen ist schon komisch, vielleicht kommen 10MB raus, wenn du 5MB einträgst?

aber sonst sind alle dateien drin?

ps: bei so grossen backups würde ich auch eher inkrementelle machen...

hi baumstark,
ich habe testhalber jetzt 5mb eingestellt. als ergebnis gab es wieder 6 dateien mit einer gesamtgröße von ca. 167 mb. (siehe bild).

bei der gesamtgröße gehe ich davon aus, dass alle dateien vorhanden sind.
allerdings gibt es auch die Fehlermeldung im log
PHP Warning: filesize() [<a href='function.filesize'>function.filesize</a>]: stat failed for /var/www/system/modules/FullBackup/tmp/FullBackup.zip in /var/www/system/modules/FullBackup/FullBackup.php on line 461

die würde auch die unterschiedliche dateigröße begründen, oder?

installiert habe ich
PHP Version 5.2.10-2ubuntu6.10

noch eine sache, der upload auf einen ftp

im log steht
[03-Jul-2012 15:06:12] PHP Warning: Cannot modify header information - headers already sent by (output started at /var/www/system/modules/FullBackup/FullBackup_Msg.php:132) in /var/www/system/modules/FullBackup/FullBackup.php on line 535

ich habe extra zum test nur die db als sicherung genommen (ca. 1 MB).
was sehr komisch ist, die zip wird korekt auf den ftp übertragen, aber das fullbackup wird nicht fertig. es beginnt immer wieder von vorne, ich habe jetzt schon 10x bestätigungsmails über das hochladen und das sichern.

auf dem ftp wir die datei immer wieder überschrieben, (03.07.2012_1341320225_437f9e0d9b679d327a3021a7a52 f875358e54f60_FullBackup_2.zip) und im verzeichnis,
/var/www/system/modules/FullBackup/backups liegen jetzt schon 16 dateien. habe alle etwa die gleiche größe.
das verzeichnis /var/www/system/modules/FullBackup/ftp ist leer.

irgendwie bekommt er keine meldung, das er eigntlich fertig ist.

wow! was machst du denn da alles???

also beim testen oder debuggen sollte man isolieren, nicht so viel wie möglich auf einmal machen ;-)

also ich würde folgendes versuchen:

1. FullBackup deinstallieren und die dazugehörigen ordner löschen / leeren. auch kurz kucken ob die db-tabelle leer ist.
2. dann mal kucken wie gross die webroot eigentlich ist. also wenn du alles markierst und dann zippst, kommt da auch ca. 170MB raus?
3. dann FullBackup neu installieren und nur die maximale dateigrösse testen, am besten auch nur dateien, ohne die db und ohne ftp oder sonst irgendeinen geänderten wert (höchstens den debug_modus in der config.php).

du hast jetzt soviele sachen / fehler gleichzeitig laufen, dass du (oder ich zumindest ;-)) völlig den überblick verloren hast...

gruss

Moin,

ich hab jetzt mal die Testausgaben erzeugen lassen:

die(var_dump($old_zip_path)); --> string(75) ".../system/modules/FullBackup/tmp/FullBackup.zip" (der Pfad ist richtig)

die(var_dump($max_size)); --> string(7) "5000000"

die(var_dump(filesize($old_zip_path))); --> int(115315634)

die(var_dump(filesize($old_zip_path) >= $max_size)); --> bool(true)

Wie es mir scheint, sind alle Ausgaben korrekt. Mit den Zahlen auf dem Server stimmen sie überein. Es ist aber deutlich zu erkennen, dass die Old-Zip deutlich größer ist als die $max_size. Um aber in die Zeile 460 zu gelangen (und das Skript dort zu unterbrechen), muss zuvor die Abfrage

PHP-Code:

---

 if (time() < $end_time) 
{
                $this->finish($backup_id);
} else
{... 


---

in Zeile 446 in den else-Zweig geraten. Kann hier eventuell ein Fehler sein? So dass das Backup an die Aufteilung erst viel zu spät kommt und die Datei an dieser Stelle schon zu groß ist und den Serverspeicher sprengt? Das merkwürdige ist ja, dass jedes mal unterschiedlich viele Dateien in der Zip landen, also nicht immer an der gleichen Datei abgebrochen wird. Ich schließe daraus, dass es nicht an den Dateien liegen kann (zumal sie in Häppchen auch durchlaufen).

Viele Grüße

moin erdpferd,

na, das ist ja mal eine schwierige nuss ;-)

also, die werte sind alle richtig und der vergleich greift ja auch. du könntest schon recht haben, dass das aufteilen 'zu spät' erfolgt und die dateien dadurch so gross werden. das hiesse aber, dass der server sehr sehr schnell ist, mit anderen worten: innerhalb der laufzeit von drei sekunden werden ca 50MB gepackt und das wär schon verdammt schnell! besonders wenn das memory limit so flach ist...

aber das könntest du ganz leicht testen, indem du in der confi.php diesen wert anpasst:

$GLOBALS['TL_CONFIG']['length_of_backup_step'] = 3;

wenn du den auf 1 setzt, läuft das script nur (circa) eine sekunde...

ich bin gespannt ;-)

ps: wenn du im BE testet, also mit 'Jetzt sichern!', dann musst du diese variable ändern. im BE läuft es auch 20 sekunden, da kann es schon sein, dass die zu gross werden:

$GLOBALS['TL_CONFIG']['length_of_backup_step_batch'] = 20;

moin baumstark und moin erdpferd,

eines habe ich jetzt definitiv herausgefunden.
die größe des zip archivs häng von der durchlaufzeit des scripts ab.
wenn im BE testet, also mit 'Jetzt sichern!' die zeit bei $GLOBALS['TL_CONFIG']['length_of_backup_step_batch'] = 1 gesetzt wird, entstehen die zips wie im BE eingestellt. (bei kleiner größe 15 mb) wie erdpferd schon vermutet hat.

daran lag es bei mir, mit den sehr unterschiedlichen größen.

ja klasse!

vielleicht sollte ich die laufzeit dann bei dem nächsten build reduzieren? aber dann dauert es noch länger...

aber herzlichen glückwunsch fips! gute arbeit...

kein problem,

sitze aber leider immer noch an 2 anderen dingen.

d.h. 2 unterschiedliche hosts einmal firma --> intranet und einmal wie auch bei erdpferd kas.all-inkl.com

1. firma thema ftp
ich habe festgestellt, das die dateien aus backup zum ftp übertragen werden, aber ...
bei ca. 20 mb ist schluß (d.h. am platz liegt es nicht) beim permaneten strg r um das ftp verzeichnis zu checken steigt die dateigröße und bei ca. 20 mb dann fängt es wieder bei 0 mb an.
jetzt habe ich datein die kleiner 20 mb sind, da überträgt er die 1. datei und das script beginnt wieder von vorn. es werden nicht alle dateien aus der sicherung übertragen.

wie ist das mit der zeit aus der config.php gilt die für den ftp auch? ich vermute ja.

das 2 thema ist die db bei kas
die wird gar nicht gesichert, egal welche tabelle ich auswähle (habe nur noch eine anghackt und diese auch schon mehrmals geändert {tabellengröße 3,2kb})
die dateien aus dem filesystem werden alle ohne probleme, mit der 3 sekundeneinstellung, gesichert.

hast du vielleicht eine idee wo ich noch ansetzen könnte.

hi fips

sehr seltsam! aber ok, schauen wir mal ;-)

also zu 1.:
manche hosts haben limits für die maximale datei grösse, aber ich denke du kannst manuell dateien hochladen, die grösser als 20MB sind?
ansonsten gibt es einen unterordner FullBackup/ftp, da werden die ganzen ftp-infos zur laufzeit gespeichert. also welche dateien noch hochgeladen werden müssen (queue) und wie weit ein download schon fortgeschritten ist (offset). vielleicht macht uns ein blick da rein ein wenig schlauer.

zu 2.)
gibt's denn da irgendeine fehlermeldung (im debug modus vielleicht?) oder fängt er einfach gar nicht erst an?

vielen dank, dass du dir die zeit nimmst

bei dem ftp gibt es keine beschränkung bezüglich der größe

er kopiert auch die datei die erzeugt wird vom /modules/FullBackup/backups zum ftp server
aber immer nur die 1. darüber bekomme ich dann ach eine mail.
wenn er die mail gesendet hat beginnt er mit der sicherung von vorne.
d.h. er erzeugt wieder ein zip-archiv legt es wieder /modules/FullBackup/backups ab.
dort sind dann 2 archive.
dann kopiert er wieder das 1. archiv welches er bereits auf den ftp kopierte, verschickt weider eine mail und es geht so weiter.

ergo es werden immer mehr dateien im /modules/FullBackup/backups

die datei ftp_queue.txt
a:1:{i:0;i:1;}
der debug zeigt leider nichts auffälliges

connection ok
uploading next part
0.00% hochgeladen via FTP 05.07.2012_1341493815_7a0aa4fbe5b1d0ca6cc950d2fc54 c5ebcaa651b1_FullBackup_1.zip



Sie werden automatisch weitergeleitet



bei dem db problem bleibt diese meldung stehen [extrahiere datenbank 1 tabellen verbleibend]
im verzeichnis /tmp sind 2 dateien [remaining_data.txt und FullBackup_DB.sql] der inhalt der dateien ist ok

der debug zeigt

Entering:tl_lock, time=1341492166
starting offset:0
extrahiere datenbank 1 tabellen verbleibend
Sie werden automatisch weitergeleitet

klar, kein thema.

ich hatte auch gerade eine eingebung. du hast ja ein backup, das aufgeteilt ist auf mehrere dateien, richtig?

aber die backup-ID ist ja bei den allen gleich, dass heisst es ist das gleiche backup. und bei den ganzen FTP sachen gehe ich eigentlich immer über die IDs, also

in der datei ftp_queue.txt :
a:1:{i:0;i:1;}

ist ja nur ein array(0=>1), das heisst backup nummer eins ist dran, aber die dateien sind ja ALLE backup nummer eins...

wow, daran hab ich gar nicht gedacht beim programmieren...

sag mir bitte bescheid, ob ich da richtig liege?

Ja, ich habe ein aufgeteiltes Backup. Nur komisch du hast doch schon soviel Installationen warum fällt es nur mir auf?

hi fips,

gute frage! ich denke die meisten, mich eingeschlossen, benutzen die erweiterung für die eher kleinen projekte, dafür hab ich sie zumindest für mich geschrieben. so für die zahnarzt oder restaurant website mit einer handvoll statische seiten, die zwar auch ein backup brauchen, aber keine 'grosse' (= teure) lösung wollen oder zahlen wollen. für die installier ich FullBackup, dann hab ich ruhe ;-)

bei grossen, wichtigen projekten würde ich definitiv eine lösung nehmen, die unter der ganzen server-ebene läuft und dadurch viel schneller und zuverlässiger ist, also entweder das, was der hoster anbietet, oder einen cronjob mit rsync oder oder oder

ABER wenn du trotzdem gerne FullBackup benutzen willst, kann ich am wochenende gerne mal kucken, ob ich die ftp transfers nicht über etwas andres als die IDs steuern kann, kann gut sein, dass das geht und gar nicht so viel arbeit ist. ist ja schliesslich doch ein bug...

gruss

Mach dir bloß keinen Streß.
Ich nutze in der Firma (Intranetseite) rsync mit FTP, mir ging es eigentlich um die Schulhomepage. Nur weil es dort keine Testseite gibt wollte ich es bei mir testen.
Nur leider funktioniert dort ja die Sicherung der DB nicht warum auch immer. Ich denke ich werde es mit cronjob und DB Backup erledigen und mir ein Script zum copyieren der dB schreiben.

Also ganz entspannt :-)