[ Meat n' Potatoes of this Article ]

1.Add additional GRE_BLOBS-Threads, up to 10 threads

2.NetWare customers consider enabling the NetWare NFS server, and modify the Reload profile to backup the GroupWise post office as if it is on a Linux server.

[ Increasing GRE_BLOBS-Threads for Backing up the OFFILES Directories ]

Because of a unique threading technology, Reload is the fastest backup solution available for GroupWise. How fast? you ask. Well for example; at the State of Utah, there is a GroupWise post office with 1,100 users on a 70 Gigabyte post office on a Linux server. Their nightly Reload backup times are just under 13 minutes. And remember, that because of Reload's unique architecture, each Reload Standard (Incremental) backup is effectively a Full Backup, which only takes about 12% of the size of the post office on disk.

You do have to do one thing to tweak Reload so that your Reload backups gain their fastest backup speeds.

When you modify a Reload post office profile, select:

Standard – Standard Backup (Incremental) Configuration Menu

BLOBS - Standard Backup BLOBS (OFFILES) Threads Configuration

There's a setting called “GRE_BLOBS-Threads” which is the key to faster backups.

The GRE_BLOBS-Threads by default are set to “2”. Most customers will want to set the GRE_BLOBS-Threads to “10”. Customers who probably do not want to modify their GRE_BLOBS-Threads are customers whose Reload backups are taking under 10 minutes as it is, or if the GRE_BLOBS sub-process of the Reload Backup Agent is already beating out the GRE_DBS sub-process. You can determine both of these bits of information by viewing the Event Log for a particular Reload post office profile. The Event Log is available from the Logs menu at the first screen you view when modifying/configuring a Reload post office profile.

The two main reasons I designed Reload not to use 10 threads by default are this:

1.For post offices that backup in less than 10 minutes, spinning up separate GRE_BLOBS-Threads may actually slow down the backup process.

2.Some customers are using Reload on workstation-grade machines. This is not a bad idea, however sometimes a workstation might have difficulty supporting too many threads. So I set the threads to the lowest common denominator so that Reload doesn't overwhelm a server that isn't prepared for Reload's unique threaded backup technology.

If your backup speeds are fast, or your are using a server that you suspect might become challenged by additional threads, you'll just have to experiment a bit by adding more GRE_BLOBS-Threads perhaps one at a time, and looking at the results of your test in the Reload Event Log.

[ For NetWare Post Offices Consider NFS instead of NCPFS ]

When you configure a Reload profile, it asks what server platform the post office is on. If the post office is on a NetWare server or cluster, then Reload uses the NCPFS software package that comes with the Novell/SUSE Linux platforms. The NCPFS package allows the Reload Backup Agent to get a NCP (NetWare Core Protocol) client connection to the NetWare server. However, it seems that the NCPFS client just isn't as fast as it's Windows counterpart.

Recently I was working with an integrator whose Reload backup times were just way too slow. I suspected that something just wasn't working right in the NetWare connection. And I remembered that another consultant I worked with a while back had made their NetWare server act as an NFS server, and then told Reload that the server where the post office resided, was a Linux server. Reload was none the wiser and it worked just fine. So we decided to give the NetWare NFS server a whirl. Here is the test results from the integrator:

---SNIP BEGIN---

> Here is the output of the speed tests:

From Linux to NW

NFS Write
> linux-reload:~ # mount
> mhtsl002:/DATA/APPS/GRPWISE/ on /mnt/nfs type nfs (rw,addr=10.10.40.8)
> MHTSL002/RELOAD.MHT on /mnt/ncp type ncpfs (rw)
> linux-reload:~ # dd if=/dev/zero of=/mnt/nfs/zeroes bs=1024k count=100
> 100+0 records in
> 100+0 records out
> 104857600 bytes (105 MB) copied, 10.3582 seconds, 10.1 MB/s
> linux-reload:~ # dd if=/dev/zero of=/mnt/ncp/APPS/GRPWISE/zeroes2 bs=1024k

NCP write
> count=100
> 100+0 records in
> 100+0 records out
> 104857600 bytes (105 MB) copied, 174.594 seconds, 601 kB/s

NFS Read
> linux-reload:~ # dd if=/mnt/nfs/zeroes2 of=zeroes2
> 204800+0 records in
> 204800+0 records out
> 104857600 bytes (105 MB) copied, 19.8013 seconds, 5.3 MB/s
> linux-reload:~ # dd if=/mnt/ncp/zeroes2 of=zeroes
> dd: opening `/mnt/ncp/zeroes2': No such file or directory

NCP read
> linux-reload:~ # dd if=/mnt/ncp/APPS/GRPWISE/zeroes of=zeroes
> 204800+0 records in
> 204800+0 records out
> 104857600 bytes (105 MB) copied, 254.211 seconds, 412 kB/s
> linux-reload:~ #
>

As you can see, NFS is significantly outperforming NCP, pointing to the fact that the NCP connection really is the bottleneck. The best part is that a NCP copy from is slower than a NCP write to.

The server in question is a NW6.0 When we tried a NW6.5 server we were seeing copy from speeds of ~1.2mB/s so there is certainly a significant difference in the performance between the versions. The NW6.0 and NW6.5 servers are on the same type of hardware and with the same amount of RAM.
---SNIP END---

Well I got to thinking, hey why not just tell everyone who wants to, just go ahead and configure NFS on the NetWare server as this integrator did, and see if it speeds up your Reload backups.

Re-configuring a Reload profile to use an NFS connection vs. an NCPFS connection is the easy part. Setting up NFS Services on a NetWare server in my experience has proven to be difficult in some environments. If it doesn't work right in the manner I explain in this article, then don't be surprised. I've been able to get six people to participate in the testing of a NetWare server as an NFS server. Four have succeeded, and two have not. So it may take some persistence to get the NetWare server to act as an NFS server. Please do not contact GWAVA support for help on how to set up the NFS services on your NetWare server, this is the kind of thing you call Novell or your local Novell integrator for.

I'll give some simple tips on setting up a NetWare server as an NFS server. There are probably some better ways of doing this, these are just the steps I used:

1.First, make a backup copy of the “exports” file in the sys:\etc directory of your NetWare server.

2.Edit the sys:\etc\hosts file by typing in the command from the NetWare console prompt:

edit sys:\etc\hosts

3.Go to the bottom of the hosts file and add the following line:

[ip address of the reload server] [a dns name for the reload server] [server short name]

For Example:

192.168.100.3 reload.www.com reload

NOTE: I didn't actually have to add the DNS name in my DNS, I just needed it in the hosts file in this manner.

4.Edit the sys:\etc\exports file by typing in the command from the NetWare console prompt:

edit sys:\etc\exports

5.Go to the bottom of the exports file and add the following line:

/[volume name]/[path to post office] -rw=[Reload DNS Address] -root=[Reload server's DNS Address]

Let's imagine your GroupWise post office is on a volume called “mail” and at the UNC path (without the server name): \mail\grpwise\corppo. Here is what you would type in

For Example:

/mail/grpwise/corppo -rw=reload.www.com -root=reload.www.com

6.Save the changes you've just made, and exit the exports file.

7.From the NetWare server console, type in the command:

load xnfs

NOTE: It is quite possible that you will get some kind of an error loading xnfs, and you will have to troubleshoot from there in order to fix the error. The NetWare NFS Server logs it's errors to the sys:\etc\nfs\xnfs.log file.

Once you can get the NFS server up and functioning, it gets really easy from there to get Reload to use the NFS export that you created.

Do the following to an existing Reload post office profile for a post office on a NetWare server:

1.Edit the Reload post office profile, and go to the Advanced menu.

2.Go to the “Connectivity” menu.

3.Change the server type to be a Linux server, and proceed through the wizard.

a. When you are asked for the export path, indicate the path in the following manner:

For example: /mail/grpwise/corppo

b. At the next screen indicate “Yes”, to indicate that the post office is directly off of the NFS Export Path.

c. Allow the profile to be tested, and make sure that it tests successfully.

4.That's it, going forward Reload will backup the post office using the NFS protocol, and when you load the Restore Mode POA, Reload will also use the NFS protocol.

[ Conclusion ]

I just heard from a customer yesterday that already had their GRE_BLOBS-Threads configured with 10 threads. However they just added NFS in the mix as explained in this article. Here are the statistics so far:

Profile 1: 40% Speed increase
Profile 2: 100% Speed increase
Profile 3: Speed decrease, going back to NCPFS
Profile 4: 50% Speed increase

[ Reload Technical Documentation ]