FullBackup

[minstyle]

Hi baumstark,

vielen Dank für Deine Hilfe!

Innerhalb des Verzeichnisses /system/modules/FullBackup haben alle Unter-/Ordner die Berechtigungen 0755 und Dateien die Berechtigungen 0644 (vgl. Screenshots im Anhang).

Außerdem sind allen Dateien und Ordnern der gleiche Besitzer/Gruppe zugeordnet.

[baumstark]

kein thema, freu mich, wenn meine software benutzt wird ;-)

also das backup läuft ja auch schon. es sieht fast so aus, als wäre nur der php-befehl chmod nicht erlaubt, evtl. aus sicherheitsgründen...

vielleicht kannst du mal den entsprechenden code-block auskommentieren, dann sollte die fehlermeldung verschwinden und du kannst mal testen, ob das backup ganz durchläuft...

du findest den entsprechenden bereich hier:
system/modules/FullBackup/FullBackup.php on line 289

also am besten den ganzen block, der mit chmod zu tun hat, eben auskommentieren, weisst du was ich meine? sonst kann ich dir auch die modifizierte datei zukommen lassen, oder hier posten...

[minstyle]

Ich habe folgende Zeilen in der FullBackup.php ab Zeile 288 auskommentiert:

            //check if tmp_path is writable
           /* if (!is_writable($tmp_path)) {
                if (chmod($tmp_path, 0775) == FALSE) {
                    throw new Exception('not chmoddable: ' . $tmp_path);
                }
            }
    */ 

Leider funktioniert es noch immer nicht und ich erhalte nun folgende Fehlermeldung im Frontend:

Warning: copy(/www/htdocs/xxx/system/modules/FullBackup/tmp/.htaccess) [function.copy]: failed to open stream: Permission denied in /www/htdocs/xxx/system/modules/FullBackup/FullBackup.php on line 300
#0 /www/htdocs/xxx/system/modules/FullBackup/FullBackup.php(300): __error(2, 'copy(/www/htdoc...', '/www/htdocs/xxx...', 300, Array)
#1 /www/htdocs/xxx/system/modules/FullBackup/FullBackup.php(204): FullBackup->checkTmpPath('/www/htdocs/v10...', '/www/htdocs/xxx...')
#2 /www/htdocs/xxx/system/drivers/DC_Table.php(1837): FullBackup->checkEnvironment()
#3 /www/htdocs/xxx/system/modules/backend/Backend.php(282): DC_Table->edit(Object(DC_Table))
#4 /www/htdocs/xxx/contao/main.php(120): Backend->getBackendModule()
#5 /www/htdocs/xxx/contao/main.php(230): Main->run('FullBackup')
#6 {main}

Fatal error: Uncaught exception Exception with message cannot copy .htaccess to: /www/htdocs/v104984/system/modules/FullBackup/tmp/ thrown in /www/htdocs/xxx/system/modules/FullBackup/FullBackup.php on line 301
#0 /www/htdocs/xxx/system/modules/FullBackup/FullBackup.php(204): FullBackup->checkTmpPath()
#1 /www/htdocs/xxx/system/drivers/DC_Table.php(1837): FullBackup->checkEnvironment(Object(DC_Table))
#2 /www/htdocs/xxx/system/modules/backend/Backend.php(282): DC_Table->edit()
#3 /www/htdocs/xxx/contao/main.php(120): Backend->getBackendModule('FullBackup')
#4 /www/htdocs/xxx/contao/main.php(230): Main->run()
#5 {main} 

Liegt es vielleicht daran, dass die Website mit dem Safe Mode Hack läuft?

[baumstark]

aha! sag das doch gleich ;-)

ja, den SMH konnte ich leider nicht berücksichtigen, weil wenn ich die ganzen datei-operationen per ftp mache, dann wird das ganze unglaublich langsam...

also wenn du den tmp-ordner auf 0777 stellst, sollte es laufen, aber das sollte man auf einem live server natürlich nie machen! zum testen kannst du es probieren aber bitte nicht im produktiv-system.

[minstyle]

Gut zu wissen.
Vielleicht solltest du im Erweiterungskatalog darauf hinweisen, dass die Erweiterung mit dem SMH eher ungeeignet ist.

Auch bei der Änderung der Dateirechte des tmp-Ordners auf 0777 hilft nicht.

[baumstark]

echt nicht? so langsam hört es sich nach einer ziemlich unglücklichen configuration an...

hast du veilleicht noch einen screenshot (wg. besitzer und rechten) von dem ordner system/modules?

[minstyle]

Der Ordner /system/modules wie auch all seine Unterordner haben 0755 und den gleichen Besitzer.

[baumstark]

ok, letzter versuch:

wenn du dich per ftp einloggst und dann einen ordner anlegst, hat der dann auch den selben benutzer?

[minstyle]

ok, letzter versuch:

wenn du dich per ftp einloggst und dann einen ordner anlegst, hat der dann auch den selben benutzer?

Ja.

Ich habe eigentlich nie Probleme mit Erweiterungen. Deine ist die erste mit der ich Schwierigkeiten habe. Dann werde ich mich wohl nach einer Alternative umschauen müssen. Trotzdem vielen Dank für deine Mühe.

[baumstark]

ja klar, erweiterungen benutzen ja auch selten das dateisystem...

es gibt ja noch andere backup-lösungen, sorry dass es nicht luft.

[minstyle]

Wirklich schade.
Ich hätte gerne deine Erweiterung genutzt, da hier neben der Datenbank auch das Dateisystem automatisiert gesichert werden kann. Andere Erweiterungen bieten leider nur ein DB-Backup an ...

[baumstark]

ja, deswegen hab ich sie ja entwickelt ;-)

sonst kannst du es mal auf einem anderen server probieren, falls das eine option ist...

[minstyle]

Ich konnte das Problem jetzt doch lösen, indem ich den Safe Mode Hack deaktiviert und die "Provider-spezifische Einstellungen" (vgl. Wie man einen Webserver für Contao konfiguriert) speziell für meinen Webhoster eingebunden habe.

[baumstark]

echt, und jetzt läuft's?

[AndreasA]

Hallo,

seit dem Upgrade auf v2.11.2 (von 2.10.3) folgende Fehlermeldung:
function.mysql-real-escape-string Access denied for user 'username'@'localhost' (using password: NO)
und:
A link to the server could not be established in

Wobei das zweitere wohl mit dem ersten Fehler zusammenhängt.

Den ersten Fehler verstehe ich sofort, weil weder Username noch Passwort (bzw. keines verwendet wird laut log...) passen, was ich nicht verstehe ist wieso, weil eigentlich sollte die Extension ja wie alle anderen mit den Daten von contao arbeiten oder?
Obwohl eventuell doch, weil mysql_real_escape_string ist keine Contao Funktion ... Gab es dafür nicht ein Contao Äquivalent?

[baumstark]

die extension schon aber "mysql-real-escape-string" nicht...

vielleicht hilft dir das weiter: https://www.contao-community.de/show...mit-FullBackup

gruss

[AndreasA]

Es ist allerdings diese Extension welche diese Funktion aufruft.
Das heißt eigentlich müsste ich den Source Code der Extension anpassen, wäre es hier nicht sinnvoller manuell - von der Extension Seite her ein mysql_connect und disconnect zu machen vor der Funktion?
Bzw. noch besser auf eine Contao eigene Funktion zurückzugreifen - z.B. muss die Datenbank ja nicht immer MySQL sein.

[baumstark]

ja klar, du hast recht. aber soweit ich weiss, gibt es keine contao eigene funktion dafür. natürlich könnte ich auch eine eigene funktion dafür benutzen, die wär aber nicht so sicher. das gute an mysql_real_escape_string ist, dass diese funktion die db benutzt und damit für diese db immer korrekt escaped, auch wenn sich die version ändert, oder der character-set etc.

hast du das upgrade auf von 2.10 auf 2.11 auf dem selben server gemacht??

dann müsste ich das nämlich definitiv rausnehmen....

[baumstark]

hallo andreas,

kannst du vielleicht mal folgendes bei dir probieren, bevor ich das evtl. in den nächsten build übernehme:

in der datei FullBackup_DB.php, Zeile 536, dieses hier:

$values_str .= "'" . mysql_real_escape_string($row[$field]) . "', "; 

hierdurch ersetzen:

$values_str .= "'" . addcslashes($row[$field], "\x00\n\r\'\"\x1a") . "', "; 

und dann testen, ob es
a) fehlerfrei durchläuft und du
b) die db fehlerfrei aus dem .sql-dump wiederherstellen kannst

(ich würd's ja selber testen, aber ich bin gerade im büro und komm nicht an meine dummy-dbs ran, vielleicht komme ich am wochenende dazu...)

[AndreasA]

Also es scheint einmal fehlerfrei durch zu laufen.
Allerdings habe ich selbst auch gerade keinen Zugriff auf eine Contao Testumgebung, weswegen ich das wiederherstellen nicht testen konnte.

Du hast allerdings vermutlich recht, dass es so nicht ganz so sicher sein wird, ABER andererseits geht man mit diesen Werten ja nicht in die DB, sondern in ein Skript zum Importieren, welches man sowieso nur manuell ausführen lassen würde.

Es könnte auch sein, dass die Meldung eventuell schon vorher da war, nur seit 2.11 funktioneirt das displayError = false bei mir irgnedwie nicht und somit fällt es schneller auf.
Vielelicht liegt es an irgnedeiner Extension, konnte ich aber noch nicht rausfinden.


Allerdings was eigentlich möglich sein sollte mittels dbUser und dbPass manuell ein mysql_connect davor und danach ein mysql_disconnect durchzuführen und eventuell eine Option anzubieten, mit der man auf diese Fallback Methode (mit addcslashes) zurückgreift, falls man keine MySQL Datenbank verwendet.

[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]

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]

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]

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

[Anke]

Hallo baumstark,

100 MB sind viel? Kleine Websites kann man ja auch noch bequem manuell sichern :-)

Bei meinem Problem mit 1&1 habe ich jetzt mal nur zwei Datentabellen (darunter die größte Tabelle, die Events, mit 92 kB) und ein kleines Verzeichnis mit Fullbackup gesichert. Das hat mühelos geklappt. Die komplette DB (3,2 MB) lässt sich jedoch nicht sichern, da hängt er sofort. Was macht deine Extension denn grundlegend anders als das alte BackupDB, mit dem das DB-Backup wie auch das Erszellen eines Seitentamplates funktioniert?

VG
Anke

[baumstark]

Hallo baumstark,

100 MB sind viel? Kleine Websites kann man ja auch noch bequem manuell sichern :-)

will man aber nicht ;-)

Bei meinem Problem mit 1&1 habe ich jetzt mal nur zwei Datentabellen (darunter die größte Tabelle, die Events, mit 92 kB) und ein kleines Verzeichnis mit Fullbackup gesichert. Das hat mühelos geklappt. Die komplette DB (3,2 MB) lässt sich jedoch nicht sichern, da hängt er sofort. Was macht deine Extension denn grundlegend anders als das alte BackupDB, mit dem das DB-Backup wie auch das Erszellen eines Seitentamplates funktioniert?

VG
Anke

BackupDB benutzt mysqldump, das ist ein linux command, d.h. es funktioniert nur unter linux und muss manuell oder per cronjob gemacht werden. und ausserdem nur die DB.

FullBackup ist definitiv für eher kleine projekte gedacht, grosse + wichtige projekte sollte man immer ausserhalb der PHP- / Webapp-Ebene sichern!!! das gilt ja ganz allgemein und grundsätzlich...

[tgr]

Moin community,

auch von mir den besten Dank für die Erweiterung. Allerdings habe ich ein Problem bei einem Kunden. Und zwar benötigt Contao > 4 Sekunden, um die Anfrage zu beantworten, sobald die Extension aktiviert ist. Dabei ist es egal, mit welcher Konfiguration, ob exkrementell oder nicht, auch die Frequenz ist dabei irrelevant.

Das Häkchen bei "Läuft gerade" ist permanent gesetzt, das backup jedoch schon ein paar Stunden alt (das wird übrigens bei mir nur ins tmp-Verzeichnis geschrieben, das ist ja aber egal).

Das Backup wiegt gute 6MB, ist also nicht groß. Hat jemand ne Idee, was ich da drehen kann?

contao 2.11.4, fullbackup 0.0.8 B 5, Seite liegt bei all-inkl.com, der Server wie der Datenbankserver seien unbelastet und der test zeigt auch, sobald fullbackup deaktiviert ist, rennt die Seite wie Hund.

LG
Thorsten

[baumstark]

moin tgr,

jep, genau so läuft die erweiterung, es werden bei zufälligen anfragen ca. 3 sek "draufgepackt", in denen das backup jeweils ein "schrittchen" weiter macht. du kannst in der config.php auch einen anderen wert eintragen, eine sekunde wäre wohl das minimum und dann würden es nur 1-2 sekunden sein...

[deltaprise]

Servus zusammen,

habe gerade die Erweiterung installiert und wollte gleich alles einstellen. Beim speichern meiner Einstellungen bekomme ich einen Fehler.

Hier mal der Auszug aus meiner log Datei:

[04-Sep-2012 11:38:52 UTC] PHP Warning: chmod() [<a href='function.chmod'>function.chmod</a>]: Operation not permitted in /home/jugendmedientage/htdocs/system/modules/FullBackup/FullBackup.php on line 289

[04-Sep-2012 11:38:52 UTC] PHP Fatal error: Uncaught exception 'Exception' with message 'not chmoddable: /home/jugendmedientage/htdocs/system/modules/FullBackup/tmp/' thrown in /home/jugendmedientage/htdocs/system/modules/FullBackup/FullBackup.php on line 290

[04-Sep-2012 11:39:36 UTC] PHP Notice: Using .tpl files (system/modules/usejquery/templates/moo_jquery_nc.tpl) is deprecated. Please use the new .html5 and .xhtml files instead. in /home/jugendmedientage/htdocs/system/libraries/Controller.php on line 169 

Was mach ich falsch, wo liegt mein Fehler?

Gruß
Dominik