Ich stand nun kürzlich vor der kleinen Herausforderung, meinen Blog und alle anderen, darin enthaltenden Blogs, auf einen neuen Server umzuziehen. Grundsätzlich wollte ich es mir dabei einfach machen und es auch einfach halten.

Die Rahmenfakten

• Das Multisiteblog besteht aus 4 Blogs.
• Die Domains bleiben vorher und nachher die gleichen.
• Der neue und der alte Provider unterstützen externe Domains, sie liegen also nicht zwangsläufig beim Webspaceprovider.
• An den Blogs ändert sich mal für ein paar Stunden nichts an den Inhalten.
• Ich möchte anschließend noch ein anderes Blog mit in das Multi-Site-Network integrieren.
• Es gibt die Möglichkeit, eine Test-URL zu haben, wo man vor dem Umzug die Installation auf dem neuen Server testen kann.

Das klingt nach einer übersichtlichen Handlung und das ist es auch. Also frisch ans Werk.

Der Umzug

Wichtig! Ich beschreibe hier, wie ich den Umzug für mich machte und wie es auch funktionierte. Ich kann natürlich nicht versprechen, dass es bei einem anderen Umzug auch so einfach klappt. Also: Backups machen, sicher sein, was man tut und ganz offensichtlich -> ich übernehme keine Haftung dafür, wenn jemand mit meiner Beschreibung sich seine WordPressinstallation zerschießt. Bitte seid euch sicher bei dem, was ihr tut.

Hier mache ich es mir sehr einfach:

1. Per FTP wird das WordPress-Verzeichnis des alten Server gesichert und in das entsprechende (Domain-)verzeichnis des neuen Servers hochgeladen. In dem Ordner sind neben allen Fotos auch alle Plug-Ins und Themes samt Child-Themes usw. Also alle Dateien, die das Blog so hat.
2. Mit Hilfe eines Tools, wie zum Beispiel dem PhpMyAdmin oder HeidiSQL wird die Datenbank gesichert (Anleitung für HeidiSQL). Falls die Zugangsdaten für die Datenbank entfallen sind: diese befinden sich auf dem alten Server in der Datei „wp-config.php“. Dort steht unter „DB_NAME“ der Name der Datenbank und unter DB_USER und DB_PASSWORD und DB_HOST die entsprechenden, anderen Daten (Benutzer, Passwort und Server). Mit diesen Daten kann dann die Datenbank vom „alten“ Server heruntergeladen werden.
3. Diese lokal runtergeladene Datenbank wird nun auf dem neuen Server zurückgespielt (Restore). Der Restore funktioniert ähnlich, wie das Backup. Um beim Beispiel mit HeidiSQL zu bleiben: man verbindet sich mit der Datenbank und geht dann auf Datei -> SQL-Daten laden und wählt die runtergeladene Datei vom anderen Server aus. Nun wird das Backup auf den neuen Server zurückgespielt. Die Daten dazu sollte man vom neuen Provider bekommen haben.
4. Jetzt sind die Daten zwar auf dem neuen Server, aber in der Konfiguration von WordPress auf dem neuen Server sind die Verbindungsdaten vom alten Server. Diese stehen in der Datei wp-config.php im WordPress-Ordner, den wir in Schritt 1 rüberkopiert haben. Die Einträge in der Datei müssen nun also auf den neuen Server angepasst werden. Folgende Einträge sind hier wichtig, damit es auch auf dem neuen Server läuft:define(‚DB_NAME‘, ‚Datenbankname‘); // Der Name der Datenbank, die du benutzt.
   define(‚DB_USER‘, ‚Datenbankbenutzer‘); // Dein MySQL Datenbank Benutzername.
   define(‚DB_PASSWORD‘, ‚Datenbankpasswort‘); // Dein MySQL Passwort
   define(‚DB_HOST‘, ‚Datenbankserver‘); // 99% Chance, dass du hier nichts ändern musst.
5. Bevor nun Änderungen an den Domains und der Webserverzuweisung vorgenommen werden (DNS-Einträge geändert werden), sollte geprüft werden, ob die Einstellungen für den Multi-Site-Blog in den Plug-Ins noch stimmen. Sonst landen unter Umständen die Domains im falschen Blog. Die sollten im Idealfall aber vom alten Blog übernommen worden sein, doch Vorsicht ist hier die Mutter der Porzellankiste.
6. Beim neuen Provider sollte man nun mit einer Test-URL nun die Adresse zur neuen WordPressinstallation aufrufen. Dort sollte nun das Blog ganz normal zu sehen sein. Mit einer Einschränkung: wenn man auf Links klickt, dann wird man in der Regel wieder unter der aktuellen Blog-Adresse landen und nicht im doppelten, neuen Blog. Beispiel: Wenn man den Test unter test.medienman.de laufen hat, dann landet man bei einem Klick wieder unter blog.medienman.de (der Seite auf dem alten Server). Der Grund dafür ist, dass die Links in der Regel alle immer die komplette Adresse beinhalten. Das führt dazu, dass man auf dem neuen Server bei jedem Klick wieder auf dem alten landet.
7. Sind alle Tests erfolgreich, kann man auch die DNS-Einstellungen ändern.

Mit diesen Einstellungen ist es nun schon so, dass das Blog schon theoretisch läuft. Praktisch ist noch das Problem, dass die Domains noch auf den alten Server zeigen. Diese müssen nun also auch mit umziehen. Mein neuer Hostingprovider gab mir den internen DNS-Namen, auf den ich verweisen kann. Also musste ich beim alten Anbieter nur die DNS-Einträge mit einem neuen CNAME-Eintrag belegen. Also zum Beispiel den DNS-Eintrag „blog.medienman.de“ -> auf den CNAME-Eintrag „host123.neuerprovider.de“ ändern. Ab dem Moment, wo man das macht, dauert es bis zu 24 Stunden (in der Regel klappt es in spätestens vier), bis über die Domain dann der neue Host erreicht wird und nicht mehr der „alte“ WebSpace. Um den Unterschied zu sehen kann man einen Rechtschreibfehler beim alten Anbieter in einem Post einbauen. Wenn der dann weg ist, sieht man deutlich, dass der Umzug erfolgt ist. Und das ganze ohne Ausfälle für die Besucher der Seite.

Wenn es zu Problemen kommt, kann man relativ einfach die DNS-Einstellungen wieder auf den alten Provider umstellen. Das hat den Vorteil, dass man den Schaden relativ klein halten kann, falls es zu unvorhergesehenen Problemen kommt.