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 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:
Users performing backup need to be LUM enabled.
Load the controller and storage device drivers on the backup server.
Load the SMDR and TSAs on the backup and target server.
See 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 2 Linux servers.
All POSIX* compliant file systems on ReiserFS, Ext2, Ext3, and XFS file systems OES 2 Linux servers, see Section C.0, POSIX File System Support.
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 information, see 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.
TSAFS supports backup of hard and soft links when backing up POSIX compliant file systems on OES 2 Linux servers. It supports backup of hard links on the NSS file system on OES 2 Linux servers.
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 volumes and Dynamic Storage Technology (DST) shadow volumes on OES 2 Linux. These volumes contain additional metadata for files and directories as compared normal POSIX compliant file systems.
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 secondary volume to back up the files and directories on it.The secondary volume can be backed up independently of the primary volume.
For information on setting up NCP volumes and the NCP metadata on them, see Using Backup Utilities with DST Shadow Volumes
in the OES 2 SP3: NCP Server for Linux Administration Guide.
DST shadow volumes use NSS file system volumes, so their metadata is the same as for NSS volumes. For information about backing up shadow volumes, see OES 2 SP3: Dynamic Storage Technology Administration Guide
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 cluster migration 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, see 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.
During a rolling cluster conversion from NetWare to OES 2 Linux, it is possible to have mixed node clusters, where different nodes in the cluster run NetWare or OES 2 Linux. For more information regarding mixed node clusters, see the OES 2 SP3: Novell Cluster Services NetWare to Linux Conversion Guide.
TSAFS supports mixed node cluster backup. Path names are represented differently on NetWare and OES 2 Linux. In order to achieve a consistent backup, TSAFS supports a NetWare emulation mode on OES 2 Linux. This mode is used to make TSAFS behave as a NetWare target on OES 2 Linux. This resolves any path name conflicts that might arise because of mixed node clusters in the setup. To enable this feature, see the NetWare Emulation Mode.
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. TSAFS is integrated with GroupWise 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:
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:
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 information on codesets, see the tsafs(1) man page.
TSAFS by default exposes the 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 2 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 targets. In netware mode, the TSA displays only NetWare File System targets. 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.