Implementing GroupWise Disaster Recovery(Reload for GroupWise)-Best Practices

  • 7020934
  • 06-Jun-2008
  • 18-Mar-2019


GroupWise Disaster Recovery (Reload for GroupWise) Installation
GroupWise Disaster Recovery (Reload for GroupWise) Setup


Implementing GroupWise Disaster Recovery (Reload for GroupWise) For the First Time - Best Practices



FYI, There are a lot more features and capabilities to GWDR than what is discussed in this document. This document is written for purposes of configuring GWDR profiles correctly such as a Post Office and Domain profiles.

Please consult the GWDR documentation for more detail and explanation on the installation and setup of the GWDR system and profiles. This guide will serve as tips and tricks, and best practices to setup and implement the GWDR system and the profiles.


The GWDR server software only runs on Linux , specifically only the SLES or OES Linux platforms.  GWDR backs up GroupWise post offices or domains on any platform, Linux or Windows, that GroupWise runs on.  All dependency software that GWDR needs to back up GroupWise post offices and domains is installed right along with the GWDR server installation.

Determine which version of SUSE or OES Linux you will implement. GWDR is supported on SLES 11 (with latest hot patches), SLES 12, SLES 15, and also OES 18. It is highly recommended to install 64 bit operating systems.

The 64-Bit platform allows for volumes over 2 terabytes, but the 32-bit platforms do not. Larger customers may want to move beyond a 2 terabyte volume. 

For larger post offices that, it is recommended to have create a separate volume for each of the GWDR profiles. This is helpful to be able to allow all other profiles backing up and not having to encounter disk space issues.


You need large amounts of disk space to house your GWDR profiles. For you average customer's needs, the amount of disk space needed to backup the post office + 14 days worth of incremental backups will be  2.5 times the size of the post office. This is the amount needed on the volume for each post office profile setup in GWDR. If keeping more than 14 days worth of backups, be sure to recalculate the disk space needed. 2.5 times is for 14 days only, so more disk space will be required if keeping more than 14 days.


EVMS is recommended for volume management and expansion features for your data partition(s). For more information on EVMS please click here:

Note: Expanding, or mounting volume is not supported by GWDR support. Please contact SUSE support for help with expanding and mounting volumes.

It is highly recommended to create a separate data volume specifically for the backup data. The GWDR software will be installed on the root partition, and will only need about 20 GB. The backups will require more, and best to put them on their own data partition.


XFS is recommended as the file system for backing up the data.

BTRFS is also supported.


For calculating disk size and what is needed please click these links here:  GWDR Disk Space Sizing (simple) and GWDR Disk Space Sizing (Advanced)


Enable the Fstab option, "No Access Time" and this should speed up the backup jobs because the file system does not have to spend time recording the access time on every file that gets written to disk.  Access time might be important for documents, but not for backups.

To do this, launch YaST and open Partitioner.  Right-click on the volume where the backups (GWDR profiles) will be stored and select "Edit".  Click on the "Fstab Options..." button and mark "No Access Time" .  Click OK and then "Finish".

At this point, you should have enough information to install your server.



Make sure to configure the NTP client on the Linux server running GWDR so that it has accurate time. NTP Client configuration is in the YaST Control Center. Since the GWDR server will be indicating backup times to the GroupWise post offices, it is important that for assurance that no e-mails ever escape the GWDR server, that the time on the GWDR server is correct.


Upgrading the SLES or OES Linux operating system will not cause any issues with the functionality of GWDR. It will still continue to run without any problems.



You'll want a static IP address for the GWDR Linux server. You will probably also want to assign a DNS name to the Linux server for ease of use later on.

It is also highly recommended to assign static IP addresses to each of the post office and domain profiles. This is helpful in a Disaster Recovery scenario where the DNS can be assigned to the post offices and domain if necessary to allow mail to continue to flow through GWDR. To configure the Disaster Recovery and assign additional IP addresses to the post office and domain profiles click this link: How to Set Up Reload Disaster Recovery


Make sure to open up the ports GWDR server firewall that you intend to use. The firewall is configured in the YaST Control Center.  For ease of use, disabling the firewall is the best option. If security is a concern, here are the ports that you should consider opening up on the Reload Linux server if your firewall is enabled:

  • Reload Web Interface: 5555
  • Access/Restore/Disaster Recovery POA's: 1677 (default).  

If you run one or more of these simultaneously, each POA will need it's own unique port or IP address. If you do not bind multiple IP addresses (see "BIND MULTIPLE IP ADDRESSES" below), then you'll need to assign a unique port to each one and open up the port on the firewall.

  • MTA's: 7100
  • GWIA: 25
  • WebAccess: 80 or 443
  • DBCOPY:  5001 (user db copy), 5002 (message db copy), and 5005 through 5016 (BLOBs threads).


For ease of use purposes, it is best to bind multiple IP addresses to the GWDR server.  Adding Multiple TCP/IP addresses is configured in the YaST Control Center.

Example scenario to illustrate how many IP addresses that would be needed:

"Company A" has a three post offices and two domains. They have implemented GWDR for the following purposes:

1. Backup and 2-Minute Restore of Mailbox Items and Address Book Items

2. On-site Disaster Recovery for:

a. Domains

b. Post Offices

c. Internet Mail

d. WebAccess

3. Retain Integration

In this scenario, the ideal TCP/IP address configuration is twelve (12) private or public IP addresses.

GWDR has the potential for four (4) different POAs that it can load for each GWDR post office profile. For ease of use it is best to bind three of the POAs to different IP addresses. This way the multiple POAs can be loaded in whatever sequence needed, and there will never be a port conflict. GWDR makes binding the POAs to the different IP addresses very simple through the GWDR Administration Menu or Web UI.

Here is an explanation of each of these POAs:

NOTE: There is more information later on in this article with some more detailed information on how to configure the various POAs mentioned here.

  • Access Mode POA

This POA allows a user to point their GroupWise client at the GWDR server and access their mailbox in it's entirety. The primary reasons that you would use the Access Mode POA are for the following tasks:

1. Accessing the GroupWise Address book, so that you can export addresses or entire address books that might have been deleted or damaged in the live system. Damaged address books are particularly more common in scenarios in the following scenarios:

a. Users are cradle syncing PDAs

b. Users are using BES and GMS attached devices

c. Users are sharing address books

2. Accessing documents that might have been deleted in the live system.

3. Accessing and archiving e-mail for a mailbox that was entirely deleted.

  • Restore Mode POA

NOTE: If the post office that is being backed up is on the Linux platform, there is no need to use the Restore Mode POA. Users do not even have to exit their client to access backups from the GWDR.

Be sure to set up the Restore Area for Linux post offices though. Click here on how to setup Restore Area for GWDR: GroupWise Disaster Recovery SEtup for GroupWise Restore Area Management - Linux

This POA is probably going to be the most commonly used POA. The Restore Mode POA is used so that users can quickly restore e-mail. This POA allows a user to point their GroupWise client at the GWDR server - at which point the user is actually accessing their live mailbox - but while connected to the GWDR server.

The user can select File | Open Backup, and they will see just the items that are not in their live mailbox. The user can then highlight an item, and right-mouse-click and select Restore. This will restore the item to their live mailbox.

  • Disaster Recovery POA (a.k.a, "Live POA")

In the case of a disaster, the Disaster Recovery POA is loaded. So when you use the push-button disaster recovery feature of GWDR loads the Disaster Recovery POA. Assuming that the POA has a DNS address assigned to it, you can simply modify the DNS "A" record for the POA to reflect the IP address on the GWDRver that the Disaster Recovery POA is bound to.

  • Retain Integration POA

The Retain Integration POA can use any of the IP addresses you have assigned, it just must use different ports. The Retain Integration POA isn't ever going to be accessed by users, and so it does not need to be a standard port such as 1677. It's just important that the Retain Integration POA for each profile is using unique ports for the Retain Integration POA for that profile.

Note: It is not recommended to run Retain Integration POA. Unless there are very slow WAN connections, or issues with Retain slowing down GroupWise systems during the archiving process, it is best to run the Retain archive job directly from the post office with a Worker installed on the same server as the GroupWise server.

  • One (1) Public TCP/IP Address for the following purposes:

GWIA & WebAccess

The GWDR can host a GroupWise Internet Agent. Here's a breif discussion of how this is done. All of the steps are taken when the GWDR server is implemented, so that things are all ready to go when the GWDR server needs to be used for Disaster Recovery purposes. By configuring everything before hand, Disaster Recovery can be truly push-button.

1. Establish a new GroupWise Secondary Domain, this domain will be normal a participating domain in the live GroupWise system at COMPANY A.  The domain just happens to be hosted on the GWDR server.

2. Install a GWIA on the GWDR server, (or another server) that is associated with the new GroupWise Secondary Domain on the GWDR server.

3. Configure the GroupWise system such that the GWIA on the GWDR server is configured as the failover GWIA for if the normal productiong GWIA is not reachable on it's MTP port.

4. Once the GWIA is implemented you may also want to create an MX record with a lesser weight than the normal production GWIA. Also, do not have the GWIA on the GWDR server loaded, only have it configured and ready to go. In GWDR, there is a place where you can tell GWDR to run the script to load the GWIA when you have switched into Disaster Recovery Failover mode for the MTA that  generally services the GWIA in the production system.

5. Just as you were able to establish a GWIA on the GWDR server, you can establish a WebAcess Application and WebAccess Agent. The WebAccess Agent should be configured to access the various GroupWise post offices that are on the GWDR server, rather than the live system. If you are using DNS Addresses for your GroupWise post offices.



1. Download the GWDR software package.

Download  to the GWDR Linux server or to a workstation and copy the software to the GWDR server.  The code is available at:

2.  Unzip the downloaded software package.

On the Linux platform, the command to unzip a file is:  unzip <filename>

3. Install the GWDR software.

At a command prompt, change to the directory where the unzipped GWDR and run the ./


1.  Go to the GWDR server's web page.

By default this is the IP address of the GWDR server and port 5555. For example:

2.  Select Tools | License | GO

Follow the on-screen prompts to implement the license


To access the Reload Administration Console type: reload in a terminal. This Reload Console Administration terminal based utility to configure the Reload server and create profiles.

More on what to do at this point in Reload Administration is explained a little later.



Make sure to enable SmartPurge for each of your post offices inside of ConsoleOne. See the GWDR documentation for more details.



If your post office(s) is on Linux, you have to create an NFS Export of your Post Office or Domain directory. The export must allow for the following rights:  rw,no_root_squash,sync

It may be well to read the documentation for more information on making and NFS export or see "How to Create A Post Office Profile (GroupWise on Linux)"


If your post office(s) is on Windows, make a GWDR Backup User that has full rights to the post offices and domains that will be backed up with GWDR.



If your post office is on Linux you don't need to make a Restore User at all. Using the File|Open Backup feature in GroupWise is even simpler when the post office is on the Linux platform.


Make sure to create a GWDR Restore User (The Restore Mode POA uses this login) that has full rights to the GroupWise post office.



From the Reload Administration main menu, choose the Create Profiles menu choice. Go through the prompts to setup the profile.


Portable Backups for Post Office Profiles

When a profile is created it comes with factory default settings. So out of the box it will function fully as a backup profile and a disaster recovery solution. However you probably want to change the factory defaults a little bit to fit the needs of GWDR.

For example, for post office profiles, determine the amount of backups to store. Default is 14 days.  They cost about 2.5 times the size of your post office on the GWDR server for each week that you keep around. So take that into consideration.

GRE_BLOBS Threads for Post Office Profiles

Tweak GRE_BLOBS threads. For server grade machines, generally you want to put the GRE_BLOBS threads to 10. This can greatly speed up the backup times of a GWDR post office profile.

GroupWise Restore Areas

Once the profile is created, and the first backup is completed, be sure to set up the Restore Areas that represent each of the GWDR post office profiles.

Backup Consistency

Set the backup Consistency to "Highest" (default) this is particularly important for customers implementing Retain Integration.

Document Management

If there are libraries at the post office, GWDR can back them up. This is enabled by default.

Configure the Access Mode, Restore Mode and Disaster Recovery ("Live") Mode POAs.

(Access Mode POA)

For the Access Mode POA, make sure to fill in the IP address and port of the Access Mode POA.

Here is the functional purposes of the Access Mode POA :

  • Export Personal Address Books
  • Use the Archive Feature to copy any items that can be archived, from the GWDR server to a user's Archive mailbox. Then the item can be un-archived in their live mailbox.
  • Access Documents in a GroupWise DMS Library

Here is how a user can use the Access Mode POA

In order to use the Access Mode POA, the user exits their client connection from their live post office, and connects to the Access Mode POA. So the Access Mode POA needs to be listening at an IP Address and Port that is unique, . . .or at least the Port needs to be unique.

Once the user is connected to the Access Mode POA, they can Export Address Books, Archive an item, or items, they want to bring back to their live mailbox. A user can also access documents in a GroupWise DMS Library.

(Restore Mode POA)

NOTE: For Linux Post Offices the Restore Mode POA is irrelevant, and unneeded. If you set up everything according to the documentation, the users only need to select File | Open Backup, while in their normal GroupWise Mailbox session to their live mailbox.

The functional purpose of the Restore Mode POA is for simple e-mail restoration via the File | Open Backup feature.

In order to use the Restore Mode POA, the user exits their client connection from their live post office, and connects to the Restore Mode POA. So the Restore Mode POA needs to be listening at an IP Address and Port that is unique, . . .or at least the Port needs to be unique.

Then the user selects File | Open Backup, while connected to the Restore Mode POA.

For the RESTORE MODE POA, make sure to fill in the IP Address and Port of the Restore Mode POA and the Connectivity settings

You must also create a Restore Area in ConsoleOne, and configure it according to the GWDR documentation. Make sure to read up in the written documentation on how to do this. 

(Disaster Recovery POA)

The functional purpose of the Disaster Recovery POA is for a Disaster Recovery event. In otherwords, you have cut over to your GWDR server so that it can function as your live post office.

For the DISASTER RECOVERY POA, which is used in Disaster Recovery purposes, make sure to fill in the IP Address, Client Server Port, MTP Port, MTA Address and MTA MTP port.

Also, test the Disaster Recovery feature for each profile, to make sure that the Disaster Recovery POA loads correctly etc. When the disaster hits, you don't want to be fumbling around trying to get the Disaster Recovery POA loaded, because there is some technical problem.

For complete instructions on setting up Disaster Recovery, see "How to Set Up Disaster Recovery".

(Retain Integration POA)

Each profile has a "Retain Integration POA". You only need to configure this POA if you have GWAVA's Retain for GroupWise product implemented and you intend to leverage the tight integration between Retain and GWDR.

Make sure to make profiles for the GroupWise domains also, people forget to do this. It's so simple and there is so little to do. 



In the WEB UI, or Reload Administration Console,, under System|Mailer Configuration configure the GWDR server to notify on warning and error conditions, and also to send daily status reports. Make sure to run the test to see that someone gets the message.

GWDR relies upon "Postfix" as it's mailer engine. So to troubleshoot mailer problems, your troubleshoot Postfix.

Postfix keeps it's log files in /var/log.  The two main files to look at are:

  • /var/log/mail
  • /var/log/mail.err

You can view this files by using the command:  cat /var/log/mail

If you want Postfix to relay messages through your GroupWise Internet Agent (GWIA) then edit the /etc/postfix/ file and go to the end of the file. Look for the line that most likely currently reads:

relayhost =

And indicate the IP address of your GWIA. For example:

relayhost =

To restart the postfix daemon enter: /etc/init.d/postfix restart

GWDR uses the Postfix utility which runs by default. If your Reload server is going to be sharing a GWIA on the same server, or is going to be accessible to the Internet it is advisable to turn off of the Postfix SMTP Daemon. Turning off the Postfix SMTP Daemon does not entirely disable Postfix, it just makes it so that Postfix is not listening for inbound SMTP sessions on Port 25. Here's what you do to turn off the SMTP Daemon of Postfix:

Edit the file /etc/postfix/ file

Look for the line that reads:  smtp inet n - n - - smtpd

Put a pound symbol in front of it and save the file, like so:  #smtp inet n - n - - smtpd

To restart the postfix daemon enter: /etc/init.d/postfix restart


You will most likely want to configure the GWDR Server's web page to be secured with authentication. To enable this, go to System | HTTP in GWDR Administration.


GWDR can run multiple simultaneous Standard backup jobs (the daily incremental jobs for post offices and domains).  With this feature the overall backup windows on a particular GWDR server can shrink significantly; however, running concurrent jobs can be disk intensive. So the feasibility of configuring this feature is really dependent on your hardware.

Or if the GWDR server is backing up data over a slow network link the disk is most likely not going to be the bottleneck, but perhaps the network connection is. In my experience, customers in a LAN environment with a server grade machine have been able to configure GWDR to support three Concurrent Standard Backup Jobs.

To configure Concurrent Standard Backup Jobs go to the "Configure" tab in GWDR Web Administration. Select the Job Handling Preferences panel. Make sure that "Allow Concurrent Standard Backup Jobs" is set to enabled. And then set "Number of Concurrent Standard Backup Jobs Allowed" to 2 for starters. if that works fine, than consider increasing this setting beyond 3. The speed of the individual Standard Backup Jobs may decrease. However; overall the total time to run all of the Standard Backup Jobs could speed up, and perhaps it could speed up significantly.

Another reason to enable this feature is to allow other backup jobs to run if the one before them stalls for some reason.  If you don't want to run your backup jobs concurrently but you do want to allow other jobs to run if one stalls, enable this feature and simply stagger your backup schedule so they start at different times.  Look at your GWDR Web Administration tool to see how long each profile takes to back up and schedule accordingly.  There are also some tricks to speeding up backups.


(See also, "Creating Multiple Post Office Backups Within a Day (Intra-Day Backups")

 Perhaps creating a backup just once a day is not often enough. Consider using the GWDR Job Utility which will allow you to increase the number of times backups are created for a particular post office. For best disk space usage and to assure that all e-mail is backed up, design Reload as follows:

1. Design the Reload Job Utility to NOT run SmartPurge for the intra-day Standard Backups.

2. Design the daily regularly scheduled Standard Backup Job from the Reload Console Administration menu to be the final job that runs in a particular day.

So for example, let's say you want from the hours of 6 A.M. to 8 P.M. every two hours for the GWDR Job Utility to created backups, and then the 10:00 P.M. job to be the final job, and this is the one that will run SmartPurge. Here is how you accomplish this:

1. Go to the GWDR Web UI, click on the profile and Configure Tab

2. Click on Backup Job Settings and Intra-Day Backup Schedule.

3. Enable Intra Day Backup Schedule for 1st, and/or 2nd Intra-Day Backup and change the time to the desired times to backup.

Note: You can only do 2 backups in one day in the interface. For more backups in the day, they will need to be setup manually. See below.

1. Add the following command to the /etc/crontab file: 

1 6-20/2 * * * root reloadj –p po1 –i

2.  Edit the profile and have the Standard backup job that is queued up by the GWDR scheduling system happen at 22:00.

This design will cause the backups throughout the day to be immediately deleted by GWDR when the next backup is created. The reason they can be deleted by GWDR is that they are not needed. Since SmartPurge does not run for the backup from 6 A.M. to 8 P.M., everything that was in a prior backup is now included in the newest backup plus any new changes.

The net effect from this approach is backups that are only 2 hours old throughout the business hours, but still only the last backup will be kept by GWDR which keeps the daily disk space for backups at only about 12% of the total size of the post office(s) being backed up.


GWDR has a button in GWDR Web Administration called "Disaster Recovery Plan". This button is meant to be assoicated with custom created *.pdf or web page specific to the disaster recovery plan for your system. The *.pdf file can be placed on the GWDR server, and should be named something other than the default disaster recovery plan file name which is drplan.pdf. The location where you can specify the URL to the Disaster Recovery Plan documentation is under the Configure tab in the Web Administration Preferences panel.

If you have a GWAVA Reload reseller they can probably help you to design your Disaster Recovery Plan documentation.


Users can restore items to their mailbox, from GWDR, without even exiting their GroupWise client. This feature does require some initial configuration that has several steps. However once it is all set up, using the Restore Area Feature of GroupWise and GWDR is very automated. Read more about setting up a Restore Area for Linux post offices in the GWDR documentation.


Your GWDR server has "Help" documentation in GWDR Web Administration. Access GWDR Web Administration which is typically at your GWDR's server's IP address on port 5555. Then click the "HELP!"  button. Review each of the panels, and watch their accompanying videos. The videos are short and informative.

Additional Information

This article was originally published in the GWAVA knowledgebase as article ID 256