Ok guys, here is my next challenge...really, the biggest problem I'm
foreseeing at the moment:
So here I am joyfully (as I curse at the computer under my breath every
time I find a new problem...) migrating all 4000+ users of the 392
different domains using the migrate-domain script (if you aren't
familiar, it basically creates a tarball of every mailbox belonging to
the domain, and then generates a script that when run will recreate the
domain, user accounts, mailing lists and forwards --with a minor amount
of fuss after the fact on the new system) --- so that is all good and
well, but here is where the problem comes in...I have 165GB of data to
migrate, and in the end I plan on taking down "Server A" and having
"Server B" completely take over, except every second after data has been
migrated over to "Server B", there is a pretty good chance that new mail
is coming in for one of the 392 different domains.
The problem is that as long as that old server is still up, I need to
worry about keeping the mail content consistent between the old server
and the new. Obviously I'd like to have the time between domain
migration and server deployment down to a minimum, but some of my
customers are quite large (600 or so email accounts, each of which will
need to be reconfigured on their end at minimum just to make sure they
are using smtp-auth, and probably changing the incoming/outgoing server
settings on a few systems that are statically set to use the server's IP
versus hostname.
Normally I'd probably opt to use rsync to keep the new server in-tune
with the old one, but I'm not sure that is exactly an option, because
the old system has vpopmail compiled with "many-domains" enabled, in
addition to "big user dirs", so once again I'm trying to interface with
a different folder structure -- for example, on the old system we have
domains that are broken up in the domain's directory by number (i.e.;
domains/0/abc.com, domains/1/bca.com, domains/cad.com, etc) as well as
users broken up by number in a similar fashion (i.e.;
domains/abc.com/0/postmaster, domains/1/bca.com/demo,
domains/cad.com/2/test, etc). Since I'm trying to standardize, I don'
want to have to compile those features in...but that makes it difficult
to use something such as rsync to run against a domain folder with the
flags set that will delete files from the destination that don't exist
on the host. So what do I do? I need a fairly automated way to keep the
mail synchronized between the servers before we take the old one down.
At the moment, there is enough manual intervention required in migrating
the domains, that it doesn't seem realistic to try to get all the data
migrated and current the day that we decide to do all of this.
I'm really really really hoping that someone out there has some ideas
and can help me out with this one. I'd like the least amount of service
disruption possible, and can't run the risk of missing or losing email
for my customers. I want to get this to work, because my next project is
to setup a replicated qmailtoaster, which should be much easier to work
with and can use rsync and/or unison to get things in check.
There has gotta be a few Toaster Master's out there that have the
perfect solution...all I need is one good idea ;-)
Thanks in advance,
Casey
Smile Global Technical Support
Submit or check trouble tickets http://billing.smileglobal.com
www.smileglobal.com <http://www.smileglobal.com>
On 10/2/11 8:21 PM, Eric Shubert wrote:
On 10/02/2011 08:04 PM, Pak Ogah wrote:
On 10/01/11 21:02, Eric Shubert wrote:
Nice job, Casey.
I hope you will consider taking a little time to document your
experiences here:
http://wiki.qmailtoaster.com/index.php/Migrating_from_non-toaster_qmail
That page has little content, so feel to edit/modify what's there.
Thanks for sharing. :)
Eric, I think the title shoud be "Migrating from Qmailrocks", as Casey
was using Qmailrocks.
Although he is using Solaris on his old server, but I think his
documentation should be able followed by other Qmailrocks users that use
Linux who also want to migrate to QMT.
as Solaris and Linux is command and path almost identical. And I think
there are many Qmailrocks users who want to migrate since qmailrocks
website/manual and support forum no longer active. (my friend is one of
them but the company buying him Windows 2008 svr + ms. Exchange)
---------------------------------------------------------------------------------
While QMR is a non-toaster_qmail setup (and thus fits the
description), it's pretty specific, and is even a predecessor of sorts
to QMT.
A separate page for QMR is fine with me.