Umzug: Meine Website läuft auf dem root-Server und so habe ich es gemacht

14 Kommentare Autor: Jürgen (jdo)

Ich habe gestern Abend meine Website (WordPress) weg von Strato auf den root-Server (vServer / VPS) von Contabo umgezogen. Der Auftritt war zirka 20-30 Minuten offline. Der Umzug ging deswegen relativ flott, weil ich viel vorbereitet und getestet habe. Erste Schritte mit einem root-Server und dessen Absicherung habe ich hier erklärt. Weiterhin gibt es noch jede Menge Notizen zu Backups, Einrichtung von Apache, Let’s Encrypt und MariaDB, Stolperfallen und so weiter, die ich alle noch nachliefern möchte. In diesem Beitrag gibt es die grundsätzlichen Schritte für den Umzug.

Ich weiß, dass das nun etwas auseinander gerissen ist und der Beitrag über eine Backup-Strategie ist schon halb fertig (wird auch was längeres). Aber die Zeit ist leider begrenzt.

Kleines Update: Backup läuft wie in diesem Beitrag beschrieben.

Auf jeden Fall ist das der erste Beitrag, der auf dem neuen Server geschrieben und veröffentlicht wurde! Und JA! Die Website fühlt sich deutlich schneller an!

Was wurde umgezogen?

Die Datenbank: Meine Website läuft mit WordPress und entsprechend befindet sich eine Datenbank dahinter. Bei Strato war das MySQL, auf meinem eigenen Server mit Ubuntu 16.04 LTS habe ich MariaDB installiert. Das scheint sich in Sachen Kompatibilität hervorragend zu vertragen und bisher sehe ich keine Probleme.

Die WordPress-Instanz: Das sind ganz einfach alle Dateien, die in der WordPress-Installation liegen. Dazu gehören Plugins, Uploads, Themes und so weiter.

Mit den beiden Komponenten war es bei mir dann schon getan . im Prinzip, aber der Teufel liegt bekanntlich im Detail.

ich weiß nicht, wie es bei anderen Hostern ist. Aber Strato erlaubt mir zum Glück einen Zugriff auf meinen Webspace via SSH und stellt grundlegende Tools wie rsync und mysqldump zur Verfügung. Das hat mir das Leben für den Umzug der WordPress-Instanz deutlich einfacher gemacht.

Als Vorbereitung hatte ich außerdem Caching-Plugins deaktiviert und auch Piwik musste temporär seinen Dienst quittieren. Für die paar Minuten ist das echt nicht entscheidend und lieber einen sauberen Neustart, vor allen Dingen mit dem Caching – habe ich mir gedacht.

Erst die Daten synchronisieren

Die Daten habe ich schon einige Zeit auf meinen neuen Server mittels rsync synchronisiert. Alle paar Tage habe ich einen entsprechenden Befehl laufen lassen, der dann immer die aktuellen Dateien der WordPress-Instanz geholt hat. Das funktioniert so ähnlich (alles eine Zeile):

rsync -avuz --exclude-from="/Pfad/zu/exclude.txt" ANWENDER@ssh.strato.de:/Pfad/zur/WordPress/Instanz/ /var/www/Verzeichnis-auf-Server/ --no-owner --no-group --delete

In der Zwischenzeit habe ich bereits eine Datenbank auf meinem neuen Server angelegt, die allerdings noch leer war. Dafür konnte ich bereits die Datei wp-config.php entsprechend anpassen und die Anmelde-Daten, sowie den Namen der neuen Datenbank hinterlegen. Da mir das rsync die Datei immer wieder überschrieben hätte, habe ich sie aus dem Sync-Vorgang ausgeschlossen (exclude). Gleiches gilt für die Datei .htaccess, die ich ebenfalls schon an meine Bedürfnisse angepasst habe. Browser-Caching via .htaccess wollte bei Strato irgendwie nie richtig funktionieren, aber auf meinem eigenen Server schon. Änderungen in der Art meine ich.

Zu diesem Zeitpunkt hatte ich bereits meine gesamte WordPress-Instanz ohne Datenbank komplett angepasst auf dem neuen Server. Was noch fehlt, ist dem Anwender www-data die Daten zu übertragen:

chown -R www-data.www-data /Pfad/zu/Wordpress/Instanz/*

und vielleicht noch nachsehen, ob das Cache-Verzeichnis beschreibbar ist:

chmod -R 755 /Pfad/zu/WordPress/Instanz/wp-content/cache/

Der Umzug an sich

Ich habe auf meinem Server einen Virtual Host in Apache mit bitblokes.de angelegt. Das DocumentRoot zeigte aber zunächst auf einen Ordner /var/www/maintain/. Dort befindet sich eine index.html, die einfach auf eine kurze Auszeit verweist.

Meine Domain befindet sich weiterhin bei Strato, aber ich kann dort unter den DNS-Einstellungen einen A-Record setzen. Dort hinterlege ich ganz banal die IP-Adresse meines Contabo-Servers und schon nach wenigen Sekunden werden alle Anfragen an den root-Server weitergeleitet. Im Anschluss hat ein Aufruf auf meine Seite so ausgesehen:

Beim Umzug eine Wartung aktiviert

Beim Umzug eine Wartung aktiviert

Wer das ganz elegant machen will, der leitet temporär alle Anfrage via .htaccess auf die Index-Seite um. Dann gibt es keine Fehler, sondern jeder bekommt die Wartungs-Nachricht.

RewriteEngine on
RewriteCond %{REQUEST_URI} !^/index.html$
RewriteRule .* /index.html [L,R=302]

Da die Domain nun auf die IP-Adresse meines root-Servers zeigt, konnte ich auch ein Zertifikat via Let’s Encrypt ausstellen lassen. Das ging vorher nicht und Let’s Encrypt meckerte, da die Domain logischerweise nicht zur IP-Adresse meines VPS passte.

Nun ging es zurück auf die Kommandozeile bei Strato und es wurde die Datenbank exportiert. Da es keine Zugriffe mehr darauf gibt (alles geht in das Wartungs-Verzeichnis), verändert sich auch nichts mehr. Wie gesagt gibt es zum Glück mysqldump und mein Befehl hat so ähnlich ausgesehen:

mysqldump --host=rdbms.strato.de -u ANWENDER -pPASSWORT DB-NAME | gzip > backup-DB.sql.gz

Die komprimierte SQL-Datei habe ich ebenfalls mit rsync direkt auf den Server gezogen. Danach wurde sie entpackt (gunzip) und im Anschluss mit einem solchen Befehl importiert:

mysql -u ANWENDER -p DB-NAME < backup-DB.sql

Es ginge auch mit zcat, aber ich habe die unkomprimierte SQL-Datei gerne parat, wenn ich was nachsehen muss.

zcat backup-DB.sql.gz | mysql -u ANWENDER -p DB-NAME

Nun ist alles bereit und ich kann in meinem VirtualHost das DocumentRoot auf die umgezogene WordPress-Instanz biegen (VirtualHost für https nicht vergessen!) und danach Apache neu starten.

Die Website hat nach dem Umzug funktioniert und sie war auf keinen Fall länger als 30 Minuten offline. Aber …

Der Teufel steckt im Detail

An sich hat alles erst einmal gut ausgesehen. Die Seite hat sich schnell aufgebaut und ich konnte mich anmelden. Das Caching ließ sich aktivieren und endlich meckern diverse Test-Seiten nicht mehr, dass kein Browser Caching aktiv ist. Auch Piwik hat schnell wieder funktioniert.

Was einen Fehler gemeldet hat, war WP Smush. Damit werden Bilder beim Hochladen automatisch noch ein bisschen besser komprimiert, was der Performance der Website zugute kommt. Ich verwende die kostenlose Version, weil 49 US-Dollar pro Monat finde ich übertrieben. Ich brauche das andere Angebot der Entwickler nicht und bei einer Einmalzahlung würde ich mir die Pro-Version kaufen. Aber für 500 Euro im Jahr – wirklich nicht. WP Fastest Cache werde ich mir hingegen leisten.

Auf jeden Fall hat WP Smush den Upload-Pfad angemeckert. Der war zu meinem Erstaunen noch der alte absolute Pfad von Strato. Wer macht denn sowas? nun konnte ich den Parameter dafür aber nicht im Plugin-Verzeichnis von WP Smush finden.

grep -r "PFADNAME" . >> search.txt

Oje, dann ist das wohl irgendwo in der Datenbank. In der Tabelle, die WP Smush anlegt, ist es nicht. Das Bauchgefühl sagt, die Tabelle wp_options zu inspizieren und siehe da. Es gibt einen Parameter upload_path unter option_name und der war bei mir auf den alten absoluten Pfad unter option_value eingestellt.

Beim Umzug habe ich nicht mit diesem absoluten Pfad gerechnet

Beim Umzug habe ich nicht mit diesem absoluten Pfad gerechnet

Ich habe extra nachgesehen, wie das bei einer frischen Installation ist und da ist der Parameter leer. WP Smush oder irgendein andere Plugin muss den Pfad hinterlegt haben oder es ist eine Altlast. Auf jeden Fall verwendet WP Smush diesen Pfad und das ist saublöd. Nachdem ich ihn manuell auf den aktuellen absoluten Server-Pfad geändert hatte, funktionierte das Plugin wieder.

Später habe ich dann gesehen, dass dieser Pfad ebenfalls in den Einstellungen unter Mediathek hinterlegt ist. Nachdem alles gut ausgesehen hat, bin ich zur Kontrolle die Einstellungen durchgegangen und siehe da …

Nach dem Umzug vielleicht die Einstellungen kurz durchgehen

Nach dem Umzug vielleicht die Einstellungen kurz durchgehen

Man lernt eben nie aus und über das GUI wäre es wohl noch schneller gegangen.

Temporär MySQL auf PHP 7 umbiegen

Was natürlich auch nicht funktioniert hat, waren ein paar Scripte, die bei Strato noch mit PHP 5.5 liefen. Gerade bei MySQL ist es aber so, dass sich von 5.5 auf 7 einiges getan hat und die mysql extension als deprecated eingestuft ist. Meine Scripte sind natürlich auf die Nase gefallen.

Da die Dinger sowieso in naher Zukunft weg oder ersetzt werden sollen, wollte ich mir keinen großen Aufwand machen. Ich habe zum Holzhammer gegriffen, der in diesem Fall MySQLConverter heißt. Bei dem Tool gibst Du ein Code-Schnipssel, eine Datei oder ein Verzeichnis an und es versucht dann, die alten Aufrufe in funktionierende zu wandeln.

Der Entwickler warnt, dass es keine Security-Checks und so weiter gibt und man lieber seinen Code umbauen sollte. bei mir hat es funktioniert und es sieht gut aus. Ein Backup meiner Scripte habe ich und daher konnte ich sie mir einfach überschreiben lassen. Wie gesagt ist das ein Provisorium, aber es hat Zeit gespart. Ich bin nur etwas beunruhigt, da Provisorien bekanntlich am längsten halten … 🙂

Alternativ für so eine temporäre Phase könntest Du auch php7-mysql-shim einsetzen. Auch hier warnen die Entwickler, dass es nur eine Zwischenlösung ist.

Der root-Server macht Spaß

Auch wenn ich ihn selbst administrieren muss, macht mir der root-Server von Contabo doch großen Spaß. Meine Website ist nun tatsächlich reaktionsfreudiger und bald kommt auch noch eine Nextcloud darauf.

Außerdem funktionieren Plugins, die auf dem kastrierten Strato-Server nicht mehr so recht wollten. WP to Twitter ist ein Beispiel.

Als VPN-Server mit sshuttle lässt er sich auch noch benutzen, was mir sehr Recht ist. In unsicheren oder nicht vertrauenswürdigen WLANs kann ich somit sämtlichen Traffic via SSH über meinen Server leiten.

Auch wenn der Umstieg im nachhinein betrachtet wohl die richtige Entscheidung war, finde ich es trotzdem inakzeptabel, dass ein Support vermutet und nicht prüft. Das hätte mir lange viel Ärger erspart.




 Alle Kommentare als Feed abonnieren

14 Kommentare zu “Umzug: Meine Website läuft auf dem root-Server und so habe ich es gemacht”

  1. intux says:

    Willkommen im Club! 😉

  2. Danke für deinen Blogbeitrag. Ich habe momentan den V-Server V80 von Strato und sehe mittlerweile anhand von Pingdom Pagespeed Check, der alle 30 Minuten durchgeführt wird, dass das Netzwerk bei denen schon sehr überlastet scheint. Da sind halt schwankungen von 1 bis 2 Sekunden drin beim Seitenaufbau und ab und zu Server-Reaktionszeiten von 350 ms laut Google Pagespeed Insights.

    Ich habe mich überall umgesehen und bin auch auf Contabo gestossen. Die Dedicated Server lachen mich dort an. Gut finde ich auch, dass dort der Haken klar erkennbar ist: es gibt keinen Support von 23 bis 8 Uhr. Damit kann ich völlig gut leben und bin froh, dass ich dann dafür nicht zahlen, sondern für gute Hardware und Support tagsüber zahle.

    • jdo says:

      Es ist etwas Aufwand, das Ding einzurichten, die Seite umzuziehen und so weiter. Aber im Endeffekt bin ich froh, umgezogen zu sein. Es geht einfach alles schneller.

      Die Preise von Contabo sind in Ordnung.

  3. Sam says:

    Super Beitrag! Strato war mal gut, hat sich aber im Laufe der Jahre nicht wirklich "weiterentwickelt"! Deswegen ist es auch gut, wenn man sich immer mal im Markt umschaut und ggf. zu einem anderen(neuen) Hoster wechselt. Am Ende hilft das auch Strato sich zu erneuern ...

    ... laut Denic wird Deine Domain immer noch von Strato verwaltet, ist das so gewollt!?

    • jdo says:

      Hallo und sorry für die späte Antwort. Dein Kommentar ist im Spam gelandet und ich habe es nicht gesehen.

      Ja, die Domain-Verwaltung liegt derzeit noch bei Strato, weil da ein ziemlicher Rattenschwanz mit dranhängt. Dafür werde ich mein Paket runterschrauben und somit weniger Geld bezahlen. Unterm Strich komme ich dann fast auf die gleichen Ausgaben, habe aber meine Ruhe.

  4. Gerriet says:

    Hallo ;D Schöner BlogArtikel ;D Bei dem Begriff V-Server = RootServer, da könnte man sich drüber streiten, was es nun genau ist. Ausser ich hier was falsch verstanden.

    Aber was ich eigentlich schreiben wollte, hat Contabo nicht früher den Anhang gehabt, schlechte Support zu haben ? Hab irgendwie mal was drüber gelesen, kann mich aber auch irren ;D
    Wobei ich selbst auch am überlegen bin, ob ich nicht mit einem meiner Projekte auf einen V-Server umziehen sollte. Was mich davon abhält, ist zum einer der Sicherheit und das es doch einiges an Arbeit macht, zu dem was ich eh schon bei den Projekten mache.

    • jdo says:

      Contabo hat keinen Support zwischen 23.00 und 8.00 Uhr. Wenn da was ist musst Du halt bis zum nächsten Morgen warten.

      Arbeit macht es eigentlich gar nicht so viel, da ich zumindest unter Linux sehr viel automatisieren konnte.

  5. Christian says:

    Sehr schöner Artikel !

    Gibt es eigentlich eine Vorlage, wie man die .htaccess beim nginx Server umsetzt ? Ich habe jetzt schon einige Varianten aus dem www getestet, bekomme aber keinen Zugriff auf die Webseite/das Admin Panel.
    Entweder erhalte ich ein "403 Forbidden" oder ein "File not found".

    • jdo says:

      Kann ich leider nicht beantworten, da ich nix mit nginx mache.
      Ich verstehe das Problem aber auch nicht genau, muss ich ehrlich zugeben.

  6. Christian says:

    Ich bin auch zu Contabo gewechselt und standardmäßig war dabei nginx aktiv. Sobald nginx läuft, wird die .htaccess nicht mehr berücksichtigt. Stattdessen müssen die "REWRITE"-Regeln entsprechend für nginx konvertiert werden. Und diesbezüglich bin ich bisher nicht weitergekommen und habe gehofft, dass mir vielleicht jemand einen Tipp geben kann, wie diese für nginx in Verbindung mit WordPress lauten müssen.

    • jdo says:

      Also bei mir nicht. Ich hab mir ein rudimentäres Ubuntu Server 16.04 installieren lassen und dann alles selbst eingerichtet. Bei mir war kein nginx installiert oder aktiv. Von daher tut es mir leid, an dieser Stelle nicht weiterhelfen zu können. Wie gesagt mache ich mit nginx nichts.

  7. Christian says:

    Kein Problem. Ich werde es ggf. einmal abschalten. Ich habe die Plesk-Administrationsoberfläche installiert, da sollte ich es relativ einfach abschalten können.

    • jdo says:

      Äh, deswegen habe ich den Teil nicht kapiert. Bei mir läuft auch kein Plesk - alles Kommandozeile. Ist zugegeben nicht ganz so komfortabel, aber ich habe es einmal eingerichtet und echt schon lange nicht mehr angefasst.

  8. Christian says:

    Da fehlen mir leider die detaillierten Kenntnisse. Daher die "Maus-Klick"-Variante per Plesk ;).