Im ersten Teil der Artikelreihe Vom Webspace zum V-Server hatte ich geschrieben, weshalb ich mich zu einem Serverwechsel entschlossen hatte. In diesem Teil erfahrt ihr nun, welche Erfahrungen ich beim Umzug gemacht habe und was es dabei zu beachten gilt. Dieser Artikel ist dabei nicht speziell auf den Wechsel vom Webspace zum V-Server abgestimmt, sondern liefert generelle Informationen für alle Serverumzüge.
Bei einem Serverwechsel sind 5 Schritte zu erledigen, die unbedingt in der richtigen Reihenfolge gemacht werden müssen.
Dateien kopieren
Zuerst solltet ihr ein Backup aller Dateien auf euren Desktop machen. Von dort ladet ihr die Dateien dann auf den neuen Server hoch. Da die meisten User eine wesentlich niedrigere Upload- als Downloadgeschwindigkeit haben, dauert das Hochladen auf den neuen Server deutlich länger als das Runterladen. Falls euer neuer Hoster euch die Möglichkeit anbietet, eure Seite unter einer Übergangsdomain zu erreichen, solltet ihr diese aufrufen um zu überprüfen, ob alles so angezeigt wird, wie ihr es euch vorstellt. Falls nicht, kann es daran liegen, dass in eurer .htaccess Befehle drin stehen, die euer neuer Hoster nicht unterstützt bzw. es fehlen Befehle, die ihr dafür benötigt. Wenn nach dem Aufruf eurer Website ein „500 Internal Server Error“ erscheint, liegt das mit ziemlicher Sicherheit an einem fehlerhaften Eintrag in der .htaccess.
Datenbank exportieren und wieder importieren
Im zweiten Schritt müsst ihr eure Datenbank exportieren (am besten gepackt) und wieder auf dem Desktop speichern. Danach richtet ihr auf dem neuen Server eine leere Datenbank ein und importiert dorthin die Tabellen. Für den Export und Import könnt ihr phpMyAdmin verwenden, dass bei den meisten Hostern installiert ist. Allerdings gibt es für den Import manchmal Größenbeschränkungen. Bei mir war es z. B. so, dass ich keine Datenbanken mit einer Größe von mehr als 2 MB importieren konnte. Falls die Datenbank zu groß ist, gibt es noch 2 Alternativen, wie ihr eure Datenbank umziehen könnt:
- SSH – Wer bei seinem neuen Hoster einen SSH-Zugang hat (Fernzugriff auf den Server über eine Konsole), kann darüber die Datenbank importieren.
- Bigdump – Dieses Skript wurde speziell für den Import von großen Datenbanken entwickelt.
Wichtig beim Umzug eurer Datenbank ist, dass ihr beim Export und beim Import die gleiche Zeichencodierung verwendet. Die Einstellung dazu findet ihr bei phpMyAdmin unter „Exportieren/Angepasst/Ausgabe/Zeichencodierung der Datei“. Ich habe für den Export und Import immer „UTF-8“ verwendet.
Bei meiner Piwik-Datenbank, die eine Größe von über 2 GB hatte, hatte ich beim Import leider keinen Erfolg. Ich hatte zwar einen Versuch gestartet und für den Upload der Datenbank über 2 Stunden gebraucht. Nachdem dieser aber gescheitert war (in der Import-Datei war eine Zeile zuviel drin, die ich auch nicht einfach entfernen konnte, weil die Datei gepackt war) habe ich auf den Import verzichtet. Sicher hätte ich es irgendwann geschafft, aber dafür, dass mir die Piwik-Daten nicht so wichtig waren, war mir der Aufwand einfach zu hoch.
Nach dem Import der Datenbank müsst ihr noch in der jeweiligen Config-Datei die Datenbankeinstellungen ändern (Host, Datenbankuser, Datenbankname, Datenbankpasswort).
DNS-Einträge ändern
Im nächsten Schritt müsst ihr die DNS-Einträge ändern lassen (also die Einträge in das von mir im Artikel Trennung von Domain und Webspace beschriebene digitale Telefonbuch). Dazu braucht ihr die IP-Adresse eures Servers (erfahrt ihr von eurem neuen Hoster). Je nach Anbieter könnt ihr diese dann in den DNS-Einstellungen eures alten Anbieters selbst eintragen (so funktioniert es z. B. bei all-inkl.com) oder euren Domain-Registrar um die Änderung der Einträge bitten. Wichtig ist dabei, dass ihr nicht nur die Einträge der Domain ändern lässt, sondern auch die Einträge aller Subdomains. Beim Umzug dieses Blogs hatte ich das leider versäumt, so dass die auf eine Subdomain ausgelagerten Grafiken nicht angezeigt wurden und teilweise nur schwarze Schrift auf dunklem Hintergrund zu lesen war (einige Leser werden sich sicher daran erinnern).
Domain übertragen
Nachdem die DNS-Einträge geändert wurden und ihr eure Projekte ausgiebig getestet habt, ob auch alles so funktioniert, wie es soll, könnt ihr mit der Übertragung eurer Domains beginnen. In den meisten Fällen funktioniert das so, dass ihr dem alten und neuen Hoster einen sogenannten KK-Antrag schickt. Daraufhin erhaltet ihr von dem alten Hoster einen AuthInfo-Code, den ihr an den neuen Hoster weiterleitet. Dieser übernimmt dann die Domain und nimmt auch die Änderung der Einträge bei der Denic vor. Wer seine Domains, wie von mir im Artikel Trennung von Domain und Webspace beschrieben, bei einem Domainregistrar registriert hat, kann sich diesen Schritt natürlich sparen.
Vertrag kündigen
Wenn ihr alle Daten kopiert, die Datenbanken erfolgreich importiert, die DNS-Einträge geändert und die Domains übertragen habt, dann könnt ihr beim alten Anbieter euren Vertrag kündigen.
Richtige Reihenfolge beim Serverwechsel
Wie bereits am Anfang erwähnt, ist es wichtig, bei einem Serverumzug die einzelnen Schritte in der richtigen Reihenfolge vorzunehmen:
- Dateien kopieren
- Datenbank exportieren und wieder importieren
- DNS-Einträge ändern
- Domain übertragen (kann eventuell entfallen)
- Vertrag kündigen
Wenn ihr diese Reihenfolge beachtet, haltet ihr die Ausfallzeiten kurz und die meisten eurer Besucher werden von dem Serverwechsel gar nichts mitbekommen.
Generelle Tipps für einen Serverumzug
Beim Umzug von mehreren Projekten solltet ihr mit dem einfachsten anfangen (z. B. ein Projekt, das nur aus Dateien besteht und keine Datenbank benötigt). Mit den dabei gewonnenen Erfahrungen tut ihr euch bei komplizierteren Projekten dann schon etwas leichter.
Die Änderung der DNS-Einträge solltet ihr zu einem Zeitpunkt vornehmen, an dem eure Website nicht so stark besucht ist, z. B. in der Nacht von Samstag auf Sonntag. Es kann danach bis zu 24 Stunden dauern (im Ausland eventuell sogar noch länger), bis eure Website auf dem neuen Server erreichbar ist. In der Regel dauert es aber nur ein paar Stunden. Bei der Übertragung der Domain entstehen dann auch keine Ausfallszeiten mehr, da der eigentliche Umzug auf der Änderung der DNS-Einträge beruht.
Bei einem Forum solltet ihr eure User 1-2 Tage vorher darüber informieren, dass ein Serverumzug bevorsteht. Kurz bevor ihr die Datenbank exportiert, solltet ihr das Forum sperren. Sonst kann es passieren, dass Postings geschrieben werden, die dann in der Exportdatei nicht mehr enthalten sind.
Eure Erfahrungen mit einem Serverumzug
Habt ihr schon mal einen Serverumzug gemacht und den Hoster gewechselt? Ist dabei alles gut gegangen oder ging auch etwas schief? Welche Erfahrungen habt ihr gemacht? Schreibt doch bitte in den Kommentaren etwas darüber.
Artikelreihe „Vom Webspace zum V-Server“:
Tipp, um den richtigen VServer zu finden:
http://www.vserververgleich.com
Ich habe derzeit das Problem, dass ich eine MySQL 4 Datenbank nicht vernünftig auf in MySQL 5 importiert bekomme, da die Sonderzeichen nicht passen. Was ich bisher bei Google gefunden habe, hat nicht wirklich geholfen. Hast du für solche Fälle auch Lösungen?
Du wirst es nicht glauben, aber ich hatte bei meinem Serverumzug das gleiche Problem 🙂 Wichtig ist, dass beim Export und beim Import der gleiche Zeichensatz eingestellt ist. Dann dürfte es zu keinen Problemen mit Sonderzeichen und Umlauten kommen.
Ich habe den Artikel noch um diese Information ergänzt.
Vielen Dank für die Anregung 🙂
Na dann probiere ich das am Wochenende mal aus und werde berichten ob es funktioniert 🙂
Solche Probleme mit den Zeichnsätzen hat man meist wenn man den phpmyAdmin nutzt.
Ich empfehle zum Export und Reimport der Datenbanken immer MySQLDumper, ein Tool was auch mit wirklich riesigen Datenbanken zurecht kommt.
Wir hatten einmal massive Probleme mit 1blu. Die haben unseren Server wegen Spam-Mails und darauf folgenden Abuse-Meldungen gesperrt. Und alle Daten schienen verloren, weil die konsequent nicht dazu bereit waren uns überhaupt zu sagen, was Sache ist. Erst nach Tagen konnten wir auf unsere Daten zugreifen, schließlich wollten sie aber unsere Domain(s) nicht rausrücken. Erst nach 3 Wochen offline war ein neuer Anbieter mit unserer Seite bezogen und wir hatten endlich unsere Adressen wieder. Diese haben wir dann vom Hoster getrennt auf einem anderen Anbieter untergebracht. Und der hat uns dann Monate später auch die genauen Gründe für den Abuse nennen können. Denn wir hatten im System eine versteckte Shell die Spam verschickte. Wir haben sie gelöscht und gut wars. Ist allerdings schon 5 Jahre her.
Übrigens, MySQLDumper kann auch direkt von Server zu Server das Backup machen, ohne Umweg auf das Dektop, und die damit verbundene Geschwindigkeitsreduzierung.
Das geht sehr fix, und es sind auch weniger Fehlerquellen.
Denn, bei jedem FTP, können Daten verändert ankommen, gerade wenn die Leitung sehr langsam ist, und Fehleranfällig (wie die meisten Home-DSL).
Server2Server ist da DEUTLICH schneller.
Serverumzüge, ja, habe ich schon mehrere gemacht, und bis auf einen sperrigen Provider, der den Kunden nicht weg lassen wollte und alles sehr verzögert hat, liefen alle ganz gut.
Mal vergessen, die DB-Einstellungen zu ändern.. (neuer User und PW).
Auch ich habe vor, bei einem Projekt vom jetzigen Provider auf einen anderen umzusteigen.
Da mein Internetzugang seehr langsam ist, wäre es für mich dann wohl besser, das Server2Server Prinzip zu nutzen.
Besten Dank für den Artikel und die interessanten Kommentare, ich werde mich an die Anleitung halten und hoffe, es funktioniert danach alles wieder 😉