SMS Backup and Restore

     

Storage Management Services (SMS), developed by Novell, provides a standard for data, devices, media, and storage management interfaces. With the appropriate agents , SMS can be configured to service different targets ”such as NetWare, NDS/eDirectory, Unix, and so on (as long as there is an agent available for the target) ”from a single backup engine. To fully understand the terminology and appreciate why you need an SMS-compliant backup solution for your NetWare network, the following sections offer a brief architectural overview of SMS and some sample SMS backup implementations .

SMS Architecture

SMS divides the storage management function into four areas of responsibility:

• Transparent communications interface

• Target-specific agent

• Storage engine

• Device interface

These are incorporated into four modules or applications, as illustrated by Figure 8.1.

Figure 8.1. Novell's SMS architectural overview.

The Storage Management Data Requester (SMDR) provides transparent local and Remote Procedure Call (RPC) links between the SMS modules running on the storage engine and the SMS modules running on the target. When you're running an SMS-compliant tape backup software on a NetWare server that is backing up a remote NetWare server, for example, SMDR.NLM must be running on both servers to facilitate the communication; a Windows SMDR module (called w32smdr.exe ) is included with eDirectory for Windows and is installed in drive :\Novell\nds\sms .

TIP

SMDR versions prior to 5.00 depend on SPX and, thus, IPX . Starting with SMDR 5.00 (shipped with NetWare 5), it is protocol independent. For NetWare 5 and later, this requester can use TCP/ IP to communicate with other SMDRs. Although SMDR 5.00 and higher can be configured to support TCP/ IP and SPX/ IPX , both protocols are supported by default. The SPX protocol is used with SMDR versions prior to 5.00.

The ability to back up data from a specific operation system platform is provided through the Target Service Agent (TSA) , which runs on the target . In SMS parlance, an SMS target is what you want to back up (the source of your data). The TSA is SMS's access road to a target's data. Through a set of generic Target Service APIs, SMS can read from, write to, and scan the target. All of SMS, except the TSA, treats the target's data as "black box data" ”only the TSA knows the target's data structure. Generally , one TSA is required for each target. The following are the different TSA modules available for NetWare:

• TSANDS.NLM ” To back up and restore tree-wide DS data.

• TSA410.NLM ” To back up and restore the file system of a Net-Ware 4.1 x or 4.2 server.

• TSA500.NLM ” To back up and restore the file system of a NetWare 5. x server.

• TSA600.NLM ” To back up and restore the file system of a NetWare 6.0 server.

• TSAFS.NLM ” To back up and restore the file system (traditional, NSS, and cluster-enabled volumes ) of a NetWare 6.5 server.

• TSADOSP.NLM ” To back up and restore files from the DOS partition on a NetWare server. (Shipped only with NetWare 5.0 and NetWare 5.1.)

• TSAPROXY.NLM ” To facilitate backup and restore files on Windows workstations running Novell Client software and have the Windows TSA agent running.

• TSADOS.NLM ” To facilitate backup and restore files on DOS workstations running Novell Client software and with TSASMS.COM loaded.

• GWTSA.NLM ” To back up and restore GroupWise mailboxes and related information.

TIP

TSAFS supports backup of open files on NSS volumes if the CopyOnWrite feature is enabled. Only the last closed version of the file is backed up. The Supervisor right is required to back up open files. To enable CopyOnWrite on a single NSS volume, at the server console, enter nss /FileCopyOnWrite= volume_name . For more information about using NSS server console commands refer to NSS documentation.

TSA500 and higher support both the traditional NetWare file system and the Novell Storage Services (NSS) released with NetWare 5 and above. The initial release of TSA500, however, does not support NSS mounted DOS FAT file systems. If you need to back up a DOS partition, use TSADOSP.NLM instead. To back up from or restore to the DOS FAT partition on a Net-Ware 6.0 and later server, load DOSFAT.NSS and TSA600.NLM (or TSAFS.NLM for NetWare 6.5). After loading the DOSFAT.NSS module, any DOS FAT partitions are dynamically made available as logical volumes. TSA600/TSAFS considers these logical volumes as resources for backup and restore.

Storage Management Engine (SME) is the heart of an SMS-compliant backup system. Its main task is to retrieve and dispense data. It is in this module where third-party vendors provide value-added features, such as maintaining a database of backed up files and management of tapes.

Instead of directly communicating with the various types of storage devices, SMS communicates with them via the Storage Device Interface (SDI) module. With the assistance of Media Manager, SDI provides SMS a logical view of the media and storage devices. Because of this, any applications using SDI can use all SMS-compatible devices without making any changes. In essence, SDI is a storage device abstraction layer within the SMS architecture, so the higher layers within SMS, such as the SME, don't need to know how to address a specific storage device for data retrieval or writing to it.

System Independent Data Format

SMS's capability to work with many different types of targets or services (such as NetWare file systems, eDirectory, Windows 2000, and so on) whose data structures are varied is due to the System Independent Data Format (SIDF) . SIDF specifies how a target's data is formatted, who does the formatting, how a session is placed on the media, and so on. The TSA is responsible for formatting and "deformatting" the target's data set (such as file data and name -space information) according to the specification. The SME simply writes the SIDF-formatted data to the storage media. Therefore, in concept, SMS's use of SIDF is very similar to the use of XDR (External Data Representation) in NFS (Network File System) developed by Sun Microsystems, except the receiving side (the SME) does not deformat the data before recording it.

SMS Backup Session Example

The interactions between the various SMS modules are complex. The following example offers you a high-level look at how an SMS backup session works and gives you some insights into how and why SMS-compliant software functions the way it does. The example assumes that the SMS engine (SME, SDI, and SMDR) is running on a NetWare 6.5 server and it is backing up the SYS volume of a remote NetWare 5.1 server, which has a TSA and SMDR running (see Figure 8.2):

1. The user selects the backup media to use. This connects the SME to SDI.
   
   
2. The user selects NETWARE5-B as the target. During this process the SMDRs on each server connect to each other; this is transparent to the user as well as the SME programmer. Through the SMDR connection, the SME running on NETWARE65 connects to the TSA running on NETWARE5-B.
   
   

   NOTE

   If the SME is backing up local data, the SMDR is bypassed so that all communication between the SME and TSA becomes direct.

3. The SME asks the TSA to provide a list of resources or data sets the user can choose to back up. The SME presents this list to the user for selection.
   
   
4. The user selects the SYS volume and specifies that the file system trustees are to be backed up as well.
   
   
5. The SME sends the user selections back to the TSA.
   
   
6. The TSA then scans (searches) NETWARE5-B for the specified data sets (resources).
   
   
7. Upon finding a data set that matches the selection criteria, the TSA formats the data set (which includes file attributes, file names , name space information and so on) according to SIDF specifications and sends it to the SME.
   
   
8. File system trustee assignments are backed up as follows :
   
   

   1. For each given file or directory, the TSA reads the Directory Entry Table (DET) to determine whether any trustees are assigned.

   2. If a trustee assignment is found, TSA reads the trustee ”this is stored as an object ID and not a DS object name.

   3. The object ID is then translated into a full DS object name.

   4. The TSA formats the data according to SIDF specifications and sends it to the SME.

9. The SME sends the received data to SDI, through Media Manager and device-specific driver, for storage on the (selected) media.
   
   
10. Steps 6 through 9 are repeated until all data sets matching the user selection criteria are found and stored.
    
    

Figure 8.2. The SYS volume of the NETWARE5-B server is being backed up, across the wire, by NETWARE65.

You can use a non-SMS solution to back up your file system provided it is NetWare-aware (so file system trustee information is properly backed up). Because it doesn't make use of TSA, however, it cannot back up NDS/eDirectory; some of the DS files are kept open by DS.NLM and thus can't be backed up or copied by conventional means ”unless it provides its own agent.

SBackup for NetWare

Included with NetWare (from NetWare 3.0 and up) is an SMS-compliant backup utility called SBackup. It is an NLM-based tape backup program. NetWare 5 and higher ship with an enhanced version of this backup engine, called SBCon. It contains all the functionality provided by earlier versions of SBackup and has the following enhancements:

• Autoloader support

• Enhanced user interface (SBCon)

• Windows workstation graphical interface (NWBack32) ”NWBack32 is not included with NetWare 6.5

• Multiple and repeatable job scheduling

• Concurrent jobs can run on multiple devices (but not on same device)

• Runs on earlier versions of NetWare and is compatible with all TSAs

• Runs in an IP-only environment if preferred

NOTE

If multiple backup and restore jobs are submitted to run at the same time on the same device , the second and subsequent jobs will receive an error because the device (tape drive or other device) is busy servicing the current job. The error message does not make it sufficiently clear that the problem is simply that the device is in use. To avoid this conflict, set the execution time for subsequent jobs to run sometime after prior jobs are completed or submit concurrent jobs to different devices.

The sections that follow outline the necessary steps for backing up and restoring your NDS/eDirectory using SBCon, which is shipped with NetWare 6.5. Before learning that, however, you need to know how to correctly set up and configure SMS for your DS environment.

Configuring SMDR and QMAN

As mentioned earlier in this chapter, SMS-compliant applications make use of SMDR, and SBCon is no exception. Unlike previous versions of SMDR that use Service Advertising Protocol (SAP) to locate other SMDRs on the network, the newer SMDR uses DS and the Service Location Protocol (SLP). Older versions of SMDR advertised the server name where it was loaded using SAP type 0x23F. This mechanism worked well in small LAN environments, but did not scale well in large environments and does not work at all in a pure IP environment. In a pure IP environment, SMDR uses either DS or SLP as a service locator instead of SAPs.

NOTE

SMDR v5.04 and later can use SLP for locating other SMDRs. This enables SMDRs to locate other SMDRs running on servers belonging 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.

NOTE

Each server that will be running SMS -compliant software needs to have its own SMDR object.

You need to install and configure SMDR and QMAN (SMS Queue Manager) before you can use any SMS applications, such as SBCon. Some third-party SMS applications may include their own queue manager instead of using QMAN. The configuration can be done during the server installation by choosing to install SMS, or you can add this service at a later time using NWConfig. If SMDR fails to load or if the SMDR object is corrupted, you can restore it to the state when the server was first installed and before it was configured. To do so, you need to delete two configuration files and two DS objects using the steps in the following procedure:

1. Log in to the server as a user that has Admin rights.
   
   
2. Make your working directory SYS:ETC\SMS .
   
   
3. There are two files within this directory, SMDR.CFG and SBACKUP.CFG ( SBCON.CFG on NetWare 6.0 and later). Both of these files are text based and can be viewed with any text editor. Either delete or rename these two files. (There is also a TSA.CFG file on NetWare 6.5 servers but you don't need to delete this file.)
   
   
4. Use a management tool, such as NetWare Administrator, to locate the two SMS-related objects in the tree. Usually these two objects are generally in the container where the NCP Server object is located. If the objects are not there, look through the tree for them. Once they are found, delete them. The default names of the objects are "SMS SMDR Group " and " server name Backup Queue." For example, for a server named "NETWARE65," the object names are "SMS SMDR Group" and "NETWARE65 Backup Queue."
   
   
5. At the server console prompt, type LOAD SMDR NEW . The NEW switch brings up the SMDR Configuration Screen (see Figure 8.3), and you're asked for three pieces of information:
   
   

   • The default context for the SMDR group: enter the desired context (such as OU=Servers.O=Company ) or press Enter to use the default context.

   • The default SMDR context: enter the desired context (such as OU=Servers.O=Company ) or press Enter to use the default context.

   • The name and password of the user who has managing rights to the object that will be created in the specified context: An example of a user name is given. When entering the user name, use absolute fully distinguished naming such as .CN=Admin.OU=Servers.O=Company .

   Figure 8.3. The SMDR configuration screen.

   
   The previous steps create a new SYS:ETC\SMS\SMDR.CFG configuration file that looks similar to this:
   
   

    #This is SMDR default configuration file #Lines beginning with # are treated as comment SMDR Context: OU=toronto.O=dreamlan SMDR Group Context: OU=toronto.O=dreamlan #Both the protocols are enabled 

   
   
6. At the server console prompt, type LOAD QMAN NEW . The NEW switch brings up the SMS Queue Manager Configuration Screen (see Figure 8.4). Similar to configuring SMDR, you'll be asked to specify the context and the name of the SMS Job Queue. After the job queue name is created, the name of the user who has managing rights is requested . This time, however, an example of the user name is not given. Follow the previous step's suggestion for the user naming. It is suggested that the same user be given rights to the queue object as the SMS group object.
   
   

   Figure 8.4. The SMS Queue Manager configuration screen.

   
   If everything is entered correctly, the configuration screen clears and a console message similar to the following is displayed:
   
   

    Started service the job queue .CN=NETWARE65 Backup Job Queue.OU=toronto.O=dreamlan Using transfer buffer size 65536 bytes. 

   
   Also, this step creates a new SYS:ETC\SMS\SBACKUP.CFG ( SBCON.CFG on NetWare 6.0 and later) configuration file that looks similar to this:
   
   

    # This is QMANAGER Configuration file # Lines beginning with # are treated as comment. # QMAN.NLM reads the information from this file when # loaded Sbackup Job Queue: .CN=NETWARE65 Backup Job Queue. OU=toronto.O=dreamlan # Default Transfer buffer size # Transfer Buffer Size: 64000 

   
   

Now you're ready to run SBCon.

Backing Up eDirectory

In NetWare 5 and above, the SBackup NLM has been renamed to SBCON.NLM (NetWare Storage Management Console; on NetWare 6.5 it is referred to as SMS ”Backup Management Console) and has a slightly different look than previous versions of SBackup (see Figure 8.5). The main difference is in the Job Administration option, which enables you to create, submit, and administer jobs in a DS queue.

Figure 8.5. The version of SBackup shipped with NetWare 5 and above is now called SBCon.

WARNING

You should be aware that NDS /eDirectory partition boundary information is not backed up; therefore, you should keep a written record of your DS tree partition placement. If no partition information exists when a restore is performed (for instance, after a total loss of a DS tree), the entire tree structure is placed into one partition ( [Root] ). You must then manually re-create the partitions and replicas.

The following steps outline how you can use SBCon to back up your DS tree. It is assumed that you have already correctly installed and configured your tape device:

1. Load the controller and storage device driver for your tape device, if not already loaded. Load NWTAPE.CDM if required by the device driver.
   
   
2. Load TSANDS.NLM on one of your NetWare servers (SMDR will be auto-loaded if not already loaded). On NetWare 6.5 servers, you can run the SMSSTART.NCF file at the console that loads SMDR, TSAFS, and TSANDS.
   
   

   TIP

   You only need to load TSANDS on one server. For best performance, you should load TSANDS.NLM and SBCON.NLM on the server holding the most replicas. This reduces the amount of tree-walking required during the backing up of the whole DS tree.

   NOTE

   If you see the "SMDR Group Context is invalid" message displayed when SMDR is loading, this means you have not completely configured the SMDR object. Refer to the earlier section, "Configuring SMDR and QMAN," to (re)configure SMDR.

3. On the server with the tape device, load QMAN.NLM and then load SBCON.NLM .
   
   
4. From the Main Menu, select Storage Device Administration.
   
   
5. From the Select a Device menu, highlight the device you want to use (see Figure 8.6). If the device is an autoloader, press Enter to display a list of loaded media.
   
   

   Figure 8.6. Select the backup device and media using the Select a Device menu.

   
   

   TIP

   If SBCon can't communicate with the tape drive, or if the console LIST DEVICES command shows the device in an Unbound state, ensure NWTAPE.CDM is loaded. If the LIST DEVICES console command sees the tape device properly, but SBCon does not recognize the device, it's possible that SBCon does not support the tape device. A list of SBCon-supported tape devices can be found in TID #10059850.

6. Highlight the media you want to use and press Enter to select it.
   
   
7. Press Esc to return to the Main Menu.
   
   

   NOTE

   Steps three through six are not absolutely necessary. These steps help you ascertain whether the job will be able to access the tape device or not before you submit the job.

8. Select Job Administration.
   
   
9. Select Backup from the Select Job menu.
   
   
10. Use the Target Service option of the Backup Options menu to select the target server. If the selected target server has multiple TSAs running, such as TSANDS and TSAFS, you also need to select the appropriate service. The name of the TSANDS service is server name .Novell Directory (for example, NETWARE_65_A.Novell Directory; see Figure 8.7).
    
    

    Figure 8.7. Select the TSANDS service for backup.

    
    
11. You're then prompted for a username and password with sufficient DS rights to back up the tree; use the . username . org naming syntax. Upon successful login, a message similar to "You are connected to the target service name <Press ENTER to continue>" is displayed. In the Target Service option, you'll now see the DS tree name listed.
    
    
12. Use the What to Back Up? option to select backing up the whole Directory tree, the schema, objects or a branch of the tree. After selecting the option, the List Resources menu is displayed.
    
    
13. Press Insert to bring up a list of DS resources that you can select for backup (see Figure 8.8). To back up the schema, for example, highlight Schema in the Full Directory Backup menu, press Enter, and the Schema menu is displayed; you'll see "[..]" in the menu. Press Esc and the word Schema is now shown in the List Resources menu indicating it will be backed up.
    
    

    Figure 8.8. You can back up the whole tree, the schema, the selected objects or the selected branches of the tree.

    
    

    NOTE

    Selecting Full Directory Backup will back up all objects in the tree, including schema. Selecting SYS volume backup will also back up Server Specific Information ( SSI ) data, which is important when restoring a crashed server (see the "Server Recovery Using Server Specific Information Data " section later in this chapter for more details.)

    TIP

    To make it easier to back up portions of the DS tree, you can create a TSANDS.CFG file, which enables you to specify the names of containers where you want backups to begin. TSANDS.CFG is a text file listing DS contexts (one per line) located in the SYS:SYSTEM\TSA directory on the server that TSANDS.NLM is loaded on. When this file is present, SBCon lists the additional contexts as available resources that you can select for backup. Note that not all backup programs support the additional resources made available by TSANDS.CFG .

14. Repeat Step 13 to select any other DS resources you want to back up.
    
    
15. Enter a description (up to 23 characters ), such as NETWARE 6.5 tree backup, in the Description field.
    
    
16. Use the Device/Media Name field to select the tape device that will be used.
    
    
17. Use the Advanced Options menu to schedule when the job will run (see Figure 8.9) and to designate whether it's a repeating job (see Figure 8.10).
    
    

    Figure 8.9. Use the Advanced Backup Options menu to further control what data to back up and to schedule the job.

    
    

    Figure 8.10. You can schedule the job as a run-once or as a recurring job.

    
    
18. Use the Append Session option to specify whether the data on the tape is to be appended or overwritten.
    
    
19. Press Esc and select Yes in response to the Do you want to submit a job? prompt. At this point, you are returned to the Select Job menu.
    
    

The job will execute automatically at the scheduled time. You can use the Current Job List option to manage the submitted jobs: from the Main Menu, select Job Administration, Current Job List. A list of queued jobs is displayed in the Queue Job menu. Similar to managing print jobs, you can put a backup job on hold and change its execution time and scheduling (see Figure 8.11).

Figure 8.11. Use the Current Job List to manage submitted SBCon jobs.

You can monitor the runtime status of an executing job by highlighting the job in the Queue Job menu and pressing Insert. A real-time display similar to the one that existed in previous versions of SBackup is shown (see Figure 8.12). From this menu, you can delete or stop the job by pressing Delete.

Figure 8.12. Real-time status of a currently executing job.

You can also check the execution status of a job using SBCon's status screen. SBCon creates two NLM screens; one is the user menu screen and the other an SMS Activity Log screen (see Figure 8.13). The information displayed in the SMS Activity Log screen is recorded in the SYS:SYSTEM\TSA\LOG\ACTIVITY.LOG file and available for review at a later time. Alternatively, you can use SBCon's run logs to determine what resources were backed up and whether there were any errors. You can access the run log from the Main Menu: Log File Administration, View a log file. To access the error log, use Log File Administration, View an Error File to access the error log. By default, the SMS activity and SBCon run files are stored in the SYS:SYSTEM\TSA\LOG directory.

Figure 8.13. SBCon reports the success or failure of a given job using the SMS Activity Log screen.

NOTE

SME.NLM is auto-loaded when the backup job starts and is unloaded after the job finishes.

Restoring eDirectory

The mechanics for restoring DS using SBCon is very similar to that of backing up DS except now your source is the tape instead of TSANDS. You can restore a single object, a branch of the tree, or the whole Directory tree. Before you restore DS data from a tape backup, you need to be aware of the following implications to your existing tree:

• A restore of DS from tape backup does not overwrite the existing database with a copy like that on the tape. Instead, the DS restore process will attempt to re-create all the objects that existed when the backup was performed.

• When a restore is performed under disaster recovery conditions, in which the original DS database has been destroyed and server reinstalled, the DS objects and attributes restored from the tape are added to the minimal DS tree provided by the NDS/eDirectory installation process. This results in a tree that is the same as the one saved to tape.

• If, however, a DS tree still exists on the server to which the restore is being performed, a restore will attempt to append to the existing tree, rather than overwrite it. In the best possible case, the restore process will have no visible effect at all. The worst possible case will result in additional, unwanted objects being added to the existing tree structure, leaving the old, corrupted structures intact, and possibly adding additional corrupt elements.

The following steps outline how to use SBCon to restore your DS (we assume that you have already correctly installed and configured your tape device):

1. Load the controller and storage device driver for your tape device, if not already loaded. Load NWTAPE.CDM if required by the device driver.
   
   
2. Load TSANDS.NLM on one of your NetWare servers. (SMDR will be auto-loaded if not already loaded.)
   
   
3. On the server with the tape device, load QMAN.NLM and then load SBCON.NLM .
   
   
4. Select Job Administration.
   
   
5. Select Restore from the Select Job menu to bring up the Restore Options menu (see Figure 8.14).
   
   

   Figure 8.14. Configure your restore options using this menu.

   
   
6. Select the Target Service to select the server to which you want to restore DS. Press Enter to bring up a list of servers running TSAs. If the selected server has multiple TSAs running, such as TSANDS and TSAFS, you also need to select the appropriate service. The name of the DS service is server name .Novell Directory (for example, NETWARE_65_A.Novell Directory).
   
   
7. You're then prompted for a username and password with sufficient DS rights to the tree; use the . username . org naming syntax. Upon successful login, a message similar to "You are connected to target service name <Press ENTER to continue>" is displayed. In the Target Service option, you'll now see the DS tree name listed.
   
   
8. Enter a description (up to 23 characters) to identify the job in the Description field.
   
   
9. Select the device and media on which DS data is stored.
   
   
10. Select the correct session on the media containing the DS data you want to restore.
    
    
11. Use Advanced Options to set any filters desired in restoring the DS, whether any existing objects should be overwritten, and configure the execution time and run schedules (see Figure 8.15).
    
    

    Figure 8.15. The Advanced Restore Options menu.

    
    

    WARNING

    Be careful when configuring the Overwrite Parent and Overwrite Child options. Any recent DS -related changes (this does not include file system trustee assignments, because they are not stored in DS ) to the object, including password, will revert the values to whatever they were at the time of the backup.

12. Press Esc and then select Yes in response to the Do you want to submit a job? prompt. You're then returned to the Select Job menu.
    
    

WARNING

Depending on the backup solution used, the trustees of [Root] might not be restored during a DS restore from tape. Admin will be the only user with full trustee rights to [Root] after a tape restore, even if other users had an explicit trustee assignment to [Root] . However, Security Equal To rights will be restored, and if a user has security equal to Admin, the user will have the same rights that admin has (which is usually full rights to the tree).

As previously mentioned in the "Backing Up eDirectory" section, your job will execute automatically at the scheduled time. You can manage and monitor your restore jobs through the Current Job List option.

Backing Up and Restoring Schema Extensions

During a DS backup, the TSANDS.NLM sends every object ”those defined by both native (base) and extended schemas ”to the backup program for backup. Versions of TSANDS.NLM prior to v4.14, however, do not send the extended schema definitions of the object types you have added to the DS database. Consequently, the resulting backup of DS contains information for objects defined in an extended schema, but not the extended schema data that defined those objects. This means that before you restore these DS objects, you have to first re-extend the schema so the definitions for extended objects exist in the tree during the restore. If this is not done, NDS/eDirectory will contain restored objects that it doesn't know how to use and will display them as Unknown objects.

The version of TSANDS.NLM shipped with NetWare 4.11 and higher, as well as the one included in SMSUP6.EXE and higher for NetWare 4.10, backs up and restores any schema extensions by default. You no longer have to re-extend the schema before DS can recognize restored objects defined by an extended schema.

Backup and Restore Services on Windows

Novell has extended the SMS architecture to include Windows NT and higher. You can use any SMS-compliant backup/restore utility to perform backup and restore operations on your eDirectory database located on your Windows eDirectory server. You can also back up the eDirectory on Windows database to a NetWare server, and vice versa. The following components facilitate the SMS-based backing up and restoring of data on Windows systems.

SMSEngn is a basic Storage Management Engine (see Figure 8.16) provided by Novell for Windows NT and higher. Unlike its NetWare cousin SBCon, SMSEngn can only back up to or restores data from a set of files ”a data file ( .DAT ) and an index file ( .IDX ). A BackupLog.log file is either created or overwritten if it already exists. You will need to back up these files to a tape or other removable media as part of the Windows file system backup.

Figure 8.16. SMS Backup and Restore Engine for Windows.

When eDirectory is installed, the SMDR and TSANDS are set up by default as a Windows service (called "W32 SMDR"). The service is always available though it may be disabled or stopped . You can verify its status via Program Settings, Control Panel, Administrative Tools, Services on Windows 2000 and higher, or Program Settings, Control Panel, Services for Windows NT. If it is not listed in the Services applet, start W32SMDR.EXE located in the drive :\Novell\NDS\SMS directory.

ndsbackup for Unix

The ndsbackup utility is a Unix command-line utility that allows you to back up and restore eDirectory objects to and from a single file (referred to as the ndsbackupfile ). Like all Unix utilities, the actions of the ndsbackup utility are controlled by command line options. The command line options that you can give are a string of characters containing exactly one function letter ( c , r , t , s , or x ) and zero or more function modifiers ( letters or digits). The string contains no space characters, and function modifier arguments are listed on the command line in the same order as their corresponding function modifiers appear in the string. The supported command line options and function modifier arguments are listed in Table 8.1.

Table 8.1. ndsbackup Parameters

NDSBACKUP PARAMETER	DESCRIPTION
-a	The full (typeless) distinguished name of the user with administrator rights to the objects being archived or restored.
c	Create the ndsbackupfile .
f	Specifies that a file will be used. Use the ndsbackupfile argument as the name of the ndsbackupfile . If it is omitted, or if the name of the ndsbackupfile is - , ndsbackup writes to the standard output or reads from the input, whichever is appropriate. ndsbackup can be used as the head or tail of a pipeline.
e	Sets error handling flag. Exit immediately with an exit status if an unexpected error occurs.
-I	Use the specified include file that contains a list of eDirectory objects, one per line, and treat it as if each eDirectory object appeared separately on the command line. If an eDirectory object is specified in both the exclude file and the include file (or on the command line), it will be included. Be careful of trailing white spaces.
r	Replace existing objects in the ndsbackupfile file by appending the eDirectory objects to the file. Therefore, during a restore older object information in the file will be overwritten by the newer data located at the end of the file. You can consider this as a form of incremental backup.
R	Specifies a replica server name or IP address. Use the option to archive or restore eDirectory objects using a server holding the replica of the eDirectory partition. If you omit the R option, the local server is used.
s	Obtain a list of objects from the tree.
t	Obtain a list of objects from the ndsbackupfile .
v	Verbose mode. Outputs the name of each eDirectory object preceded by the function letter. With the t function, v provides additional information about the ndsbackupfile entries.
w	Prompts for action. Output the action to be taken and the name of the eDirectory object, and then wait for the user's confirmation. If you enter y , the action is performed. If you enter any other key, the action is not performed. This function modifier cannot be used with the t function.
x	Restore objects to the tree from the ndsbackupfile . If a named eDirectory object matches a container whose contents have been written to the ndsbackupfile , this container is recursively extracted.
X	Use the exclude-file argument as a file containing a list of eDirectory objects to be excluded from the ndsbackupfile when using the functions c , x , s , or t . Multiple X arguments may be used, with one exclude file per argument. If an eDirectory object is specified in both the exclude file and the include file (or on the command line), it will be included. Be careful of trailing white spaces.
eDirectoryobject	The full (typeless) distinguished name of a leaf object or a container to be archived (when the c or r functions are specified), extracted ( x ) or listed ( t ). The action applies to all of the objects and (recursively) subordinate objects of that container. To archive the whole tree, specify the Tree object. You can also back up the eDirectory schema by specifying Schema as the eDirectory object. To back up the entire tree along with the schema, specify Full Directory Backup. If you do not specify the eDirectory object to be backed up, ndsbackup uses the default Full Directory Backup option.

The command syntax for ndsbackup is

 ndsbackup function [modifier options] [option arguments] [-a admin.org] [-I include-file]  [eDirectoryobject] 

WARNING

The order of the option arguments is dependent on the order of the specified modifier options. For instance, ndsbackup fR means the ndsbackupfile needs to be specified before the name of replica server.

To archive, restore, or list eDirectory objects, you need to specify the fully distinguished name of a leaf object or container that is to be archived, extracted, or listed. To archive the whole tree, specify the Tree object (or leave the eDirectoryObject name from the command line). You can also back up the eDirectory schema by specifying Schema as the eDirectory object.

NOTE

ndsbackup is not an SMS -based application. It uses standard NDS /eDirectory APIs to access the tree, which means the target server does not need to have TSANDS running.

The following is a partial output from ndsbackup when backing up the whole tree:

 [RH9-eDir root]#  ndsbackup cfRv fullbackup.april-01-2004 10.6.6.1 -a admin.xyzcorp  Password : a .O=XYZCorp. a .OU=IS_Admins.O=XYZCorp. a .OU=Groups.OU=IS_Admins.O=XYZCorp. a .CN=RootAdmins.OU=Groups.OU=IS_Admins.O=XYZCorp. a .OU=Tree_Admins.OU=Groups.OU=IS_Admins.O=XYZCorp. a .CN=Admin.OU=IS_Admins.O=XYZCorp. a .OU=Scripts.OU=IS_Admins.O=XYZCorp. a .OU=Company.O=XYZCorp. a .OU=East.OU=Company.O=XYZCorp. a .OU=Scripts.OU=East.OU=Company.O=XYZCorp. a .OU=West.OU=Company.O=XYZCorp. a .OU=Scripts.OU=West.OU=Company.O=XYZCorp. a .CN=Admin.OU=Company.O=XYZCorp. a .CN=LDAP_Proxy_User.OU=Company.O=XYZCorp. [RH9-eDir root]# 

In the previous example, the order of the function modifiers is fR , which means the name of the ndsbackupfile is fullbackup.april-01-2004 while the address of the replica server is 10.6.6.1. An eDirectoryObject name is not provided, thus the backup mode defaults to full backup. Since there is no command line option to specify a password (this is for security reasons ”but it also makes automating the backup process more challenging), ndsbackup prompts you for the password, which is not echoed (not even as a series of asterisks ). If you omit the -a option, you will be prompted for the username.

NOTE

ndsbackup will not accept input from a redirected file ( for example , " < filename "). Thus you cannot circumvent security and send the password to ndsbackup that way.

The "a" that appears in front of each object name in the ndsbackup output is the result of the verbose ( v ) option. It indicates that each of those objects is being archived.

You can customize the backup process of the ndsbackup utility by choosing specific eDirectory objects to be excluded or included in the backup session. Whether you use exclude ( X ) or include ( -I ) usually depends on the size of the data you want to back up, compared to the size you do not want to back up. As an example, to back up most of the eDirectory tree structure while omitting only a small part, use the exclude option to omit the part you do not want to back up as it is more efficient than using include and needing to specify everything else.

NOTE

Everything that you do not want specifically excluded is included. After you exclude part of the structure, you cannot include objects below that container.

Third-Party SMS-Compliant Backup Solutions

There are a number of third-party SMS-compliant backup solutions available for NetWare. Although not required, we recommend that when selecting a server-based application (such as a SMS-compliant backup solution) for your NetWare servers be certain the product has Novell's YES, Tested and Approved certification.

In order to receive a Novell YES, Tested and Approved certification, generally referred to as the YES certification, a software application must be subjected to a number of testing criteria, such as low memory conditions to see how the application handles exceptions. In the case of backup systems, testing requires that the client/server application correctly back up and restore NetWare volume (which includes NSS volumes), file, and eDirectory information.

NOTE

YES certification of products that works with Novell Nterprise Linux Services and product certifications for SuSE Linux (SUSE LINUX READY Program) are also available. Visit www.suse.com for more information about SuSE product certifications.

Novell Technical Support works closely with companies that test products through Novell DeveloperNet. If you call Novell for end-user or system integrator support and your network incorporates YES, Tested and Approved third-party products, Novell technicians can reference existing support documentation such as YES Bulletins and TIDs. If the error persists, technicians can duplicate the situation in one of Novell's labs or work with the product vendor, leveraging the relationship that was developed during the testing process to resolve the problem. In short, YES, Tested and Approved is Novell's first line of interoperability assurance for Novell customers.

Every YES, Tested and Approved product has a YES Bulletin that details what products were used in the testing ”such as versions of Novell products, network adapters, controller devices, and supported drivers. The YES Bulletin also indicates specific product configuration, date of the testing, special network configuration information or other related information important to product interoperability in the network environment. For example, a YES Bulletin can tell you whether a particular backup solution can properly back up and restore all the various file formats supported on your network or whether a device driver handles memory over 16MB correctly. This information may be in the form of a configuration note or a line item indicating whether or not certain functionality is supported.

NOTE

Visit the YES, Tested and Approved Bulletin Search page ( developer.novell.com/yessearch/Search.jsp ) to search for the latest certified products and to view existing YES Bulletins.

The following are some of the more popular backup system choices that have received the YES certification:

• VERITAS Backup Exec for NetWare Version 9.1 (YES Bulletin #70552) ” Formally developed by Seagate, VERITAS Backup Exec was the first NetWare 5 “certified data protection solution. Because NetWare 5 and higher can be configured to run in a pure IP environment, Backup Exec for NetWare fully supports IP and IPX protocols, ensuring your data protection no matter how you configure the network. As a fully SMS-compliant backup application, Backup Exec protects any size Novell Storage Services (NSS) volume by utilizing Novell (or VERITAS “developed) Target Service Agents ”even terabyte size volumes. In addition, Backup Exec's NDS protection includes all objects, containers, and extended schema, plus additional client network information that has been added in NetWare 5 and above. For more information about VERITAS Backup Exec for NetWare, visit www.veritas.com.

• BrightStor ARCserve Backup for NetWare v9 (YES Bulletin #69429) ” Originally developed by Cheyenne, Computer Associates International, Inc.'s BrightStor is an enterprisewide storage management software product that enables you to back up and restore data on NetWare servers and all workstations attached to those servers. Similar to Backup Exec, BrightStor is a fully SMS-compliant backup solution that supports NSS volumes and works over both IPX and IP. For more information about BrightStor ARCserve Backup for NetWare, visit www.ca.com.

• Backup Express v2.1.5 (YES Bulletin #71325) ” Originally developed by Arcadia Software, Syncsort Inc.'s Backup Express is an enterprise-class backup and restore solution designed for Unix, Linux, Windows, and NetWare environments. Backup Express supports any combination of Unix, Linux, Windows, NetWare, and Network Data Management Protocol/Network Attached Storage (NDMP/NAS) devices in a Storage Area Network (SAN) environment. It can perform backup of all data directly across the fiber or iSCSI network, dynamically share all tape drives , and control this single enterprise environment with a single catalog and easy-to-use GUI. Backup Express's distributed architecture allows it to back up to any device in the network whether it is running Unix, Linux, Windows, or NetWare, while maintaining a single central catalog for the entire enterprise. For more information about Backup Express, visit www.syncsort.com .

From our experience, the major YES certified data backup solutions players for the Intel platform are BrightStor ARCserve and VERITAS Backup Exec. Many large sites that have mainframes use a combination of BrightStor ARCserve and Backup Exec along with some form of mainframe-based backup solution (such as IBM's Tivoli Storage Management, formerly called ADSM) for their enterprisewide backup strategies.

There are a number of good, but not YES certified, backup solutions favored by customer sites. Chief among these solutions is Legato's Networker for NetWare (www.legato.com/products/ networker /netware.cfm).

NOTE

When searching for a NetWare backup solution, you should not limit your selections to YES-certified products. Rather, you should evaluate a number of them and pick what works best for your particular needs and environment.