And here the way I did migrations: 1) Dump and import the Database using mysqldump 2) rsync the email data to the new server 3) Change MX entry 4) during DNS propagation run rsync often to resync new mail files to the new sever
Have migrated two servers that way without down times. Disabled qmail and all services on the old machine once DNS propagated to ensure all clients have switched (all had since I have a whopping 6 users ;-)). Things get even easier with a separated DB since you can just move the data files and make sure the new server connects to the same DB. If you can add a NFS storage for mail data too, you can even take that out of the picture. Works well enough for smaller setups. Anything bigger would need a clustered file system (which I still want to at with [ceph]). I guess that's for another day though ;-) Sent from my iPhone > On 08 Jul 2015, at 20:06, Sebastian Grewe <sebast...@grewe.ca> wrote: > > Two additions: > > 1) Don't do it by hand since users have to change their password if you don't > have plain text enabled: > http://dba.stackexchange.com/questions/9306/how-do-you-mysqldump-specific-tables > 4) use rsync -var > > Sent from my iPhone > >> On 08 Jul 2015, at 19:54, Eric Broch <ebr...@whitehorsetc.com> wrote: >> >> I suppose I'd do it in this order >> >> 1) Create the domain and all the users on the new server. Given that it's >> such a small domain, I'd do it by hand you could dump the db but then you'd >> have to drop the unnecessary tables. I'm not sure of a way to extract one >> table in mysql. >> 2) Point the email clients POP or IMAP to the new server. This would be easy >> if your using a domain name. >> 3) Route email to the new server. (Mail would not be received between the >> last two steps). >> 4) Copy the mail for the domain over. I would not use unison for this. >> Recently, I used 'scp' with the recurse option for each user in the domain >> but had to change the permissions on the new files to vpopmail.vchkpw. >> >> Eric >> >> >> >>> On 7/8/2015 11:28 AM, Gilbert T. Gutierrez, Jr. wrote: >>> I will try what you suggested. >>> >>> There are actually several domains (6) and they each have about 30 users >>> each spread over multiple office locations. >>> >>> Gilbert >>> >>>> On 7/8/2015 10:05 AM, Eric Broch wrote: >>>>> On 7/8/2015 9:18 AM, Gilbert T. Gutierrez, Jr. wrote: >>>>> I have a domain on my Qmail Server that I am migrating to another server. >>>>> I want both servers to be up as I am transitioning the domain. My >>>>> question is, how do I keep the old server up and have it just forward new >>>>> email destined to the domain to the new server and not try to capture it >>>>> locally? >>>>> >>>>> Gilbert Gutierrez >>>> Hi Gilbert, >>>> >>>> I don't think you can do this with at least a small amount of down time >>>> for the new domain, but... >>>> >>>> In order to forward mail to the new server from the old ( I think that's >>>> what you're asking) without removing the domain from your old server you >>>> can comment out the migrated domain in /var/qmail/control/virtualdomains, >>>> and put a route to it in /var/qmail/control/smtproutes and restart qmail >>>> or reload qmail. Please investigate to your satisfaction first. I tried >>>> this once on my server and it worked. >>>> >>>> Of course the domain must be created with all the users on the new server >>>> in order for it to receive mail and for your IMAP (or POP) clients to >>>> work. In order to sync the two hosts you can use unison, rysnc, or scp. >>>> I've used all three. I use unison mostly, and here's a link to it, which >>>> setup can be tailored for replication of only one domain >>>> (http://wiki.qmailtoaster.com/index.php/QMT_Failover_replication_Setup). >>>> >>>> How big is this domain? >>>> >>>> Eric >>
