gelöst Probleme mit Plesk automatisches Backup via FTP
member31 (Level 1) - Jetzt verbinden
27.01.2008, aktualisiert 13.03.2008, 11398 Aufrufe, 17 Kommentare
Hallo ich habe seit längerem bzw. schon immer das Problem das meine automatisierten Backups (Plesk) die anschließend per FTP verschoben werden ca. 5-8 Tage reibungslos laufen und dann hört das Backup plötzlich auf und erst nach einem reboot vom Server geht das Backup wieder für diese besagte Zeit. Bis jetzt konnte ich den Fehler noch nicht finden, wenn ich nur Plesk neu starte geht es nicht, immer nur nach einem kompletten reboot alle anderen crons usw. laufen einwandfrei. Kann mir ev. jemand einen Tipp geben was das ev. sein könnte?
Rootserver bei Strato
Plesk 8.3.0
Suse 10.2
MySQL/PHP 5.0
Rootserver bei Strato
Plesk 8.3.0
Suse 10.2
MySQL/PHP 5.0
17 Antworten
- LÖSUNG theton schreibt am 27.01.2008 um 13:29:54 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 13:40:02 Uhr
- LÖSUNG theton schreibt am 27.01.2008 um 13:53:10 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 14:02:05 Uhr
- LÖSUNG theton schreibt am 27.01.2008 um 14:16:39 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 14:20:48 Uhr
- LÖSUNG theton schreibt am 27.01.2008 um 14:26:18 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 14:31:00 Uhr
- LÖSUNG theton schreibt am 27.01.2008 um 14:33:56 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 14:36:29 Uhr
- LÖSUNG theton schreibt am 27.01.2008 um 14:37:57 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 14:39:49 Uhr
- LÖSUNG member31 schreibt am 05.02.2008 um 00:21:38 Uhr
- LÖSUNG theton schreibt am 05.02.2008 um 00:35:41 Uhr
- LÖSUNG member31 schreibt am 05.02.2008 um 00:40:41 Uhr
- LÖSUNG theton schreibt am 05.02.2008 um 00:56:40 Uhr
- LÖSUNG member31 schreibt am 13.03.2008 um 00:25:56 Uhr
- LÖSUNG theton schreibt am 05.02.2008 um 00:56:40 Uhr
- LÖSUNG member31 schreibt am 05.02.2008 um 00:40:41 Uhr
- LÖSUNG theton schreibt am 05.02.2008 um 00:35:41 Uhr
- LÖSUNG member31 schreibt am 05.02.2008 um 00:21:38 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 14:39:49 Uhr
- LÖSUNG theton schreibt am 27.01.2008 um 14:37:57 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 14:36:29 Uhr
- LÖSUNG theton schreibt am 27.01.2008 um 14:33:56 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 14:31:00 Uhr
- LÖSUNG theton schreibt am 27.01.2008 um 14:26:18 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 14:20:48 Uhr
- LÖSUNG theton schreibt am 27.01.2008 um 14:16:39 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 14:02:05 Uhr
- LÖSUNG theton schreibt am 27.01.2008 um 13:53:10 Uhr
- LÖSUNG member31 schreibt am 27.01.2008 um 13:40:02 Uhr
LÖSUNG 27.01.2008 um 13:29 Uhr
Trag mal in deine Crontab eine MAILTO-Zeile ein, entferne evtl. gesetzte Ausgabe-Umleitungen für die Crons und schau was an Fehlern produziert wird. Also einfach an den Anfang ein
MAILTO=deine@emailadresse.tld
MAILTO=deine@emailadresse.tld
LÖSUNG 27.01.2008 um 13:40 Uhr
Hallo ist ja schon lange eingetragen, darüber erhalte ich keinen Fehler.
Trotzdem vielen Dank Ich denke das hat irgendwas mit dem backupmanager (backupmng) zu tun nur was
Gruß Markus
Trotzdem vielen Dank Ich denke das hat irgendwas mit dem backupmanager (backupmng) zu tun nur was
Gruß Markus
LÖSUNG 27.01.2008 um 13:53 Uhr
Ist auch die Ausgabe-Umleitung (also das '>/dev/null 2>&1') am Ende des Crontab-Eintrags rausgenommen? Wenn ich mich recht erinnere ist das per Default bei Plesk eingetragen. Ich kann mir irgendwie nicht vorstellen, dass es keinen Fehleroutput gibt oder die Fehlermeldungen wenigstens irgendwo geloggt werden. Hab leider gerade keinen Server mit Plesk parat um genauer nachschauen zu können. Evtl. hilft auch ein
grep -r "backup" /var/log/*
weiter um zugehörige Fehlermeldungen in den Logs zu finden.
grep -r "backup" /var/log/*
weiter um zugehörige Fehlermeldungen in den Logs zu finden.
LÖSUNG 27.01.2008 um 14:02 Uhr
Die Ausgabe-Umleitung ('>/dev/null 2>&1') ist noch drin, für was muss diese raus? Damit ich eine Fehlermeldung erhalte?
LÖSUNG 27.01.2008 um 14:16 Uhr
Diese Ausgabeumleitung nach /dev/null sorgt dafür, dass sämtlicher Output in's Nirvana geschickt wird. Zugemailt bekommst du aber nur Sachen, die nicht irgendwohin umgeleitet werden und somit auf STDOUT bzw. STDERR ausgegeben werden. Beispiel ein Hello-World als Perl-Skript im Cron:
Skript:
#!/usr/bin/perl
print "Hello World";
Cron-Eintrag 1:
*/5 * * * * root /pfad/zum/skript.pl
Cron-Eintrag 2:
*/5 * * * * root /pfad/zum/skript.pl > /var/log/hello.log
Cron-Eintrag 3:
*/5 * * * * root /pfad/zum/skript.pl > /dev/null
Cron-Eintrag 4:
*/5 * * * * root /pfad/zum/skript.pl > /dev/null 2>&1
Eintrag 1 sorgt dafür, dass die Ausgabe auf STDOUT erfolgt. Ist in der Crontab ein Mailto gesetzt, wird der Output an die angegebene Adresse gesendet sofern ein lokaler Mailserver zu Verfügung steht (einfach mal mit dem Programm 'mail' auf der Konsole eine Mail verschicken um zu sehen ob es funktioniert).
Eintrag 2 sorgt dafür, dass die Ausgabe statt auf STDOUT in die Datei /var/log/hello.log geschrieben wird.
Eintrag 3 sorgt dafür, dass sämtliche Sachen, die normalerweise auf STDOUT ausgegeben werden im Nirvana landen (/dev/null ist quasi der Sofort-Mülleimer des Systems).
Eintrag 4 sorgt dafür, dass sowohl Sachen, die auf STDOUT, als auch die auf STDERR ausgegeben werden im Nirvana landen.
Skript:
#!/usr/bin/perl
print "Hello World";
Cron-Eintrag 1:
*/5 * * * * root /pfad/zum/skript.pl
Cron-Eintrag 2:
*/5 * * * * root /pfad/zum/skript.pl > /var/log/hello.log
Cron-Eintrag 3:
*/5 * * * * root /pfad/zum/skript.pl > /dev/null
Cron-Eintrag 4:
*/5 * * * * root /pfad/zum/skript.pl > /dev/null 2>&1
Eintrag 1 sorgt dafür, dass die Ausgabe auf STDOUT erfolgt. Ist in der Crontab ein Mailto gesetzt, wird der Output an die angegebene Adresse gesendet sofern ein lokaler Mailserver zu Verfügung steht (einfach mal mit dem Programm 'mail' auf der Konsole eine Mail verschicken um zu sehen ob es funktioniert).
Eintrag 2 sorgt dafür, dass die Ausgabe statt auf STDOUT in die Datei /var/log/hello.log geschrieben wird.
Eintrag 3 sorgt dafür, dass sämtliche Sachen, die normalerweise auf STDOUT ausgegeben werden im Nirvana landen (/dev/null ist quasi der Sofort-Mülleimer des Systems).
Eintrag 4 sorgt dafür, dass sowohl Sachen, die auf STDOUT, als auch die auf STDERR ausgegeben werden im Nirvana landen.
LÖSUNG 27.01.2008 um 14:20 Uhr
Vielen Dank, dann nehme ich es mal raus und mal schauen was passiert. Komisch ist halt echt das ich den kompletten Server neu starten muss damit die backup-tasks wieder funktionieren, ein plesk restart alleine hilft da nicht...
LÖSUNG 27.01.2008 um 14:26 Uhr
Hast du mal überprüft ob evtl. der Cron-Daemon crasht und das Problem vielleicht garnicht bei Plesk liegt? Also mal mit 'ps ax | grep cron' schauen ob dann der Cron-Daemon noch läuft.
LÖSUNG 27.01.2008 um 14:31 Uhr
Wenn dies der Fall wäre, dann dürften Dinge wie Statistiken usw. ja auch nicht laufen aber diese laufen ja alle einwandfrei...oder liege ich da falsch?
LÖSUNG 27.01.2008 um 14:33 Uhr
Kommt drauf an wie die Statistiken gemacht werden, aber sofern das auch über Cronjobs passiert, liegst du da richtig. War halt eine Möglichkeit. Ich kenne ja die Details des Servers nicht und manchmal übersieht man die einfachsten Sachen.
LÖSUNG 27.01.2008 um 14:36 Uhr
Ja das läuft auch über die crons und zwar dieser hier:
/usr/local/psa/bin/run-parts.sh /etc/psa/plesk-cron.daily
der ist für die täglichen Auswertungen zuständig.
/usr/local/psa/bin/run-parts.sh /etc/psa/plesk-cron.daily
der ist für die täglichen Auswertungen zuständig.
LÖSUNG 27.01.2008 um 14:37 Uhr
Nunja, dann schau mal was du beim nächsten Ausfall an Meldungen bekommst.
LÖSUNG 27.01.2008 um 14:39 Uhr
Ja bin mal gespannt, vielen vielen Dank für deine Bemühungen Melde mich wenn ich was neues in Erfahrung gebracht habe...
LÖSUNG 05.02.2008 um 00:21 Uhr
Hallo, so nach 6 Tagen sind die Backups abgebrochen, erst kam folgende Meldung:
Following error is occured during scheduled backup process:
Error in BackupState.doActivityRunner()
Traceback (most recent call last):
File "/usr/local/psa/admin/share/agent_runner/agent_runner.py", line 98, in doActivityRunner
newState = self.doActivity()
File "/usr/local/psa/admin/share/agent_runner/agent_runner.py", line 391, in doActivity
errtxt = runAgent(self, self.session)
File "/usr/local/psa/admin/share/agent_runner/agent_runner.py", line 258, in runAgent
cmd.spawn()
File "/usr/local/psa/admin/lib/python/subproc.py", line 238, in spawn
proc.run()
File "/usr/local/psa/admin/lib/python/subproc.py", line 193, in run
BaseSubprocess.run(self)
File "/usr/local/psa/admin/lib/python/subproc.py", line 177, in run
self.wait()
File "/usr/local/psa/admin/lib/python/subproc.py", line 197, in wait
BaseSubprocess.wait(self)
File "/usr/local/psa/admin/lib/python/subproc.py", line 187, in wait
raise NonzeroExitException(self, os.WEXITSTATUS(status))
NonzeroExitException: was finished with exit code 9
dann kam einen weitere Meldung:
backupmng: Unable to connect to Plesk Database: Too many connections
backupmng: Unable to connect to Plesk Database: Too many connections
backupmng: Unable to connect to the mysql database
backupmng: Unable to connect to the mysql database
und das war es dann, nach Neustart ging es wieder,jetzt warte ich mal ob sich diese Meldungen wiederholen.
Following error is occured during scheduled backup process:
Error in BackupState.doActivityRunner()
Traceback (most recent call last):
File "/usr/local/psa/admin/share/agent_runner/agent_runner.py", line 98, in doActivityRunner
newState = self.doActivity()
File "/usr/local/psa/admin/share/agent_runner/agent_runner.py", line 391, in doActivity
errtxt = runAgent(self, self.session)
File "/usr/local/psa/admin/share/agent_runner/agent_runner.py", line 258, in runAgent
cmd.spawn()
File "/usr/local/psa/admin/lib/python/subproc.py", line 238, in spawn
proc.run()
File "/usr/local/psa/admin/lib/python/subproc.py", line 193, in run
BaseSubprocess.run(self)
File "/usr/local/psa/admin/lib/python/subproc.py", line 177, in run
self.wait()
File "/usr/local/psa/admin/lib/python/subproc.py", line 197, in wait
BaseSubprocess.wait(self)
File "/usr/local/psa/admin/lib/python/subproc.py", line 187, in wait
raise NonzeroExitException(self, os.WEXITSTATUS(status))
NonzeroExitException: was finished with exit code 9
dann kam einen weitere Meldung:
backupmng: Unable to connect to Plesk Database: Too many connections
backupmng: Unable to connect to Plesk Database: Too many connections
backupmng: Unable to connect to the mysql database
backupmng: Unable to connect to the mysql database
und das war es dann, nach Neustart ging es wieder,jetzt warte ich mal ob sich diese Meldungen wiederholen.
LÖSUNG 05.02.2008 um 00:35 Uhr
backupmng: Unable to connect to Plesk Database: Too many connections
Offenbar bleiben dort einige MySQL-Verbindungen hängen oder die max-connections-Zahl für MySQL ist zu niedrig eingestellt. Mach mal beim nächsten Mal ein
mysql -u root -p
Password: <hier-das-db-root-passwort-blind-eingeben>
Und lasse dir im MySQL-Client dann mit 'show processlist' die offenen Verbindungen anzeigen. Am Ende gibt er dir dann auch aus wieviele Verbindungen gerade offen sind. Sind es zum Zeitpunkt, an dem du nachschaust, nicht ungewöhnlich viele, ist es scheinbar nur ein temporäres Problem und eine zeitliche Verschiebung der Backups sollte Abhilfe schaffen. Ist die MySQL-Prozessliste immernoch voll, wenn du nachschaust, solltest du verifizieren auf welcher Datenbank und Tabelle die meisten Zugriffe sind und entsprechend etwas dagegen tun. Alternativ schraubst du halt die maximal erlaubten Verbindungen hoch.
Offenbar bleiben dort einige MySQL-Verbindungen hängen oder die max-connections-Zahl für MySQL ist zu niedrig eingestellt. Mach mal beim nächsten Mal ein
mysql -u root -p
Password: <hier-das-db-root-passwort-blind-eingeben>
Und lasse dir im MySQL-Client dann mit 'show processlist' die offenen Verbindungen anzeigen. Am Ende gibt er dir dann auch aus wieviele Verbindungen gerade offen sind. Sind es zum Zeitpunkt, an dem du nachschaust, nicht ungewöhnlich viele, ist es scheinbar nur ein temporäres Problem und eine zeitliche Verschiebung der Backups sollte Abhilfe schaffen. Ist die MySQL-Prozessliste immernoch voll, wenn du nachschaust, solltest du verifizieren auf welcher Datenbank und Tabelle die meisten Zugriffe sind und entsprechend etwas dagegen tun. Alternativ schraubst du halt die maximal erlaubten Verbindungen hoch.
LÖSUNG 05.02.2008 um 00:40 Uhr
Hallo vielen Dank, werde ich dann mal austesten, habe aber alle backups 15min zeitlich versetzt vielleicht sollte ich das ev. auch noch mal erhöhen. Zu diesem Zeitpunkt wo der Ausstieg war gab es auch Probleme mit dem smtp zwecks überlastung deshalb warte ich jetzt mal was beim nächsten Abbruch an Fehlermeldung kommt...
Wünsche ein Gute Nacht
Wünsche ein Gute Nacht
LÖSUNG 05.02.2008 um 00:56 Uhr
Der SMTP-Server könnte durchaus die Ursache sein, da Plesk seine Benutzerdaten für den Mailserver in einer MySQL-DB speichert und somit bei jeder Mail Datenbankanfragen gemacht werden.
LÖSUNG 13.03.2008 um 00:25 Uhr
Hallo Theton, so jetzt läuft das Backup seit ca. 2Monaten durch, es lag an den kurzen Zeiten die ich zwischen den Backups eingerichtet hatte. Ich habe jetzt jedes Backup um 30min. zeitlich versetzt und über den ganzen Tag verteilt, seitem läuft es bestens. Vielen Dank nochmal, erst durch gewisse Hilfestellungen von Dir kam ich der Sache auf die Spur
Gruß Member31
Gruß Member31
Ähnliche Inhalte
Neue Wissensbeiträge
Heiß diskutierte Inhalte
