Quelltext der Seite V-PowerServer startet nach Wiederherstellung eines Backups mit BackupControl nicht - mySQL startet nicht


[[Kategorie:Linux]]
[[Kategorie:STRATO]]
[[Kategorie:Webserver]]
==Vorwort==
Zum Zeitpunkt als ich diesen Artikel geschrieben habe nutze diese Webseite einen '''''V-PowerServer''''' von STRATO. Hinzugebucht hatte ich '''''BackupControl''''' was ein tägliches Backup des kompletten Servers verspricht mit einfacher Wiederherstellung.<br>
<br>
Leider musste ich die Option schon 2 mal ziehen, beim ersten mal aus Faulheit (hatte es verkonfiguriert), beim zweiten mal weil die Disk-Quota vollgelaufen war und nun kein Prozess mehr temporäre Dateien erstellen konnte.<br>
<br>
Nachdem ich die Wiederherstellung angestoßen hatte, dauerte es jedes mal etwa eine Stunde, dann war der Server wieder erreichbar. Leider startete beide male der mySQL-Server auf Grund von Fehlern in der Datenbank nicht. Das liegt aus meiner Sicht daran, das STRATO bei der Sicherung nicht mit Snapshots und Stilllegung des Dateisystems arbeitet - die Dateien werden einfach im laufenden Betrieb kopiert. Bei Dateien an denen gerade etwas geändert wird kann das aber eine blöde Idee sein - insbesondere wenn es mehrere Dateien sind die zusammen gehören.<br>
<br>
Eine Datenbank besteht in der Regel immer aus mindestens 2 Dateien: Der eigentlichen Datenbank-Datei und der Log-Datei (auch Transaktions-Datei genannt). In die Log-Datei wird geschrieben was als nächstes geändert wird, dann wird es in die Datenbank geschrieben und zum Schluss wird der Erfolg wieder in der Log-Datei verzeichnet. Passen die Log Datei und die Datenbank-Datei nicht zusammen, kann die Datenbank nicht gestartet werden (das ist nicht nur bei mySQL so, auch z.B. der Microsoft SQL Server funktioniert so).<br>
<br>
Wenn wir nun also einfach im laufenden Betrieb die Datenbank-Dateien wegkopieren, kopieren wir z.B. erst die Datenbank-Datei. Die ist groß, es dauert also ein paar hundert Millisekunden oder sogar Sekunden. Danach, also später, wird die Log Datei kopiert. Gab es in diesen Zeitraum eine Änderung in der Datenbank, wird die Log-Datei neuer sein als die Datenbank-Datei, die beiden Dateien haben unterschiedliche Änderungs-Zeiten. Und somit passen die nicht mehr zusammen, die Datenbank wird nicht starten.<br>
<br>
Es ist also Glückssache ob eine Sicherung nach dieser Methode funktioniert - zumindest für Datenbanken.
<br>
Nachfolgend ist eine Methode das ganze wieder zum laufen zu bekommen. Ich habe natürlich vom ersten mal gelernt und deshalb immer Backups meiner Datenbanken, also Dumps der Datenbanken, die regelmäßig und automatisch erstellt werden. Trotzdem ist es mühsam damit den Server wieder herzustellen. Die nachfolgende Methode kann zumeist schneller sein.<br>
<br>
<br>
----
==Ausgangslage==
Wir haben unseren ''''V-PowerServer''''' per '''''BackupControl''''' wiederherstellen lassen. Nachdem wir das ganze über die Mangement-Oberfläche von STRATO gestartet haben, ließen wir einen Dauerping auf den Server laufen:<br>
 ping znil.net -t
Nach kurzer Zeit lief der Ping ins leere, nach etwa einer Stunde fand der Ping wieder sein Ziel.<br>
<br>
Ein Aufruf der Webseite oder der Plesk-Oberfläche ist nun jedoch nicht möglich, es wird im Browser ein Fehler bei der Verbindung zur Datenbank gemeldet.<br>
<br>
Wir können uns aber per SSH /puTTY noch auf den Server verbinden.<br>
<br>
<br>
----
==Datenbank trotz Fehler starten und sichern==
Wir starten eine SSH-Sitzung auf unserem Server und wechseln zum <code>root</code> Benutzer:
 sudo -i
<br>
Dann versuchen wir noch einmal den mySQL-Server zu starten:<br>
 /etc/init.d/mysql start
Ich nehme hier den '''init.d''' Weg weil da mehr Text ausgegeben wird, sprich man sieht auch Fehlermeldungen.<br>
wenn es nun klappt - super! Ansonsten machen wir wie folgt weiter:<br>
Wir prüfen einmal das Fehler-Log von mySQL:
 cat /var/log/mysql/error.log
Da werden solltet Ihr einen Fehler finden das die InnoDB nicht geladen werden konnte (bzw. viel bla bla mit den Hinweis das die Datenbank eventuelle einen Fehler hat). Da steht zwar auch das es eventuell eine Fehler in mySQL ist, das können wir aber wohl ausschließen.<br>
<br>
Wir bearbeiten nun die Konfigurationsdatei von mySQL
 nano /etc/mysql/my.cnf
und suchen den Abschnitt
 [mysqld]
Direkt darunter fügen wir eine neue Zeile ein und schreiben in diese
 innodb_force_recovery = 4
Es muss also so aussehen:<br>
 [mysqld]
 innodb_force_recovery = 4
speichert die Datei und beendet den Editor.<br>
Versucht nun noch einmal mySQL neu zu starten:<br>
 /etc/init.d/mysql start
klappt das nun mach mit den nächsten Schritt weiter. Gibt es immer noch einen Fehler, setzt in der <code>my.cnf</code> die Werte langsam nach oben auf 5, 6, 7 etc. - nach jeder Erhöhung speichern und wieder einen Start des Dienstes versuchen bis es klappt.<br>
<br>
Ist die Datenbank/mySQL nun gestartet, exportieren wir nun alle Daten/Datenbanken darin in eine Datei:<br>
 mysqldump -uadmin -p`cat /etc/psa/.psa.shadow` -A > /root/dumpall.sql
Der Dump wird mit dem Benutzer "admin" und dem Passwort aus der ".psa.shadow" ausgeführt. Wenn dies nicht klappt, also er auch sagt das sich der Benutzer nicht anmelden kann, versucht es noch einmal mit
 mysqldump -A > /root/dumpall.sql 
Dann wird das ganze als Benutzer "root" gemacht. Macht Lösung 2 aber nur wenn Lösung 1 nicht klappt!
<br>
Klappt der Export ohne Fehlermeldung können wir weiter machen. Gibt es einen Fehler beim Export so
* Stoppt den mySQL Server wieder
* Erhöht den Wert von <code>innodb_force_recovery</code> um 1
* Startet den mySQL Server wieder
und probiert den Export noch einmal bis es klappt.<br>
<br>
<br>
----

==Datenbank neu aufbauen==
Nun haben wir also eine erfolgreiche Kopie aller Datenbanken.<br>
Wir löschen nun alle Datenbanken und erstellen eine neue, saubere Datenbank-Struktur.<br>
<br>
Beendet den mySQL-Server wieder:<br>
 /etc/init.d/mysql stop
Kommentiert die Zeile mit <code>innodb_force_recovery</code> wieder aus der <code>my.cnf</code> aus:<br>
 nano /etc/mysql/my.cnf
 [mysqld]
 # innodb_force_recovery = 4
Löscht den Inhalt des Datenbank-Verzeichnisses von mySQL:<br>
 rm -rf /var/lib/mysql/*
Erstellt die Grund-Datenbanken wieder neu:<br>
 mysql_install_db
Startet mySQL wieder
 /etc/init.d/mysql start
<br>
<br>
----
==Datenbanken wieder importieren==
In der nun neuen und leeren Datenbank gibt es noch "nichts", also auch noch keine Benutzer. Deshalb arbeiten wir in mySQL zunächst als "root" weiter.<br>
Wir Importieren die zuvor gesicherten Daten wie folgt:<br>
 mysql < /root/dumpall.sql
<br>
Nun müssen wir noch den Admin-Benutzer für Plesk noch wieder herstellen.<br>
<br>
<br>
----
==Plesk Admin wiederherstellen==
Als Vorbereitung lassen wir uns das Passwort des Admins Benutzers anzeigen und kopieren es uns einmal weg (oder wir arbeiten mit 2 SSH Sitzungen gleichzeitig):<br>
 cat /etc/psa/.psa.shadow
Das Passwort sollte ähnlich wie folgt aussehen:<br>
 $AES-128-CBC$wRfzDaQSRSSfDpUVRA15OGPeQ==$57oj3Xtxv4EBSVCkiqq==
Wir starten eine mySQL Eingabeaufforderung mit
 mysql
Dann geben wir den Benutzer '''''admin''''' alle Rechte:<br>
 GRANT ALL PRIVILEGES ON *.* TO 'admin'@'localhost' WITH GRANT OPTION;
 FLUSH PRIVILEGES;
und setzen das Kennwort für den Benutzer:<br>
 SET PASSWORD FOR 'admin'@'localhost' = PASSWORD('$AES-128-CBC$wRfzDaQSRSSfDpUVRA15OGPeQ==$57oj3Xtxv4EBSVCkiqq==');
In die Hochkommas setzt Ihr genau die Zeichenfolge die wir zuvor aus der <code>/etc/psa/.psa.shadow</code> ausgelesen haben.<br>
Mit
 quit;
Melden wir uns wieder von mySQL ab.<br>
Nun testen wir ob wir Erfolg hatten:<br>
 mysql -uadmin -p`cat /etc/psa/.psa.shadow`
Bekommen wir nun wieder eine mySQL Konsole hat alles geklappt.<br>
<br>
<br>
----

==Dienste neu starten und Tests==
Starten nun mySQL und Apache neu (reine Vorsichtsmaßnahme):<br>
 /etc/init.d/mysql stop
 service mysql start
 service apache2 restart
<br>
Versucht nun ob eure Webseiten und die Plesk-Oberfläche wieder zu erreichen ist - das sollte nun so sein.<br>
<br>
<br>
----
==Plesk Fehler Abonnement / Subscription beheben==
Falls Ihr in der Plesk-Oberfläche danach noch Fehler z.B. in der Datenbankverwaltung wie
 Warning: The subscription is temporarily unavailable because the data backup or restoration is in progress. Please try again later.
habt (im deutschen steht da was von Abonnement) macht in der SSH Sitzung noch folgendes
 /usr/local/psa/bin/domain --on h2159108.stratoserver.net
der "Domänenname" hinten ist der Name unter dessen Domäne euer STRATO Server läuft (steht auch immer oben in der Plesk-Oberfläche).
Solltet Ihr mehre Abonnements/Webspaces haben reicht es wenn Ihr das ganze für eines davon macht, vorzugsweise dem welches zuerst da war.
<br>
<br>
----
==Postfix reparieren==
'''''Scholle''''' hat unten in den Kommentaren noch beschrieben wie man den Postfix wieder zum laufen bekommt wenn dieser auch rumzickt.<br>
 /usr/local/psa/admin/sbin/mailmng --stop-service 
 mv /var/spool/postfix/plesk/poplock.db /var/spool/postfix/plesk/poplock.db_ 
 /usr/local/psa/admin/sbin/mchk --with-spam 
 /usr/local/psa/admin/sbin/mailmng --start-Service
Eine andere Möglichkeit ist die Deinstallation von Postfix über das Plesk Interface mit anschließender Neuinstallation (so wie '''''Markus''''' es gemacht hat.<br>
<br>
<br>
----

==Quellen==
Die ganzen Infos habe ich mir aus den folgenden Webseiten zusammengesucht und zu einem neuen ganzen zusammengefügt. Wie immer stand auf keiner Seite '''DIE''' Lösung, aber aus den ganzen Schnipseln konnte ich mir meinen Weg zusammenreimen:<br>
* http://kb.parallels.com/de/116916
* http://forum.parallels.com/showthread.php?110517-Changed-mySQL-admin-password-broken-Plesk
* http://kb.parallels.com/en/112492
* http://forum.parallels.com/showthread.php?288452-Issue-after-update-to-11-5-30-Warning!-The-subscription-is-temporarily-unavailable
* http://www.loboweb.eu/node/282
* http://stackoverflow.com/questions/1135245/how-to-get-a-list-of-mysql-user-accounts
<br>
<br>
----

==Kommentare==
<comments />