Auf einem Linux Server, unter Plesk Version 10.4.4, Centos 5.8 läuft als Cron-Job zu einer festgelegten Zeit ein Backup von ein oder mehreren Webhosting-Paketen ab. Dies hat auch bis zum Micro Update #44 (MU#44) anstandslos funktioniert.
Das Problem
Doch auf einmal kommt eine Mail mit dem folgenden Betreff: „Backup/Restore task notification“ und dem Mail Inhalt, der darüber aufklärt, dass der „Task status is: error“ ist. Im Anhang dieser Mail ist eine Datei mit dem Namen „migration.result“ angehängt, die darüber aufklärt das die Datenbank nicht gesichert wurde, „Failed to execute backup database„.
Der folgende Artikel zeigt eine Lösung für das genannte Problem auf.
Die Datei mit dem Namen „migration.result“ hat dabei immer den mehr oder wenig gleichen Inhalt:
<?xml version="1.0" encoding="UTF-8"?> <execution-result status="error" log-location="/usr/local/psa/PMM/sessions/2012-11-02-084116.555/migration.result"> <object name="we-love-portugal.com" type="domain"> <object name="database_xy" type="mysql"> <message id="b5e13b8f-48f3-4fcb-8241-4f7fe3649a26" severity="error" code="msgtext"> <description>Failed to execute backup database</description> </message> </object> <object name="database_xy_2" type="mysql"> <message id="6366c7a5-92ff-4b89-838f-bc2975fe7519" severity="error" code="msgtext"> <description>Failed to execute backup database</description> </message> </object> </object> </execution-result>
Scheinbar hat das Micro Update #44 (MU#44) vom 9. Oktober ein Problem verursacht.
Die Lösung
Das Problem befindet sich in der Datei: $PRODUCT_ROOT_D/PMM/agents/shared/Db/MysqlShellBackend.pm Die Variable $PRODUCT_ROOT_D gegen die aktuellen Umgebungsvariablen ersetzen. Hier, im aktuellen Beispiel, ist das – kann aus der Datei migration.result entnommen werden – /usr/local/psa//PMM/agents/shared/Db/MysqlShellBackend.pm.
Die Datei mit Putty oder WinSCP öffnen und in die Zeile #52 gehen. Hier tauschen wir die Zeile, von:
print OPTSFILE "[mysqldump]\npassword=" . $self->{password};gegen:
print OPTSFILE "[mysqldump]\npassword=\"" . $self->{password} ."\"";Wichtig ist dabei der Unterschied, wie das Passwort maskiert wird; daran liegt es nämlich. Datei speichern und alles ist wieder gut.
Nachtrag
Eines noch zum Abschluss; es lohnt sich das /tmp Verzeichnis zu prüfen. In meinem Fall ist der Ordner mit wenigen GB ausgelegt und war nach der Störung komplett voll, sodass ich die ganzen dumps von Hand löschen musste.
Nochmals Achtung; mit den Micro Updates #45 und #46 (MU#45, MU#46) wurde die Einstellung wieder rückgängig gemacht. Also nach Update prüfen ob die Datei erneut geändert wurde.
Als Chefkoch arbeite ich als Systemadministrator und Programmierer. Hier blogge ich über Joomla, Magento, WordPress und Windows. In meiner Freizeit fotografiere ich viel, fahre mit meiner Yamaha XT660R oder Jogge durch die Gegend.