Information on how the new tsafs.nlm works with GroupWise backup restore enablegw=yes

Information on how the new tsafs.nlm works with GroupWise backup restore enablegw=yes

TSAFS detects the GW files and backs them up appropriately.

The TSAFS does not depend on or make use of the gwtsa.ncf file. The TSAFS knows nothing of what a GroupWise domain or post office is. The only think it knows how to recognize is an individual GroupWise database file. It does this through a combination of examining the file name and thesignatureof the file.

The TSAFS therefore does not display a 'domain' or 'post office' (or any other) type of GroupWise object or hierarchy like the GWTSA does. It simply knows how to deal with individual GW databases cooperatively with a live GW system.

Restoring GroupWise data with the TSAFS is the same basic procedure as with the GWTSA, but with some differences. The similarity is that one needs to restore the entire post office or domain directory to a different location than from where it was backed up (unless reconstructing from bare metal due to catastrophic, complete data loss, in which case it is appropriate to restore the image to the location it was backed up from).

The important detail to remember about restore is that you should never restore backed-up GroupWise databases over the top of existing live GroupWise databases.See In-Place restore for more info.

The GWTSA and TSAFS differ in the procedure used to restore to a different location from where the files were backed up. For the GWTSA, the user needs to add a /home switch in the gwtsa.ncf file so that an additional [TMP] object appears on the list of resources recognized by the GWTSA. This [TMP] object is the restore target directory, where the backed-up data is redirected to during the restore.

The procedure for doing the same redirect with the TSAFS is simpler. Since the TSAFS already deals directly with files and directories, it need only be instructed to redirect the backed-up files to a different directory during the restore. The 3rd party backup software provides the mechanism that the backup administrator uses to configure the restore area, and passes that information along to the TSAFS.

Introduction:

Backing up GroupWise databases using GWTSA needed a certain configuration to be made on the server side. These configurations ensured the backup and restore are preformed properly. GWTSA didn't employ any performance modeling, which made the GWTSA not perform as the file system did. To overcome this the file system TSA (TSAFS) is now enabled to backup the GroupWise database so that the GroupWise database backup can leverage the performance benefits that the file system TSA (TSAFS) provides. To enable the file system TSA to backup or Restore GroupWise database, the TSAFS should be loaded with the following switch

load tsafs.nlm /EnableGW=yes

This would enable the file system TSA to recognize the GroupWise database and perform a consistent backup of those live databases. Due to the multi-threaded nature of the TSAFS backup process model, the performance of GroupWise is better. This switch is load time persistent and needs to be done only once.

Backup:

When the TSAFS is loaded with /enablegw=yes switch, TSAFS internally recognizes the GroupWise databases. This eliminates the need to perform any configuration as was the case with the older GWTSA. Though the TSAFS doesn't provide a hierarchical view of the GroupWise domain or post office, it can internally recognize those and back them up on a live GroupWise System. There are certain GroupWise files that are intentionally skipped during the backup because they're unneeded/temp or in use files:

- agent log files (example: 1028mta.001 and 1028poa.001)
- gwcache.db (WebAccess document management cache database)
- xNStore files (transitory files used by the GroupWise agents)
- proc and pulse.tmp files
- QuickFinder indexes and incrementals (.idx and .inc files) which are being updated during the backup
- files in OFFILES that are being written during the backup
- Files in the WSPCSOUT and WSPCSIN directories

Restore:

In-Place restore:

Restoring the backed up GroupWise database to the same location where the live GroupWise database is running is NOT recommended, unless the administrator is rebuilding the whole GroupWise system because of unforeseen situations like catastrophic complete data loss. The problem is that the GroupWise database will be brought back to the state it was in when backed up which will cause the loss of any current database changes, unless the changes are also backed up and restored. This doesn't need any configuration with TSAFS, as in GWTSA, except that the TSAFS should be loaded with the /EnableGW=yes switch.

Out-of-Place restore:

In the case of GWTSA the /Home directory configuration is to be made in the gwtsa.ncf file, but such configuration is not necessary in TSAFS. Since TSAFS by default exhibits a file system nature, a simple rename restore (different location) should do. Most of the Third party engines allow restore of data to a different location, this instructs the TSAFS to perform a out-of-place restore and the change in volume/path etc is taken care by the TSAFS internally.

Lost user emails are recovered using the Out-of-Place restore in conjunction with the 'Restore Area' in ConsoleOne and the File|Open Backup menu item in the GroupWise client. When an entire user account is deleted, Out-of-Place restore is also used, and ConsoleOne is used to restore the user account.

Limitations:

1. Hierarchical display of GroupWise Domain/post office is not currently available, since TSAFS deals with file/directories.

2. TSAFS.NLM dated 10/18/2004 and above has the /EnableGW switch present, that enables consistent GroupWise database backup. (TSA5UP16.EXE)

.
When loading GroupWise in protected memory it is necessary to load a separate instance of the Gwenn4.nlm to address space 0 for the TSAFS to work. This can be done by adding a Gwenn4.nlm load statement to the Resource load script.

Formerly known as TID# 10095865