GroupWise 2012 Backup Time Stamps

I did a series of posts about backing up GroupWise 2012.

Backing up GroupWise 2012 with dbcopy
Backing up GrouWise 2012 with BackupExec
Backing up GroupWise with Acronis vProtect 7

All of the methods used did not rely on a dedicated GroupWise backup agent. They were all basically file copy operations of various sorts. All of the methods discussed worked fine and could be used as an effective backup strategy. However, after a time, I discovered that they all lacked a critical step.

Amongst the many things that GroupWise tracks in its various databases is when last a mailbox was backed up. Dedicated GroupWise backup agents set this attribute after completing a backup operation. The last backup time stamp attribute is important when retention policies are implemented. One commonly used policy is the restriction on emptying the mailbox Trash folder until after a backup has been performed. This is a critical policy in many industries for regulatory compliance as it prevents deletion of messages without a record of the message.

Unfortunately, I failed to take this last backup date/time stamp into account in my various backup methods. The result being that users were unable to empty their Trash. This is however, not an uncommon issue and Novell has long provided a command line utility, /opt/novell/groupwise/agents/bin/gwtmstmp, to deal with it.

Using the gwtmstmp utility, it is possible to set or reset several time stamp attributes stored within GroupWise. Using it in a script in conjunction with the previously discussed backup methods allows everyone to be able to empty their Trash folders again. The command we will want to use looks like this:

gwtmstmp -b -s -p /gwsystem/gwpo

This sets(-s) the backup time stamp(-b) for all mailboxes in the specified post office(-p) to the current date and time. If we needed to specify a particular date, the command would look like this:

gwtmstmp -b -s -d 03/31/2012 -p /gwsystem/gwpo


Taking the dbcopy script from this post as an example, we wind up with something like this:

#!/bin/bash
#Differential backup.
#Runs a dbcopy of files dated since Sunday or newer.

cd /opt/novell/groupwise/agents/bin

SUNDAY=`date +%m-%d-%Y -d "last Sunday"`
TODAY=`date +%Y-%m-%d -d "today"`

dbcopy -t 10 -i $SUNDAY /gwsystem/gwdom /mnt/backupserver/gwbackups/$TODAY/gwdom
dbcopy -t 10 -i $SUNDAY /gwsystem/gwpo /mnt/backupserver/gwbackups/$TODAY/gwpo

gwtmstmp -b -s -p /gwsystem/gwpo


Now everybody is happy.

Backup GroupWise 2012 On Linux With Symantec BackupExec

One of the more traditional ways for performing backups within an enterprise is with the use of a common off-the-shelf(COTS) backup program such as Symantec BackupExec running on a dedicated or remote backup server. This backup server performs file based backups to tape or disk. The Net Codger had difficulty finding documentation on how to backup Novell GroupWise 2012 running on Linux with such a system. This is (one way) how to do it.

For this exercise we will be using Symantec BackupExec 2010(See Update at the end of this post.) or 2012 running on a Windows server to properly backup a Novell GroupWise 2012 system running on Suse Enterprise Linux 11(SLES11). It is pertinent to note that this is a plain SLES 11 install that does not utilize Open Enterprise Server(OES), so these instructions are equally applicable to a Red Hat server or others.

The procedure starts off in a familiar fashion where we install the Linux backup agent, provided as an option with BackupExec, onto the Linux host that we want to backup. In this case, SLES 11. The Remote Agent for Linux, Unix and Solaris(RALUS) is a separate license purchse, but the software can be found on the BackupExec installation media.

Copy the ralus_rmals_rams-nnnn.tar.gz file from the BackupExec installtion media to a directory on your SLES11 host e.g ~/Downloads/ralus/ Change into the directory and run

./tar vxfz ralus_rmals_rams-nnnn.tar.gz

This will expand the installation files into the current directory or a subdirectory. Now run

./installralus

Step through each of the install script’s prompts answering appropriately. The IP address or host name of the BackupExec server prompt is the only one that must be changed. Most or all of the other prompts can be left at their defaults. Once the installation process is finished, start the agent by running

/etc/init.d/VRTSralus.init restart

Now, with the RALUS agent running, go to the BackupExec server and create a backup job. This is done just like any other backup job. Your SLES11 server can be found under Favorite Resources – > Linux/Unix Servers. Expand your server and then expand [ROOT] to make your file selections.

There are a couple of things to note when backing up via RALUS. Firstly, any chrooted processes will likely create a <chroot>/proc directory under the chroot. My somewhat dated version of RALUS tries to back these up unless you explicitly exclude them. One such chroot instance on SLES11 is /var/lib/ntp/. There the proc directory contains a “file” called kcore which lists as 128 TERABYTES. BackupExec dutifully tries to back up this virtual file. I’ve never waited to see how long it will actually take to complete, but it will add a day or more to your backup time. Make sure you exclude all /proc instances.

Similarly, my backup jobs run very long sometimes if the lost+found directory at the root of each mount point isn’t excluded from your backup job. This shouldn’t happen, so I suspect a bug in my version of RALUS, but hunt them down and exclude them or your backup job may run very long and show incorrect byte counts.

When backing up GroupWise the only absolutely essential directories to backup are the ones containing the domain and post office databases e.g.

/gwsystem/gwdom
/gwsystem/gwpo

You could reinstall and recover a GroupWise system with just these directories. But, you will have a fair bit of work to do when performing a disaster recovery if you don’t have various config files also backed up. For this reason, I recommend a more complete backup of your GroupWise system. The backup source list really should include the following directories as a minimum

/gwsystem/gwdom
/gwsystem/gwpo
/opt/novell/groupwise
/etc

For my backups, I select the entire file tree and then exclude the stuff that is really unneeded like /tmp and those described earlier in this post.

After the selections are made, double check the Advanced options.

They should look like above with directives to follow junction points, but not follow symlinks.

The Linux, Unix, and Macintosh settings, show above, should have only “Follow local mount points” and “Lock remote files” selected. Set you schedule, hit submit and you’re done.

It is important to note that RALUS is a file based backup agent. It is unaware of databases like, eDirectory so you will be unable to successfully backup and restore eDirectory with RALUS. For eDirectory, I recommend a root cron job that runs the ndsbackup utility locally.

ndsbackup cvf /root/edirbackup “Full eDirectory Backup”


RALUS can then pickup the /root/edirbackup file and you can use the ndsbackup utility to restore eDirectory from that file should that disaster ever arrive.

GroupWise is also a database. So, this method does present the possibility of an inconsistent database upon restore. My experience has been good, no problems with restores, so far. But, the possibility exists. If it becomes an issue, I’ll likely use LVM snapshots in conjunction with BackupExec Pre/Post commands to snapshot the GroupWise partition, backup the snapshot and then remove the snapshot. It should work fine, but I prefer to avoid possible issues with Pre/Post scripts not working correctly.

Backup jobs, using RALUS, provide acceptable performance for a file based backup over a 1Gbps network. BackupExec job rates vary depending on many factors, not the least of which is the number of messages within the post office. Myriads of small files increase seek times and reduce overall job throughput. But, despite a lot of small files, my jobs average between 1,200 and 1,800MB/minute. It’s not blazing, but it gets the job done within the designated backup window.

One final note: When it comes time to restore, it is often desirable to restore to a different location. Looking at the BackupExec File Redirect option screen, it appears at first that it might only be possible to restore to CIFS based destinations because of the apparent use of UNC paths. But, this is not the case. If you click the browse button you will see that you can browse and select other RALUS agents as destinations for the restore.

The UNC path, shown above, will restore to the root of the file system on a SLES11 Linux machine with RALUS installed.

Update
Since this article was originally posted, Novell has released SP2 for SLES11. SP2 uses Linux kernel version 3.0 instead of the previous 2.6 kernel. BackupExec 2010 RALUS does not support or work with kernel 3.0. Newly released BackupExec 2012 is supposed to support Linux kernel 3.0, but I have not yet tested it. Either do not upgrade SLES11 to SP2 or upgrade BackupExec to version 2012.

Update
I missed an important issue with GroupWise backup time stamps. See this post for more details. GroupWise 2012 Backup Time Stamps