FullBackup

[baumstark]

kein stress, es eilt ja nicht ;-)

du hast recht, das wär schon ein sehr seltsamer angriff... mir ging es aber mehr um die db-version und den zeichensatz, eigentlich ist mysql_real_escape_string schon empfohlen...

und ich hab mal gekuckt, contao hat eine methode, ich glaub 'escapeParams', zum escapen, aber die ist protected und benutzt (bei mysql) auch mysql_real_escape_string, kann ich also auch nicht wirklich benutzen...

gute idee mit "mysql_connect davor und danach ein mysql_disconnect", aber da wäre ich ein wenig besorgt um die performance, weil das wird ja bei jedem feld gemacht! eigentlich ist mysql_real_escape_string auch schon zu heavy an dieser stelle und ziemlich viele leute haben probleme mit scriptlaufzeiten und memorylimits u.ä., hmmm vielleicht ist addcslashes allgemein gar keine schlechte idee...

[AndreasA]

Man könnte vielleicht ganz am Anfang eines Backups ein mysql_connect durchführen und am Ende dann ein mysql_disconnect.
Damit würde es nicht pro Feld notwendig sein, sondern quasi über alles.
Das einzige Problem wäre eventuell ein zu frühes abbrechen.

[baumstark]

hi andreas,

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

[Jowi]

Server überlastet

Hallo

Auf der Suche nach einer umfassenden Backup Lösung für Contao sind wir seit 3 Wochen FullBackup intensiv am testen.

Zuerst hat es nicht funktioniert und wir hatten auch das Problem mit dem Fehler :
function.mysql-real-escape-string Access denied for user 'username'@'localhost' (using password:" NO)

Dies wurde ja mit der neusten Version behoben und der Fehler tritt nicht mehr auf.

Leider hatten wir grosse Probleme mit der Belastung des Servers. Das Problem ist, dass das Script die Systemressourcen des Servers exzessiv belastet und es mehrheitlich nicht fertig ausgeführt wurde. Zudem musste unser Hoster mehrmals eingreifen. So können wir leider die Extension nicht nutzen. Ansonsten wäre es ja eine tolle Funktion.

Hat vielleicht jemand von euch gleiche oder ähnliche Erfahrungen oder gibt es eine Lösung?

Grüsse

[baumstark]

hallo jowi,

ja, bei echt grossen backups, bzw. echt geringen memory-limits gibt es manchmal performance-probleme, weil (unter anderem) die .zip datei sehr gross wird...

ich hab das öfter gehabt bei hostern wie 1&1, strato u.ä., dass der server dann einfach abricht, ohne fehlermeldung.

folgendes versuche ich dann in der regel, je nach projekt:

- inkrementelle backups benutzen
- unwichtige db-tabellen ausschliessen (suchindex etc.)
- maximale Dateigrösse der .zip Datei evtl. runterschrauben
- in der config/config.php die folgenden vars. runterdrehen:

$GLOBALS['TL_CONFIG']['db_rows_limit'] = 500; //DB rows per write in bytes
$GLOBALS['TL_CONFIG']['zip_file_limit'] = 200; //max file adds per one go
$GLOBALS['TL_CONFIG']['fullbackup_split_size'] = 5 * 1000 * 1000;

gerade das "db_rows_limit" ist komischerweise sehr oft der grund für die sehr hohe memory-benutzung...

ich hoffe das hilft?

[Jowi]

Vielen Dank für die rasche Antwort.

Ja das es an der grossen Zip Datei liegen könnte dachte ich mir auch schon.

- Inkrementelle Backups habe ich noch nicht probiert, aber zuerst muss es einmal zu Ende durchlaufen
- DB-Tabelle auschliessen - Stimmt hab ich noch nicht versucht - die Logs könnte man ja auch noch ausschliessen
- Gut werde auch noch die max Dateigrösse angeben

Die config File werde ich auch noch anpassen.

Ja Danke erstmals.

[baumstark]

hi jowi,

ja gerne und viel glück. sorry, dass es nicht einfacher geht, das hat mich auch schon öfter ziemlich genervt....

und theoretisch könnte man das programmatisch abfangen, indem man die memory limits ausliest und die werte dynamisch anpasst und dann ein paar testläufe macht etc. etc., aber das ist glaube ich eine menge arbeit und dafür kommt es relativ zu selten vor, eigentlich.

[Anke]

Erste Erfahrungen

Hallo!

Eine tolle Erweiterung, die endlich mal komplette und ganz leicht zu (re)installierende Datensicherungen liefert.

Leider hängen die Backups noch öfter mal, auch Servern, auf denen es bereits funktioniert hat. Lediglich beim 1&1-Tarif Home 5.0 geht es nicht, dort stoppt das Skript, da offenbar keine ZIP-Datei erstellt werden kann (und an mangelnden CHMOD-Rechten kann's nicht liegen).

Etwas unangenehmer ist im Moment, dass die Backup-Emails nicht an die in FullBackup angegebene E-Mail-Adresse gehen, sondern an die unter Einstellungen hinterlegte Adresse (Systemadmin) geschickt werden, was verschiedentlich für Irritationen sorgt. Ich habe die Extension unter 2.11.3/4 installiert. Ist das möglicherweise ein Bug?

Viele Grüße,
Anke

[baumstark]

Emails

hallo anke,

bist du da sicher? an den Systemadmin werden eigentlich immer nur fehler-emails geschickt...

wenn die backups anfangen zu hängen, liegt es fast immer daran, dass die dateien zu gross werden für die memory limits des jeweiligen servers. das kann also gut sein nach einer zeit...

versuch da doch einfach mal die temporär-dateien vom backup auszuschliessen, sowohl von den dateien als auch den datenbank-tabellen. wenn das nicht reicht, müsstest du evtl. die maximale Dateigrösse der .zip Datei reduzieren.

[Anke]

hallo anke,

bist du da sicher? an den Systemadmin werden eigentlich immer nur fehler-emails geschickt...

Aha, dann gehen Fehlermeldungen also an den Systemadministrator (Einstellungen) und nicht an den Websiteadministrator (Seitenstruktur), und Erfolgsmeldungen entweder an die im FullBackup angegebene Adresse oder - falls nicht angegeben - wiederum an den Systemadministrator bzw. alternativ geht gar keine Benachrichtigung raus, richtig?

Intuitiv ist der Websiteadministrator für mich immer der "Webmaster" gewesen, offenbar brauchte ich das bis jetzt nie zu unterscheiden ;-)

Richtig ist jedenfalls, dass die letzte Erfolgsmeldung wie gewünscht an den Webmaster ging, und dort hätte auch die Fehlermeldung landen sollen und nicht quasi bei der Geschäftsführung ... Okay, da muss ich umdenken.

wenn die backups anfangen zu hängen, liegt es fast immer daran, dass die dateien zu gross werden für die memory limits des jeweiligen servers. das kann also gut sein nach einer zeit...

versuch da doch einfach mal die temporär-dateien vom backup auszuschliessen, sowohl von den dateien als auch den datenbank-tabellen. wenn das nicht reicht, müsstest du evtl. die maximale Dateigrösse der .zip Datei reduzieren.

Peinlich, ich habe gerade festgestellt, dass mit den gefühlten hunderttausend eingerichteten E-Mail-Adressen die 10 GB des Managed Hosting-Pakets von DomainFactory so gut wie ausgereizt sind. Dann brauche ich mich wohl über Kapazitätsprobleme bei der Website mit ihren 800 MB nicht zu wundern. Mal sehen, ob das FullBackup wieder funktioniert, sobald die IT sich eine andere Lösung für die Mailkonten ausgedacht hat ... Die letzte Backup-Datei hatte 113 MB, und jetzt hängt er bei 70 MB. Ich denke, da ist einfach kein Platz mehr!

Mit dF gibt es nach meiner Erfahrung jedoch am wenigsten Probleme. Bei anderen Hostern hängt FullBackup fast immer und wie gesagt, bei 1&1 kommt es nicht mal zum Erstellen einer Zip-Datei.

VG
Anke

[baumstark]

hallo anke,

jetzt bring mich nicht durcheinander mit den ganzen 'webmastern' ;-) es wird nur die fehler-email an den admin (= techniker) geschickt, alle anderen an die eingetragene email-adresse (= kunde).

und ja, bei einigen host und günstigen paketen gibt es öfter probleme mit den dateigrössen, besonders bei 1&1 oder strato, das ist ziemlich nervig...

[Anke]

Hallo baumstark,

durcheinanderbringen wollte ich dich natürlich nicht, aber wenn man mal alle Postings zu System- und Webadmins durchsieht ... verursacht das wohl immer wieder Verwirrung.

Mein hängendes DomainFactory-Backup liegt, wie ich inzwischen klären konnte, eindeutig nicht an mangelndem Speicherplatz. Wäre es vielleicht möglich, mal eine kleine Liste von Einstellungen zu bekommen, die man vor der Installation der FullBackup-Erweiterung via PHP-Info abchecken könnte, damit man schon eine ungefähre Ahnung hat, wo auf Seiten des Webservers die Grenzen liegen?

Dann habe ich noch eine Frage: Wie sollte man verfahren, wenn das Backup einen Hänger gemeldet hat und weitermachen soll? Die Dateien im tmp-Verzeichnis löschen? Ein neues Backup definieren?

Viele Grüße,
Anke

[baumstark]

hi anke,

am einfachsten ist es beim hänger wahrscheinlich den order 'tmp' zu leeren, das alte backup zu löschen und eben ein neues anzulegen.

allerdings wird es ja wahrscheinlich beim nächsten mal wieder hängen, wenn du nix daran änderst... wie gesagt, ich würd einmal die systemwartung von contao laufen lassen, ordner wie system/tmp und system/html ausschliessen und dann von der datenbank die tabelln tl_log und tl_search_index, dann sollte das backup schon deutlich kleiner sein...

und mit einem skript die grenzen des webservers abchecken ist leider nicht so einfach, es ist ja kein absoluter wert den man abfragen kann, es hängt von mehreren werten ab (memory limit, dateigrösse zip-datei, grösse der einzelnen dateien, grösse der datenbank, etc. etc.), da kann man es einfacher direkt mal testen (mit 'jetzt sichern')...

[Anke]

hi anke,

am einfachsten ist es beim hänger wahrscheinlich den order 'tmp' zu leeren, das alte backup zu löschen und eben ein neues anzulegen.

allerdings wird es ja wahrscheinlich beim nächsten mal wieder hängen, wenn du nix daran änderst... wie gesagt, ich würd einmal die systemwartung von contao laufen lassen, ordner wie system/tmp und system/html ausschliessen und dann von der datenbank die tabelln tl_log und tl_search_index, dann sollte das backup schon deutlich kleiner sein...

Die Systemwartung habe ich natürlich :-) durchlaufen lassen und ein paar Ordner ausgeschlossen, Tabellen allerdings nicht. Das Backup hatte in den letzten zwei Wochen zweimal erfolgreich eine Datensicherung von je 113 MB angelegt, ohne jegliche Ausschlüsse. Das letzte Mal ist er bei 70 MB hängen geblieben. Jetzt hat es wieder geklappt, wie gesagt, mit ein paar ausgeschlossenne Ordnern und vorheriger Systembereinigung. Das ist wohl ein "Sensibelchen" ...

Ich sehe allerdings wenig Sinn darin, Tabellen oder Ordner ausschließen zu müssen, denn das würde den vielversprechenden Begriff "FullBackup" ja ad absurdum führen. Genauso wenig Sinn macht eine Systemwartung vor automatischen Backups.

und mit einem skript die grenzen des webservers abchecken ist leider nicht so einfach, es ist ja kein absoluter wert den man abfragen kann, es hängt von mehreren werten ab (memory limit, dateigrösse zip-datei, grösse der einzelnen dateien, grösse der datenbank, etc. etc.), da kann man es einfacher direkt mal testen (mit 'jetzt sichern')...

Ich meinte eigentlich kein Skript, sondern ein paar Minimalwerte. Einen Blick in die php-info oder so zu werfen ist meist weniger zeitaufwändig als FullBackup zu installieren und herumzuprobieren.

VG
Anke

[baumstark]

hallo anke,

100MB ist ja auch nicht gerade klein für eine contao installation, ausserdem ist die grösse der einzelnen dateien manchmal relevant, viele kleine dateien funktionieren besser als z.B. grosse video-dateien.

vielleicht kannst du mal versuchen die maximalgrösse auf 50MB zu setzen, dann solltest du 2-3 einzelne .zip dateien erhalten.

viel glück