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:
1. Upgrade the old dovecot 1.2.15 to 2.1.whateveritis from debian
squeeze backports.
2. 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.
3. Migrate my parents &c to use the new server.
4. When all users have been moved on to using the new server, upgrade
MX records for the domain to point at the new server.
5. 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?
--
/Wegge
Leder efter redundant peering af dk.*,linux.debian.*
On Jul 14, 2014, at 1:22 PM, Anders Wegge Keller <wegge at wegge.dk> 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: > > 1. Upgrade the old dovecot 1.2.15 to 2.1.whateveritis from debian > squeeze backports. > > 2. 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. > > 3. Migrate my parents &c to use the new server. > > 4. When all users have been moved on to using the new server, upgrade > MX records for the domain to point at the new server. > > 5. 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? > > -- > /Wegge > > Leder efter redundant peering af dk.*,linux.debian.*I did this several years ago using imapsync to sync the accounts from an old server to a new server. Once all the accounts have been sync'd and you're ready to cut over to the new server, run imapsync one last time to catch anything new that's arrived. It will go very quickly. Disable postfix/dovecot on the old server and change your DNS to point to the new server. Or better yet, if the old and new servers are on the same network, just swap the names and IPs of the new and old servers. -Terry Terry Barnum digital OutPost http://www.dop.com
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: > > 1. Upgrade the old dovecot 1.2.15 to 2.1.whateveritis from debian > squeeze backports. > > 2. 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. > > 3. Migrate my parents &c to use the new server. > > 4. When all users have been moved on to using the new server, upgrade > MX records for the domain to point at the new server. > > 5. 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?
> > I have an idea how such a transition could go: > > 1. Upgrade the old dovecot 1.2.15 to 2.1.whateveritis from debian > squeeze backports.Backports version is a bit outdated so you might want to consider using version from jessie, which seems to follow the upstream more closely. The tradeoff is of course the need to pull some system libraries with it as well, namely libc. Newer version may interfere with whatever else you run on the server and you'll probably need to solve some dependencies manually. It's working for me on pure dovecot server, YMMV Other than that I more or less aggree with the post from Terry Barnum - stop postfix to prevent delivery of new mail, block the old IMAP/POP3 server from regular users, use some sort of IMAP sync (either imapsync or - IMO - even better doveadm sync) to download data from the old server to the new one. After that's done, switch IP addresses and enable services on new server. It'll need some late-evening/night time work and maybe console access if the IP switch goes wrong, but otherwise it should be hassle-free - particulary no need to change ppl's mail client settings this way