Druckbare Version
sehr seltsam...
und beim automatischen brauchst du ein wenig traffic, das backup wird durch requests 'vorangetrieben'. hast du das auf einem test server laufen? dann würde ich ein reload tool empfehlen, damit man nicht dauernd auf 'neu laden' klicken muss ;-)
Das heisst ohne Seitenbesucher kein automatisches Backup?
Also das ist eh nur ein Testsystem, fast nur die Grundinstallation von Contao.
Sollte dann ja eigentlich nicht so viele requests benötigen...
Ich bin gespannt :-)
ganz genau, das scheint viele leute zu irritieren... ;-)
sind schon verdammt viele requests, wenn man die selber machen muss, aber wie gesagt, so eine reload-erweiterung für ff oder chrome ist schnell installiert..
Habs schon durch, war nicht so viel geklicke.
Funktioniert hat auch alles aber zum Abschluss leider wieder die hässliche Fehlermeldung, diesmal ntürlich direkt auf der Webseite :-(
Code:Warning: ftp_chdir() [function.ftp-chdir]: Failed to change directory. in /var/www/xxxxxx/html/contao/system/modules/FullBackup/FullBackup_FTP.php on line 239
#0 /var/www/xxxxxx/html/contao/system/modules/FullBackup/FullBackup_FTP.php(239): __error(2, 'ftp_chdir() [uploadNextPart(Resource id #233, 'html/contao_bac...')
#2 /var/www/xxxxxx/html/contao/system/modules/FullBackup/FullBackup.php(125): FullBackup_FTP->processQueue(7)
#3 /var/www/xxxxxx/html/contao/system/modules/frontend/PageRegular.php(87): FullBackup->heartbeat()
#4 /var/www/xxxxxx/html/contao/index.php(198): PageRegular->generate(Object(DB_Mysql_Result), Object(DB_Mysql_Result), Object(PageRegular))
#5 /var/www/xxxxxx/html/contao/index.php(333): Index->run(Object(DB_Mysql_Result))
#6 {main}
Warning: Cannot modify header information - headers already sent by (output started at /var/www/xxxxxx/html/contao/system/functions.php:134) in /var/www/xxxxxx/html/contao/system/libraries/Template.php on line 230
#0 /var/www/xxxxxx/html/contao/system/libraries/Template.php(230): __error(2, 'Cannot modify h...', '/var/www/xxxxxx...', 230, Array)
#1 /var/www/xxxxxx/html/contao/system/modules/frontend/FrontendTemplate.php(187): Template->output('Content-Type: t...')
#2 /var/www/xxxxxx/html/contao/system/modules/frontend/PageRegular.php(142): FrontendTemplate->output()
#3 /var/www/xxxxxx/html/contao/index.php(198): PageRegular->generate()
#4 /var/www/xxxxxx/html/contao/index.php(333): Index->run(Object(DB_Mysql_Result))
#5 {main}
das geht natürlich nicht...
also versteh ich das richtig, dass eigentlich alles funktioniert und auch hochgeladen wird, nur danach kommt die fehlermeldung???
Ja genau, beim letzten Reload der Seite kommt die Fehlermeldung...
warum logged er sich dann überhaupt nochmal ein??? ist denn die .zip datei auf dem server genau so gross wie lokal?
Komisch...
Die Datei wird per FTP übertragen:
05.08.2011_1312546436_58a11b44adaa3b28818a53ca241a 2ad39cc5be00_FullBackup_7
Die Datei steht im Link der Mail:
05.08.2011_1312555073_31c3118b8c74f81a1f57ec8a778b 36fe25376012_FullBackup_7
Bei der Datei die per FTP übertragen wird Bleibt der Name bei dem automatischen Backup gleich, das erstellungsdatung passt aber zu dem in der Mail, bzw. dem im Contao Datei System...
Irgendwas kommt da doch durcheinander...
hi dns
ja, das kann aber durchaus sein, die dateien müssen nicht identisch sein, und sind es auch selten. der link in der email ist ja zum runterladen. und die ftp queue ist davon völlig unabhängig und arbeitet alte dateien der reihe nach ab....
er versucht bei dir also eine ältere hochzuladen, was aber eigentlich normal ist. und du bist sicher, dass du den ftp-pfad zwischenzeitlich nicht geändert hast???
vielleicht einmal deinstallieren, alle dateien löschen und dann neu installieren, aber ich denke, das wirst du schon öfter gemacht haben, oder?
Damit es noch verwirrender wird:
Das intervall ist zum testen auf stündlich eingestellt.
Bei dem Backup um 14:13 Uhr wurde folgende Datei erstellt (mail+ftp):
05.08.2011_1312546436_58a11b44adaa3b28818a53ca241a 2ad39cc5be00_FullBackup_7
Bei dem Backup um 15:22 Uhr und 16:37 Uhr ist der Name wieder (ftp):
05.08.2011_1312546436_58a11b44adaa3b28818a53ca241a 2ad39cc5be00_FullBackup_7
Allerdings ist der Dateiname der Mail zum Download des Backups im Contao Dateisystem:
15:22
05.08.2011_1312550544_3492d8f2a92da770ba9e0708f23a 2f2f7bba6e9c_FullBackup_7.zip
16:37
05.08.2011_1312546436_58a11b44adaa3b28818a53ca241a 2ad39cc5be00_FullBackup_7.zip
Verstehe ich nicht...
Deinstalliert und installiert nicht, aber zwischendurch war ein Update des Moduls...
Und das Testweb ist umgezogen von ner lokalen xampp installation auf nen Webserver.
Bei allen Fällen der gleiche Fehler...
hmm, und überall ist der ftp-pfad gleichgeblieben???
aber ok, ich würd dir das de-installieren und säubern vorschlagen, dann gibt es in der config.php noch eine zeile:
$GLOBALS['TL_CONFIG']['fullbackup_debug'] = FALSE;
wenn du die variable auf TRUE setzt, müsstest du zumindest viel mehr output (bei 'jetzt sichern') kriegen, vielleicht hilft uns das weiter. es ist auch immer schwierig, so aus der ferne zu diagnostizieren...
Cool danke, werd gleich am Montag morgen mal testen...
Schönes Wochenende erst mal...
Moin.
Bekomme mit TRUE auch nicht mehr Infos.
Also Die Warnings hab ich jetzt ausgeblendet.
Das automatische Backup funktioniert nun auch.
Das manuelle nicht, aber das ist nicht weiter tragisch. Möchte jetzt nicht weiter nach dem Fehler suchen.
Danke Baumstark!
Hallo,
ich habe das Fullbackup getestet - läuft soweit einwandfrei. Wenn ich jedoch die DB lokal installiere und die Seite dann aufrufe - werden alle Umlaute falsch dargestellt (z.B Büros ) - Ich habe alles nachgeschaut. DB steht utf-8 drin.
Ich öffne die ZIP Datei mit Winrar... und öffne die sql datei mit Textpad und spiele Sie dann per phpMyAdmin ein.
habe auch schon versucht - die sql datei als utf-8 abzuspeichern und nochmals einzuspielen - bringt nichts.
Kennt irgendjemand das problem bzw. ne Lösung. Ansonsten läuft die Geschichte ziemlich gut...
Danke
Gassi
Hat sich schon von selbst erledigt.... ANSI ist das Zauberwort.....
Hallo zusammen,
ich nutze die aktuelle Contao-Version 2.11.2 und erhalte beim Anlegen eines neuen Backup-Auftrages folgende Fehlermeldung:
D.h. ich kann derzeit keine Backup-Aufträge erstellen bzw. durchführen lassen.PHP-Code:Warning: chmod() [function.chmod]: Operation not permitted in /www/htdocs/xxx/system/modules/FullBackup/FullBackup.php on line 289
#0 /www/htdocs/xxx/system/modules/FullBackup/FullBackup.php(289): __error(2, 'chmod() [checkTmpPath('/www/htdocs/v10...', 509)
#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 not chmoddable: /www/htdocs/xxx/system/modules/FullBackup/tmp/ thrown in /www/htdocs/xxx/system/modules/FullBackup/FullBackup.php on line 290
#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}
Handelt es sich hier um eine Rechteproblem? Wenn ja, wie muss ich den CHMOD einstellen?
Auf schnelle Antwort würde ich mich sehr freuen.
hallo minstyle,
definitiv ein rechteproblem.
hast du die erweiterung aus dem katalog installiert oder per ftp hochgeladen?
bei installation aus dem katalog sollten die rechte eigentlich funktionieren...
Die Erweiterung habe ich über das Contao-Backend, also über den Erweiterungskatalog installiert.
ok, das funktioniert normalerweise... kannst du vielleicht mal die owner und premissions der ordner und unterordner in system/modules/FullBackup prüfen, ob es da irgendwelche unregelmässigkeiten gibt. also sowas wie der ordner FullBackup hat einen anderen besitzer als alle anderen in dem ordner, oder alle anderen haben die rechte 0755, der FullBackup/tmp aber 0700 oder so etwas.
das kannst du in deinem ftp programm oder in der ssh shell (falls vorhanden) sehen.
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.
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...
Ich habe folgende Zeilen in der FullBackup.php ab Zeile 288 auskommentiert:
Leider funktioniert es noch immer nicht und ich erhalte nun folgende Fehlermeldung im Frontend:PHP-Code://check if tmp_path is writable
/* if (!is_writable($tmp_path)) {
if (chmod($tmp_path, 0775) == FALSE) {
throw new Exception('not chmoddable: ' . $tmp_path);
}
}
*/
Liegt es vielleicht daran, dass die Website mit dem Safe Mode Hack läuft?PHP-Code: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}
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.
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.
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?
Der Ordner /system/modules wie auch all seine Unterordner haben 0755 und den gleichen Besitzer.
ok, letzter versuch:
wenn du dich per ftp einloggst und dann einen ordner anlegst, hat der dann auch den selben benutzer?
Ja.Zitat:
Zitat von baumstark
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.
ja klar, erweiterungen benutzen ja auch selten das dateisystem...
es gibt ja noch andere backup-lösungen, sorry dass es nicht luft.
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 ...
ja, deswegen hab ich sie ja entwickelt ;-)
sonst kannst du es mal auf einem anderen server probieren, falls das eine option ist...
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.
echt, und jetzt läuft's?
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?
die extension schon aber "mysql-real-escape-string" nicht...
vielleicht hilft dir das weiter: https://www.contao-community.de/show...mit-FullBackup
gruss
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.
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....
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:
hierdurch ersetzen:PHP-Code:$values_str .= "'" . mysql_real_escape_string($row[$field]) . "', ";
und dann testen, ob esPHP-Code:$values_str .= "'" . addcslashes($row[$field], "\x00\n\r\'\"\x1a") . "', ";
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...)
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.
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...
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.
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.
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
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?
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.
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.
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
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.
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?Zitat:
Zitat von baumstark
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.
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!Zitat:
Zitat von baumstark
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
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...
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
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')...
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" ...Zitat:
Zitat von baumstark
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.
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.Zitat:
Zitat von baumstark
VG
Anke
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
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
will man aber nicht ;-)Zitat:
Zitat von 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.Zitat:
Zitat von Anke
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...
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
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...
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:
Was mach ich falsch, wo liegt mein Fehler?PHP-Code:[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
Gruß
Dominik
Einen ähnlichen Fehler hatte ich auch. Schau mal, ob die angemerkten Ordner den selben Bsitzer haben wie der Rest der Ordner und versuche, den zu ändern.
Ich konnte den Besitzerwechsel nur über das web-FTP im Kundenmenü meines Providers durchführen.
Erst einmal Danke für deine schnelle Antwort. "Leider" ist der Besitzer überall gleich.
Hab die Seite mal local installiert und da kann ich meine Einstellungen speichern. Warum geht das dann online nicht?:eek:
Hallo,
ich hatte diese Nacht jetzt das erste mal ein Backup gemacht und dabei einen Ftp-upload eingestellt. Sonst hab ich das Backup immer normal im Modulverzeichnis ablegen lassen.
Nachdem ich den Update-Prozess eine Weile verfolgt hatte, ist mir aufgefallen, das beim Upload-Teil die % immer bei 0% standen. Es wurde zwar die Seite regelmäßig aktualisiert und irgendwann kam auch die Meldung, dass das Backup abgeschlossen sei, aber dann fing der Upload wieder an. Also hab ich mich im Backend neu eingeloggt und den Status vom Backup kontrolliert. Bei "läuft gerade" war kein Haken drin, also scheinbar fertig. Ich hab auch die Mail mit dem Download-Link bekommen. Das Backup wurde ja trotzdem im Modulordner abgelegt.
Ich hab dann auf den Upload-Ftp geschaut, ob da überhaupt eine Datei abgelegt wurde. Dem schien erstmal auch so zu sein, allerdings hat sich die Dateigröße ständig geändert. Von groß zu klein und auch anders rum. Also völlig wirr. Es scheint also noch immer im Hintergrund ein Prozess zu laufen, der mit dem Upload zusammenhängt.
Wie kann ich den Prozess stoppen, ohne das irgendwas passiert?
Danke
einfach die dateien im ftp unterordner löschen, dann sollte es aufhören...
Hm ... hab die Backup-Datei auf dem Ftp gelöscht, aber die wird immer wieder neu angelegt. Hab auch den Haken bei "Auf FTP Server hochladen" rausgenommen.
hallo,
nicht auf dem ftp-server. ;-) im ordner system/modules/FullBackup/ftp...
Hallo!
Ich habe das Problem, dass Fullbackup zwar ein korrektes Backup erstellt, ich aber keine E-Mail-Benachrichtigung erhalte. Ich arbeite mit contao 2.11.6 und dem aktuellen Release von Fullbackup. Es funktioniert weder auf einer lokalen Installation unter XAMPP noch auf einer Installation auf einem WWW-Server (Hoster weiß ich nicht). In beiden Fällen habe ich ein "Jetzt sichern"-Backup erstellt, auch unterschiedliche E-Mail-Adressen angegeben, die zip-Datei wird richtig erstellt, aber es kommt keine Benachrichtigung rein.
Woran kann das liegen bzw. muss ich vielleicht in den allgemeinen Contao-Einstellungen noch etwas einstellen?
P.S.: "Per E-Mail verschicken" ist natürlich angehakt ;-).
hallo mary,
werden denn sonst emails von contao verschickt? Evtl. könntest du mal versuchen emails via SMTP zu verschicken? (in den contao einstellungen)
ich geh mal davon aus, dass auch eine korrekte email adresse eingetragen ist? ;-)
gruss
Ja, das ist es offensichtlich. Ich habe nun den E-Mail-Versand auf SMTP umgestellt und jetzt funkts.
Woran kann es liegen, dass dies mit der internen Funktion nicht funktioniert?
Die Konfiguration zum Thema "mail", die ich in der php.ini (PHP 5.3.8) auf XAMPP gefunden habe:
- Internal Sendmail Support for Windows: enabled
- sendmail_from: no value
- sendmail_path: no value
- mail.add_x_header: Off
- mail.force_extra_parameters: no value
- mail.log: no value
Ich gehe einmal davon aus, dass ich hier "schrauben" muss.
Danke!
Wie sieht die Roadmap aus für die Extension – wann ist sie freigegeben für Contao 3.0.x?