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

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.

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.

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.

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).

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.

Es ist also Glückssache ob eine Sicherung nach dieser Methode funktioniert - zumindest für Datenbanken.
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.

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:

ping znil.net -t

Nach kurzer Zeit lief der Ping ins leere, nach etwa einer Stunde fand der Ping wieder sein Ziel.

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.

Wir können uns aber per SSH /puTTY noch auf den Server verbinden.

Datenbank trotz Fehler starten und sichern

Wir starten eine SSH-Sitzung auf unserem Server und wechseln zum root Benutzer:

sudo -i

Dann versuchen wir noch einmal den mySQL-Server zu starten:

/etc/init.d/mysql start

Ich nehme hier den init.d Weg weil da mehr Text ausgegeben wird, sprich man sieht auch Fehlermeldungen.
wenn es nun klappt - super! Ansonsten machen wir wie folgt weiter:
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.

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:

[mysqld]
innodb_force_recovery = 4

speichert die Datei und beendet den Editor.
Versucht nun noch einmal mySQL neu zu starten:

/etc/init.d/mysql start

klappt das nun mach mit den nächsten Schritt weiter. Gibt es immer noch einen Fehler, setzt in der my.cnf 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.

Ist die Datenbank/mySQL nun gestartet, exportieren wir nun alle Daten/Datenbanken darin in eine Datei:

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!
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 innodb_force_recovery um 1
Startet den mySQL Server wieder

und probiert den Export noch einmal bis es klappt.

Datenbank neu aufbauen

Nun haben wir also eine erfolgreiche Kopie aller Datenbanken.
Wir löschen nun alle Datenbanken und erstellen eine neue, saubere Datenbank-Struktur.

Beendet den mySQL-Server wieder:

/etc/init.d/mysql stop

Kommentiert die Zeile mit innodb_force_recovery wieder aus der my.cnf aus:

nano /etc/mysql/my.cnf
[mysqld]
# innodb_force_recovery = 4

Löscht den Inhalt des Datenbank-Verzeichnisses von mySQL:

rm -rf /var/lib/mysql/*

Erstellt die Grund-Datenbanken wieder neu:

mysql_install_db

Startet mySQL wieder

/etc/init.d/mysql start

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.
Wir Importieren die zuvor gesicherten Daten wie folgt:

mysql < /root/dumpall.sql

Nun müssen wir noch den Admin-Benutzer für Plesk noch wieder herstellen.

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):

cat /etc/psa/.psa.shadow

Das Passwort sollte ähnlich wie folgt aussehen:

$AES-128-CBC$wRfzDaQSRSSfDpUVRA15OGPeQ==$57oj3Xtxv4EBSVCkiqq==

Wir starten eine mySQL Eingabeaufforderung mit

mysql

Dann geben wir den Benutzer admin alle Rechte:

GRANT ALL PRIVILEGES ON *.* TO 'admin'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;

und setzen das Kennwort für den Benutzer:

SET PASSWORD FOR 'admin'@'localhost' = PASSWORD('$AES-128-CBC$wRfzDaQSRSSfDpUVRA15OGPeQ==$57oj3Xtxv4EBSVCkiqq==');

In die Hochkommas setzt Ihr genau die Zeichenfolge die wir zuvor aus der /etc/psa/.psa.shadow ausgelesen haben.
Mit

quit;

Melden wir uns wieder von mySQL ab.
Nun testen wir ob wir Erfolg hatten:

mysql -uadmin -p`cat /etc/psa/.psa.shadow`

Bekommen wir nun wieder eine mySQL Konsole hat alles geklappt.

Dienste neu starten und Tests

Starten nun mySQL und Apache neu (reine Vorsichtsmaßnahme):

/etc/init.d/mysql stop
service mysql start
service apache2 restart

Versucht nun ob eure Webseiten und die Plesk-Oberfläche wieder zu erreichen ist - das sollte nun so sein.

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.

Postfix reparieren

Scholle hat unten in den Kommentaren noch beschrieben wie man den Postfix wieder zum laufen bekommt wenn dieser auch rumzickt.

/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.

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:

Kommentare

Loading comments...