Checkliste für den Umzug einer Webseite
Mit der Checkliste für den Umzug einer Webseite sollten euch die Arbeiten leicht fallen und der Umzug auf einen neuen Server ohne Downtime möglich sein. In den letzten Jahren habe ich circa 1 bis 2 Seiten pro Monat auf einen neuen Server migriert. Meistens waren das Magento Onlineshops, sehr oft auch WordPress Webseiten. Auch dieser Blog hat bereits vier Mal den Server gewechselt. Aus diesen Erfahrungen habe ich diesen Artikel erstellt. Oft ging der Umzug problemlos und ohne Downtime, manchmal gab es aber auch das eine oder andere Problem…
Checkliste für den Umzug einer Webseite
Die Gründe für einen Serverwechsel sind sehr unterschiedlich. Aus meiner Erfahrung ist der häufigste Grund ein Upgrade auf einen besseren, schnelleren Server. Hin und wieder spielen aber auch die laufenden Kosten eine Rolle und man möchte die Webseite auf einen billigeren Webspace kopieren. In jedem Fall muss man folgendes beachten:
Dokumentation (optional)
Wenn man eine Webseite umzieht an dessen Entwicklung man selbst nicht beteiligt war, dann ist eine ausführliche Dokumentation Pflicht. Dabei wird erfasst, welches System verwendet wurde (zB CMS Systeme wie WordPress oder Shopsysteme wie Magento), welche Module und Erweiterungen installiert sind, welche Versionen die Software hat und ganz wichtig: wo gab es Eingriffe der Entwickler. Bei sehr kleinen und eigenen Webseiten kann der Schritt übersprungen werden.
Kenne den Server (optional)
Neben der Dokumentation der Software ist auch der technische Hintergrund zu ergründen. Unterschiedliche Betriebssysteme oder Laufzeitumgebungen (zB PHP Versionen) müssen ermittelt umd auf Kompatibilität geprüft werden. Bei den meisten shared Webspaces kann der Schritt entfallen, ea kommt aber immer wieder vor, dass man im Nachhinein feststellen muss, dass zum Beispiel eine Apache Extension fehlt, ein Memory Limit zu niedrig ist oder der Mailversand nicht funktioniert… es empfiehlt sich auf der selben neuen Serverumgebung zuerst ein Testsystem anzulegen und alle kritischen Prozesse durchzugehen.
Übernahme der Daten
Sobald man alle Informationen hat beginnt der eigentliche Spaß. Das kopieren der Daten. Moderne LAMP Applikationen bestehen aus Daten (Skript Dateien, Ordner, Bilder, …) und Datenbanken (meist MySQL). Diese müssen wir nun auf den neuen Server kopieren.
- Datenbanken übernehmen
Datenbanken sind meist recht unkompliziert zu kopieren. Über Datenbankprogramme wie PhpMyAdmin lässt sich das sogar für Laien einfach lösen. Am alten System exportiert man die Struktur und die Daten der Datenbank. Es empfiehlt sich diese gepackt (zip, bzip2 oder gz) herunterzuladen. Auf dem neuen Server erstellt man nun eine neue leere Datenbank und kann die eben erzeigte Sicherung der Datenbank importieren. Sobald die Datenbank jedoch eine bestimmte Größe übersteigt (zum Beispiel eine Magento Datenbank mit über 1 GB), dann muss man die Datenbank über die Kommandozeile exportieren beziehungsweise importieren. Das geht mit folgenden Kommandos (unter Linux):
MySQL Export:mysqldump --opt -p -u DBUSER DBNAME > db.sql
MySQL Import:
mysql -h LOCALHOST -u DBUSER -p DBNAME < db.sql
- Daten kopieren
Die Programmdaten liegen als Ordner und Dateien am Server. Diese überträgt man entweder direkt per SSH auf den neuen Server oder alternativ über FTP.- FTP
mittels FTP wird der Umzug zur Qual. Man kann die Daten nicht direkt von einem Server auf den anderen ziehen. Meist verwendet man Programme wie Filezilla um die Daten lokal herunter und danach am neuen Server hochzuladen. WordPress geht gerade noch, bei einem Magento Shop mit 20.000 bis 30.000 Dateien dauert das mehrere Stunden und ist nicht zu empfehlen! - SSH
auf der Kommandozeile kann man auf Servern zig GB Daten oft innerhalb weniger Minuten kopieren. Dabei geht man keinen Umweg über den lokalen Rechner sondern zieht die Daten direkt auf den neuen Server. Das geht mehr oder weniger gut, oft gibt es Ports und fehlende Unterstützung für Shellprogramme. Oft ist das Kopieren nur von einem der beiden Server möglich. Mögliche Programme dafür sind rsync, wget oder scp. Anbei zwei Beispiele:
Rsync:rsync -avz Ordner/ BENUTZER@example.com:NEUERORDNER/.
Rsync mit einem nicht Standard Port zB 222:
rsync -avz -e "ssh -p 222" Ordner/ BENUTZER@example.com:NEUERORDNER/.
SCP:
scp -r . BENUTZER@example.com:NEUERORDNER/.
SCP mit nicht Standard Port zB 222:
scr -P 222 -r . BENUTZER@example.com:NEUERORDNER/.
- FTP
Einstellungen
Sobald FTP Daten und Datenbanken kopiert wurden müssen noch die Einstellungen angepasst werden. Jedes System hat dafür eine Konfigurationsdatei in der die Verbindungsdaten zu Datenbank (DB Name, Login, Passwort, Port und Host) eingetragen werden. Erst wenn alle Server spezifischen Konfigurationen angepasst wurden ist man für den letzten Schritt bereit.
Domain übernehmen
Eine Domain kann man sehr einfach auf einen neuen Server „umziehen“. Im Backend beim Domain-Hoster findet man 2 relevante Einstellungen. Der A Record (AAAA Record) und der MX Record. Diese sind für folgende Informationen verantwortlich:
- A Record
die Domain wird auf den Server mit der dort hinterlegten IP Adresse aufgelöst. Das heißt example.com wird von einem DNS Server in die unter der Domain example.com hinterlegte IP Adresse übersetzt. Der Browser stellt die Anfrage der Domain an den nächsten DNS Server, dieser liefert die IP Adresse zurück. Über die IP Adresse wird dann die Webseite abgefragt. - AAAA Record
ist exakt das selbe wie der A Record jedoch nicht mit IPv4 sondern den neueren IPv6 Adressen. Sofern der Server diese unterstützt sollte man diese auch ändern. - MX Record
ist im Prinzip das selbe wie der A Record nur geht es dabei um die IP Adresse des Mail Servers. Sofern man am neuen Server eine Mailbox mit dem selben Namen hat kann man auch diesen Eintrag ändern. Man kann aber genauso gut den Mailserver mit einer ganz anderen IP verwenden.
Die Änderung des A Records dauert mehrere Stunden. Warum? Beim Domainhoster ändert man die hinterlegte IP Adresse, pingt man danach jedoch die Domain wird man feststellen, dass die IP Adresse des Servers nach wie vor die alte ist. Das ist kein Fehler. Es gibt im Internet hunderte DNS Server. Die Information welche IP Adresse einer Domain zugeordnet ist verbreitet sich dabei recht langsam über alle DNS Server. Manchmal dauert es 3 Stunden, manchmal 6. Das hängt immer davon ab, von welchem DNS Server man die IP Adresse bezieht. Für andere Benutzer im Internet kann das aber länger dauern. Spätestens nach 24 Stunden sollte sich die Information jedoch über alle Server verbreitet haben.
Fazit
Mit meiner Checkliste für den Umzug einer Webseite sollte euer nächster Umzug problemlos ablaufen. Falls man sich unsicher ist sollte man immer vorher einen Testserver erstellen und auf diesem die komplette Applikation durchtesten. Für die meisten Projekte macht es Sinn, wenn am neuen Server neben dem Live- auch ein Testsystem existiert.
Im nächsten Artikel zeige ich euch noch wie ihr die Downtime auf 0 reduziert.
Hey,
danke für die Anleitung. Habe sie soeben benutzt und alles scheint (noch) zu funktionieren.
Mehr wollte ich auch nicht.
Viele Grüße!