Liebe Leser,
heute Abend ist ein wichtiger Termin für diese Webseite. Denn ich ziehe mit ihr um. Ich habe mir in den letzten Tagen einen neuen Hoster gesucht und bin nun Kunde beim Hallenser Hoster Alfahosting. Nun muss noch die Seite dahin kommen. Wie passiert das?
Zunächst einmal musste ich mir natürlich einen Plan machen, wie ich am besten den Umzug realisiere. Und dann bin ich auf die wohl beste Möglichkeit gestoßen, die man haben kann. Im folgenden werde ich kurz meinen „Schlachtplan“ ausführen. Wenn jemand bis heute Abend Ergänzungen oder Verbesserungsvorschläge hat, können diese gern geäußert werden. Ich lade praktisch zum „Brainstorming“ ein.
Vorüberlegung
Es ist ja nicht so, dass der neue Hoster vom alten Hoster die Daten übermittelt bekommt. Man muss da schon selbst tätig werden. Was die Hoster untereinander austauschen, ist der so genannte „AuthInfo Code“ zum Übertragen der Domain Daten. Den muss man beim alten Hoster erfragen, spektakulärerweise über die Kündigung.
Hat man den „AuthInfo Code“ dann erhalten, wäre es meiner Ansicht nach ziemlich fatal, diesen beim neuen Hoster gleich anzugeben, denn dann wandern die Domain Daten innerhalb von Minuten zum neuen Hoster, und die Seite ist dann unter Umständen nicht mehr erreichbar.
Das sollte man dann doch irgendwie vermeiden können, finden Sie nicht auch? Und deshalb muss man sich genau überlegen, wie man vorgeht. Klar, es kann sein, dass ich mir zu große Sorgen mache, denn diese Seite zieht das erste Mal seit ihrem Bestehen um. Aber ich habe eine kleine, noch im Aufbau befindliche Partnerseite bereits umgezogen, und da war das alles kein Problem.
Ich werde jetzt also mal aufschreiben, was ich alles zu tun gedenke. Denn beim Domain-Umzug ist einiges zu beachten. So besteht z.B. ein WordPress Blog nicht nur aus Dateien, sondern auch aus einer Datenbank. Und die muss mit umgezogen werden, damit die Webseite weiter funktioniert.
Also genug geredet, ich schreibe jetzt mal, wie ich mir das gedacht habe.
Der Umzug
Datensicherung
Zunächst einmal macht man eine Datensicherung. Typischerweise lädt man sich dabei alle Daten herunter. Das betrifft an sich alles, was die Seite betrifft. Irgendwelche Fehlerprotokolle oder Zugriffsprotokolle muss man dabei nicht mit sichern, es sei denn, man will da Zugriffe überprüfen.
Am einfachsten geht das, indem man ein FTP-Programm wie FileZilla verwendet. Damit kann man dann gleich mal die gesamte Datenstruktur der Webseite herunterladen. Und Berechtigungen bleiben so auch erhalten.
Mit dem gleichen FTP-Programm kann man dann die Daten auf den FTP beim neuen Hoster schieben. Man muss sich nur neu dort anmelden.
Datenbanksicherung
Am einfachsten lädt man die Datenbank über die Datenbankverwaltung beim alten Hoster herunter. Dort wird meistens PHPMyAdmin angeboten, und dort kann man die Datenbank als SQL-Datei exportieren. Beim neuen Hoster lädt man diese Datenbankdatei einfach in eine neue Datenbank hoch, indem man sie importiert. Alles keine Hexerei.
Aber was macht man, wenn man den Fehler erhält, dass die Datenbank zu groß ist? Der Import schlägt dann fehl. Dafür gibt es den so genannten MySQLDumper. Das ist ein Tool, das man sich ganz einfach im eigenen Webspace installieren kann. Da meine Datenbank zu groß ist, um über PHPMyAdmin importiert zu werden, muss ich den also eh verwenden. Und da sind meine Gedanken die folgenden:
- Nach der Installation den Dumper aufrufen (Die Adresse wird bei der Installation generiert)
- Über den Menüpunkt „Backup“ eine Sicherung der Datenbank starten (Aufpassen: am besten mit aktivierter GZip-Komprimierung)
- Das Backup findet man dann auf dem FTP des alten Hosters in der Verzeichnisstruktur der Webseite unter /MySQLDumper/<Version>/work/backup
- Es empfiehlt sich, die Dateien auch noch einmal herunterzuladen
- Auf dem FTP des neuen Hosters lädt man dann schon einmal die Backup-Datenbank hoch (Da ich ja schon vorher die kompletten Dateien rüber geschoben habe, habe ich schon eine Struktur des MySQLDumper auf dem neuen FTP und muss „nur“ die Datei nach /work/backup schieben)
- Dann muss der AuthInfo Code erst einmal angegeben werden, denn ohne kann die Weboberfläche des MySQLDumper nicht erreicht werden – ACHTUNG! Webseite ist jetzt nicht verfügbar!
- Sind die Domain Daten dann übertragen (das geht im Allgemeinen recht schnell, wie ich erfahren habe), kann der Dumper dann über die Webseitenandresse und /MySQLDumper/<Version> erreicht werden
- Dort klickt man dann auf „Wiederherstellen, und – so Gott will und der Entwickler des Dumper Recht hat – die alte Datenbank wird in einer neuen Datenbank wiederhergestellt
Abschließen des Umzugs
Nachdem die Datenbank wiederhergestellt ist, ist der Umzug aber noch nicht fertig. Denn der bestehende Blog weiß ja nur von der alten Datenbank auf dem alten MySQL Server mit alten Anmeldedaten. Das muss dann noch angepasst werden. Für WordPress ist das eine Datei, die angepasst werden muss, nämlich die wp-config.php. In der Beispieldatei wp-config-sample.php ist genau erklärt, was angepasst werden muss:
/** MySQL Einstellungen - diese Angaben bekommst du von deinem Webhoster. */ /** Ersetze database_name_here mit dem Namen der Datenbank, die du verwenden möchtest. */ define('DB_NAME', 'database_name_here');
/** Ersetze username_here mit deinem MySQL-Datenbank-Benutzernamen */ define('DB_USER', 'username_here');
/** Ersetze password_here mit deinem MySQL-Passwort */ define('DB_PASSWORD', 'password_here');
/** Ersetze localhost mit der MySQL-Serveradresse */ define('DB_HOST', 'localhost');
/** Der Datenbankzeichensatz der beim Erstellen der Datenbanktabellen verwendet werden soll */ define('DB_CHARSET', 'utf8');
/** Der collate type sollte nicht geändert werden */ define('DB_COLLATE', '');
Danach sollte, wenn alles gut gegangen ist, der Blog wieder verfügbar sein.
Abschließende Bemerkungen
Genau das habe ich heute Abend vor. Ich will so viel wie möglich vorher schon erledigen, damit der Ausfall so gering wie möglich ist. Der Datentransfer mittels FTP und auch das Backup mit dem MySQLDumper sind kein Hexenwerk. Auch die Einstellungen in der wp-config.php habe ich schnell erledigt. Das passiert ja völlig unabhängig vom Domain Transfer.
Ich hoffe dann, dass meine Seite das Wiederherstellen der Datenbank überlebt und dass ich an alles gedacht habe. Es wird zu einem Ausfall kommen, das ist mal klar. Aber ich hoffe einfach mal, dass danach die Webseite in gewohnter Form, nur wesentlich performanter wieder zur Verfügung steht.
Haben Sie Anregungen, wie ich das alles bewerkstelligen kann, dann kommentieren Sie ruhig. Um 20 Uhr werde ich dann den Transfer einleiten und die Arbeiten mit dem Dumper vornehmen. Wünschen Sie mir Glück! Bis später!
Hallo Henning,rnrnvom Prinzip her alles richtig.rnrnZu beachten wäre noch, dass nicht alle Plugins auch bei neuen Hoster funktionieren müssen. Auch kann es sein, das Du in der Datenbank noch Änderungen vornehmen musst, da mache Plugins z.B. Pfade deines alten Hosters in der DB gespeichert haben, die es zu ersetzen gilt. Dafür empfehle ich Dir das Plugin: Search and Replace, http://wordpress.org/plugins/search-and-replace/.rnEs gibt auch ein Plugin, was den Umzug noch einfacher macht als Du es vorhast. Das solltest Du auf jeden Fall mal testen: Duplicator, http://wordpress.org/plugins/duplicator/. Bei den meisten Installationen funktioniert es ohne Probleme und der Umzug ist in wenigen Minuten erledigt.rnBedenke bitte auch, dass die Domain nach dem Umzug noch ca. 24 Stunden, manchmal auch etwas länger braucht, um von überall auf der Welt auf den neuen Hoster zu verweisen.rnSonst viel Glück für den Umzug!rnrnMicha
Hallo Micha,nndie Plugins habe ich tatsächlich nicht gebraucht. Aber trotzdem vielen Dank für den Hinweis. Mein Plan ging so, wie ich ihn mir zurecht gelegt hatte, auf. Meine Domain ist jetzt bei Alfahosting und – soweit ich es sehen kann – voll funktionstüchtig.nnDen Duplicator schaue ich mir mal in Ruhe an. Wer weiß, vielleicht braucht man das ja mal wieder.