Vorgehensweise Mailserver Umzug (DNS Settings)

    Hallo zusammen,


    ich versuche hier mal mein Anliegen zu formulieren. Ich habe nun im Adventskalender einen etwas leistungsfähigeren RootServer geschossen, um von meiner VPS umzuziehen.


    Hat jemand vielleicht ein best Practice zum Umzug? Primär geht's mir um das switchen der DNS Einträge. Ich wollte jetzt keinen Snapshot umziehen, sondern das eine oder andere Umstrukturieren und somit das Teil neu aufsetzen u.a. von Unbuntu zu Debian usw.

    Soweit alles kein Thema, aber wie halte ich die Ausfallzeit am geringsten? Meine Idee wäre hier zum Zeitpunkt X die rDNS Einträge auf Netcup zu switchen, danach die DNS IP Settings des Domainhosters auf den neuen Server zu ändern.


    Gäbe es hier noch etwas zu beachten oder habe ich etwas vergessen und/oder ggf. nicht bedacht? Für jeden Input dankbar!


    Besten Gruß

    Step 1: Teste die Migration ausführlich.

    Ich hatte meine Mailcow migrieren wollen von einem alten auf ein neuen Server. Allerdings hat dies mit Backup und Restore leider nicht geklappt. Das ist mir nur wegen Test aufgefallen. Deswegen habe ich die Migration mit einem rsync der Ordner durchgeführt.

    Step 2: Planen

    Planen, Planen, Planen.

    Wenn der Migrationspfad läuft Plane die Migration.

    Wann kannst du die Migration am besten durchführen?

    Wenn musst du informieren?

    Was musst du testen?

    Laufen alle Zugänge?

    Externes Testpostfach vorhanden?

    Step 3: Vorbereitung

    Setze die TTL der betroffenen Domains runter

    Informiere die Menschen

    Step 4: Durchführung

    Führe die Migration durch, transferiere die Daten, passe die Config an, passe die Domains an. Behalte dabei einen ruhigen Kopp und bleib geduldig.

    Step 5: Testen, testen, testen!

    Test alles was geht. Und das ausführlich!

    Empfang von Extern

    Versand nach Extern usw usw usw

    RS Eggnog | VPS 1000 G10 | VPS 1000 G10 SE | VPS piko G11s | VPS nano G11s | VPS mikro G11s | Webhosting 4000 NUE ADV23

    Gefällt mir 4

    Vielen Dank für die Informationen! Versuche ich zu berücksichtigen … hab schon diverse Testpfade durch und bin ganz zuversichtlich.

    Kleiner Vorteil hier, ich bin der einzige User auf dem System. Das sollte aber natürlich dennoch möglichst geräuschfrei funktionieren.

    Mach dir nicht zu große Sorgen wegen der Downtime. Quasi jeder Mailserver versucht Mails tagelang zuzustellen. Empfangsseitig sollte nichts verloren gehen.

    Wenn möglich, teste ob du mit der neuen IP Emails an Telekom und Microsoft Mailaddresse schicken kannst. Die brauchen öfters Einzelbehandlung...

    Zitat von 17martin

    Wenn möglich, teste ob du mit der neuen IP Emails an Telekom und Microsoft Mailaddresse schicken kannst. Die brauchen öfters Einzelbehandlung...


    Neue IP, Telekom ist kein Problem. Microsoft hingegen zum 🤮 . Etliche Formulare ausgefüllt, Antwort vom Bot, wir haben kein Problem mit ihrer IP. Alles klar 🤮. Wenn da jemand ein Patent Rezept weiß, würde ich gerne hören 😀.

    Abhängig von der gewählten Softwarelösung für den Mailserver kann man eine Ausfallzeit durchaus auch vollständig vermeiden, indem man, sofern Dovecot verwendet wird, beispielsweise doveadm-sync einsetzt (was beim Betrieb mehrerer Mailserver im Multi-Master-Betrieb sowieso unumgänglich ist): (1) Neuen Mailserver aufsetzen, (2) zweiten MX-DNS-Eintrag für diesen hinzufügen, (3) warten, bis erste E-Mails angenommen werden, und (4) MX-DNS-Eintrag für alten Mailserver entfernen. Logischerweise ist sicherzustellen, dass wirklich alle E-Mails auf dem neuen Mailserver synchronisiert wurden, bevor man den alten endgültig abschaltet.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Ente gut, alles gut 1 Gefällt mir 1
    Zitat von m_ueberall

    doveadm-sync

    exakt, that's the way it's done, empfangsseitig.

    Du kannst auch eine Zeitlang zwei MX records haben. Dann werden nach und nach Absender auf den neuen, höher priorisierten Server umschwenken und, wenn der neue grad nicht da ist, den alten verwenden.

    Wenn dann der traffic auf dem alten Server abnimmt, und alles auf dem neuen ankommt, kannst Du den alten MX entfernen.

    Versandseitig ähnlich: den alten noch stehen lassen, die Clients auf den neuen Server hetzen, beobachten, den alten entfernen, wenn kein Traffic mehr kommt.