1.2 SMS Components
In order to achieve full functionality, SMS is implemented as two independent components that provide the following functional abstractions:
-
Storage Management Data Requester (SMDR) provides remote connectivity and transfers data between the target and the backup servers.
See Section 1.2.1, Storage Management Data Requester for more information.
-
Target Service Agent (TSA) provides abstraction details of the specific target being backed up.
See Section 1.2.2, Target Service Agent (TSA) for more information.
The backup process is explained below:
-
A typical backup involves the backup application using the SMDR on the backup server to communicate with the target server. The SMDR on the target server uses a TSA to read and abstract the target data.
-
The backup application uses a formatted buffer delivered by the TSA and the SMDR to send it to a storage medium such as a tape drive.
-
Every target server needs to have its own TSA that understands the target-specific objects. If a new target needs to be backed up, only a new TSA needs to be added and the entire backup infrastructure can be reused.
1.2.1 Storage Management Data Requester
The Storage Management Data Requester (SMDR) is the communication module in the SMS architecture. The SMDR defines the API framework, provides remote connectivity, and abstracts the details of any communication between the servers. Thus, SMDR is capable of transferring any target data between the target and backup server. Most backup applications use the API exposed by SMDR to make use of functionality exposed by SMS. For information on configuring SMDR, See Section 3.4, Configuring SMDR.
1.2.2 Target Service Agent (TSA)
The Target Service Agent (TSA) provides an implementation of SMS APIs for a particular target. The TSA provides transparency by abstracting details of the specific service (such as GroupWise or NSS) being backed up. For example, various backup applications use file system TSA to back up and restore NSS file system data and metadata (trustee assignments, namespaces, and file attributes). A TSA understands the target and knows how to scan, read, and write a particular target’s data. Each target needs a TSA.
Table 1-1 Target Services and Their Corresponding Target Service Agents in OES 2 Linux
|
Target Service |
Target Service Agent |
|---|---|
|
NSS file system |
TSAFS |
|
Cluster resources |
TSAFS |
|
VFS-compliant file systems |
TSAFS |
|
eDirectory |
TSANDS |
|
GroupWise |
TSAFS |
|
TSAFSGW |
|
iFolder |
TSAIF |
-
TSAFS backs up a target server, so it services all file systems (and possibly cluster resources) on a particular target server.
-
GroupWise backup functionality is included with the file system TSA.
However, the functionality does not provide object level backup, but simply ensures that GroupWise database backups are consistent by freezing the GroupWise database before a regular file system backup. This functionality is not turned on by default. See File System TSA (TSAFS) to turn on this functionality as required.
File System TSA (TSAFS)
The File System TSA (TSAFS) supports all VFS-compliant file systems and NSS. Some of the salient features are:
-
Implements a predictive data caching model that provides improved backup performance.
-
Provides parameters to fine-tune performance.
-
Provides parameters that can be used to fine-tune performance to the specific environment.
-
Ability to interpret OES 2 Linux data streams.
-
Cluster enabled.
-
Multiprocessor enabled.
-
Compatible with the data format used by existing versions of the TSA.
-
Ability to ensure consistency while backing up GroupWise databases.
-
Provides a NetWare emulation mode.
-
Ability to handle data across locales by providing data in UTF-8 format.