Migrating a domain (or domain(s)) from one server to another preserving inbound email

[jlixfeld]

Greetings,

I've been trying to figure out the best way to migrate domains from one server to another without the issue of bouncing mail. The easiest approach to migrating existing data, as I understand it, seems to be to do it on a per-Admin/Reseller basis using admin backup on oldserver, transfer the backup to newserver and then restoring. This restores the Admin/Reseller and all data for all domains associated with that Admin/Reseller.

I believe this also covers DNS zone files, but I'm not crystal clear on whether or not the zone files are copied over intact, and just the server IP is re-written upon restore, or if the restore operation creates new zone files from scratch. Barring that, the migration of existing data seems pretty straight forward.

The part that isn't so straightforward, in my particular case, is how to prevent new email from being delivered to oldserver while the backup/transfer/restore is in progress. To me, this causes a case of split brain where the backup won't catch email that has been delivered since the backup started. I've read bits about how to workaround this; some recommend suspending the domain under migration, but from my testing all that does is cause the messages to bounce with a permanent failure due to 550 "Unknown User".

What I think I would like to have happen is to disable local delivery on oldserver for each domain under migration so oldserver accepts any new mail but holds it in it's queue until the migration is complete, but I don't know how to get oldserver to ignore the fact that it actually *can* deliver mail for a particular domain and instead just spool it (or fail with a non-permanent error so then it's just the sending server and oldserver that have to fight about the delivery ).

If there was a way to disable local delivery on oldserver, the backup/transfer/restore process would happen, the zone files for the domains would restored on newserver in the process, and all I'd have to do is update the registrar with the new IP info, at which point the mx would have a new IP, so exim on oldserver would start delivering what it had queued up to newserver, so would the rest of the Internet.

The other option would be to do the registrar update before starting the backup, pointing the nameserver to newserver, but I believe that too would cause email to permanently bounce since newserver won't have a zone file for any of the domains until the backup/transfer/restore is completed. In my case, that would take hours due to the volume of data that needs to be moved.

I'm sure other folks have done this a thousand times and it obviously worked out for them, so maybe I'm over thinking this?

Thoughts?

Thanks in advance for any insight.

 

[Richard G]

There might be a better method, but previously I first stopped Exim from running on the old server.
After that I do the registrar update, which takes several hours to sync anyway when changing to a new ip.
Then I start the admin backup/transfer to the new server and the restore.

As long as the new data is not through DNS yet, mail will be tried to be delivered at the old server, which will be rejected because Exim is not running and can't be delivered at that point. But mail normally this will be tried again and so the mail will be delivered at a later time and in that case DNS is synced so it should be delivered to the new server.
To be more secure that if possible no email is lost, I'm doing this kind of transfers at night time when most people are a sleep and almost no email is send.

 

[jlixfeld]

Hi Richard,

I thought about that. Stopping Exim would certainly work, but that would take mail down for the entire system

 

[jlixfeld]

For the archives, I figured out a way to do this. It's not perfect, but it's sufficient for my needs.

I created a new file for local_domains that was identical to the domains file for relay_domains, except the former excludes the domains under migration.

domainlist local_domains = lsearch;/etc/virtual/domains2
domainlist relay_domains = lsearch;/etc/virtual/domains : localhost

[root@hosting1 admin]# diff /etc/virtual/domains /etc/virtual/domains2
< arionetworks.ca
> #arionetworks.ca
[root@hosting1 admin]#

The end result is any mail received for arionetworks.ca is pseudo-accepted because it is in relay_domains, but cannot be delivered locally because it is not in local_domains, so it fails with a temporary reject due to MX loop.

2016-06-04 09:17:43 lowest numbered MX record points to local host: arionetworks.ca (while verifying <jlixfeld - at - arionetworks.ca> from host smtp03.beanfield.com [76.9.193.172])
2016-06-04 09:17:43 H=smtp03.beanfield.com [76.9.193.172] F=<jlixfeld - at - beanfield.com> temporarily rejected RCPT <jlixfeld - at - arionetworks.ca>: lowest numbered MX record points to local host
2016-06-04 09:17:43 H=smtp03.beanfield.com [76.9.193.172] incomplete transaction (QUIT) from <jlixfeld - at - beanfield.com>

What I believe should happen after the migration is complete and after the registrar has been updated, beanfield.com will try to deliver the message once again, but this time the MX record will point to newserver, which will be able to both relay and locally deliver the queued up message and that should be that!

I wonder how useful it would be to have an option to manipulate local_domains and relay_domains independently of one another so people could make these kinds of changes from within DA, not having to futz with the CLI. Perhaps there could be other uses for a feature like this as well?

Thanks for your note, Richard. Your reply got me thinking along these lines.

 

[Richard G]

but that would take mail down for the entire system

That's indeed the downside of it.

I like the solution you came up with and hope it indeed works that way. Good thinking. I might try this next time too.
I'm glad to hear my note was of help in some way.