On 07/01/2012 09:40 AM, Maxwell Smart wrote:
On 06/27/2012 06:27 PM, Eric Shubert wrote:
On 06/27/2012 05:14 PM, Cecil Yother, Jr. wrote:
I have two servers, server A and server B. They are both Centos 5.8,
built on the V2gnu iso. They are basically identical with all updates. I
have about a dozen e mail domains on server A and 2 e mail domains on
server B. Can I run the qtp-backup on server B and restore those on
server A so that all my mail domains reside on one server?
TIA
--
Not without a bit of modification. The backup is ok, but qtp-restore
is written load from scratch. With a bit of tweaking you should be
able to get it to do a non-destructive restore. The database load
would need to be changed to merge the backup in with the existing
database, as would various control files such as rcpthosts,
morercpthosts, virtualdomains, and the users/assign file (and don't
forget the cdb file for that one).
That would be a nice feature for qtp-restore actually, have it ask if
you want to add the domains to the existing configuration or clean out
the existing configurations.
It might be simpler to create the domains manually though, write a
script to add the users to the target host (or add them manually too),
then simply rsync /home/vpopmail/domains/ from the old to the new
host. This would be the safest route I'm guessing. You could test out
the target after doing the initial rsync, then do a final rsync (which
would be fast) when you're ready to cut over.
OK, I chose the easy solution. I created the accounts on the machine
with existing accounts, created a new account in Thunderbird and copied
the mail from the old account to the new account. This went rather
quickly and was relatively painless.
Is Unison as described in the wiki still the recommended way of creating
a failover / duplicate server?
I don't know that there's any one recommended way. It depends on what
your needs are. Unison can be appropriate in some instances.
Dovecot is doing some interesting development in the area of high
availability mail stores. I would take a look at what's going on there.
I think the important thing to do when setting up a high availability
mail solution is to separate components in a meaningful way before
trying to provide redundancy. This is because each component presents
different challenges regarding redundancy. For instance, a redundant
submission server is rather trivial compared to a redundant imap or
storage server. A typical separation is between the front end and back
end (storage) components, at least as a first step. Once you have front
and back end separation, replication of each would mean having 4 hosts.
So the BL here is that while QMT is presently often a single host setup,
using 2 self-contained QMT hosts is likely not the best approach to
building a HA solution.
I'm presently working on a design of QMT components such that they'll be
loosely coupled, and able to be combined more easily into a HA solution.
I expect to be publishing this on the devel list in a few months or so.
Stay tuned for that.
Is rsync an option?
Rsync is appropriate for backing up mail stores and configurations
(mysql database needs to be addressed separately). I don't see it
playing a role in HA configurations, except for providing backups, which
should still be done. HA, like raid, is *not* a backup solution.
--
-Eric 'shubes'
---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
