[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is this method of installing backup store servers good?
----- "John Fulton" <fultonj@lafayette.edu> wrote:
>
> I'm able to push block level clones of LUNs between data centers
> quickly
> via EMC SAN Copy. During the multi server install you install the
> right
> server in the right order (ldap, store, mta, proxy). For two store
> servers, with two passive backups I can either:
>
> 1. Install all four store servers as if they're going into production
> at
> once.
>
> 2. Install only two store servers, finish the install, and finally
> shut
> the installed store servers down and clone their /opt/zimbra to the
> second SAN for the second set of store servers to use.
>
> Option two seems simpler since I don't want to confuse the multi
> server
> set into thinking that my backup servers are an active part of the
> set
> and then try to remove them and stop their zimbra processes. I also
> plan
> to clone the production LUNs regularly for quicker recovery and to
> get
> users back to a point in time clone of their data in a disaster
> (after
> an e2fsck).
We are planning to do #2 (and have already done it to create our staging environment in VMs). I would strongly urge you *not* to do #1. You don't want to tell Zimbra it has 4 mailbox servers to work with when you only plan to give it 2.
If your DR environment really is going to be a clone of prod, then that'd be the best way to create it.
We plan to do nightly snapshots of all of our LUNs and replicate them to our remote data centre, with the following exceptions
- Our redolog LUN will either be synchronously or asynchronously mirrored, whatever we can get away with without impacting performance. We have tested using the zmplayredo command to replay the redo logs and bring a snapshot back into sync and it seems to work. This effectively lets your DR site pick up right where the prod site left off, with the caveat that Zimbra must be down while the redolog is replayed, and it can take a few hours to replay a day's worth of transactions.
- HSM won't be snapshotted, as we don't yet have the budget to buy a second HSM array. So if HSM gets nuked, it'll have to be restored from tape. We're going with a 90-day period to move messages to HSM, so most people will be able to live with not being able to get at old mail while it's coming back from tape. Unfortunately, calendar items also get HSM'd, so we have an RFE in to allow us to choose NOT to move appointments. We don't want the loss of HSM to affect a user's ability to see their calendar.
--
Steve Hillman IT Architect
hillman@sfu.ca IT Infrastructure
778-782-3960 Simon Fraser University