DNS/Apache/Proxy: Webseite umziehen ohne Downtime

Ich wurde kürzlich mit der Frage konfrontiert, wie man eine Webseite auf einen anderen Server umzieht, ohne dabei eine längere Downtime in Kauf zu nehmen oder inkonsistente Datenbankeinträge zu erzeugen.

Kleine Vorbemerkung: Die folgende Anleitung ist nur für Domaininhaber nützlich, die Zugriff auf die DNS-Einstellungen ihrer Domain haben. Wer ein Webhosting-Paket benutzt, bei dem dies nicht der Fall ist, sollte seinen Provider um Hilfe bitten.

Problem DNS-Umstellung

Im konkreten Fall ging es um das folgende Szenario:
Die Webseite example.com liegt auf einem Apache-Webserver A, mit der IP-Adresse 1.2.3.4. Sie soll nun zu einem anderen Provider umgezogen werden, wo sie zukünftig auf dem Server B, mit der IP-Adresse 5.6.7.8, gehostet werden soll (ebenfalls Apache).

Hierfür ist es nötig, die entsprechenden A-Records in der DNS-Verwaltung der Domain zu ändern. Example.com soll zukünftig nicht mehr auf den Server A, sondern auf den Server B zeigen. Nimmt man die DNS-Änderungen vor, steht man jedoch vor einem Problem: Abhängig von dem gesetzten TTL-Wert des A-Records kann es zwischen einigen Stunden und mehreren Tagen (meist sind es 24h) dauern, bis alle DNS-Server die neue IP-Adresse übernommen haben. In dieser Zeit wird es also passieren, dass einige Anfragen noch bei Server A ankommen, während andere schon bei Server B landen.

Beim Umzug statischer Webseiten muss man sich über dieses Phänomen keine Gedanken machen. Für Webprojekte mit dynamischen Inhalten ist es hingegen sehr problematisch.

Schreibt beispielsweise ein Blogleser einen Kommentar zu einem Artikel und ist dabei noch mit Server A verbunden, wird der Kommentar nicht in der Datenbank des Servers B angelegt und geht somit verloren. Der betreffende Nutzer ist darüber hinaus vielleicht auch noch böse auf den Seitenbetreiber, denn für ihn sieht es am nächsten Tag so aus, als hätte man seinen Eintrag kommentarlos gelöscht.

Um dieses Problem zu lösen, könnte man die Webseite auf dem alten Server abschalten oder dafür sorgen, dass keine dynamischen Änderungen mehr möglich sind. Ein entsprechender Hinweis könnte die Nutzer über die Umstellung aufklären:


Sobald die DNS-Änderungen bis zu den Besuchern vorgedrungen sind, werden sie den Hinweis nicht mehr sehen und alles wird wie gewohnt funktionieren.

Für kleinere Projekt-Webseiten oder Blogs mag dieses Vorgehen gut funktionieren und vermutlich werden die Nutzer mit Verständnis reagieren. Betreibt man aber einen Web-Service, den viele Leute alltäglich benutzen, läuft man mit dieser Art der Umstellung sicher Gefahr, sich einige User zu vergraulen. Hier sollte also eine Variante her, bei der die Webseite permanent erreichbar bleibt und bei der vor allem keine Daten verloren gehen.

Apache: Alter Webserver als Proxy

Die wohl einfachste Variante um dies zu erreichen, ist den alten Webserver temporär zum Proxyserver zu machen. Er soll ab dem Zeitpunkt der DNS-Änderung alle ankommenden Anfragen an den neuen Host weiterleiten, und dies möglichst in einer Art und Weise, von der die Nutzer nichts mitbekommen.

Apache sei Dank, ist dies mit einfachen Mitteln umsetzbar. Benötigt werden dafür die Module mod_proxy, mod_proxy_http und, je nach Umsetzung, mod_rewrite.

Wer einen dedizierten Linux-Server betreibt (oft auch "Root-Server" genannt), kann die genannten Module in der Regel mit dem Kommando a2enmod aktivieren, bzw. mit a2dismod abschalten (z.B. a2enmod mod_rewrite).

Wer jetzt gerade nur Bahnhof versteht und von Apache-Webservern keine Ahnung hat, hat sich vermutlich keinen dedizierten Server, sondern nur ein bisschen Webspace angemietet. Ob sich das im Folgenden vorgestellte Vorgehen auch in diesem Fall umsetzen lässt, hängt davon ab, ob der Provider die genannten Apache-Module auf seinem Server aktiviert hat. Bei den meisten halbwegs professionellen Hosting-Angeboten ist dies der Fall. (Es lässt sich mit der PHP-Funktion apache_get_modules() herausfinden oder indem man seinen Provider fragt.)

Wer also über die genannten Apache-Module verfügt, kann die Weiterleitung zwischen den Servern über zwei verschiedene Varianten einrichten:

Variante 1: Proxy via mod_rewrite und .htaccess

Diese Variante eignet sich sowohl für Betreiber dedizierter Server als auch für Leute, die sich "nur" Webspace gemietet haben.

Auf dem Server A legt man im Wurzelverzeichnis der Domain example.com eine .htaccess-Datei mit dem folgenden Inhalt an:



Dies ist auch schon die ganze Magie. Alle Anfragen, die bei Server A ankommen, werden zum Server B weitergeleitet. In diesem Beispiel wird davon ausgegangen, dass die Webseite bereits auf dem Server B eingerichtet wurde und unter http://5.6.7.8/example.com abgerufen werden kann.

Nutzer, die die Webseite example.com aufrufen (und noch nicht die IP-Adresse von Server B kennen), bekommen von alledem nichts mit. Ihre Anfrage wird von Server A entgegengenommen. Dieser arbeitet nun als Proxy - das heißt, er lädt die Inhalte von Server B und liefert sie dann selbst an den Nutzer aus.

Natürlich muss man bei der Zieladresse nicht mit der Server-IP arbeiten. Wenn man weiß, dass in einigen Tagen die DNS-Umstellung der Hauptdomain example.com ansteht, kann man schon einmal eine Subdomain anlegen, welche auf die neue IP-Adresse verweist, z.B. new.example.com. Diese ist dann nach einiger Zeit überall verfügbar und kann in gleicher Weise in die .htaccess-Datei eingetragen werden.

(Für Serverbetreiber hat dieses Vorgehen den Vorteil, dass man den VirtualHost in der Apache-Konfiguration später nicht noch einmal bearbeiten muss, wenn man bereits den ServerAlias *.example.com gesetzt hat.)

Variante 2: Proxy in den VirtualHost eintragen

Diese Alternative funktioniert nur für Personen, die Zugriff auf die Konfigurationsdateien des Apache-Webservers haben.

Es geschieht das Gleiche wie in Variante 1, nur dass die Konfiguration an einer anderen Stelle vorgenommen wird, nämlich in der VirtualHost-Konfiguration des Servers.


Die Direktive ProxyPreserveHost sorgt dafür, dass der aufgerufene Hostname mit an den Zielserver übergeben wird. Dies ist wichtig, falls auf dem Zielserver mehrere Webseiten über eine IP-Adresse erreichbar sind.

Nach Änderungen an der VirtualHost-Konfiguration muss stets der Webserver neu gestartet werden (/etc/init.d/apache2 restart oder service apache2 reload).

Tipps und Hinweise für einen stressfreien Serverumzug

Zum Schluss noch ein paar generelle Tipps:

• Alles, was man tut, sollte gut durchdacht passieren. Die meisten Fehler passieren durch die eigene Schusseligkeit. ;)
• Bei manchen Providern hat man zwar Zugriff auf die DNS-Verwaltung, jedoch kann man die TTL-Werte nicht selbst festlegen und erfährt über das Interface auch nicht, welcher Wert dafür festgelegt ist. In diesem Fall kann man ein DNS-Lookup-Tool benutzen, um den TTL-Wert zu erfahren (Angabe in Sekunden).
• Bei der DNS-Umstellung sollte man, über die TTL-Zeit hinaus, noch etwas mehr Zeit einplanen. Einige Provider ändern die DNS-Einträge nicht sofort, wenn man auf Speichern drückt, sondern z.B. nur einmal innerhalb von 24 Stunden. Dementsprechend dauert es dann noch länger, bis andere DNS-Server die Änderung mitbekommen. Außerdem kann es vorkommen, dass die Rechner einiger Nutzer die alte IP-Adresse, trotz DNS-Änderung, noch eine Weile im Cache vorliegen haben.
• Bevor die Adressumstellung erfolgt, sollte man die Webseite auf dem neuen Server zum Laufen bringen und dort ausgiebig testen. Besonders auf PHP-Einstellungen wie die Standardkodierung (ISO-8859, UTF-8, ...), register_globals, safe_mode, das memory_limit usw. sollte man achten. Unterscheiden sich die Parameter vom alten Server, kann dies ungewünschte Seiteneffekte haben (von kaputten Umlauten, über Fehlerseiten bis hin zu Performance-Problemen).
• Bei stark frequentierten Webseiten mit dynamischen Inhalten kommt man eventuell nicht um eine kurze Downtime herum. Kritisch ist der Zeitraum zwischen dem Einpflegen der Daten(bank) auf dem neuen Server und dem Aktivieren der Weiterleitung. Änderungen, die in dieser Zeit auf dem alten Server vorgenommen werden, sind auf dem neuen Server nicht vorhanden.
  Wer sich gar keinen Ausfall erlauben will, kann die Umstellung auch im laufenden Betrieb vornehmen und eventuell entstandene Datenunterschiede anschließend per Hand einpflegen. (Ich rate allerdings von diesem Vorgehen ab.)
• Betreiber von dedizierten Servern sollten nicht nur die eigentliche Webseite auf Herz und Nieren prüfen, sondern die komplette Serverkonfiguration. Gerade im Bereich Sicherheit werden viele Fehler gemacht.
  • Sind die Passwörter sicher genug?
  • Wurden Passwörter doppelt verwendet? (Sollte vermieden werden.)
  • Stimmen alle Datei- und Zugriffsrechte? (chmod 777 ist meist keine gute Idee.)
  • Wurden alle Nicht-Administratoren in eine Chroot-Umgebung eingesperrt?
  • Wurde die Firewall korrekt eingerichtet? (z.B. iptables)
  • Sind Ports offen, die nicht benötigt werden?
  • Sind sämtliche Serverzugänge (z.B. SSH, FTP) sicher?
  • Wurde ein System zur Abwehr automatisierter Angriffe eingerichtet? (z.B. Brute-Force-Angriffe auf SSH)
  • Gibt es eine sichere, funktionierende Backup-Lösung (auch für Datenbanken)?

So, das wär's erst mal zum Thema Webseitenumzug. Bei Fragen, Ergänzungen und Verbesserungsvorschlägen einfach kommentieren. :)


Nachtrag 06.02.2014: Noch ein wichtiger Hinweis: Wenn in einem Unterordner eurer Webseite schon eine .htaccess-Datei mit Rewrite-Regeln vorhanden ist, muss diese ebenfalls angepasst werden. Ansonsten verweisen URLs auf diesen Unterbereich eurer Webseite immer noch auf den alten Server.

Geschnatter