Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I plan on moving some WHM/cpanel accounts to a new server, I am under the impression that during transition, some emails might land on old server even if the files have already been copied to the new server.

Is it possible to prevent this so that all incoming emails during the transition won't get lost?

share|improve this question
    
Do you have many email accounts migrating? Are you changing web hosting providers? Do your current hosting providers provide your DNS? –  Paul Mar 3 '13 at 10:47
    
@Paul Yes, quite many email accounts. Yes changing providers. Yes the current one handles DNS, I've root access if that matters. –  IMB Mar 3 '13 at 11:01
    
You have root access to the current server? So you can shut down exim? –  Paul Mar 3 '13 at 11:08
    
@Paul Yes I've root so I can shut exim down. light bulb moment So I guess all I've to do is: 1. Shutdown exim 2. Move files 3. Update DNS to point to new server 4. Turn on exim on new server. Is that it? –  IMB Mar 3 '13 at 11:17
    
I would time the DNS change for a Friday evening so it's had time to update before most people will start using it again. –  Austin ''Danger'' Powers Mar 3 '13 at 11:18

2 Answers 2

up vote 4 down vote accepted

Ok, this is fairly straightforward from your comments.

  1. Change your A and MX records for the email server TTL to something small - 60 seconds
  2. Wait until the current TTL has expired, and so everyone is using the new 60 second TTL
  3. Shutdown exim
  4. Full backup on current server, full restore on new server
  5. Change DNS records, and restore TTL to sensible value

Because you have reduced TTL, your outage Window is a long as it takes you to backup/restore the files and change DNS.

share|improve this answer
    
Also, when the old server is simply not accepting new messages anymore (playing dead; not rejecting with an error), I'd assume that sane email senders would at some point request the new DNS settings? (This might surely delay email if the TTL has not been changed, but should not have email delivered to the old server.) –  Arjan Mar 3 '13 at 13:07
    
@Arjan Yes, the DNS lookup is independent from the mail server attempting to send. The OS does it. So if the mail server tried to send, it would do a lookup, and get the old IP, then fail to deliver because exim isn't running. As the TTL on the record is only 60 seconds, then an hour later (or whatever retry is configured) it would have to do a new DNS lookup - if this is after the DNS change and new server is up and running, it will deliver to the new exim. –  Paul Mar 3 '13 at 20:44

Another method (if any downtime at all is absolutely unacceptable to you), is to use Postfix or similar as basically a delayed relay.

You could start a server as a relay, and then configure the scan threshold to be something very high (and keep expanding it if your maintenance window grows, which they often do :p ). Alternatively, you could firewall-block any outbound relay/send attempts in such a way the Postfix (or whatever) would requeue the messages.

Network/DNS wise, you'd set up a relaying/delaying server as mentioned above, point your old MX record to it (with the TTL reduction as mentioned by @Paul), conduct your maintenance, point the MX record back where it should go, change the relayhost in Postfix to point to that record (it might get annoyed because it thinks it's pointing to itself, in which case you'd need a second temporary MX), and let it process the queue.

That was a bit fragmented as an explanation. For more information, check out this ServerFault question and this how-to. That should get you on the right path.

Then again, if a little bit of downtime is acceptable to you, @Paul's solution is much simpler.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.