This section provides information on how SMS backs up data from eDirectory and from the file system.
Meet the following prerequisites before starting the backup software.
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 servers.
All POSIX* compliant file systems on ReiserFS, Ext2, Ext3, and XFS file systems OES servers, see Section C.0, POSIX File System Support.
NSS file system and associated metadata on OES 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.
NOTE:SMS now supports backup of Active Directory trustees on an AD-enabled NSS volumes.
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 servers. It supports backup of hard links on the NSS file system on OES 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 on Linux POSIX file systems. These volumes contain additional metadata for files and directories as compared to normal POSIX compliant file systems.
TSAFS supports backup and restore of additional metadata for files and directories under NCP 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 Client libraries.
For information on setting up NCP volumes and the NCP metadata on them, see Managing NCP Volumes
and Managing File System Trustees, Trustee Rights, and Attributes on NCP Volumes
in the OES 23.4: NCP Server for Linux Administration Guide.
NOTE:When the backup of cluster NCP POSIX Volumes is in progress, the cluster resource goes comatose when it is migrated or failed over to another node.
NCP server for Linux allows administrators to create shadow volume pairs by using two NSS volumes as the primary volume and the secondary volume. The metadata on each volume is the same as for independent NSS volumes. When the DST volume is mounted, the secondary volume is mounted in Linux but is not mounted in NCP. This allows the secondary volume to be visible to backup software even though users do not directly access the files.
You must separately back up the primary volume and the secondary volume to back up the files and directories on them. Backup tools can apply one backup policy to the primary file tree and a different backup policy to the secondary file tree. The only operations that take place on the secondary volume are backup, or remove and archive.
For information about backing up the primary NSS volume and secondary NSS volume in a DST volume, see Using Backup Utilities with DST Shadow Volume Pairs
and Backing Up DST Shadow Volumes
in the OES 23.4: Dynamic Storage Technology Administration Guide.
OES 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 OES 23.4: OES Cluster Services for Linux Administration Guide.
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, it is possible to have mixed node clusters, where different nodes in the cluster run NetWare or OES. For more information regarding mixed node clusters, see the OES 2015 SP1: Novell Cluster Services NetWare to Linux Conversion Guide.
TSAFS supports mixed node cluster backup. Path names are represented differently on NetWare and OES servers. In order to achieve a consistent backup, TSAFS supports a NetWare emulation mode on an OES 2018 or later server. This mode is used to make TSAFS behave as a NetWare target on OES 2018 or later server. 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
To autoload the TSAFS settings, perform the steps mentioned in the section Autoloading the TSAFS Settings.
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
To autoload the TSAFS settings, perform the steps mentioned in the section Autoloading the TSAFS Settings.
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.
To autoload the TSAFS settings, perform the steps mentioned in the section Autoloading the TSAFS Settings.
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 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.
To autoload the TSAFS settings on OES Linux, perform the steps mentioned in the section Autoloading the TSAFS Settings.
To make the TSAFS settings persistent, perform the following steps:
Go to the file /etc/opt/novell/sms/smdrd.conf.
Modify the line autoload: tsafs to read as autoload: tsafs --filename
For example, Modify the line autoload: tsafs to autoload: tsafs --EnableGW --noCachingMode.
Restart novell-smdrd using rcnovell-smdrd restart or systemctl restart novell-smdrd.service command. This command shuts down and restarts the smdrd daemon.
Wait for few seconds and then issue smsconfig -t command. The following is displayed:
The loaded TSAs are, tsafs --filename. For example, autoload: tsafs --EnableGW --noCachingMode.