Probleme mit Plesk automatisches Backup via FTP
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 79249
Url: https://administrator.de/forum/probleme-mit-plesk-automatisches-backup-via-ftp-79249.html
Ausgedruckt am: 23.12.2024 um 20:12 Uhr
17 Kommentare
Neuester Kommentar
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.
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.
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.