Mail umziehen - Neuer Server

P

p0se

Member
Hallo,

Ich habe aktuell zwei Server mit Plesk.

Server A (Alt)
Server B (neu)

Auf dem Server A liefen bis vor kurzen alle Webseiten und Postfächermeiner Kunden. Die Webseiten habe ich bereits erfolgreich auf den Server B umgezogen.

Nun möchte ich gerne die Postfächer inklusive Mails von Server A auf Server B umziehen. Das umziehen an sich ist kein Problem.

Ich bin mir nur nicht Sicher wie der vernümftigste Weg ist, ohne das die Kunden etwas merken.

Aktuell nutze ich für SMTP und IMAP folgende domain mail.xxxxx.de Auf diese Domain ist in Plesk das Mailzertifikat hinterlegt. Alle Kundenadressen haben einen mx Record auf mail.xxxxx.de.

Für mich wäre der Weg nun die Postfächer bzw. Mails auf Server B zu ziehen, dann den DNS Eintrag für die Subdomain mail.xxxxx.de auf Server B zu leiten, dann in Plesk auf Server B ein Zertifikat für mail.xxxxx.de anzulegen und dieses zum Schutz von E-Mails zu nutzen.

In dem Fall müsste kein Kunde etwas an seiner Konfiguration machen.

Was mich dabei stört ist allerdings die Zeit der Domainänderung die halt theoretisch 24 Stunden dauern kann. In der Zeit gehen dann eventuell Mails verloren.

Hat jemand einen besseren bzw. Sinnvolleren Plan?
 
Du könntest auf dem alten Server für die DNS-Caching-Zeit NAT-Regeln(SNAT+DNAT) setzen, die Anfragen an die Mail-Ports(25,110,143,465,587,993,995) auf den neuen Server umleiten.

Die SNAT-Regel deswegen, damit das Paket auch wieder über den alten Server zurückgeroutet wird.

Code: 
IP_ALT="1.2.3.4"
IP_NEU="5.6.7.8"
PORTS="25,110,143,465,587,993,995"
/sbin/iptables -t nat -I PREROUTING  1 -p tcp -m multiport --dports $PORTS \
   --destination $IP_ALT -j DNAT --to-destination $IP_NEU
/sbin/iptables -t nat -I POSTROUTING 1 -p tcp -m multiport --dports $PORTS \
   --destination $IP_NEU -j SNAT --to-source $IP_ALT

Die Einstellung ist nach einem reboot von Server alt weg und muss neu gesetzt werden.
 
Last edited by a moderator:
Mails von echten Mailservern gehen nicht verloren, da sie über mehrere Tage/Wochen hinweg erneut zugestellt werden, solange der Zielmailserver nicht erreichbar ist.

*) Gegebenfalls die Kunden informieren, dass es in den nächsten 7 Werktagen wegen Wartungsarbeiten zu kleineren Verzögerungen in der Mailzustellung kommen kann.

*) Alten Mailserver komplett stoppen
*) DNS-Einträge auf neuen Mailserver setzen
*) Postfächer auf neuen Mailserver migrieren
*) Zertifikat vom alten auf den neuen Mailserver kopieren und einrichten
*) Neuen Mailserver starten
*) Fertig.
 
Evtl hilfreich könnte auch die Vorabreduzierung der TTL des MX Records auf einen sehr kurzen Wert (z.B. einige Minuten) sein. Es ist zwar nicht garantiert, dass diese Zeit bei den DNS Caches der großen Provider respektiert wird, aber besser als 24 oder 48 Stunden TTL wäre es sicher trotzdem.

Natürlich nicht vergessen, die TTL nachher wieder hochzustellen.
 
Was den SMTP-Teil angeht, ist das schon richtig, dass man den alten Server einfach abschalten kann.

Wenn man aber noch IMAP miteinbezieht, dann ensteht evtl. die Situation, dass Mails teils auf dem alten und teils auf dem neuen Server landen(z. B. gesendete Mails) oder dass der IMAP-Dienst halt für die Zeit der Umstellung / DNS-Cache nicht erreichbar ist. Evtl. kann man die Umschaltung auf die Nacht oder das WE legen.

Auch die Postfachmigration nebenbei sorgt bestimmt mal für Verwirrung, wenn nicht angekündigt, so dass mal eben so alle IMAP-Mails weg sind und dann irgendwann wieder da.

Weitere Sache, die unangenehm sein kann, ist, dass durch die Kopie der Mails die Mailclients meinen, alle Mails erneut herunterladen zu müssen. (Das ist mir in der Vergangenheit trotz entsprechender Sorgfalt(Zeitstempel,...) und auch hinterher ungeklärter Ursache passiert). Das dürfte dann wohl eher die POP3-User betreffen, sofern es die denn noch gibt.
 
Last edited by a moderator:
Mit "Mailserver komplett stoppen" meinte ich selbstverständlich SMTP + IMAP + POP3 (sofern noch verwendet), dann gibt es auch keine Probleme mit den IMAP/POP3 Stati.
 
Warum nicht gleich wie Joe USer sagte DNS aktualisieren, den alten Mailserver runter und den neuen nach Transfer der Konten hoch.
Ich habe sowas mal gemacht, da ist dann eben mal 3 Stunden der Mailserver offline bis das DNS überall gesynct hat.
Stirbt niemand davon von wenn man das nachts macht und vorher die Kunden gewarnt hat dass eine Wartung stattfindet.
 
Ich mache das seit 19 Jahren (alle zwei bis drei Jahre) genau so und hatte damit noch nie Probleme.
Bei mir betrug die längste Verzögerung einer Mail dabei zwar fünf Tage, aber es das kam dafür insgesamt auch nur bei einer handvoll Mails vor.
Normalerweise trudeln die letzten verzögerten Mails nach zwei bis drei Tagen ein, die meisten Mails verzögern sich zwischen vier und 32 Stunden.

Insofern bietet sich bei Firmen eine Migration am Freitag Nachmittag an, dann läuft am Montag normalerweise wieder Alles rund und nahezu kein Mitarbeiter oder Kunde bemerkt etwas davon.
 
Genauso und nicht anders läufts, sonst gehen Mails verloren, weil sie noch beim alten Server abgeliefert werden.

Eine Downtime sollte für einen Mailserver aufgrund der genannten Mechanismen kein Problem sein.
 
Joe User said:
Mails von echten Mailservern gehen nicht verloren, da sie über mehrere Tage/Wochen hinweg erneut zugestellt werden, solange der Zielmailserver nicht erreichbar ist.

*) Gegebenfalls die Kunden informieren, dass es in den nächsten 7 Werktagen wegen Wartungsarbeiten zu kleineren Verzögerungen in der Mailzustellung kommen kann.

*) Alten Mailserver komplett stoppen
*) DNS-Einträge auf neuen Mailserver setzen
*) Postfächer auf neuen Mailserver migrieren
*) Zertifikat vom alten auf den neuen Mailserver kopieren und einrichten
*) Neuen Mailserver starten
*) Fertig.
Click to expand...


Hat 1A so funktioniert. Danke!
 
You must log in or register to reply here.
Back
Top