I would move the imap.* to a neverland address while doing the switch so users arn't opening email while files are being rsynced.
OR, just add a firewall rule to old server blocking imap.
I would also send a notice to uses a few days (preferably a week in a large setup) saying that email may be intermittently unavailable at 9pm on bla bla day while we perform maintenance on our servers to improve our service to you.
Have a place on your site where they can check the status of the move and it should avoid "most" phone calls.
Thomas Suckow
On Thu, Aug 13, 2009 at 9:48 PM, Timo Sirainentss@iki.fi wrote:
On Aug 14, 2009, at 12:36 AM, Gary Chodos wrote:
We have to replace one mail store (foo.example.org) with another (bar.example.org). I rsync'd the maildirs from foo to bar today and the plan is to hold all delivery (in the SMTP server) on foo over the weekend, rsync again (this time it should be much faster since the large xfer already occurred today), then flush the SMTP queue on foo towards bar, direct all new deliveries to bar.example.org. Users currently access their IMAP mailboxes via imap.example.org. I plan to just 'flip the switch' at DNS so imap.example.org points to bar.example.org (instead of foo.example.org) so users don't have to change anything on their end and should not even notice this change.
And I guess you also thought about the DNS cache TTLs?
Is there anything else I should think about to mitigate users noticing a change?
If the maildirs are identical and no mails get lost during the move, that should be it.
Does the fact that the mail filenames include 'foo.example.org' in the file name (while new deliveries to bar.example.org will include that new hostname) spell trouble later on or can I ignore it?
Filenames don't matter.
And finally, dovecot on foo.example.org is 1.1.7 while the new server is running 1.1.16. I don't think that should be an issue, but mentioning it just in case.
Whenever upgrading it's a good idea to go through the items marked with "*" in NEWS file (http://dovecot.org/doc/NEWS-1.1) There aren't many usually.