Aktionen

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

Aus znilwiki

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



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



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



4 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




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



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



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



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


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



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




11 Kommentare


elmacchiato@live.de

52 Monaten zuvor
Punktzahl 0++
Coole Tutorial. Leider läuft nach dem Wiederherstellen aus einem Backup und der Reparatur von mysql nach Deiner Anleitung mein Postfix nicht mehr. Hast da auch ein cooles Tutorial zu?

BLinz

52 Monaten zuvor
Punktzahl 0++

Leider nein - ich hatte postfix nicht genutzt - bin jetzt auch ganz weg von STRATO da ich ständig Probleme hatte. Ist die Datenbank von Plesk selbst denn noch heile geblieben?

Bernhard

cmosfett

51 Monaten zuvor
Punktzahl 0++
Ich habe heute die gleiche Erfahrung gemacht. Zunächst hatte ich nur das Original-Script von Parallels zum Abschalten des SSLv3-Poodle Problems (http://kb.sp…om/de/123160) auf meinem V-Server laufen lassen. Ich hatte mir darüber zuvor keine Sorgen gemacht, da Strato vollmundig sein tägliches, automatisches Backup als vollständige, Ein-Klick-Datensicherung bewirbt. Jedenfalls funktionierte nach dem Durchlaufen des Scripts und Neustart des Servers weder mein Webshop noch die Plesk-Verwaltungs-Software, übrigens mit der gleichen Fehlermeldung wie später, als ich mit dem Strato BackupControl-Tool den vorherigen Server-Stand vom Nachmittag vermeintlich wieder hergestellt hatte. Im Moment versuche ich einen Restore vom Vortag. Wenn das auch nichts bringt, werde ich Strato kündigen und mir einen anderen Dienstleister suchen.

Markus

46 Monaten zuvor
Punktzahl 0++
Danke, danke, danke! Ich hab ewig nach einer Lösung gesucht. So hats geklappt und alles ist wieder am laufen!

nochmal Markus

46 Monaten zuvor
Punktzahl 0++
Tja, leider funktioniert mein Postfix auch nicht mehr.... gibts eine Lösung?

und nochmal

46 Monaten zuvor
Punktzahl 0++
Ok, postfix deinstallieren und über Plesk (Komponente fehlt dann) wieder installieren. Dann funktioniert es wieder....

BLinz

46 Monaten zuvor
Punktzahl 0++

Tja,

wie schon weiter oben erwähnt nutze ich Plesk - und Strato - gar nicht mehr. Das Backup ist - mener Meinung nach - ein Flopp. Plesk ist schon eine großartige Software ... aber für Privat zu teuer. Ich nutze inzwischen einen Root-Server bei Kimsufi mit ISPConfig. Plesk kann zwar 10 mal mehr als ISPConfig - aber ist dafür kostenlos.

Aber noch mal zum Thema: DAS BACKUP VON STRATO TAUGT NICHTS! Kümmert euch selbst um ein Backup der Datenbanken (zum Beispiel mit mySQL Dumper) und eurer Dateien!

Bernhard

Christian

45 Monaten zuvor
Punktzahl 0++

Zu Deinem Tutorial fallen mir nur 3 Worte ein:

DANKE! DANKE! DANKE!

Andreas

44 Monaten zuvor
Punktzahl 0++

Ich muss mal so sagen... strato hilft schon weiter. Aber deine Beschreibung ist einfach bombe... Ich wis garnicht wie ich meine Dankbarkeit ausdrücken soll. Macht weiter so

Daumen hoch :)

Aquila

41 Monaten zuvor
Punktzahl 0++

Ich hätte es nicht mehr für möglich gehalten, aber Dank dieser Anleitung läuft die Seite tatsächlich wieder, auch wenn ich beim Datenbank-Backup den Fehler Error 2013: Lost connection to MySQL server during query when dumping table `sys_log` at row: 51884 wodurch einige Typo3 Inhalte verloren gingen.

Vielen Dank für das Zusammentragen und Aufbereiten der Informationen!

BLinz

41 Monaten zuvor
Punktzahl 0++

Trotzdem finde ich das das Strato Backup seinen Namen nicht verdient ... dem Betriebssystem zu sagen das gesichtert wird / ein Snapshot angelegt wird wäre doch das geringste Problem ... dann währe die Datenbank nämlich auch beim Zurücksichern noch in Ordnung.

Also wie schon zuvor beschrieben: Kümmert euch selbst um ein (externes) Backup eurer Datenbanken !!!!!

Mathias

40 Monaten zuvor
Punktzahl 0++
Wow...ich muss einfach mal DANKE sagen. Ich war langsam am Verzweifeln, weil ich seit 2 Tagen ohne Erfolg an diesem Problem gesessen habe. Diese Anleitung war meine Rettung, Danke!

typ@alobi.de

40 Monaten zuvor
Punktzahl 0++

Hallo. Ich habe das gleich Problem gehabt. Leider hat mir Strato den Verweis auf diese Seite erst 4 Tage nach meiner Anfrage geschickt. Auf Grund dieser Geschichte werde ich mir auch einen anderen Anbieter suchen und das obwohl ich seit Jahrenden mit eineigen Servern bei Strato bin: Der Grund sind genau diese Sicherungen. Wenn Strato die Sicherungen anbietet, ist auch Strato dafür verantwortlich, dass sie funktionieren. Ich habe 12 vollständige Sicherungen und alle sind defekt UND ich muss ab der 3 Überprüfung für jede weitere 1,90€ bezahlen UND jede Überprüfung hat minimum 24 Stunden gedauert UND das Zurückspielen der Sicherung hat auch mindestens 24 Stunden gedauert. Somit war ein Produktionsserver fast 6 Tage nicht erreichbar. Das ist nicht nur eine Frechheit, dass ist geschäftsschädigend. Natürlich ist mir klar, das Strato dank des Kleingedruckten nicht zu belangen sein wird, aber das Vertrauen ist komplett hin.

Mich würde interessieren, wie das andere "Leittragende" sehen.

Manuel

39 Monaten zuvor
Punktzahl 0++

Vor einigen Tagen wolle ich auf meinem Strato-VServer apache updaten. Apt hat in dem Prozess einfach fröhlich sämtliche Plesk-Module entfernt. Also habe ich den Restore versucht.

Habe nun exakt das gleiche Problem. Ich konnte deine Anleitung nachvollziehen, bis zu dem Punkt vor "Datenbanken wieder importieren". Mysql startet nicht. Es gibt keine Fehlermeldung, es bleibt einfach hängen, bis ich mit STRG+C abbreche.

Bin etwas verzweifelt, wenn ich versuche mysql per apt zu entfernen und neu zu installieren, passiert wieder das gleiche, wie zu Anfang, apt löscht alle Pleskmodule (k.a. warum).

Hast du einen Tipp, wo ich noch schauen könnte, warum mysql beim Start hängt? Im Ubuntuforum gibts darüber einen 5-Seitigen Thread ohne eindeutige Lösung.

BLinz

39 Monaten zuvor
Punktzahl 0++

hat der Abschnitt mit dem "Datenbanken neu aufbauen" geklappt? Dienst anhalten Verzeichnisinhalt löschen mysql_install_db

ansonsten musst du maal in das Log von mysql schauen warum es nicht startet (in der Regel unter \var\log\mysql\error.log)

Dierk

14 Monaten zuvor
Punktzahl 0++
Man muss bis zu 4!!! Stunden warten (war bei mir so), bis alles wieder eingespielt ist.

Andreas Schrder

39 Monaten zuvor
Punktzahl 0++

Herzlichen Dank für dieses Tutorial. Es hat mir mindestens 2 Tage Arbeit erspart.

WELTKLASSE!!!

Frank Ix - frankxberlin@gmx.de

38 Monaten zuvor
Punktzahl 0++

Hallo,

jetzt ist mein Kommentar fast nicht erschienen, weil ich fast übersehen hätte, dass keine Links gepostet werden dürfen. Deine Anleitung funktionierte bei mir, weil Du die DB neu erstellt hast. Anders als bei kb.odin.com/de/6586.

Strato verweist in seiner Supportmail übrigens auf Deine Seite:

"... vielen Dank für Ihre Anfrage, die ich Ihnen gerne beantworte.

Ich kann mir vorstellen, dass dies ärgerlich für Sie ist, ich bitte für die entstandenen Unannehmlichkeiten um Entschuldigung.

Es besteht die Möglichkeit, dass die Datenbank während eines Schreibprozesses gesichert wurden. Da wir Ihre Prozesse bei einem Backup nicht stoppen, kann das passieren. Das führt dazu, dass die Datenbank beschädigt wird. Darum auch unserer Hinweis im BackupControl.

Ich selbst kann hier von Außen leider nicht eingreifen. Jedoch gibt es im Internet dazu folgende Anleitung: znil.net/index.php?title=V-PowerServer_startet_nach_Wiederherstellung_eines_Backups_mit_BackupControl_nicht_-_mySQL_startet_nicht

Ich hoffe, meine Informationen waren hilfreich für Sie und für weitere Fragen stehen Ihnen meine Kollegen und ich gern zur Verfügung."

Dank und Gruß,

Frank Ix

Scholle

38 Monaten zuvor
Punktzahl 0++

Hey, danke für die Hilfe.

Ich musste allerdings noch die Postfix DB reparieren, damit auch wieder ankommen:

  1. /usr/local/psa/admin/sbin/mailmng --stop-service
  2. mv /var/spool/postfix/plesk/poplock.db /var/spool/postfix/plesk/poplock.db_
  3. /usr/local/psa/admin/sbin/mchk --with-spam
  4. /usr/local/psa/admin/sbin/mailmng --start-service

Thomas

37 Monaten zuvor
Punktzahl 0++

Herzlichen Dank für dieses super Tutorial!

Ich war schon am Verzweifeln...

Fabian

37 Monaten zuvor
Punktzahl 0++

Vielen Dank Znil für diesen Artikel, hat auch mir weiter geholfen.

Schade dass ihr keinen Button zum Spenden habt ;-)

Frohe Feiertage!

Daniel

36 Monaten zuvor
Punktzahl 0++
Da diese Anleitung bei mir leider nicht gegriffen hatte, habe ich einfach ein wenig probiert. Es half bei mir tatsächlich schon die Dateien (Datenbanken) nach der Serverwiederherstellung vom Ordner /var/lib/mysql in einen anderen Ordner zu sichern, dann alle Dateien im Ordner /var/lib/mysql löschen, mysql stoppen und mit mysql_install_db wieder neu aufbauen. Beim Neuaufbau direkt den admin wieder mit dem alten Passwort anlegen und ihm alle Rechte geben. Danach die zuvor gesicherten Dateien wieder zurück nach /var/lib/mysql und dann allen Dateien den Eigentümer mysql:mysql mit chown zuweisen. Danach den mysql wieder starten und siehe da, es ging alles. Kann natürlich auch Glück gewesen sein aber man kann es ja mal testen wenn ohnehin nichts mehr läuft :-)

Dierk

14 Monaten zuvor
Punktzahl 0++

Danke, danke, danke!

Das war die einzige Anleitung, die mir wirklich helfen konnte. Super geschrieben, danke!
Kommentar hinzufügen
znilwiki freut sich über alle Kommentare. Sofern du nicht anonym bleiben möchtest, trage deinen Namen oder deine Email-Adresse ein oder melde dich an. Du kannst das Feld auch einfach leer lassen.