This section provides information on how SMS backs up data from Novell®eDirectory™ and from the file system.
Meet the following prerequisites before starting the backup software.
TSAFS supports backing up open files on Novell Storage Services (NSS) volumes if the CopyOnWrite feature is enabled.
To enable CopyOnWrite on a single NSS volume, see Appendix A, File-Level Snapshot Commands in the OES 2: NSS File System Administration Guide. Supervisor rights are required to back up the open files.
When you perform a backup, you need to decide whether to keep compressed files in the same state or back them up in a decompressed state.
Listed below are few guidelines to make this decision:
Backups are faster if files are in compressed form. If volume compression is turned on and you back up compressed files in a decompressed state, restore speed is degraded when existing files are overwritten.
Compression is not supported in some environments (such as a NetWare® 3.11 server or Novell® Storage Services™ 2.0). If you intend to restore a file that is currently compressed to an environment that does not support compression, back it up in a decompressed state.
You might run out of disk space if you restore decompressed files to a volume, because the compression does not begin immediately.
Files that are not frequently accessed can be moved to tertiary storage by any Hierarchical Storage Management software (HSM Software). These files continue to be available in the form of stubs in the primary storage device. The stubs contain information necessary to access the file contents from the tertiary storage using the HSM software.
During backup it is possible to back up these files in the following manner:
Back up only the stubs
Back up both the stubs and the data associated with the file
If the tertiary device itself is backed up independently, choosing to back up only the stub information helps reduce the amount of data. This, in turn, helps save space on tape and increase backup performance because data does not need to be restored from the tertiary device during backup. However, restores require the HSM software to be set up and ensure tertiary storage associations are maintained as they were during the backup.
When both the stub and the data are backed up, the data is restored for the backup process. On restore, either the stub or data or both can be restored. However, backing up migrated file data can impact the backup performance because the data needs to be demigrated from a tertiary storage device. In addition, the backup would include both the target server as well as the tertiary storage data, which requires adequate planning for tape storage.
Before starting the backup process, you need to perform the following tasks:
Load the controller and storage device drivers on the backup server.
Load the SMDR and TSAs on the backup and target server.
Refer to the Section 3.3, Starting SMS Services for information on how to start SMS services.
To back up file system data, TSAFS must be loaded on each target server for which a backup is to be created (see Before Running the Backup Software).
TSAFS supports backing up:
File system metadata such as name spaces, extended attributes, trustee rights, and data streams on OES.
All POSIX* compliant file systems on ReiserFS, Ext2, Ext3, and XFS file systems OES Linux, see Section C.0, POSIX File System Support in OES Linux.
NSS file system and associated metadata on OES Linux which are not available through POSIX interfaces.
TSAFS uses the ECMA SIDF standard format to store the file system data. For more information, refer to the Standard ECMA-208 Web site).
This section discusses the following:
Trustee assignments are stored as part of the file system as an Identifier (ID).
TSAFS uses these IDs to determine the respective fully distinguished names (FDN) and backs up the FDNs. This allows trustees assignments to be restored even if a particular user object was deleted and re-created which would cause the ID to be different. Even if the User object is deleted and re-created with a new ID, the user’s trustee assignments in the file system are restored using the FDN.
For additional information about object ID and trustee issues, see Restoring Trustee or Owner Assignments.
Server-specific information such as the replica information, ID information, name spaces loaded, and system configuration is stored on the SYS volume. This information is backed up as part of the file system as a single resource. This resource includes the following five files:
servdata.nds contains server-specific eDirectory™ data.
dsmisc.log contains the replica list and replica types on the backup server during backup.
startup.ncf contains the disk driver, name spaces, and SET parameters.
autoexec.ncf contains load modules and the server configuration.
vol$info.txt contains volumes on the server, name spaces loaded, compression, and migration information.
The server-specific information does not need to be restored unless you have lost the SYS: volume.
TSAFS supports backup of hard and soft links when backing up POSIX compliant file systems on OES Linux and it supports backup of hard links on OES 2 NetWare and OES 2 Linux.
In the case of hard links, a file is backed up for each instance of a hard link. TSAFS provides an option for backup applications that backs up the file data for only the first instance of the hard link and maintains stubs without backing up file data for subsequent instances. For a successful restore, ensure that the restore includes the first instance.In the case of soft links, TSAFS backs up soft link information and also data indicating which file it is linked to. If the backup definition does not include the linked file, then the file's data is not backed up.
NCP™ server for Linux allows administrators to create NCP and Dynamic Storage technology volumes on OES Linux. These volumes contain additional metadata for files and directories as compared normal POSIX compliant file systems.
For more information on setting up NCP volumes, Dynamic Storage Technology volumes and metadata maintained by the same, refer to the OES 2: NCP Server for Linux Administration Guide.
TSAFS supports backup and restore of additional metadata for files and directories under NCP and Dynamic Storage Technology volumes. When backing up an NCP volume file or directory, trustee assignments and inherited rights filters for the data set is additionally backed up using the Novell client libraries.You must backup the shadow volume to back up the migrated files and directories.The shadow volume can be backed up independent of the primary volume.
Novell Cluster Services™ is a server clustering system that ensures high availability and manageability of critical network resources including data (volumes), applications, and services. It is a multinode clustering product for OES that is enabled for eDirectory and supports failover, failback, and migration (load balancing) of individually managed cluster resources. For more information, see the Novell Cluster Services documentation.
For a cluster to work as a high-availability system, the file system, the applications, and services that run on the cluster should be cluster-enabled. SMS supports backup and restoration of cluster-enabled resources. In addition, the backup session can be automatically recovered in case of a failover or failback of the target cluster-enabled resources, if the backup application supports it.
Consider the following before preparing for backup and restoration of cluster-enabled resources. These conditions are applicable only if the backup application is cluster-enabled.
If cluster-enabled resources are to be backed up or restored, SLP should be used as the discovery mechanism.
A cluster node will have clustered and one or more non-clustered volumes. When the particular cluster server is chosen for backup, only the clustered volumes will be listed. To backup non-clustered volumes, choose the physical server instead.
HINT:To treat all cluster volumes as non-clustered for backup, disable the cluster option in TSAFS, refer to Section 3.5, Configuring the Target Service Agent for File System. This will enable listing of all cluster volumes as part of the cluster node instead of virtual server resource.
NOTE:Backup and restoration of cluster-enabled resources is not supported in NetWare versions earlier than NetWare 6.
In OES, it is possible to have mixed node clusters, where different nodes in the cluster may run either OES NetWare or OES Linux. For more information regarding mixed node clusters, refer to the OES 2 SP1: Novell Cluster Services 1.8.5 for Linux Administration Guide.
TSAFS supports mixed node cluster backup. Path names are represented differently on OES NetWare and OES Linux. In order to achieve a consistent backup, TSAFS supports an NetWare emulation mode on OES Linux. This mode is used to make TSAFS behave as a NetWare target on OES Linux. This resolves any path name conflicts that might arise because of mixed node clusters in the setup. To enable this feature, refer to the NetWare Emulation Mode on OES Linux.
This section describes additional features supported by TSAFS:
The default apparmor profile opt.novell.sms.bin.smdrd is available in /etc/apparmor/profiles/extras/ folder. The profile contains all permissions to the paths and libraries and permissions that smdr requires during its execution. The profile contains the rw permissions to the file system root(/)to enable the backup of any path on the file system. You can modify the profile as per your security requirements. On modifying the profile, reload Apparmor with the rcapparmor command.
TSAFS supports backing up GroupWise® database files from the OES. TSAFS is integrated with GroupWise on OES NetWare and OES Linux to provide consistent backups of GroupWise database files by locking them before a backup is taken.
NOTE:This feature ensures that a snapshot of the GroupWise database files are consistent are backed up. This backup cannot be used to restore GroupWise objects such as a particular mailbox or a user object.
To enable the GroupWise backup feature in TSAFS, use the following switches:
For OES NetWare use:
For OES Linux use:
smsconfig -l tsafs --EnableGW
TSAFS by default uses a predictive caching mechanism to cache ahead data sets for backup operations. Some backup applications process incremental or differential backups by filtering the data sets themselves rather than use TSAFS options. Under such circumstances the cache built up by TSAFS is not used. This leads to slower backups as TSAFS spends more time caching unwanted data sets.
The non-caching mode of operation disables TSAFS predictive caching thus eliminating any performance issues when used with applications that do their own filtering.
To enable the non-caching mode of operation in TSAFS, use the following switch:
For OES NetWare use:
For OES Linux use:
smsconfig -l tsafs --noCachingMode
By default, TSAFS assumes that filenames on the disk are UTF-8 encoded. If they are not, TSAFS skips these files and reports them in the skipped data set log. In such cases, the following switch can be used to set the appropriate code set for backup and restore:
smsconfig -l tsafs --useCodeSet=codeset
For more information on codesets, refer to the tsafs(1) man page or in the SMS man Pages section, view the HTML version of the man page.
TSAFS on OES Linux, by default, exposes Linux File System as the target. TSAFS has a built-in switch that makes it possible to expose the TSA as a NetWare File System. This enables you to use TSAFS on OES Linux as if it is a NetWare target.
NetWare emulation mode can be turned on using:
smsconfig -l tsafs --tsaMode=mode
where mode is linux, netware, or dual. In linux mode, the TSA displays only the Linux File System target. In netware mode, the TSA displays only NetWare File System target. In dual mode, both the targets are displayed.
When connected to the NetWare File System target, you can see only NSS file system resources.
NOTE:NetWare Emulation mode is intended to provide a migration path for applications that are already NetWare-aware and might be deprecated in the future. However, all backups taken using the NetWare emulation mode will be valid and recoverable in all future releases.