Storage Management Services (SMS) allows you to back up SMS targets such as eDirectoryTM, the file system, cluster-enabled pools, or hard disks on individual workstations to media such as a tape drive for off-site storage, and gives you a periodic view (daily, weekly, monthly) of your data. Then in case of hardware failure, natural catastrophe, corrupted data, or incorrectly deleted or changed data, you can retrieve a previous version of the data.
Backup services provides information on supported devices, the SMS architecture, memory requirements, types of backup offered, customizable options, schedules, how to back up eDirectory, how to back up the file system (both traditional NetWare® file system and Novell Storage ServicesTM), how to back up cluster-enabled pools, and how to use Target Service Agents (TSA).
The following topics are discussed in this section:
Storage Management Engine (SME) for backup and restore operations. Novell provides the SBCON utility as a basic SME for NetWare.
See Storage Management Engine (SME) for more information.
Storage Management Data Requester (SMDR) for passing communication between the backup program (see Storage Management Data Requester) and the TSA software (see Target Service Agents (TSAs).)
Storage device interface is used to pass information between the SME and the storage device.
Device drivers are used to control the behavior of the storage devices.
Target Service Agents (TSAs) pass requests and commands between the SME and server or eDirectory database, and prepare the data for the SME. TSAFS.NLM must be loaded on the server where the data is to be backed up.
NOTE: The TSA600 has been replaced by TSAFS. From this release onwards, we'll will not be supporting TSA600.
See Target Service Agents (TSAs) for more information.
TSAProxy is used to register the workstation with the host server. TSAProxy also identifies and keeps track of the stations waiting to be backed up. It receives I am here messages from workstations available to be backed up. The TSAProxy keeps the names of these workstations in an internal list and displays the list, allowing you to select a target for a backup or restore procedure.
The SBCON process involves two machines:
SBCON can also be loaded and used on one machine.
SBCON uses an application on the host server to communicate with modules on target devices. The application reads the information from the target device and sends it to a storage medium, such as a tape drive.
SBCON supports 0.25-inch, 4mm, and 8mm storage devices. If you are using 4mm tape, use only DDS (Digital Data Storage)-certified, computer-grade tapes.
IMPORTANT: To ensure reliable operations, pretest all media storage devices that are not Novell certified with the appropriate NetWare device driver and SBCON backup and restore utility.
Use the driver files recommended by your hardware manufacturer.
The Storage Management Engine (SME) is central to the SMS architecture. The SME communicates with the network clients to back up and restore information.
SBCON has three modules:
Q Manager facilitates multiple job scheduling plus other features. Loading Q Manager automatically loads the backup engine. The user interface can be loaded after you load the Q Manager. See Setting Up for information on Q Manager.
The Storage Management Data Requester (SMDR) is the communication module in the SMS architecture. It provides transparent access to SMS services in an intranet as it allows access to local or remote SMS services. The SMDR APIs are used by SBCON and other third-party applications as well. SMDR uses TCP Port Number 413.
The features of the SMDR 6.00 include the following:
Protocol Independence: SMDR 6.00 is protocol independent and does not depend on Sequenced Packet ExchangeTM (SPXTM) or Internetwork Packet ExchangeTM (IPXTM) protocols. From NetWare 5.1 onwards, the requester also uses TCP/IP for communicating with other SMDRs. Although SMDR 6.00 can be configured to support TCP/IP, SPX/IPXTM, or TCP/IP and SPX/IPX, both protocols are supported by default. SMDR versions prior to 5.00 use the SPX protocol.
If cluster-enabled pools are to be backed up or restored, use SLP as the discovery mechanism.
The protocols can be specified in the configuration file, SMDR.CFG (see Using the SMDR Configuration File for more information).
NDS Registration and Name Resolution: SMDR creates an SMS Remote Procedure Call (RPC) object in eDirectory. The default tree of the server (the tree in which the server is present) is used for eDirectory registration.
The SMS RPC object is defined with the following attributes:
The SMDR creates an instance of this RPC class at the SMDR Context location in the server's default tree. The SMDR Context is specified in the SMDR.CFG file, which can be edited at any given time.
Multiple SMDRs are grouped together to reduce the search scope in eDirectory. A SMDR Group object defines this search scope. This group represents an instance of a predefined group class in the eDirectory schema. Any number of such groups can exist in eDirectory. The SMDR can become a member of one or more groups by registering its object's (SMS RPC object) context.
When SMDR requires name resolution, it searches all members of the SMDR Group at SMDR Group Context. The SMDR Group Context and SMDR Group are specified in the SMDR.CFG file.
Discovery and Name Resolution Using SAP: SMDR can be configured to use Service Advertising Protocol (SAP) for locating other SMDRs in an IPX environment. Each SMDR advertises the server name where it is loaded using service type 0x23F. But in an IP environment, NDS and Service Location Protocol (SLP) replaces SAP.
Discovery and Name Resolution Using SLP: SMDR can be configured to use Service Location Protocol (SLP) for locating other SMDRs. This enables SMDRs to locate other SMDRs running on servers that belong to different trees. Every SLP enabled SMDR will register itself in the smdr.novell domain when loaded. The SLP enabled SMDRs will query this domain for locating registered SMDRs.
Name Resolution Using HOSTS File:SMDR can also be configured to use the SYS:\ETC\HOSTS file for IP name resolution. It enables SMDR to do name resolution along with SLP and NDS mechanisms.The HOSTS file is automatically installed in the SYS:\ETC directory when you install TCP/IP.
Name resolution using HOSTS file and the discovery and name resolution mechanisms are enabled by default.
The SMDR.CFG file is a text file located in the SYS:\ETC\SMS\ directory on your server.
You can modify the configuration file from the command prompt by entering:
LOAD SMDR NEW
The SMDR Configuration screen is displayed where you can make the required modifications.
If you try to load SBCON when you have not set the SMDR on a server with the corresponding eDirectory objects and configuration, SBCON will autoload the SMDR and prompt you for configuration information. (This screen is hidden by the SBCON screen). To rectify this problem, press Alt+Esc to allow the SMDR to complete its setup before loading SBCON.
If NetWare Common Install is used to install SMS (see Customizing the NetWare Server as the Backup Server for more information), this problem will not occur. If the SMDR is explicitly loaded for the first time, the screen for configuration information will not be hidden.
To run SBCON, the host server requires the following:
If 3 MB of memory is not available, try setting the storage buffers lower than the default and still run SBCON.
Each backup session produces three types of files:
Log files are produced by the engine during backup and restore. Log files are placed in a directory on the host server and accessed through the SBCON Main Menu or from a Windows* 95, 98, 2000 or Windows NT* workstation using NWBACK32.
Error files are produced by the engine while backing up. Error files are placed in a directory on the host server and accessed through the SBCON Main Menu or from a Windows 95, 98, 2000 or Windows NT workstation using NWBACK32.
Both log and error files contain information such as the date, time, and media identification for a session. But the error file also contains a list of any errors that occurred during the backup session, such as files that were not backed up (see Log and Error Files for more information on these files). The log and error files are labeled with the same description you give the session.
SBCON has three types of backup sessions:
Full backup---Backs up the entire file system of the selected target regardless of whether the data has changed since the last backup, and clears the Modify bit after the backup.
Differential backup---Available only for the file system; backs up only data that has been changed since the last full or incremental backup. When you perform a differential backup, the modify bit is not cleared after the backup. All files modified since the last full backup are included in the backup (unless they have been deleted). Each differential backup uses more media and is slower than an incremental backup because it backs up more files.
IMPORTANT: Do not interchange differential backups and incremental backups. If you do, the differential backup will not contain all changes since the last full backup. Use full backups interspersed with differential backups or full backups interspersed with incremental backups.
Incremental backup---Available only for the file system; backs up only data that has been changed since the last full or incremental backup (whichever was last). Incremental backup sessions back up only files that have the modify bit set (that is, files that changed since the last full or incremental backup session when the modify bit was cleared).
All backup types contain advanced options to allow you to customize your backup. These options allow you to
You can choose specific subsets of a data set to exclude from or include in the backup session by selecting major resources, such as volumes, files, directories, or path.
See Scan Data Sets.
Whenever you perform a custom backup or restore, you can use the exclude and include options to select subsets of what you want to back up.
Whether you use exclude or include usually depends on the size of the data you want to back up, compared to the size of the data you do not want to back up.
To back up most of the file system structure or eDirectory tree structure while omitting only a small part, use the exclude option to omit the part you do not want to back up. Everything that you do not specifically exclude is included.
After you exclude part of the structure such as a volume, directory, or container, you cannot include any subdirectories, files, or objects beneath that excluded volume, directory, or container.
To back up a small part of the file system structure, use the include option to specify the data you want. Everything you do not specifically include is excluded.
When you select only part of the file system structure to include (such as a volume), all directories, subdirectories, and files under that selection are included in the backup by default.
In the figure given below, volume SYS: is selected as an include option. All other areas of the file system structure are excluded from the backup. You can exclude some subdirectories or files beneath your selection if necessary.
The same principle applies when you specify a directory with the include option. The figure below shows that all directories, subdirectories, and files under the NetUsers directory are included in the backup. All other areas of the file system structure are excluded from the backup.
The reverse is true when you select a major TSA resource, a directory, or a file as an exclude option. All other areas of the file system structure are included in the backup.
By combining the include and exclude options, you can control what is backed up.
For example, the following command sequence results in volume HOME being included in the backup with the exception of the MARY directory and the WIDGET.EXE file.
Include major TSA resources HOME:
Exclude directories (full path): HOME:NETUSERS/MARY
Exclude path/files HOME:NETUSERS/KARL/PROJECT/WIDGET.EXE
You can specify a different type of data set to be scanned.
A data set is a group of data that can be manipulated by SBCON. Each data set in the file system structure can be classified as a parent or a child, and each class includes different types of data items.
Within SBCON, a parent might be a server, eDirectory, a volume, or a directory. A child is a file, which is the lowest level of the directory structure.
The unit below a parent is not necessarily a child; it might be another parent, or the line might end with the parent. The unit above a child must always be a parent.
Items in a data set for either a parent or child should be items that do not frequently change. You might choose to exclude from the backup session one or more items in the data set of your target.
SBCON allows you to overwrite all existing parents or children. Children can be overwritten only if the date on the data set on the hard disk is more recent than the date of the data set backup.
Keep a hard copy log of your backups in case your online log and error files become corrupted. The log should contain the following information:
Before you begin backup procedures, plan a backup schedule based on your needs. Consider such factors as the number of users and frequency of changes to files.
You can perform different types of backups on different schedules:
Daily---Perform an incremental or differential backup after the close of business. If revisions are heavy and rapid, consider several backup sessions each day.
Weekly---Perform an incremental or differential backup after the close of business on the last day of the week for three of the four weeks in the month.
Monthly---Perform a full backup on the last business day of the month (for example, the last Friday).
Major changes---Perform a full backup before and after you change your configuration, and before and after you upgrade your server to a new version of NetWare.
Application changes---Perform a custom backup before and after you modify applications.
Careful planning can help you minimize the impact of data loss. Before you back up, consider the following:
TSAFS.NLM supports backup of open files on Novell Storage Services (NSS) volumes if the CopyOnWrite feature is enabled.
To enable CopyOnWrite on a single NSS volume, do the following:
Continue with the next sections to prepare for the backup session.
Each type of backup has a different effect on the backup and restore process. When planning your backup schedule, consider all of the following variables before determining which schedule is right for you.
Media usage and backup speed. This helps increase the speed of the restore.
Restoring after incremental backups. If you have performed full and incremental backups and need to restore data, you must restore the last full backup as well as all subsequent incremental backups.
Restoring after differential backups. If you have performed full and differential backups and need to restore data after an unexpected loss, restore only the last full and differential backup.
The best way to protect your eDirectory database is to use replicas. Replication, however, is not sufficient protection for a single server network or when all copies of the replicas are destroyed or corrupted. In these instances, if the eDirectory data has been backed up regularly, the eDirectory tree structure can be restored using SMS.
You can back up the entire tree or a selected section of the tree starting with a particular container. You can back up the schema and schema extensions. Trustee assignments are backed up as part of the file system.
You cannot back up partition information. If the eDirectory tree structure becomes corrupted and you restore the eDirectory data, all data is restored to one partition, [Root]. You need to repartition that portion of the tree.
It is important that you keep a written copy of the tree structure and the partitions. You can use the DSMISC.LOG file that is backed up with the file system as part of the server-specific information.
This section discusses the following:
The network of servers that comprise an eDirectory tree structure continually exchange updates and other time-sensitive information. The eDirectory database exists as a set of files that are stored in the SYS: volume and are hidden so they are not accidentally tampered with or deleted.
The eDirectory database files cannot be backed up, as was the case with bindery files in NetWare 3.12 or earlier versions.
eDirectory is not server-centric, and neither are its backup and restore processes. Backing up eDirectory, for example, backs up data that is spread out over multiple servers. SMS Directory database backups gather all the necessary eDirectory data.
To handle the necessary links and dependencies between objects, the backup and restore system must be able to navigate the entire eDirectory tree structure.
In NetWare, a random ID number is assigned when an object is created. NetWare uses object ID numbers to keep track of information such as users' trustee rights to directories and files in the file system. These object ID numbers are stored in the directory entry table (DET) of each file and directory and are server-centric.
When NetWare is backed up, SMS-compatible products store the objects' fully distinguished names on the backup media, not the objects' ID numbers. If an object with the same distinguished name as on the backup media already exists in the eDirectory tree structure, its object ID is not overwritten during a restore. If an object with the same name does not already exist in the eDirectory tree structure, it is assigned a new object ID when it is restored. This occurs on every server where the object is used.
The schema is backed up automatically with a full eDirectory backup. You can also choose to back up the schema separately using a custom eDirectory backup.
Whenever insufficient information is known about an object, such as when one of its mandatory attributes is missing, eDirectory creates as a placeholder an Unknown object.
During a restore session of the eDirectory database information, Unknown objects are created when restoring an object that has an access control list (ACL) or any other attribute that refers to other objects that do not currently exist in the eDirectory tree structure.
This condition is common in a restore, because only one object can be restored at a time. When this condition arises, an Unknown object is created until the real object is restored.
For example, User object User1 has been given property and object rights to User object User2. If User1 and User2 are deleted and only User2 is restored, an object named User1 will be created but it will have a base class of Unknown. This occurs because the access control list of User2 lists User1, which was not restored. The Unknown object is used as a placeholder in the tree. If User1 is later restored, it will replace the Unknown object.
If the restore session does not include the object for which the placeholder was created, the object remains in the eDirectory tree structure as type Unknown. Expect to see Unknown objects after a restore session if all network resources such as servers, volumes, and users are not in place before the restore session starts.
Objects that remain unknown after a restoration is completed are objects for which eDirectory could not resolve the dependencies.
In this case, you can do one of two things:
In order to back up the eDirectory database, the TSANDS.NLM software must be loaded on one server in the eDirectory tree structure---preferably the server containing a replica of the largest partition.
For large or complex networks, you can improve performance by loading the TSANDS.NLM software for a particular partition. This minimizes network traffic during the backup process and improves performance when the backup program performs name resolution across the eDirectory tree structure.
The version of TSANDS.NLM that ships with NetWare allows selective backup and restoration of an eDirectory tree structure.
HINT: Not all third-party backup applications support this selective backup and restoration. Check with the application vendor for details on product features.
In SBCON, you can begin the backup of the eDirectory database from any server in the eDirectory tree structure. The backup process continues from that point downward to the end of that portion of the tree. If the selected container is [Root], the entire eDirectory tree structure is processed.
This allows you to back up the entire eDirectory tree structure or subsets such as a single branch, a single container, or even a single leaf object. Also, a scan option allows backup of only those objects for which the backup user has the Supervisor right.
When you back up eDirectory, we recommend that you back up the eDirectory tree structure in one session whenever possible. Although partial eDirectory backups and restores are possible, numerous precautions and additional issues must be noted. See Partial eDirectory Restores for more information.
The network administrator can assign backup administrators with limited rights to the eDirectory tree structure.
For example, suppose in your company you have three Organizational Units that need to be backed up (East, West, Mid). You could create three User objects---BackAdmin1, BackAdmin2, and BackAdmin3---and give them rights to the Organizational Unit that they are responsible to back up.
You then create a TSANDS.CFG file that lists the fully distinguished name of the contexts where the backup administrators' rights begin. It would look similar to the following:
.OU=East.O=Acme
.OU=West.O=Acme
.OU=Mid.O=Acme
Backup administrators have rights to back up the eDirectory tree structure beginning only at the context listed, and the rights continue until the tree stops or the rights are filtered out. Backup administrators should use a custom eDirectory backup to back up the portions of the tree for which they have rights.
The network administrator assigns the Supervisor right to the backup administrators for the section of the eDirectory tree structure that they are responsible to back up. The network administrator then needs to create a TSANDS.CFG file that lists the fully distinguished names of the containers where each of the backup administrators' rights begin. The TSANDS.CFG file should be saved in the SYS:SYSTEM\TSA directory of the server.
In general, the eDirectory database should be backed up on a weekly basis. The frequency of this backup depends on how often changes and updates are made to the eDirectory tree structure. For a tree that changes often, you might want to perform an eDirectory backup every time you do a full backup of all servers on the network.
IMPORTANT: Always back up eDirectory prior to major tree modifications.
To get a full backup, the entire eDirectory tree structure needs to be functioning, meaning that all partitions are synchronizing normally. An eDirectory tree cannot be backed up entirely if any replicas of any partition are offline.
Back up your volumes so that in the case of hardware failure, natural catastrophe, or accidental change or deletion of files, you can restore the file system to a previous state and not lose the data.
To back up file system data, an appropriate SMS TSA must be loaded on each server for which a file system backup is to be created (see Loading the Target Service Agents). To back up file system information, make sure your backup application can handle the NetWare file system name spaces, extended attributes, trustee rights, compression, etc.
Once the device drivers for your backup hardware and the SMS TSA software is loaded, you can run the backup program of your choice (see Loading SBCON).
Trustee assignments are stored as part of the file system as an ID. They are backed up by default when the file system is backed up with the SMS TSA software. If a User object is deleted and then re-created or restored, its object ID changes. This is why the SMS TSA module uses fully distinguished names for objects to back up the trustee rights from the file system. If a User object is deleted and re-created with a new ID, the user's trustee assignments in the file system can be restored.
As long as an object with the same name on the backup media exists in the eDirectory tree structure when the file system is restored, the TSA can interact with eDirectory to rebuild the directory entry table (DET) to reflect new object ID numbers.
For additional information about object ID and trustee issues, see Restoring eDirectory.
Server-specific information such as the replica information, ID information, name spaces loaded, and system configuration is stored on the volume SYS:. This information is backed up as part of the file system as a single resource. This resource includes the following five files:
DSMISC.LOG contains a replica list and replica types on the server at backup.
STARTUP.NCF contains a disk driver, name spaces, and SET parameters.
AUTOEXEC.NCF contains load modules and the NetWare operating system configuration.
VOL$INFO.TXT contains volumes on the server, name spaces loaded, compression, and migration information.
You can also choose to back up this information individually. The information is not restored unless you specifically choose to restore it. It does not need to be restored unless you have lost the SYS: volume. In that case, you must replace the hardware and restore this information. For more information, see Restoring the Entire eDirectory Tree Structure.
Novell Cluster ServicesTM allows you to configure up to 32 NetWare servers into high-availability cluster, where resources can be dynamically switched or moved to any server in the cluster. Consolidation of applications and operations on a cluster has benefits such as lower costs, scalability, and increased availability. See the Novell Cluster Services documentation for more information.
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.SBCON supports backup and restore of cluster-enabled pools. In addition, the backup session can be automatically recovered in case of a failover or failback condition.
NOTE: Backup and restore of cluster-enabled pools is not supported in NetWare versions earlier than NetWare 6.
SBCON supports automatic recovery of backup sessions if failover or failback occurs. The backup engine reconnects to the Target Service Agent and resumes the backup from where it had terminated. Various cluster options like Enable Auto-Recovery and Retry Interval are provided by SBCON. You can use the default values or reset the values while submitting the backup job. The engine begins the reconnection attempts after waiting for a configurable time, and then retries at regular intervals until the connection is re-established or the number of retries has expired.
After the connection is re-established, the internal structures of the TSA are built and the recovered session is continued from where it had terminated. User intervention is not required during the recovery period. You can view the status in the Session Report screen.
Consider the following before preparing for backup and restore of cluster-enabled pools:
For more information, see Backing Up Cluster-enabled Pools from the Server.
In SMS, a target is any machine on the network that requires backup. Examples of targets include SQL database engines, eDirectory databases, workstations, and NetWare servers.
Through specific TSAs, SBCON allows you to back up the information that exists on the following targets. These TSAs are listed in general as follows:
Table 1. Target Services and Their Corresponding Target Service Agents
| Target Service | Corresponding Target Service Agent |
|---|---|
NetWare 6 |
TSAFS |
eDirectory |
TSANDS |
Windows 95 and 98 workstation |
W95TSA |
Windows 2000 and Windows NT workstation |
Windows NT TSA |
GroupWise® data |
GWTSA |
A Target Service Agent (TSA) is a software module that understands how to scan, read, and write the target data. The primary functions of an SMS TSA are to prepare the target data for backup or restoration, and to communicate with the storage management engine (SME). For example, an SMS TSA for a NetWare server understands name spaces, file and directory attributes, security privileges, etc., for the data on that server.
The TSA packages data from the target and presents it to the SME in a generic format. This allows one SME to interact with many types of TSAs.
NetWare 6 provides TSAFS.NLM, with the following features:
