Strato VServer Backup, aber richtig!?

[daralla]

Hallo zusammen.

Nachdem ich einen guten Teil des letzten Wochenendes damit verbracht habe meinen Strato VServer nach crash neu aufzusetzen stellt sich die Frage wie das in Zukunft mit weniger Aufwand gehen könnte.

Die Fakten...

1. Der Crash. Selbst verursacht vermutlich, obwohl mir der genaue Grund wohl immer rätselhaft bleiben wird. Jedenfalls hatte ich vor zwei Wochen für eine Owncloud Server Instanz redis als Memcache installiert, das dann auch problemlos zu laufen schien. Im Zuge der redis Installation wurde das zuvor genutzte apcu de-installiert, woraufhin sich ein Wordpress cache-plugin beschwerte. In dessen Einstellungen konnte man alternativ auch redis als Cache nutzen (als experimentell gekennzeichnet), was ich aktiviert habe .
Und das wars dann. Unmittelbar darauf kein Zugriff auf den Server per SSH mehr möglich, nach reboot über die Strato Verwaltung ging SSH wieder, aber mysql startete nicht mehr, auch nicht manuell. logs blieben leer. Plesk war logischerweise auch tot ohne mysql.

2. Backup / Restore. Die automatisch angelegten Strato Backups erschienen mir als letzte Chance, obwohl ich schon wusste, daß deren Sicherungsmethode mit mysql wohl nicht recht kompatibel ist, da einfach ohne vorherige Datenbank dumps "live" weggesichert wird. So war dann auch das Ergebnis, mysql lief immer noch nicht, mit drei verschiedenen wiederhergestellten Backups.

3. Neuanfang. Also, Neuinstallation des ganzen Systems, danach Restore eines Plesk Backups. Das funktionierte leidlich, mysql lief wieder, alle Domains / vhosts samt Wordpress waren wieder online. Owncloud blieb zerschossen und Postfix wollte erst keine Mails senden, aber letzteres hab ich inzwischen hingekriegt.

4. Frage. Ist es möglich auf welche Art auch immer Backups zu erstellen die tatsächlich das halten was das automatische Strato Backup scheinbar verspricht aber nicht erfüllt, nämlich komplette Wiederherstellung des Servers inkl. aller Dienste und Funktionen, insbesondere auch der Datenbanken, ohne größere Handarbeiten?

Eine Idee die ich habe: 2,90 pro Monat in Advanced (Strato-)Backup investieren, dann könnte das Zeitfenster des automatischen Backups festgelegt werden (bei der kostenlosen Version bestimmt Strato die Uhrzeit, bei mir derzeit täglich gg. 14:00). Dann könnte man kurz vor dem Zeitfenster mysql und ggf. andere Dienste per cronjob beenden und nach dem Backup ebenso wieder starten. Wenn der Server nachts für 2 Stunden nicht erreichbar wäre, wär das kein Problem. Auf diese Weise sollten doch die mysql Datenbanken konsistent bleiben, oder nicht?

Dankbar für alle Tips...

 

[danton]

Die Sicherung einer Datenbank auf Datei-Ebene hat das Problem, dass die Datenbank während des Sicherns einen inkonsistenten Zustand bekommen kann (nicht zwingend muß, nur sehr wahrscheinlich). Hier hat jedes Datenbanksystem seinen eigenen Ansatz. Bei MySQL erstellst du einfach einen Dump aller Datenbanken mit dem Befehl mysqldump. Die dadurch erzeugten Dateien werden dann gesichert. Mit ihrer Hilfe kannst du z.B. eine leere MySQL-Datenbank wieder befüllen.
Falls MySQL nach einem Crash nicht mehr startet und nix in den Logs steht: Loglevel hochdrehen, damit MySQL mehr Informationen logt - dann bekommst du MySQL auch wieder zum Laufen, um ggfl. Dumps zurückzuspielen

 

[ThomasChr]

Gegen inkonsistente Backups von Mysql sichere ich mich ab indem einfach regelmäßig mittels mysqldump die kompletten Datenbanken gedumpt werden.
Alternativ evtl. einen Slave-Mysql Server extern mitlaufen lassen...

Thomas

 

[daralla]

Die Sicherung einer Datenbank auf Datei-Ebene hat das Problem, dass die Datenbank während des Sicherns einen inkonsistenten Zustand bekommen kann (nicht zwingend muß, nur sehr wahrscheinlich). Hier hat jedes Datenbanksystem seinen eigenen Ansatz. Bei MySQL erstellst du einfach einen Dump aller Datenbanken mit dem Befehl mysqldump. Die dadurch erzeugten Dateien werden dann gesichert. Mit ihrer Hilfe kannst du z.B. eine leere MySQL-Datenbank wieder befüllen.
Falls MySQL nach einem Crash nicht mehr startet und nix in den Logs steht: Loglevel hochdrehen, damit MySQL mehr Informationen logt - dann bekommst du MySQL auch wieder zum Laufen, um ggfl. Dumps zurückzuspielen

Ja, das ist ja genau das Problem, wenn mysql gar nicht mehr startet nützen auch evtl. angelegte dumps nichts, da ich die ja dann nicht ohne weiteres wieder einspielen kann. Danke für den Tip mit dem Log Level, aber selbst im besten Fall läuft das ja doch wieder auf langwierige Fehlersuche und jede Menge Handarbeit hinaus, was ich genau vermeiden wollte.

Was ich suche ist eher was im normalen Home-PC Sektor inzwischen selbstverständlich ist: ein Komplett Backup das ich mit wenigen Handgriffen vollständig lauffähig wiederherstellen kann. Mit stundenlangem Gefrickel kriegt man fast alles wieder hin, aber das kann doch heutzutage nicht der Stand der Dinge bei virtuellen Servern sein, oder doch?

PS: manuelles mysqldump braucht es eigentlich gar nicht wenn man die Backup Funktion von Plesk benutzt, da werden nämlich dumps angelegt und mitgesichert. Nur wenn eben wie in meinem Fall mysql gar nicht mehr startet gibts auch keine Wiederherstellung per Plesk.

 

[ThomasChr]

Das Backup kannst du eben schon wieder einspielen. Du musst entweder mysql neu installieren, oder manuell die Datenbankdateien löschen. Dann hast ne leere Datenbank, die startet dann auch wieder, und in die spielst dein Dump ein.

Thomas

 

[crazychef]

Hallo daralla,

ich habe gesehen das du auch auf einem Strato vServer mit Plesk eine Owncloud installiert hast.
Ich versuche das auch, scheitere jedoch an der Tatsache das der Installation Wizard von Owncloud immer behauptet er könnte nicht in das Datenverzeichnis schreiben, das liegt direkt auf root, also außerhalb des Webservers.
Hat das bei dir funktioniert?
Verwendest du Ubuntu oder CentOS?
Ich habe schon alle Varianten mit Rechten und Ownern des Ordners versucht.

Wäre dir dankbar wenn du einen Tip für mich hättest.
Gerne auch PN

Beste Grüße
Kai

 

[daralla]

Hallo daralla,

Ich versuche das auch, scheitere jedoch an der Tatsache das der Installation Wizard von Owncloud immer behauptet er könnte nicht in das Datenverzeichnis schreiben, das liegt direkt auf root, also außerhalb des Webservers.

und da liegt auch das Problem, das wird (und soll auch) nicht funktionieren. Installiere entweder in ein Unterverzeichnis des Webroot, also z.B. "/var/www/vhosts/<dein.domainname>/httpdocs/owncloud" oder direkt ins Webroot einer eigens angelegten Subdomain "/var/www/vhosts/<dein.domainname>/<deine.subdomain/httpdocs", beides geht ohne Probleme.

 

[daralla]

Das Backup kannst du eben schon wieder einspielen. Du musst entweder mysql neu installieren, oder manuell die Datenbankdateien löschen. Dann hast ne leere Datenbank, die startet dann auch wieder, und in die spielst dein Dump ein.

Thomas

Na ja, wie gesagt, Gefrickel. Da kann ich auch, wie geschehen, den Server via Strato Verwaltung neu aufsetzen und mittels des jungfräulichen Plesk das Plesk-Backup wieder einspielen. Was ich eigentlich suche ist eine one-click (oder "one command") Restore Methode. Eben das was Strato mit seiner automatischen Komplettbackup Funktion suggeriert, was aber eben wg. mysql nicht funktioniert.

 

[crazychef]

und da liegt auch das Problem, das wird (und soll auch) nicht funktionieren. Installiere entweder in ein Unterverzeichnis des Webroot, also z.B. "/var/www/vhosts/<dein.domainname>/httpdocs/owncloud" oder direkt ins Webroot einer eigens angelegten Subdomain "/var/www/vhosts/<dein.domainname>/<deine.subdomain/httpdocs", beides geht ohne Probleme.

"You should locate your ownCloud data directory outside of your Web root if you are using an HTTP server other than Apache"

Da suche ich mich zu tode, wer richtig liest ist klar im Vorteil, mein Fehler.

Danke

 

[daralla]

"You should locate your ownCloud data directory outside of your Web root if you are using an HTTP server other than Apache"

Da suche ich mich zu tode, wer richtig liest ist klar im Vorteil, mein Fehler.

Danke

und selbst wenn Du einen anderen HTTP server verwenden würdest wäre mit "outside of your Web root" nicht direkt das root des Webservers gemeint, eher ein separat angelegtes Verzeichnis und darin dann ein owncloud Unterverzeichnis, also z.B. "/stuff/owncloud". Direkt im Server root ist immer 'ne miese Idee, und funktioniert vermutlich wg. Rechten sowieso nicht.

 

[lyn2k9]

Gegen inkonsistente Backups von Mysql sichere ich mich ab indem einfach regelmäßig mittels mysqldump die kompletten Datenbanken gedumpt werden.
Alternativ evtl. einen Slave-Mysql Server extern mitlaufen lassen...

Thomas

Ich bin bisher immer mit dieser Methode gut gefahren:

https://wiki.ubuntuusers.de/MySQL/Backup/#Datenbankdateien-auf-ein-anderes-System-zurueck-spielen

Vorher kurz die SQL-Datenbank anhalten, Daten abziehen, SQL-Datenbank starten. Problem an der Sache ist, dass die SQL Datenbank für ein paar Sekunden pro Tag nicht erreichbar ist.

 

[daralla]

Okay, anscheinend gibt es keine wirklich simple Backup/Restore Methode für einen VServer mit mysql.

Nochmal zur eigentlichen Wurzel des Übels, vlt. kann ja jemand die Info gebrauchen. Wie beschrieben begann der Ärger nach Installation von Redis als Cache für Owncloud. Mittlerweile habe ich das hier recherchiert und bin ziemlich sicher daß genau diese Sicherheitslücke bei mir zugeschlagen hat, also ein nach dieser Anleitung installiertes Redis mit standardmäßig Bindung an alle Netzwerk-Interfaces wurde gehackt und dabei "$home/.ssh/authorized_keys" überschrieben.

Wenn ich das rechtzeitig erkannt hätte, hätte mir ein Recovery-Boot und Wiederherstellung der "authorized_keys" vermutlich den ganzen Trouble erspart... aber na ja, wieder was gelernt.

 

[danton]

Wenn ich das rechtzeitig erkannt hätte, hätte mir ein Recovery-Boot und Wiederherstellung der "authorized_keys" vermutlich den ganzen Trouble erspart... aber na ja, wieder was gelernt.

Nein, das hätte nicht gereicht. Wenn jemand die authorized_keys austauscht, dann mit dem Zweck, Zugriff auf deinen Server zu erlangen - und du mußt davon ausgehen, dass er dies auch getan hat und am System Änderungen vorgenommen hat. Auch wenn du das System neu installiert hast, mußt du dein System jetzt untersuchen, denn du hast ein Backup eingespielt, das evtl. ja schon kompromitiert ist.

 

[daralla]

Nein, das hätte nicht gereicht. Wenn jemand die authorized_keys austauscht, dann mit dem Zweck, Zugriff auf deinen Server zu erlangen - und du mußt davon ausgehen, dass er dies auch getan hat und am System Änderungen vorgenommen hat. Auch wenn du das System neu installiert hast, mußt du dein System jetzt untersuchen, denn du hast ein Backup eingespielt, das evtl. ja schon kompromitiert ist.

Nein, das (Plesk-)Backup das ich wieder eingespielt habe stammt von vor der Redis Installation, insofern ist es diesbezüglich auf jeden Fall clean. Und natürlich benutze ich seit der Neuinstallation andere SSH keys und Passwörter für das System als vorher.

 

[danton]

Und natürlich benutze ich seit der Neuinstallation andere SSH keys und Passwörter für das System als vorher.

Dabei auch an die Webanwendungen gedacht wie z.B. das von dir oben erwähnte Wordpress?

 

[daralla]

Dabei auch an die Webanwendungen gedacht wie z.B. das von dir oben erwähnte Wordpress?

Sicher. Gibt also keinen Grund den so oft und bereitwillig erteilten "Experten" Rat "wenn jemals im Umkreis von 5 km um Deinen Server ein verdächtiges Byte gesichtet wurde, wirf alles weg und starte bei Null" zu befolgen...