Re: Moving Sites
Thanks for all the responses. I did not include in the original text that the IP's are all
changing; required as I am moving to a new colo. I think what I'll do is simply set the ttl on
BIND for mail.dailydata.net to a very low value, then manually move files which are newer than
the shutdown date over. I believe scp, rsync, etc... have flags that allow me to only get more
recent files and to maintain ownership (users have the same gid and uid on the new box).
Any other suggestions are gratefully appreciated, and again, thanks for all the responses.
Rod
> On Mon, Oct 20, 2003 at 10:43:16PM -0500, Rod Rodolico wrote:
>> Stupid Question: I have about 50 web sites and a few hundred e-mail accounts to move to a
>> new
>> server. New IP address, etc... Web sites are no problem, but I do not want my clients to
>> notice any problems with e-mail. They have IMAP available, so many of the clients store
>> their
>> e-mail on the server.
>>
>> Any ideas on how to move the e-mail accounts seamlessly. I have all
>> their MX records pointing to one address: mail.dailydata.net.
>
> That's good.
>
>> I have rsync'd all the files over, and can do it again whenever, but
>> that won't work as they will be checking their mail on one machine
>> while, I assume, some might be delivered to the other, older server
>> (I was planning on keeping the old server up a few days in case I
>> screw up).
>
> Also good.
>
>> Guess is boils down to this. When I update the address of
>> mail.dailydata.net, it can take up to 72 hours for that change to
>> perculate throughout the net, so I'm assuming some places will still
>> try to send to the old IP and, if I leave that box on, be delivered
>> to it. If I turn the other box off, I'm assuming they will bounce.
>
> Why change IP's in the process?
>
> Since I just did this last week... :)
>
> o rsync all the mailboxes over. (Um, they were -huge- here...
> it took hours.)
>
> o rsync again (this one took an hour or so)
>
> o rsync again (8 minutes! wooo!!! close enough!)
>
> o set 'New' to defer incoming mail. Not to deliver it, just
> queue it. In postfix, this is:
> defer_transports = local
>
> o simultaneously:
> old# postfix stop && ifdown eth0
> new# ifup eth0:1
> ie, swap the machines around. Bring down the old machine's
> network and bring up the new one where the old one was. Convince
> any routers to re-arp. You should bring up another interface on
> 'old' so you can still talk to it, since you'll need it still...
>
> o rsync the mailboxes again. This should be -really- fast since
> only a few minutes have gone by.
>
> o remove the 'defer_transports' setting, and flush the queue...
> mail that was queued will now be delivered (and appended onto
> stuff that was rsync'd over... ie, no lost mail).
>
> o go back to 'old', which prolly still has piles of mail in the
> queue. Set up a transport map for your domains to pass stuff
> to the new mail server. (ie, this machine no longer deals with
> final delivery of mail to your domains ... make sure it knows
> that.)
>
> o restart postfix so it can send all the queued mail, and, if they
> bounce, it can send the bounces to the new server thanks to the
> transport map.
>
>
> o in a few days, the queue will be clean and you can shutdown the
> machine for real.
>
>
>> Am I creating a problem that doesn't exist?
>
> Yep. :) It's -much- easier to keep the same IP. You just have to be
> sneakier and do it late at night.
>
> --
> | All her life she was a dancer, but no
> brian moore <bem@rom.org> | one ever played the song she knew.
> | -- the residents
>
>
> --
> To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
--
Missiles of ligneous or osteal consistency have the potential of fracturing osseous structure,
but appellations will eternally remain innocuous.
Reply to: