Backing up an NFS Gateway volume: Not a recommended or supported strategy.

  • Document ID:7003233
  • Creation Date:07-May-2009
  • Modified Date:26-Apr-2012
    • Micro Focus Products:
      NetWare
      NFS Protocol

Environment

Novell NetWare 6.5
Novell NFS Gateway for NetWare 6.5

Situation

Doing a typical NetWare-style backup of an NFS Gateway volume is not a recommended or supported strategy, as it is not possible to do a true, full backup of the data using this method.

Resolution

Data should be backed up natively from the file system which actually holds the data.  This is the only way to ensure a true backup.

If it is desired to backup the NetWare trustee rights that have been assigned to a NFS Gateway volume, the easiest approach would be to make backups of the NFS Gateway shadow files which store that information.  These files are stored by default in various subdirectories under SYS:\GATEWAY\  or in another <vol>:\GATEWAY\, as set in the NFS Gateway volume configuration.  This will also hold other Netware-specific meta data, like file attributes, LONG name space, etc.  Most of this information is easily replaced / rebuilt, but trustee assignments are sometimes numerous and tedious to replace.

An alternative method of using TRUSTBAR.NLM for backing up and restoring trustee rights is discussed in the NFS Gateway on-line doc, section 5.0 and 5.1.   See https://www.novell.com/documentation/nfsgynw65/index.html

Additional Information

Novell does not recommend backing up an NFS Gateway volume as a strategy for safeguarding data.  This is because the true file contents and true meta-data do not exist on the NFS Gateway system.  Rather, they exist on a remote system which is accessed via the NFS protocol.  Novell will not support the use of backup software on an NFS Gateway volume.  Some of the concerns regarding backups of a NFS Gateway volume are discussed here:
 
A lot of backup software uses "dirty" (nonstandard) methods to get more complete access to the file system than would be normally allowed.  These methods often do not function well on an NFS Gateway volume.  While NFS Gateway volumes appear, for most purposes, just like any another NSS volume, they are considerably different.

Backing up files through NFS Gateway will backup the files according to the NetWare virtual meta-data.  This does not necessarily preserve the original names or attributes of the files.  For example, Unix and Linux file systems typically allow characters which LONG and DOS name space do not allow.  Therefore, if a NFS Gateway volume is backed up and later restored, the resulting file names on the Unix or Linux hosts which really holds the files will be a translation of the original names, rather than the actual original names.

The remote file system's native meta-data, such as the user and group ownership and permissions, are stored only on the remote host, so they are not backed up through NetWare backup methods.
 
The archive bit, on which many NetWare backup packages rely, is not a reliable indication of whether a file on an NFS Gateway volume needs to be backed up.  Since the file does not really reside on NetWare, the remote system could change the file without the NetWare archive bit being reset.

In error conditions, NFS Gateway may not show all files the really reside on the remote NFS Server.  Errors occurring during the remote operations could artificially truncate directory listings.  Backups could therefore be incomplete, without an error being passed between NetWare OS and the backup software.

Similar to all NFS client implementations, because the imported file system does not reside locally on the NetWare, cache inconsistency issues could exist for both data and meta-data.

Formerly known as TID# 10100093