Serverumzug - wie am besten?

Und erzähl. ob es klappt

unsere Listen waren ähnlich aber nicht gleich

und zum Thema DNS Update, das dauert keine 20 Sekunden bei mir .... also sowohl das ändern wie auch das umstellen, das hängt ja immer davon ab, wie schnell der DNS Server aktualisiert über den du aufs Netz zugreifst.

das hängt ja immer davon ab, wie schnell der DNS Server aktualisiert über den du aufs Netz zugreifst.

und das ist der Punkt weil nicht beeinflussbar. Siehe Synonyms Bemerkung bzgl. 48 Stunden später auf der anderen Seite des Globus...

Hallo zusammen,

@sensei
Das mit dem DNS geht bei mir auch sehr schnell, teilweise 20-30 Minuten, aber eben nur hier. In Berlin schaut es schon wieder anders aus und in anderen Ländern noch mehr. Das ist das Problem, ist ja nicht zeitgleich überall so.

@chris21
Das mit dem Tunnel habe ich mir nun angesehen, hatte nun auch eine frische Doku zu Debian Lenny dazu gefunden. Wenn ich mir das aber recht überlege, hört sich gut an, aber ist sehr viel Aufwand bei dem ich eigentlich zwei Maschinen zum testen bräuchte, hab aber nur eine. Neue Benutzer, eventuell Port wechseln, Schlüssel, AutoSSH, Startscripte etc.

Werde dann wohl doch auf die Lösung mit dem Fallback gehen, wenn ich da nicht noch eine andere Doku zu finde. Mehr Aufwand ist das nämlich nicht wirklich, da ich die Configs eh alle anpassen muss und das sind alles Arbeiten im Vorfeld. Der Ausfall dürfe da auch nur 2-3 Minuten sein. Alte DB stoppen, kopieren, neue starten.

Hm, aber ich sehe mich da mal noch weiter um. Vielleicht finde ich ja noch was im Bereich Forwarding.

@Synonym das Problem kannst du lösen, indem du den alten Server noch on lässt mit einer locked Version für 48h. Dann laufen die Besucher nicht ins leere und wenn alle DNS Server aktualisiert wurden dann kannst du den Server auch platt machen.

@Sensei
Das war ja einer meiner Punkte im ersten Post. Die Frage war ja, ob das auch anders / einfacher geht, eventuell für die Zukunft. Dass der alte Server online bleiben muss, bis der Umzug komplett ist, ist ja klar, sonst gibt es ja keine Bilder oder nur teilweise.

Also etwa was in der Art, dass die Domain weg fallen würde, dann wäre das mit dem Umzug zukünftig nicht mehr. Dann müsste ich aber über den Host gehen und der ändert sich jedes mal (daher mit Domain aktuell). Würde es aber eine Möglichkeit geben, an einer zentralen Stelle den Host zu hinterlegen, dann wäre das wieder viel einfacher. Allerdings reicht es nicht, den als "Meta-Info" in der DB zu speichern, denn die liegt ja auf dem Server. Sprich, ich suche indirekt einen Weg, die Anpassung der ganzen einzelnen Config der Portale zukünftig zu umgehen.

Mein Gedanke war da schon so wie bei der Bottrap, das ganze als Autoupdate zu machen von einem vServer aus, aber das ist mir zu unsicher, da meine DB-Verbindungsdaten zu hinterlegen. Das andere, ein Config-File zentral auf dem vServer, aber dann jedes mal die Daten extern von einem Server laden, bei jedem Request, ist auch sehr umständlich, zumal dann das Ausfallrisiko enorm steigt.

Das sind nun zwei Gedanken gewesen die ich so hatte, eine einheitliche Config zu haben, die nur einmal geändert werden muss. Das andere wäre einfach ein einheitliches Ziel zu haben, aber wie gesagt, bei jeden Serverwechsel gibt es einen neuen Host und eine neue IP.

Zu umgehen ist das nur, wenn ich einen vServer nehme, der kann upgegradet werden ohne dass sich Host oder IP ändert (zumindest fällt mir nichts anderes ein). Nur bei dem kommen dann immer wieder Kernel-Updates dazwischen, die der Hoster teils zu den besten Besucherzeiten einspielt. Daher bin ich da weg vom vServer und auf den Root, wo ich mir die Zeit selbst festlegen kann.

Jetzt aktuell würde ich wieder sagen, die Kernel-Updates stören nicht weiter, aber wenn ich da so an letztes Jahr denke. Da waren die teilweise alle 4 Wochen und jedes mal der vServer 30 Minuten offline (immer so zwischen 12 und 16 Uhr), teilweise auch über Stunden hinweg, weil irgend ein Dienst nicht mehr gestartet ist.