webEdition - Forum

Mit WE 6 wurden viele Probleme bei der Backupfunktion beseitigt. Jetzt kämpfe ich schon 2 Tage mit einem Phänomen, was vorher nicht auftrat. Die Wiederherstellung beginnt anfangs normal, aber bei 28% steht es auf der Stelle. Im Logfile zeigt sich, dass es an einem Punkt nicht weiter geht und immer wieder eine Datei geschrieben wird. (siehe Anlage).

Die Variante der Wiederherstellung mit dem mysqldumper und dem übertragenen Ordner "site" und das anschließende Rebuild funktioniert fehlerfrei.

Am Server wurde seit der funktionierenden Version nichts geändert. Speicherplatz ist noch genug... Das Backup gepackt ist 212.0338 kb groß, die xml-Datei 604.976 kB. Kann es sein, dass die Obergrenze bei dem WE-Backup 600 MB ist?

webEdition-Version 6.0.0.6
PHP-Version 5.2.6
memory_limit 64 MB
MySql-Version 5.0.44
max_allowed_packet 15.999 MB

Ich habe gerade das selbe Problem mit der Wiederherstellung eines Backups und probiere das auch schon den 2. Tag. In WE 5 hatte ich nie Probleme mit einer Wiederherstellung. Jetzt in Version 6.0.0.6 bleibt sie mal bei 45%, meistens bei 84 oder 85% und spätestens bei 95% wegen Timeout stehen. Beim Hostersupport habe ich angerufen, mit dem Server gibt es keine Probleme. Die Backupdatei ist gepackt mit 77 MB auch nicht übermäßig groß. Zur Wiederherstellung hab ich nur die we-Backup-Dateien. Wie bekomme die Website zum Laufen?

Gibt es noch jemand, der einen Nothilfesupport machen kann? Eine Supportseite scheint es im Moment nicht zu geben.

Manchmal machen große Dateien (z.B. pdf) beim Backup Probleme.

Zwei sichere Methoden für das Backup, welche immer funktionieren.

Variante 1

1. Dateien im Ordner "site" (befindet sich im Verzeichnis /webEdition/) per ftp sichern
2. Mit dem mysqldumper ( http://www.mysqldumper.de ) die Datenbank sichern
3. Ordner "Site" in das neue System per ftp übertragen
4. Datenbankdump in den Ordner "backup" im Vezeichnis /mysqldumper/work per ftp übertragen
5. Rebuild über Dokumente und Vorlagen

Variante 2

1. Grafikdateien aus dem Ordner "site" (befindet sich im Verzeichnis /webEdition/) per ftp sichern
2. Backup ohne Grafikdateien erstellen
3. Gafikdateien in den Ordner "Site" des neuen Systems per ftp übertragen
4. Wiederherstellungsfunktion von WE
5. Rebuild über Dokumente und Vorlagen

Nur würde mich interessieren, was die in der Protokoll-Datei gezeigte Widerholung von "Reading offset ..." verursachte.

Hab gerade erst gestern bei Hosteurope ein Backup (inkl. externer Dateien) erfolgreich eingespielt. Es gibt also zumindest kein grundsätzliche Problem damit.

Ich vermute mal es ist das alte leidige Thema großes Backup/große Dateien in Zusammenhang mit diversen Limits.
Sei es das memory_limit, die CPU-Zeit oder die maximale Scriptlaufzeit - irgendwas haut immer rein.

Wenn ich ein Backup nicht wieder einspielen kann, setze ich mir ein leeres wE lokal auf, mit total überzogenen Limits (256MB, Scriptlaufzeit auf 600 Sekunden) und spiele das ganze lokal ein. Von dort mache ich dann die übliche Dateisystem/SQL-Kopie die ich dann am Server wieder einspiele. Den SQL-Dump z.B. mit http://www.ozerov.de/bigdump.php .

@Daniel: Ich denke aber auch beim Backup gibt es genug Optimierungsmöglichkeiten - ich hab' grade diverse überflüssige Aktionen aus dem pageLogger-Installer rausgeschmissen, die nur unnötig CPU-Zeit und Speicher gekostet haben, u.a. die SQL-Datei von 5,9MB auf 4,5MB eingeschrumpft.

Gruß, Martin

Klar, optimieren kann man immer. Wenn nicht an WE, wo sonst?!

Ich stelle jetzt auch mal generell die Frage in den Raum: Warum funktioniert das Backup so umständlich wie es eben funktioniert? Viele Optionen kann man meiner Meinung auch kicken, wie Du schon angedeutet hast, Martin. Es ist ein Backup, und da kann man auch wirklich alles sichern was es gibt ohne für jeden Furz eine Abfrage einzubauen. Wer das nicht will, kann ja die Import/Export-Funktion nutzen.
Das Backup könnte so einfach sein. Komplette DB in ein .SQL (Beispiel SQL-Dumper) und zusammen mit allen Files in ein .ZIP verpackt. Warum muss da ewig in XML hin und hergeparst werden etc? Macht das Sinn? <-- Ernstgmeinte Frage.

Nur man braucht ja sowieo die Möglichkeit, alte Backups einzuspielen. Von daher macht es nur noch mehr Arbeit wenn man das angeht.

"Grundsätzlich" ist immer relativ Aber in der Tat funktioniert das gleiche Backup mit MAMP auf dem Mac eingespielt.

Also gibt es Probleme (Größenbeschränkungen) auf dem Webserver. Aber welche?

Hi,

we:willRockYou hat geschrieben:Warum muss da ewig in XML hin und hergeparst werden etc? Macht das Sinn?[/size]

Ja, das ergibt (um von dem englischen "macht" mal weg zukommen) Sinn. Wenn sich in der Datenbankstruktur was ändert, dann hat man mit einem einfachen SQL-Dump einige Probleme. Durch das XML-Format kann man eine Kompatibilität über Versionsgrenzen hinaus sicherstellen. Habe letztens erst wieder ein Backup von webEdition 3 (fast) ohne Probleme in ein webEdition 6 rein bekommen.

MfG
Dirk Einecke

Stimmt, das habe ich nicht bedacht.

Aber das ist ein Problem, dass man lösen könnte. Das Update macht ja ggf. auch Änderungen an der Tabellenstruktur. Genau das könnte man auch nach dem Einspielen eines Backups machen.

Liebe Leut... kommen wir mal wieder zum Ursprung dieses Themas zurück.

Gibt es irgendwo man vernünftige Informationen (gesammelt und eine einer Stelle wo man die infos auch findet), was WE für Servereinstellungen benötigt?

Denn in diesem beschriebenen Fall scheint WE mehr Ressourcen zu benötigen als auf dem Server eingestellt sind.

urlaubsland-polen hat geschrieben:Liebe Leut... kommen wir mal wieder zum Ursprung dieses Themas zurück.

Sind wir, wir versuchen nur das Problem einzugrenzen bzw. in der Zukunft zu umschiffen.

urlaubsland-polen hat geschrieben:Gibt es irgendwo man vernünftige Informationen (gesammelt und eine einer Stelle wo man die infos auch findet), was WE für Servereinstellungen benötigt?

Denn in diesem beschriebenen Fall scheint WE mehr Ressourcen zu benötigen als auf dem Server eingestellt sind.

Siehe oben, das kann dir keiner beantworten, das musst du in eigenen Experimenten selbst herausfinden.

Einstellungen, die funktionieren sind z.B.: memory_limit=1024MB, max_Execution_time=86400

Gruß, Martin

Dann sage ich es mal so. An Limits kann es eher nicht liegen.

Backup-Wiederherstellung funktioniert nicht mit:
webEdition-Version 6.0.0.6
PHP-Version 5.2.6
max_execution_time 60
memory_limit 64 MB
MySql-Version 5.0.44
max_allowed_packet 15.999 MB


Backup-Wiederherstellung funktioniert mit:

webEdition-Version 6.0.0.6
PHP-Version 5.2.10
max_execution_time 30
memory_limit 32 MB
MySql-Version 5.1.37
max_allowed_packet 2 MB

Voraussetzung: identische Backupdatei, erstellt mit

webEdition-Version 6.0.0.6
PHP-Version 5.2.6
max_execution_time 600
memory_limit 64 MB
MySql-Version 5.0.44
max_allowed_packet 15.999 MB

Nachdem ich gestern den ganzen Tag probiert habe meine Backups wieder einzuspielen, bin ich auf eine verblüffend banale Lösung gekommen, die ich in einem anderen Zusammenhang hier im Forum gefunden habe. Meistens wird geraten, das Backup ressourcenschonender anzulegen und die Geschwindigkeit zu drosseln. In WE ist seit der Version 6 die Standardeinstellung für das Backup sehr niedrig. Als ich versuchte, die Wiederherstellung mit einer noch geringeren Geschwindigkeit zu machen, kam das Timeout noch eher. Nachdem ich in den WE-Einstellungen (Einstellungen > Allgemein > Backup) die Geschwindigkeit auf fast das Maximum eingestellt hatte, ging auf einmal alles ganz flüssig und ohne Probleme. Vorher hat mich ein Versuch der Wiederherstellung fast eine Stunde gekostet, jetzt brauche ich 5 Minuten für ein 77 MB-Backup.

Langsam komme ich näher an das Problem heran. Was ist die Ursache für so etwas?

Could not create local Folder at we_live_tools.inc.php/checkAndMakeFolder(): '/home/www/XXXXX/html/webEdition/site//struktur/images/bilder_struktur'

Auf dem Quellsystem ist die Struktur normal

Could not create local Folder at we_live_tools.inc.php/checkAndMakeFolder(): '/home/www/XXXXX/html/webEdition/site/struktur/images/bilder_struktur'

In der Tabelle tblErrorLog gibt es 204 solcher Fehler. Vor dem Backup habe ich neben dem Rebuild über Dokumente und Vorlagen auch über den Index ein Rebuild gemacht und mit phpmyadmin die Datenbank repariert. Trotzdem besteht der Fehler noch... Ist was mit der Datei we_live_tools.inc.php ?

Das erstellte Backup kann ich nicht öffnen (über 600 MB groß).