Implementing Reload for off-site disaster recovery

I've worked with two customers as of late in conjunction with the customers
implementing Remote Reload profiles. I also was training a GWAVA reseller on
the East coast of the U.S. and was explaining just how he should implement
Reload for maximum gain for disaster recovery purposes for a large bank
implementation.

First off, an explanation of this concept. Disasters can be of two different
kinds. There are server disasters, and site disasters.

[ SERVER DISASTERS ]
Server disasters are more common and they can include things such as hardware
or software failures. If the server is housing a GroupWise post office or
domain then with Reload in place, no problem, you can cut over to the Reload
server right away with Reload's push-button disaster recovery. In the realms
of GroupWise another server disaster can be a GroupWise data disaster, for
example someone is cleaning up the GroupWise server and they accidentally
delete part of a post office. I mention this because I was on a customer site
a couple of weeks ago, and they said that had just happened to them recently.

[ SITE DISASTERS ]
A site disaster is less common, however site disasters are a growing threat
and are of great concern to many organizations. A site disaster is one in
which SITEA might experience a catastrophic event or a prolonged outage
event. It is for this reason that Reload supports a "Remote Reload" profile
type. A Remote Reload profile is designed in the following manner. SITEA has
a local Reload server providing backup, quick-restore and server disaster-recovery
services. SITEB has a Reload server that is pulling across the
incremental backups from the SITEA's Reload server. SITEB then is providing
off-site disaster recovery services for SITEA.

To come a little closer to one customer's scenario, which we will called ACME
Bank, SITEA and SITEB are both major locations for ACME Bank. There will be a
Reload server at both SITEA and SITEB. The Bank likes the quick restore
features of Reload, but off-site disaster recovery is their primary aim
behind implementing Reload. Originally the reseller interned to implement a
Reload server at both sites, but their design wasn't the best because it only
took into account off-site disaster recovery. The Reload server at SITEB for
example was going to directly backup the GroupWise servers at SITEA. The
Reload server on SITEA would also directly backup GroupWise servers on SITEB.

This is doable, but still not ideal. Here's why. Although this design was
more efficient on disk-space, and it also allowed for off-site disaster
recovery, the design didn't allow for on-site disaster recovery which is
actually a more common likelihood. Furthermore, when you use a profile type
of a "Remote Reload Profile", the Reload to Reload server connection pulls
data using the more efficient NFS protocol. Oh, I didn't mention the
customer's GroupWise system is on NetWare, like most GroupWise systems.
So the design I proposed, and which I propose to all customers is as follows:
SITEA has a Reload server with Reload Profiles which locally backs up the

GroupWise post offices and domains.
SITEA's Reload server also has defined "Remote Reload" profiles that actually
correlate with the Reload Profiles on the Reload server at SITEB.
SITEB has a Reload server with Reload Profiles which locally backs up the
GroupWise post offices and domains.
SITEB's Reload server also has defined "Remote Reload" profiles that actually
correlate with the Reload Profiles on the Reload server at SITEA.
Now, another important point. ACME Bank already has a good investment into
network infrastructure between SITEA and SITEB. They have created a large

enough network pipe between SITEA and SITEB to support other business
processes. Reload works very nicely in this kind of an environment. Generally
you design your Reload to Reload server communication to happen after
business hours. So the network pipe is being well utilized in the night-time
also. Basically each night Reload needs to replicate about 12% of the size of
the post office. This being the case, if your post office is 100 gigabytes in
size for example, you can expect that each night Reload will need to
replicate 12 gigabytes. For ACME Bank this is no problem. However for
customers who do not have a fast enough link an off-site Reload server is not

feasible. As I have been talking to GWAVA salespeople about who the prime
candidates are for off-site disaster recovery, it's generally not the
small business or single-site organizations that are going to benefit from
Reload's low-cost off-site disaster recovery. The reason for this is that these
organizations do not have the business needs that have caused them to build the
network infrastructure sufficient to support off-site replication of 12% of the size of the post office each night. I have found that no matter how small the company is, their GroupWise post offices are generally large, perhaps even more so for smaller organizations because they use GroupWise for more business processes then some larger organizations.

CONCLUSION
Reload is always a good solution for any GroupWise customer. It's a superior backup, quick restore and disaster recovery solution over any other solution available. A Reload off-site server is an ideal solution for those customers who are concerned with the threat of a site disaster. Those customers who already have an investment into a WAN that can support replication of 12% of the size of their post offices will be the ones that will be able to implement Reload without any further investment beyond the investment of the Reload software and servers. Those customers who do not have multiple sites will need to plan accordingly for network links sufficient to replicate 12% of the size of their post offices. For one organization that I spoke to recently this was going to mean an additional $3,500 a month, which meant that an off-site Reload server was not feasible for this customer, unless they reduced the size of their post office.