Notfallsystem einrichten?

H

haegar

New Member
Hallo zusammen,

bin nicht sicher ob ich hier richtig bin - liebe Admins-> bitte verschieben falls es ein besseres Forum dafür gibt!

So nun zu meinem Anliegen:
Nach einigen unangenehmen Erfahrungen mit Serverausfällen (Server tagelang nicht erreichbar, teils nicht mal per SSH) bei meinem Hoster möchte ich zumindest für ganz schlimme Fälle eine Fallback-Lösung schaffen. Da das vielleicht 1 mal im Jahr oder (hoffentich) nie zum Einsatz kommen wird, soll es nur geringe oder keine laufenden Kosten verurachen.
Nach langer Suche habe ich immer noch nichts gefunden. Das kann jetzt heißen dass ich falsch gesucht habe oder dass es gar nicht so geht wie ich will.

Meine Idee wäre, ein lokales System (z.B. in einer VM-Ware) aufzusetzen und analog zum Webserver mit mehreren VHOSTS einzurichten. Die Datensicherung des echten Servers (erfolgt heute schon für mysql und die Verzeichnisse der Joomla und Wordpress-Sites sowie des Mailservers auf ein HiDrive-Laufwerk in der Cloud) könnte dann jederzeit vom Hidrive auf den lokalen Server kopiert werden, DNS-Eintrag umbiegen und fertig.

Das dauert dann zwar auch mal ein paar Stunden bis die DNS-Einträge geändert sind, soll aber ja auch nur dann zum Einsatz kommen, wenn alles andere an Rettungsmaßnahmen versagt hat. Außerdem ist klar, dass dann alles recht langsam wäre (mein DSL-Upstream mit nur 1024kBit) aber besser als völlig unerreichbar.

Ich könnte mir auch vorstellen, dass auf dem Notfall-System zwar der Mailserver läuft, an Stelle der echten Webseiten aber nur eine Meldung, dass die Seiten wegen Serverreparatur offline sind (allemal besser für Besucher als bei einem Google-Link nur ein Verbindungstimeout zu bekommen).

Daher hier die Frage, ob ein solches System überhaupt denkbar ist - oder ob es eine ungefähr gleichwetige Alternative gibt.
Wenn ja suche ich gerne weiter, aber im Moment glaube ich, dass ich da ganz auf dem falschen Dampfer bin und mir etwas anderes für den Notfall überlegen muss, weil ich ja im DNS immer nur eine feste IP eintragen kann und meine IP ja jeden Tag wechselt.

P.S. natürlich hat der Hoster auch eine Backup-Lösung, aber erstens dauerte es beim letzten Mal 16 Stunden!! um einen Server mit rund 20GB Umfang zu restoren, zweitens waren in diesem Restore alle Datenbanken zerschossen, so dass ich danach noch mein (glücklicherweise vorhandenes) Backup vom Hidrive einspielen musste (wozu ich auch erst nach der Arbeit kam, weitere 10 Stunden Ausfall) und drittens hatte ich gerade vor ca. einem Jahr einen ähnlichen Ausfall, da dauerte es 5 Tage bis das Restore da war...).
Aber vielleicht bin ich ja nur beim falschen Hoster - es ist einer der ganz großen in Deutschland und ob andere da wirklich besser sind...??? Ähnliche Leidensgeschichten findet man bei anderen Hostern ja auch.

Danke und Gruß,
Siegbert
 
Last edited by a moderator:
Email Server von zu Hause kannst du vergessen, da Du wahrscheinlich eine dynamische Ip hast die werden von den meisten Spamfiltern geblockt. Welchen Hoster hast du dennn?
16h oder 5 Tage für ein Restore nicht schlecht. :eek:
 
haegar said:
Nach einigen unangenehmen Erfahrungen mit Serverausfällen (Server tagelang nicht erreichbar, teils nicht mal per SSH) bei meinem Hoster möchte ich zumindest für ganz schlimme Fälle eine Fallback-Lösung schaffen. Da das vielleicht 1 mal im Jahr oder (hoffentich) nie zum Einsatz kommen wird, soll es nur geringe oder keine laufenden Kosten verurachen.
Click to expand...

Was denn nun? Erst sprichst du von einigen Ausfällen, dann sagst du, daß deine Fallbacklösung maximal einmal im Jahr (oder seltener) benötigt wird...
Wie häufig tauchen die Probleme nun tatsächlich auf?

Davon mal abgesehen zäumst du das Pferd von hinten auf. Zuerst sollte man mal abklären, wo die Ursachen für die Ausfälle sind. Mit deiner anvisierten Lösung würdest du nämlich nur die Auswirkungen etwas beschönigen, aber die Ursache würde weiter bestehen bleiben.
Wenn das Problem beim Hoster liegt (was nach deiner Beschreibung über den Restoreversuch nicht auszuschließen wäre), dann würde zumindest für mich ein möglicher Anbieterwechsel relativ weit oben stehen.
Liegt das Problem allerdings in einer fehlerhaften Konfiguration der von dir bereitgestellten Serverdienste, dann solltest du da ansetzen.
Deine geplante Fallbacklösung sollte erst nach der Ursachenanalyse und deren Beseitigung der nächste logische Schritt sein.
 
Ursache kann ich nur vermuten: Hoster ist Strato, auf dem Server läuft ubuntu 12.04 und Plesk 12.08. Von einem auf den anderen Tag (ich kann nur vermuten dass es ein Plesk Micro-Update war) war die VHost-Konfiguration defekt. Alle auf einer der beiden IP-Adressen laufenden Sites zeigten nur noch die Plesk-Defaultseite und /usr/local/psa/admin/bin/httpdmng --reconfigure-domain gab Fehlermeldungen wegen sich überlappender VHOSTS aus. Danach kam statt der Plesk-Default Seiten die Apache Default-Seite. 2 Std. googlen und misslungene Reparaturversuche, daher zurück zum Backup von vor 2 Tagen --> nach 16 Std. war der Server wieder mit puTTy erreichbar.
Ähnlich vor einem Jahr, damals war ich aber der Schuldige - hatte bei der Installation etwas falsch gemacht und wollte zurück zum letzten Backup. Dummerweise an einem Freitag-Abend. Restore kam gar nicht mehr zum Ende und der Suppoert hat am Wochenende nichts machen können. Irgendwann Mittwoch-Abend war die Shell wieder erreichbar aber die Datenbanken defekt. Seitdem sichere ich die noch mal extern.
 
Ursache kann ich nur vermuten: Hoster ist Strato, auf dem Server läuft ubuntu 12.04 und Plesk 12.08.
Von einem auf den anderen Tag (ich kann nur vermuten dass es ein Plesk Micro-Update war) war die VHost-Konfiguration defekt. Alle auf einer der beiden IP-Adressen laufenden Sites zeigten nur noch die Plesk-Defaultseite. Eine Reparatur mit /usr/local/psa/admin/bin/httpdmng --reconfigure-domain gab Fehlermeldungen wegen sich überlappender VHOSTS aus.
Danach kam statt der Plesk-Default Seiten die Apache Default-Seite. 2 Std. googlen und misslungene Reparaturversuche, daher zurück zum Backup von vor 2 Tagen (auch für so was macht man ja Backups) --> nach 16 Std. war der Server wieder mit puTTy erreichbar.
Ähnlich vor einem Jahr, damals war ich aber der Schuldige - hatte bei einer Installation etwas falsch gemacht und wollte zurück zum letzten Backup. Dummerweise an einem Freitag-Mittag. Restore kam gar nicht mehr zum Ende, Freitag-Abend niemand mehr im Support erreichbar. Der am Samstag gleich um 8 Uhr erreichte Support-Mitarbeiter hat am Wochenende nichts machen können, außer ein Ticket für den technischen Support zu erstellen. Irgendwann Mittwoch-Abend war die Shell wieder erreichbar aber die Datenbanken defekt. Seitdem sichere ich die noch mal extern.

Am liebsten wäre mir eine funktionierende Backup-Lösung bei Strato. Im Falle eines Defekts zurück zum letzten funktionierenden Stand gehen, eigene Sicherungen relevanter Daten (Datenbank-Backup, dynamische Inhalte von Webseiten ochgeladene Bilder etc.) zurückspielen - fertig. Aber das hat jetzt zwei mal nicht geklappt oder statt Stunden Tage gedauert.

Gruß,
Siegbert
 
Für Deine fehlerhafte Backup+Restore-Strategie kann Dein Serveranbieter mal rein gar nichts.

Backup der Nutzdaten per tar+dbdump+gpg auf einen Backupserver geht fix und ist immernoch eine der unproblematischten Lösungen überhaupt. Auch im Restore simple und schnell zu handhaben (Basissystem und benötigte Dienste neu aufsetzen, Nutzdaten restoren, Reboot, fertig).

Und für die Ausfälle bist wohl auch nur Du allein verantwortlich, so what...
 
Alle auf einer der beiden IP-Adressen laufenden Sites zeigten nur noch die Plesk-Defaultseite. Eine Reparatur mit /usr/local/psa/admin/bin/httpdmng --reconfigure-domain gab Fehlermeldungen wegen sich überlappender VHOSTS aus.
Click to expand...
Und was steht da jetzt genau Drin?
 
Joe User said:
Basissystem und benötigte Dienste neu aufsetzen
Click to expand...
Wenn man das noch mit Puppet oder Chef automatisiert, ist das Neuaufsetzen eine Sache von Minuten.
Plus der Möglichkeit, die aktuelle Serverkonfiguration für das Vorbereiten von Änderungen/Erweiterungen lokal in Vagrant zu testen.
 
Joe User said:
Für Deine fehlerhafte Backup+Restore-Strategie kann Dein Serveranbieter mal rein gar nichts.

Backup der Nutzdaten per tar+dbdump+gpg auf einen Backupserver geht fix und ist immernoch eine der unproblematischten Lösungen überhaupt. Auch im Restore simple und schnell zu handhaben (Basissystem und benötigte Dienste neu aufsetzen, Nutzdaten restoren, Reboot, fertig).

Und für die Ausfälle bist wohl auch nur Du allein verantwortlich, so what...
Click to expand...

Nur um Missverständnisse zu vermeiden: die genannten Backups erstellt STRATO und das Restore wird über die Serververwaltung von STRATO ausgelöst, da habe ich keinerlei Einfluss. Genau deshalb suche ich ja eine eigene Backup-Lösung und für die Nutzdaten mache ich das ja auch schon. War wohl in meinem Posting missverständlich beschrieben.
Problem ist hier, dass im Falle einer Fehlkonfiguration des Servers das Restore des Betriebssystems manchmal Tage braucht. Und erst wenn der Server grundsätzlich wieder läuft kann ich ja meine Nutzdaten zurücksichern.
Deinem Post entnehme ich aber, dass ich auf diese Weise nicht nur Nutzdaten sichern kann, sondern die gesamte Serverkonfiguration und mich so von den Backups des Hosters vollkommen unabhängig machen kann. Ich verfolge das mal weiter, danke für den Hinweis.

@rolap: genauen Text müsste ich nachsehen, sinngemäß "Vhost at ip x.x.x.x:80 Overlaps with Vhost an x.x.x.x:80 First has prcedence". Aber das ist Thema in einem anderen Thread im Plesk-Forum. Hier wollte ich nur klären, wie ich im Falle einer mehrtägigen Downtime ersatzweise einen anderen "Server" über den Domainnamen erreichbar machen kann, der mindestens Notdienste anbietet.
 
haegar said:
Nur um Missverständnisse zu vermeiden: die genannten Backups erstellt STRATO und das Restore wird über die Serververwaltung von STRATO ausgelöst, da habe ich keinerlei Einfluss. Genau deshalb suche ich ja eine eigene Backup-Lösung und für die Nutzdaten mache ich das ja auch schon. War wohl in meinem Posting missverständlich beschrieben.
Problem ist hier, dass im Falle einer Fehlkonfiguration des Servers das Restore des Betriebssystems manchmal Tage braucht.
Click to expand...
Und da liegt das Problem das Du Deine fehlerhafte Konfiguration wieder einspielst.
Ich könnte mir auch vorstellen, dass auf dem Notfall-System zwar der Mailserver läuft, an Stelle der echten Webseiten aber nur eine Meldung, dass die Seiten wegen Serverreparatur offline sind (allemal besser für Besucher als bei einem Google-Link nur ein Verbindungstimeout zu bekommen).
Click to expand...
Für die Webseiten musst du ja nur den A-Record der Domain auf deine Home IP ändern.
Für Mail würde ich das so machen.
Code: 
mail   A IN  1.1.1.1  (Server-IP)
mail2  A IN  2.2.2.2 (Home-IP)
@     MX IN  10  mail.domain.de
@     MX IN  20  mail2.domain.de

Funktioniert der Server nicht gehen Die Email automatisch an Deine Home IP.
Zu beachten ist, wenn Du IMAP verwendest hast Du ungleiche Postfach Inhalte.
Laut Deine Fehlerbeschreibung liegt das Problem ja an der Vhost Konfiguration Email sollt ja funktionieren.
 
Basissystem und Dienste sollst Du ja auch nicht restoren sondern neu installieren, das geht auch bei Strato zeitnah. Dann die eigenen Configs und Nuzdaten zurückspielen, rebooten, fertig.
 
rolapp said:
Für Mail würde ich das so machen.
Code: 
mail   A IN  1.1.1.1  (Server-IP)
mail2  A IN  2.2.2.2 (Home-IP)
@     MX IN  10  mail.domain.de
@     MX IN  20  mail2.domain.de

Funktioniert der Server nicht gehen Die Email automatisch an Deine Home IP.
Click to expand...

Gib ihm bitte nicht die Empehlung, seine Mailroute auf seinen Internetanschluß zu Hause zu verbiegen!
Das funktioniert nicht wirklich und er landet ziemlich schnell auf diversen Blacklists und hat dann tagelang zu tun, da wieder runter zu kommen.
 
Nexus da hast Du vollkommen recht. Ich wollte nur aufzeigen wie es machbar wäre. Es sollte keine Empfehlung sein.
 
Hallo zusammen,

danke für die zahlreichen Tipps.

Ich nehme folgendes mit:
1) ein Umbiegen auf den eigenen DSL-Anschluss / IP-Adresse macht wegen zu erwartenden Problemen mit Mail-Blacklists keinen Sinn
2) daher ist es sinnvoller die Backup-Startegie zu ändern

zu 2)
Bisher habe ich STRATO das Betriebssystem und die Serverkonfiguration alleine sichern lassen und mich nur um die Nutzdaten gekümmert. Das ist theoretisch OK, aber wenn die Wiederherstellung über die STRATO-Mechanismen mehrere Tage dauert ist der Server einfach zu lange Offline. Also werde ich die Serverkonfiguration zukünftig ebenfalls noch selbst sichern.

Backup-Plan wäre dann:
  • 1 x monatlich oder nur bei Änderungen ein Gesamt-Backup
  • täglich wie bisher Backup der Nutzdaten
  • vor größeren Änderungen ebenfalls Backup der Nutzdaten
  • nach größeren Änderungen und getestetem System Gesamt-Backup

Restore:
  • Starten des Servers im von STRATO angeboten "Notfallmodus"
  • Zurücksichern des letzten Gesamtbackups
  • Zurücksichern der letzten Nutzdaten

Eben mal Zeiten gestoppt um ein ungefähres Gefühl dafür zu bekommen, wie lange das dauern könnte:
  • 1,8 GB - Datei zum ftp-Server kopieren: 9 Min
  • selbe Datei zurück-kopieren: 4 Minuten

Das Gesamtbackup ist ca. 18 GB groß, die Nutzdaten machen davon rund 8 GB aus. Hochgerechnet heißt das:
  • Gesamtbackup dauert rund 1,5 bis 2 Stunden
  • Nutzdatenbackup dauert rund halbe bis 3/4 Stunde
  • Rücksichern Gesamtbackup dauert 3/4 bis 1 Std.
  • Rücksichern Nutzdaten dauert 15 bis 20 Minuten

Werde das mal so einplanen. Da der Server dann mehrere Std. "down" wäre, kann ich es nicht testen. Versuche den Test mal mit Rücksicherung in lokale Installation - sollte zur Evaluierung des Konzepts reichen. Schlimmstenfalls muss dann halt doch wieder die STRATO - Sicherung für das Wiederherstellen der Serverkonfiguration herhalten.

Nochmals Danke und Grüße,
Siegbert
 
Last edited by a moderator:
haegar said:
1 x monatlich oder nur bei Änderungen ein Gesamt-Backup
nach größeren Änderungen und getestetem System Gesamt-Backup
Click to expand...

Warum willst du das OS mitsichern?

Joe User said:
Basissystem und Dienste sollst Du ja auch nicht restoren sondern neu installieren, das geht auch bei Strato zeitnah. Dann die eigenen Configs und Nuzdaten zurückspielen, rebooten, fertig.
Click to expand...

Genau wie Joe sagt, eine Neuinstallation geht wesentlich schneller als wenn du zig GB an Systemdateien hin und her schaufelst.
 
nexus said:
Genau wie Joe sagt, eine Neuinstallation geht wesentlich schneller als wenn du zig GB an Systemdateien hin und her schaufelst.
Click to expand...

Schon mal produktive Systeme in der Hand gehabt? Die Nutzdaten da drauf übersteigen für gewöhnliche das Volumen der Systemdateien (bei einem Linux Host) um ein Vielfaches. Bei Linux sprechen wir da auch eher von einem Volumina im unteren einstelligen Gigabyte-Bereich. Wenn überhaupt soviel.
Wenn man im Gegensatz dazu mehrere Gigabyte Nutzdaten sichern muss, machens die paar Systemdateien auch nicht mehr fett.
Da kann man die Dateien ebenso gut mitnehmen und brauch nur einmal den Restore des gesamten Systems anstoßen, fertig. Keine Gefahr beim schnellen Nachkonfigurieren irgendwas zu vergessen oder Fehler zu machen. Die Dauer des Restore-Prozesses beeinträchtigt es kaum. Im Gegenteil, es kann bei ernsthaft genutzten Systemen durchaus den Gesamtprozess deutlich beschleunigen, wenn man eben nichts mehr manuell machen muss.
 
Firewire2002 said:
Schon mal produktive Systeme in der Hand gehabt? Die Nutzdaten da drauf übersteigen für gewöhnliche das Volumen der Systemdateien (bei einem Linux Host) um ein Vielfaches. Bei Linux sprechen wir da auch eher von einem Volumina im unteren einstelligen Gigabyte-Bereich. Wenn überhaupt soviel.
Click to expand...

Da hast du natürlich nicht ganz unrecht, aber ich bin von den Größenangaben aus Post #14 ausgegangen und von der dort ebenfalls genannten Zeitspanne zwischen den Fullbackups, was im Restorefall noch zusätzlich eine Aktualisierung des aus dem Backup stammenden Systems erforderlich machen würde.
Es kommt halt immer auf die Größe an...
 
Die Gefahr besteht aber immer noch, das man sich fehlerhafte Konfigurationen zurück sichert.
Dss hat halt beides Vor- und Nachteile.
 
Wenn ich weiß, dass ich einen Konfigurationsfehler habe, gibt es 3 Möglichkeiten:
  1. Ich behebe den Fehler
  2. Ich stelle ein Backup eines früheren Datum wieder her, in dem der Fehler noch nicht existierte
  3. Ich installiere neu, schreibe meine Konfiguration neu und stelle meine Nutzdaten aus dem Backup wieder her

Wer und warum auch immer sich für Variante 3 entscheidet, hätte eben so gut Variante 1 nehmen können. ;)
Davon ab ist es bei Variante 3 völlig unerheblich, ob in dem Backup die Systemdateien nun mit einbegriffen waren, oder nicht. Wenn ich sie nicht brauche, stelle ich sie eben auch nicht wieder her und hole mir aus dem Backup nur das was ich brauche. In sofern ist es nur selten ein Mehraufwand, die Systemdateien einfach mit zu sichern.

Anders sieht es aus, wenn ein produktives System keine Nutzdaten vorhält. Spontan würden mir da zum Beispiel DHCP-Server einfallen. Für eine handvoll Config Files muss man nicht unbedingt das gesamte System sichern. Da kann es unter Umständen tatsächlich sinnvoller sein, einfach neuzuinstallieren und die paar Configs irgendwo her zu ziehen (SVN bietet sich da durchaus an).
 
You must log in or register to reply here.
Back
Top