Ein Serverumzug mit Hindernissen

Eigentlich sollte es ein schneller und unkomplitzierter Serverumzug von 1&1 zu Strato werden, allerdings machten mir gewisse Hürden einen gewaltigen Strich durch die Rechnung. Aber um der Geschichte nicht gleich die Spannung zu nehmen, möchte ich kurz erklären, wieso es überhaupt zu einem Serverumzug kam.

Es gab gewisse Dinge die mich bei 1&1 prinzipiell gestört haben. Unter anderem war es die unübersichtliche Weboberfläche des Kontrollzentrums und deren verwirrender Aufbau. Der Hauptgrund allerdings war, dass für meinen Vertrag nur eine Kapazität von einer einzigen Datenbank zur Verfügung stand. Da ich aber sehr experimentierfreudig bin und für gewisse Projekte auf mehrere von sich unabhängige Datenbanken angewiesen bin, musste ich mir etwas einfallen lassen. Die Option von 1&1 einfach Datenbanken zu dem aktuellen Vertrag dazuzubuchen kam für mich nicht in Frage, da der Preis einfach frech war und nicht zur Relation der Dienstleistung stand.

Also schaute ich mich nach einem neuen Provider um. Jeder Provider den ich gefunden hatte, biete für seinen Managed Hosting Vertrag mehr als eine Datenbank an, Strato sogar eine Maximum von 25! Die Qualität der Seite, darunter die Ladezeiten und der Serviceumfang im Allgemeinen, sollte sich natürlich nicht drastisch verschlechtern. Natürlich war mir dennoch klar, das Strato nie die Qualität von 1&1 bezüglich Hosting angeht ankommt. Doch ich nahm dies in Kauf und informierte mich darüber, wie man eine WordPress Installation mit Datenbank am besten umzieht.

Andere Provider wie beispielsweise HostEurope.de haben mir auf Grund von mehreren Bewertungen und des Serviceumfanges nicht zugesprochen.

Da ich ja eine 1-Click-Wordpress Installation bei 1&1 hatte, war ich etwas skeptisch wie weit ich an 1&1 diesbezüglich gebunden bin. Trotz meiner Sekpsis beantragte ich einen Domainumzug zu Strato und dachte an maximal 48 Stunden bis zur Umsetzung. Was sich allerdings schnell als schlechten Scherz rausstellte und mir klar gemacht wurde, dass der Umzug einfach fünf ganze Tage in Anspruch nimmt. Die Begründung von 1&1 war folgender (eins zu eins Wortlaut):

„Wir haben am 07.11.2018 die Mitteilung erhalten, dass Sie einen Domain-Umzug der Domain anotherblog.org zu einem anderen Registrar beantragt haben. Wenn Sie mit dem Umzug einverstanden sind, brauchen Sie nichts weiter zu tun. Möchten Sie den Umzug abbrechen, können Sie ihn jederzeit abbrechen.Wenn wir bis zum 12.11.2018 nicht von Ihnen hören, wird der Umzug durchgeführt.

 

Nachdem ich mich bei 1&1 dann schriftlich gemeldet hatte, dass ich keine Bedenkzeit bräuchte und meine Domain doch so schnell wie möglich umgezogen werden soll. Kam leider nur folgende Antwort:

„Das erhaltene Schreiben dient nur der Information Ihrerseits und bezüglich eines möglichen Abbruches des Domainumzuges. Der Abbruch ist Ihrerseits jedoch nicht gewünscht. Der Domainumzug wird daher am 12.11.2018 stattfinden. Ein vorzeitiger Umzug ist leider nicht möglich.“

 

Für mich hört sich das an, dass 1&1 mit Absicht fünf Tage die Domain zurückhält. Technisch kann dies ja nicht eine solch utopische Zeit in Anspruch nehmen, da ich auch innerhalb des Tages auch noch die Bestätigung des Domainumzugs von Strato erhielt. Ich habe mich dann bei ICANN auf der Website erkundigt, ob es dort eine feste Regelung zu den Wartezeiten von Domainumzügen gibt. Fehlanzeige, dort wird auch auf keine Wartezeit seitens ICANN hingewiesen. Durch die Schreibweise bekommt man allerdings vermittelt, dass dies von Provider zu Provider unterschiedlich ist und diese selbst einen Zeitraum definieren können.

 

Nach kurzerm Ärgernis machte ich mich an die Vorbereitung. Folgende Schritte mussten durchgeführt werden:

  • WordPress Installation exportieren (1&1).
  • MySQL Datenbank exportieren (1&1).
  • WordPress Installation hochladen (Strato).
  • Datenbank erstellen (Strato).
  • MySQL Datenbank importieren (Strato).
  • Interne Domainumleitung (Strato).
  • SSL erzwingen mit 301-Redirect (Strato).

 

Die WordPress Installation mit allen Verzeichnissen von 1&1 über einen FTP-Client vom Webspace herunterladen. Dafür wird der Hauptordner mit all seinen Dateien und dessen drei Unterordnern wp_content, wp_includes und wp_admin benötigt. Die Ordnerstruktur wurde parallel zum Serverumzug gleich mit angepasst.

Als Nächstes wurde dies auf den Strato Webspace erneut über einen FTP-Client hochgeladen. Die .htaccess kann für den neuen Webauftritt verworfen werden, da Strato eine eigene automatisiert erstellt.

Danach wird eine neue Datenbank mit dazugehörigem Passwort erstellt. Sobald dies geschehen, kann auch der Import der Datenbank erfolgen. Wichtig ist die Bearbeitung der Datensätze für den Verbindungsaufbau der Datenbank in der wp-config.php Datei.

// ** MySQL-Einstellungen – Diese Zugangsdaten bekommst du von deinem Webhoster. ** //
/** Der Name der Datenbank für WordPress */
define( ‚DB_NAME‘, ‚DB_NAME‘ );

/** MySQL-Benutzername */
define( ‚DB_USER‘, ‚DB_USER‘ );

/** MySQL-Passwort */
define( ‚DB_PASSWORD‘, ‚DB_PASS‘ );

/** MySQL-Serveradresse */
define( ‚DB_HOST‘, ‚rdbms.strato.de‘ );

/** Database Charset to use in creating database tables. */
define( ‚DB_CHARSET‘, ‚utf8‘ );

/** The Database Collate type. Don’t change this if in doubt. */
define( ‚DB_COLLATE‘, “ );

Gegebenenfalls müssen noch die zwei Datenbankeinträge für siteurl und home in der Tabelle *options angepasst werden.

Sobald die Domain dann bei Strato liegt, konnte die interne Domainweiterleitung eingerichtet werden und das benötigte SSL-Zertifikat mit dem 301-Redirect. Und das war es dann in der Theorie auch.

Allerdings nicht für mich… Stichtag Domainumzug hat stattgefunden und anotherblog.org war leider nicht aufrufbar. Nachdem ich mehrere Fehlerquellen ausgeschlossen hatte und sogar einen Thread bei wordpress.org über mein Problem verfasst hatte und um Hilfe bat. Kam dann die entscheidende Lösung von dem Strato-Support.

Strato bietet den Kunden eine Funktion an die sich PHP-Boost nennt und die PHP-Scripte des Webauftritts 100% schneller laden zu können. Das Ganze baut auf FastCGI auf und ist ein Code-Caching System. Daher nicht automatisch für alle CMS kompatibel. Das Ganze Problem hat mich im Endeffekt fast fünf weitere Tage gekostet, bis die Seite dann endlich wieder online ging.

Nun bietet sich mir dank der Vielzahl an Datenbanken reichlich Freiheit für Projekte an. Jetzt muss ich es nur noch schaffen Strato für Let’s Encrypt bei den Managed Hosting Paketen zu überzeugen. Der Preis für weitere SSL-Zertifikate oder für einen so genannten „SSL Wildcard“ ist kostenpflichtig und muss dazugebucht werden. Beispielsweise würde der „SSL Wildcard“ dann fast so viel Kosten wie einen Monat der gesamte Webauftritt und dies steht natürlich für kostenlose SSL-Zertifikate von Let’s Encrypt nicht ansatzweise zur Relation. Um Let’s Encrypt installieren zu können, fehlen einem die Rechte auf dem Webspace/Host von Strato.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.