I've done this a couple of times, and there are a couple of things you can do to help make it go smoothly. I did it not too long ago to move to a new single server, and am getting ready to do it again to a fully redundant setup (3 nodes for percona clustering, 2 of the nodes as dovecot with sync).
- Set your current MX records TTL to the lowest you can, usually 30 minutes. This will make it quicker to do the final transition when you do.
- Create an A record in DNS for the new server, but no MX records for it just yet.
- If you're using SPF, add your new server IP address to the TXT record.
Get your new server up and ready and *tested*. Verify everything works. Web access to roundcube/squirrelmail/whatever, imaps access from thunderbird/outlook/whatever and so on, sending mail from the new server. The works.
Get bi-directional replication going between the two servers. This
doesn't have to be dovecot dsync, you can use offlineimap too.
Whatever, get sync going. The aim is to be sure that any changes on one
server are synced to the other one. Test it - use swaks to create mail
on the new server, make sure it shows up cleanly on the old (that people
are still using).
- NOW, add an MX record of higher (lower number) priority pointing to the new server. Remove the MX record for the old server.
Point clients to the new server. This can be done gradually, as mail will be replicated between the two systems.
All new mail should now be going to the new server, while some systems with cached DNS will still use the old one. Any mail they deliver to the old server will replicate to the new one. The cached MX records should expire fairly soon (remember the 30 minute TTL you set) but sometimes they don't for a while.
Wait a few hours.
- Disable inbound smtp on the old server.
Now any connections coming into the old will fail, and the source systems should spool the mail for retry later, delivering to the new server. Clients can still use the old server, and even send mail from it.
Wait a day or so and watch the old server. Pretty quickly you should see no more connections coming into it. "tshark port 25 or port 587" is your friend here.
Finally decommission the old server once you have all clients moved over to the new server.
If anyone is interested, that redundant setup is part of an automated installer I've been working on. You can set up a 3-node environment on cheap VPS', two 2gig ram nodes for the dovecot/exim4/roundcube/spamassassin/clamav and a 512meg ram one for the 3rd Percona cluster DB node (to make a quorum). Everything replicates via encrypted vpn, so you can point to either main node for roundcube or imaps. Works fine in Amazon AWS too, though that's a little pricier than the cheap VPS providers.
On 2014-07-14 16:22, Anders Wegge Keller wrote:
A frind of mine and I are running a dedicated server, that among other things host mail for ourselves and friends and families. All in all about 15 different domains with 35-40 users. The machine in question is old, so we are doing a slow transition from the old server to the new one. So far, we've managed to move web hosts seamlessly. Due to the technical capabilities at some of the user base, it would be nice to get to a setup, where we can move individual users imaps from the old server to the new one, as we get the time to visit them.
I have an idea how such a transition could go:
Upgrade the old dovecot 1.2.15 to 2.1.whateveritis from debian squeeze backports.
Set dsync up to replicate mails from the old server to the new server. I know that 2.2 is recommended, but with a limited amount of user, I'm willing to take a performance hit.
Migrate my parents &c to use the new server.
When all users have been moved on to using the new server, upgrade MX records for the domain to point at the new server.
When all MX records are updated, decalre success.
Is this feasible, and what would the risks be. For instance, during step 4, mails are bound to arrive at bothe the old and new server for some time. Will this cause problems?
Is there a simpler solution to the problem?