On 07/01/2012 10:46 AM, Eric Shubert wrote:
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.
A high availability solution is not required, nor is separation. I have
a very small server, less than a dozen domains with just over 2GB of
mail. A reliable secondary machine that is identical to primary machine
would suffice.
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.
I fail to understand why two identical servers in separate locations
doesn't qualify as a backup solution. Both servers have secondary
backup hard drives with duplicated data and the second server takes the
place of the first if the first is ever broken. Why is that not desirable?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
