Odyssee mit Strato HighQ Server

Strato ist tot – Es lebe Hetzner

Inzwischen sind wir wohl fast zehn Jahre Strato Kunde, die ersten Jahre liefen ziemlich gut, aber jetzt reicht es uns. Bei mir schleicht sich allmählich das Gefühl ein, dass die Qualität der Strato Server-Hardware extrem nachgelassen hat. Innerhalb von eineinhalb Jahren hatten wir drei technische Defekte bei unseren Strato HighQ root Servern: 07/2010, 10/2011 und 01/2012. Dieser Ausfall führte jedesmal zu einem totalen Austausch des Webservers. Hier unser Tatsachenbericht:

Strato Hardware-Defekt feststellen (Tag 1)

Kurze Zeit nach dem Serverausfall entdeckt Susanne, dass am Rechner etwas nicht stimmt. Zwar hatte ich schon länger einen Verdacht, dennoch kann man nicht vorsorglich den Rechner austauschen lassen. Schließlich war der Seitenaufruf irgendwie langsamer als beim vorherigen Server, obwohl es sich um ein neueres Modell handelte. Zudem stieg in den Google Webmastertools die "Dauer des Herunterladens einer Seite" auf fast 10.000 ms. Ein normaler Wert liegt irgendwo zwischen 500 bis 1.000 ms. Natürlich sorgen wir immer für ein regelmäßiges Backup aller Daten. Trotzdem lief dieses mal einiges extrem schief.

Zunächst glaubt man, den Server wieder hochfahren zu können. Es kommt gelegentlich vor, dass ein einfacher reboot bzw. shutdown des Servers oder ein Restart eines einzelnen Serverdienstes: apache, mysql, etc. den PC wieder auf richtige die Spur bringt. Also versucht man erstmal die üblichen Fehlerquellen auszuschließen, bspw. top Befehl nutzen und diverse Dienste starten. In unserem Fall, war jedoch dies schon gar nicht mehr möglich, ein Neustart war erforderlich. Leider war danach immer noch kein externer Zugriff auf den Webserver möglich. Nicht einmal mit PuTTY gelang dies. Aus diesem Grunde waren schon etwas verzweifeltere Bemühungen notwendig, bspw. der Aufruf der zentralen Administrationskonsole für Strato Produkte. Dort ist es möglich den Status des Servers festzustellen, RemoteConsole einsetzen oder den RecoveryManager nutzen, um den Rescue Modus zu starten.

Nach einigen mißtrauischen Versuchen stand der Versuch auf dem Plan, den Server mit dem RecoveryManager neu zu booten. Leider waren alle Bemühungen erfolglos, weshalb wir in unserer ungläubigen Verzweiflung (nach 2 defekten Rechnern!!!) doch einen Hardwaretest unternahmen. Dazu gibt es einen ausführlichen Test, der rund 12 Stunden dauert und einen Kurztest mit etwa 2 Stunden. Obwohl wir den Kurztest nutzten bekamen wir erst etwa 10 Stunden später das Ergebnis mitgeteilt. Der Netzwerktest lieferte einen Hardwaredefekt, angeblich ist die Netzwerkkarte kaputt.

Manch einer wird jetzt denken, kein Problem, so ein Bauteil ist doch schnell ausgetauscht. Aber da kennt er die Geschäftsgepflogenheiten von Strato schlecht. Egal welches Bauteil defekt ist, also Festplatte, Netzwerkkarte, Arbeitsspeicher, etc., bei Strato wird der komplette Rechner ausgetauscht. Marketingtechnisch klingt es natürlich extrem verlockend RAID 1 System mit zwei gespiegelten Festplatten. Im Endeffekt aber ziemlich nutzlos. Der Rechner wird aus rechtlichen Gründen ausgetauscht. Vor diesem Hintergrund sieht der technische Support solche panischen Anrufe von Kunden recht gelassen. Es werden keinerlei Bemühungen unternommen auch nur ansatzweise, den betroffenen Kunden zu helfen. Immerhin waren wir jetzt schon das drittemal betroffen, die Vorgehensweise war aber immer die gleiche. Einige Kunden und Kollegen berichten ebenfalls von ähnlichen negativen Erfahrungen. Und so kommt es, dass schon mal der erste Tag verstreicht, ohne den geringsten Erfolg.

Strato HighQ Server bestellen (Tag 2)

Damit wir mit unseren 30 Domains schnellstmöglich wieder online sind, entschlossen wir uns, einen neuen Strato HighQ Server anzumieten und dort alle Backups vom FTP-Backupserver einzuspielen. Ist zwar mühsellig, aber zumindest eine praktikable Lösung. Also fix einen neuen Server bestellt, um der Lösung des Problems etwas näher zu kommen. Jedoch dauert diese Prozedur einige Stunden, bevor wir loslegen konnten. Nachdem leider unsere Netzwerkkarte defekt war, sind wir nicht in der Lage den einfachen Weg zu gehen, nämlich einen direkten Import der Backupdaten (also Kunden- und Domaindaten) mittels Migrationsmanager. Das wäre so easy gewesen, da merken die Kunden kaum etwas vom Umzug.

Mit Hilfe von ncftp und PuTTY (SSH2) ist es jedoch möglich die gesicherten Daten auf den neuen Webserver zu transferieren. Glücklicherweise sind der alte Rechner und die neue Maschine komplett identisch, beide nutzen Ubuntu 10.04 LTS 64bit als Betriebssystem und Plesk 10.2 als Administrationspanel. Demzufolge sollte der Import der Sicherungsdaten keinerlei Probleme bereiten. Ich entpacke mit dem tar Tool die Daten, generiere mit pleskrestore eine Mapping-Datei und starte die Wiederherstellung der ersten Domain. Doch dem ist leider nicht so, ein Datenimport ist unmöglich. Zuerst versuchte ich einige verschiedene Parameter, gab aber nach einigen Stunden entnervt auf. Nach ein wenig Recherche fand ich heraus, dass es eigentlich kein Problem ist sogar Daten aus Plesk Servern v8.x und v9.x zu importieren. Dazu muss man manuell lediglich die Daten auf den lokalen PC herunterladen und in den Plesk Backupmanager hochladen, der es in das Repository kopiert und zugleich die Daten ins richtige Plesk 10.x Format konvertiert. Leider erscheint bei dem Versuch die Domain zu importieren immer eine Fehlermeldung. Was sich nicht gerade positiv auf mein Gemüht auswirkt.

Kein Problem denke ich auf die schnelle, dann kann ich ja immer noch ein Upgrade der Plesk Version vornehmen. Dazu gehe ich in die Plesk Administrationsoberfläche und suche den Punkt Upgrade. Dummerweise ist ein Upgrade aktuell nicht möglich, Strato hat sich wie üblich dazu entschlossen ein Upgrade nicht zu erlauben. Weder die v10.3 noch v10.4 von Plesk sind einsetzbar. Das bedeutet letzlich, es ist uns nicht möglich mit der identischen Maschine unsere Backups einzuspielen. Tja was tun: "Gutes Rad ist teuer". Susanne entschließt sich nun doch einen Experten zu Rate zu ziehen, aber auch er scheitert leider an dem Projekt "Datenrettung" mit Strato. Ziemlich mißmutig verfolgen wir nun einen neuen Plan, endlich einen Server mieten bei Hetzner.

Hetzner root Server EQ4 bestellen (Tag 3)

In unserer Not kommt schnell Plan C zum Zuge, wir bestellen einen Hetzner root Server EQ4. Schon nach dem letzten Ausfall wollten wir zu Hetzner wechseln, aber auf die Schnelle ist es oft einfacher und bequemer beim gleichen Hostinganbieter zu bleiben. In diesem Fall blieb uns aber gar keine andere Wahl, die Datenrettung ist schlicht unmöglich. Also Server bestellt, Ubuntu + Plesk 10.3.1 installiert und konfiguriert. Jetzt die Daten per ncftp abholen und der Datenimport kann starten. Zum Glück wußte ich, wie man das Tool bequem nachinstalliert. Die Theorie ist gut, nur die Praxis sieht anders aus. Ein Zugriff auf den Strato FTP-Backupserver ist lediglich aus dem Strato Netz möglich (gilt übrigens auch beim Hetzner Server). Tja, was tun. Daten sind zwar gesichert, aber man kann einerseits bei Strato wegen der falschen Pleskversion die Daten nicht wiederherstellen und andererseits wegen dem falschen Netzwerk die Daten nicht abholen.

  # PuTTY Login & ncftp nachinstallieren
  apt-get update
  apt-get install ncftp

  # ncftp Verbindung aufbauen
  ncftp -u b123456 -p PASSWORT backup.stratoserver.net

  # Datensicherung abholen
  get *.pleskbackup.tar.gz
  quit
  

Der Witz geht natürlich weiter. Ganz nach dem Mediamarkt Motto: Ich bin doch nicht blöd. Schon ziemlich nah an der totalen Verzweiflung fällt mir spontan das Linux Tool wget ein. Damit lassen sich Daten von einer URL-Adresse abholen. Natürlich ist diese Idee mit einer defekten Netzwerkkarte beim Strato Server unmöglich. Zum Glück hatten wir aber gestern einen neuen Strato Webserver bestellt. Dummerweise liegen die Backupdaten im root Verzeichnis /var/backup/, worauf man mit wget nicht zugreifen kann. Leider war auf dem Server die Herstellung eines Kunden nicht möglich, aber es funktioniert einen Kunden inkl. Domain anzulegen. Sinnloserweise hatte ich schon bei allen ca. 40 Domains die IP-Adressen in den DNS-Einträgen auf den Strato Server umgestellt. Dennoch war dies in diesem Fall mein Glück, weil ich so zumindest eine Domain anlegen und sofort nutzen konnte. Mit dem Befehl cp kopierte ich die Daten in ein verstecktes Verzeichnis in dieser ansonsten leeren Domain. Jetzt war ich in der Lage vom Hetzner Server aus auf diese Daten mit wget zuzugreifen.

   wget http://domain.tld/ordner/dateiname.tar.gz

Die Backups lagen endlich alle auf dem neuen Webserver. Zwar fehlte uns die Pleskkonfiguration, aber das lässt sich mit etwas Zeitaufwand und KnowHow wieder einrichten. Mit diesem ersten positiven Signal, erhellte sich zumindest kurzfristig meine Stimmung. Tatsächlich war ich in der Lage mit dem pleskrestore Befehl meine erste Domain, die FTP-Daten und meine Datenbanken herzustellen.

Domains & Kundendaten wiederherstellen (Tag 4)

Inzwischen war Tag 4 der Rettungsaktion angebrochen. Die Frage war zunächst, stelle ich in Plesk erst die Kunden her und importiere danach die daten, oder eher umgekehrt. Ich entschloss mich für die zweite Variante, erst daten herstellen und später in Ruhe die Pleskkonfiguration konfigurieren. Nacheinnader war ich in der Lage die Domains wiederherzustellen.

  # Datei entpacken
  tar xvf meinedomain.de.pleskbackup.tar.gz

  # Inhalt Konfigurationsdatei anzeigen lassen
  /usr/local/psa/bin/pleskrestore --info backup_meinedomain.de_info_0815.xml

  # Generiere Mapping-Datei
  /usr/local/psa/bin/pleskrestore --create-map backup_meinedomain.de_info_0815.xml -map mapfile.txt

  # Mappingfile verifizieren
  /usr/local/psa/bin/pleskrestore --validate-map mapfile.txt

  # Daten wiederherstellen
  /usr/local/psa/bin/pleskrestore --restore backup_meinedomain.de_info_0815.xml -map mapfile.txt -level all

Mühsam ernährt sich das Eichhörnchen, eine Domain nach der anderen war wieder sichtbar. Bis auf zwei kleinere Domains konnten wir alle Domains sofort wieder herstellen. Komischerweise war es nicht möglich auf unsere eigene Domain zuzugreifen. Beim Aufruf der Seite kam immer wieder nur interner Serverfehler 500. Zuerst dachte ich an die DNS-Einträge, da die Domainnamen direkt in die Strato Server eingebunden waren. Aus diesem Grunde wollten wir die wallaby.de-Domain schnellstmöglich umziehen. Da wir zu Hetzner wechseln, wollten wir den dort verfügbaren Domain Registration Robot nutzen. Hierfür muss jedoch zunächst ein 4-seitiges Formular ausgefüllt und per Fax an Hetzner gesendet werden. Was natürlich am Wochenende kaum klappen kann. Nach einigem Grübeln kam ich dann doch noch auf die rettende Idee, es handelt sich womöglich um einen Umleitungs- oder Rechtefehler.

Nach einigen umfangreicheren Tests kam ich zu der Erkenntnis, dass eine falsche Berechtigung der Auslöser des Problems war, gepaart mit einer unpassenden .htaccess Datei im root-Verzeichnis der Domain. Ausdauernd korrigierte ich einen Fehler nach dem anderen, bis endlich wieder unsere Seite online war. Jetzt mussten nur noch die anderen beiden Domains eingespielt werden. Leider waren jedoch die XML-Dateien mit der Importkonfiguration fehlerhaft. Die Dateien mussten manuell bearbeitet werden, was sich aber etwas komplex gestaltete. Denn die Herstellung lief über diverse IDs: vendor-guid, owner-guid und guid:

  <domain cr-date="2012-01-21" guid="89a0df809-4566-78er-89df-asfdsaffe34rew"
  id="30" name="domain.tld" owner-guid="dfasdfadsf-4566-asdf-23df-afddsafdsff"
  vendor-guid="jkadfjldsaf-jlsa-1234-465a-132asdf1da12" www="true">

Irgendwann kam ich auf die Lösung. Indem ich zuerst die Kunden anlegte, davon ein Backup erstellte und mir zuletzt das XML-Datei herunterlud. Durch den Vergleich der defekten Datei mit der korrekten Datei konnte ich die XML-Struktur nachbauen. So ließen sich alle Daten herstellen. Auch für manche Datenbanken hatte ich eine einfache Lösung gefunden. Ebenfalls die Datenbank mit gleichem Namen und Benutzer anlegen. Anschließend die entstehende neue Datei in /var/lib/mysql ersetzen durch die Originaldatenbank aus der Datensicherung. Diese MySQL-Daten sicherer ich mit dem mysqldump Befehl täglich per Cron-Job und backup.sh und kopiere diese dann auf den FTP-Backupserver.

  # Duplizieren der mysql-Verzeichnisse
  rsync -az --delete --delete-after /var/lib/mysql/ /var/backups/mysql

  # Erstellt aus allen Dateien & Verzeichnissen eine Archivdatei
  tar czf mysql.tar.gz /var/lib/mysql

  # Datentransfer aller Dateien auf den Backupserverm
  cd /var/backups
  ncftp -u $FTPUSER -p $FTPPASS backup.serverkompetenz.de << EOF
  mput *tar*
  quit
  EOF

Als letztes steht nun noch die Plesk-Konfiguration an, aber das hat jetzt sicherlich etwas Zeit. Als Fazit möchte ich jedem wirklich folgende zwei Dinge ans Herz legen: "Drum prüfe wer sich ewig bindet!" und "Datensicherung ist Chefsache!".