Novell is now a part of Micro Focus

Backing Up and Restoring NetWare Directory Services in NetWare 4

Articles and Tips: article

DOROTHY BOWERS
Product Manager
Operating Systems Division

MICHAEL FAIRBANKS
Software Engineer
Operating Systems Division

KERRY LOVELESS
Product Support Engineer
Major Accounts

DALE MAUGHAN
Product Support Engineer
Novell Technical Services

KEN NEFF
Principal Technical Writer
Systems Research Department

01 Aug 1995


This AppNote gives procedures for backing up and restoring NetWare Directory Services™ (NDS™) in NetWare7 4 networks. It begins with a brief overview of Storage Management Services™ (SMS™) and NDS, focusing on those aspects which most directly relate to backup and restore issues. The AppNote then presents general concepts that are necessary to understand concerning backup and restoration in the NetWare 4/NDS environment. It describes how to devise a comprehensive backup plan for NetWare 4, how to properly restore NDS information in various example scenarios, and what to watch out for in specific situations.

RELATED APPNOTES

Jan 95 "Planning an NDS Tree"

Mar 94 "Management Procedures for Directory Services in NetWare 4.01"

Apr 93 NetWare 4.0 Special Issue

Introduction

In the NetWare 3 environment, the backup and restoration of network data is a relatively straightforward process that is generally understood throughout the industry. Once developers and users grasp the basic concepts behind the NetWare 3 file system - the bindery, user ID numbers, trustee rights, and so on - an appropriate backup and restore scheme can be readily devised.

With the introduction of NetWare 4, the basis of networking expanded from a server-centric way of organizing data to a global community of data repositories. The move from NetWare 3's server-based bindery to NetWare Directory Services (NDS) greatly enhanced network flexibility, access, and manageability. It also necessitated some new procedures for properly backing up and restoring NDS information.

This AppNote gives network administrators, information systems personnel, systems engineers, and technical support providers recommended procedures for backing up and restoring NDS information in NetWare 4 networks. It begins with a brief overview of Storage Management Services (SMS) and NDS, focusing on those aspects which most directly relate to backup and restore issues. The AppNote then presents general concepts that are necessary to understand concerning backup and restoration in the NetWare 4/NDS environment. It describes how to devise a comprehensive backup plan for NetWare 4, how to properly restore NDS information in various example scenarios, and what to watch out for in specific situations.

Note: Some of the procedures outlined in this AppNote are advanced procedures that should be performed by or with the assistance of someone who is experienced in NetWare 4 and NDS. If you need help with any of these procedures, contact your authorized Novell support provider.

This AppNote is not intended to be an exhaustive guide to backing up and restoring NDS. Individual network environments will vary, and exact procedures differ among various backup/restore products. For specific details, consult the documentation and readme files that come with your NetWare operating system software and with your particular backup application. Sources for additional information are listed in Appendix A of this AppNote.

Overview of SMS and NDS

This section presents a brief overview of SMS and

NDS, focusing on concepts that relate to backup and restore issues. If you are already familiar with SMS and NDS, skip ahead to "Developing a Data Protection Plan." If you need more detailed information than is given here, see the additional resources listed in Appendix A.

SMS and Compatible Backup Programs

Novell developed Storage Management Services as an open architecture for interfacing storage management products with the NetWare operating system. Designed in cooperation with third-party application developers, the SMS architecture provides a standard interface for storing, accessing, and managing data on a variety of computing platforms (NetWare servers, DOS/Windows clients, Macintosh clients, and so on). Through SMS, applications can see a consistent view of data across dissimilar file systems and other resources such as SQL databases, the NetWare bindery, and NetWare Directory Services.

SMS itself is not a product but a framework for developing storage management engines. SMS provides basic backup, restore, and data migration capabilities. Third-party developers can then add features to deliver their own backup and data storage solutions, without having to worry about the intricacies of the operating system or file systems. Customers can choose whatever SMS-compatible applications meet their needs, independent of their hardware and software decisions.

Components of the SMS Architecture

The SMS architecture consists of the primary components described below.

Storage Management Engine (SME). Central to the SMS architecture is the Storage Management Engine (SME). The SME communicates with network clients through a common interface that ensures cross-platform support and the ability to support new platforms and versions with minimal changes. The most common implementation of the SME is a backup and restore application. The SME contains most of the value-added features and is the component most often provided by third-party developers. Novell provides a basic SME with NetWare called SBACKUP.

Target Service Agent (TSA). In SMS terms, a target is any item on the network that requires backup. Examples of targets include SQL database engines, NDS databases, print servers, clients, and NetWare servers. An SMS Target Service Agent (TSA) is a software module that knows how to scan, read, and write the target file system data. The primary functions of an SMS TSA are to prepare the target data for backup or restoration, and to communicate with the SME. The TSA is the only module in SMS that needs to understand the details of the target file system's structure (path specifications, directory hierarchy, access rights, and so on). An SMS TSA for a NetWare server, for example, understands all about name spaces, file and directory attributes, security privileges, and so forth, for the data on that server.

Because the knowledge of the target file system structure is confined to the TSA, the TSA can package data from the target and present it to the SME in a generic format. This generic presentation of data allows one SME to interact with many different kinds of TSAs. The modularity of SMS components also allows a backup/restore application to support new releases of an operating system as long as there is a TSA that understands that operating system's data. When releasing a new version of the NetWare operating system, for example, Novell need only provide new SMS TSAs to allow existing SMS-compatible products to service the new operating system.

Novell currently has SMS TSAs available for NetWare 3.11 and 3.12 servers, NetWare 4.01/4.02 and 4.1 servers, NetWare Directory Services, NetWare SQL, and DOS/MS Windows, OS/2, Macintosh, and UnixWare clients.

Storage Management Data Requester (SMDR). SMDR is the communication link between the backup application (SME) and the SMS TSAs. It is the function of SMDR to locate the SMS TSAs on the network and to communicate instructions to the intended agent. SMDR is also the communication link to the SDI.

Figure 1 illustrates how these components work together within the SMS architecture.

Figure 1: SMS architecture.


System Independent Data Format (SIDF)

SIDF is an international standard(ECMA-208) which defines a common format for storing data on secondarystorage devices such as tape. SIDF ensures compatibility betweencurrent and future SIDF-based products, and stored or archiveddata. SIDF allows users the flexibility to upgrade or change theirbackup applications over time, but continue to read their olderdata. SMS supports SIDF through both the SDI and its TSAs, whichgenerate data streams in the SIDF format.

Novell originally developed SIDF, but has since turned it over to an independent, cross-industrycommittee called the SIDF Association, of which Novell is a member.Designation of products as "SIDF compliant" is being handled exclusively by the SIDF Association. Anyone wishing further information about SIDF can contact the SIDF Associationheadquarters at 708-255-3003.

The SME is the taskmaster of SMS. It conveys to the TSA what kind of data the user wants to work with. During a backup session, the SME receives processed data from the TSA and (through the storage device interface) gives it to the device driver to be written to the storage media. During a restore session, the SME tells the device driver which data the user wants to restore. The SME then receives the data from the driver and passes it to the TSA, which writes the data onto the target.

Currently, the SME runs on a NetWare file server as a NetWare Loadable Module (NLM). It is the SME that handles all the user interaction and forwards the users' requests to the TSAs and to the device driver. SMS TSAs can be loaded as NLMs on the host file server or on other target servers, or they can be loaded as memory-resident modules on client machines.

Using SMS-Based Products to Back Up NetWare 4

NetWare 4 introduces several new features to enhance the manageability of user data. For example, features such as data compression and data migration allow customers to make more efficient use of the network's online and offline storage. These features also require new capabilities for data backup and recovery applications. Backup applications designed for the NetWare 3 environment may not handle NetWare 4 data correctly. (For information about the capabilities of specific backup applications, contact the application vendor.)

Novell provides support for NetWare 4's new features through the SMS architecture. SMS-based applications utilize the services provided by SMS to ensure protection of NetWare 4 servers. SMS also provides a TSA designed specifically for NetWare Directory Services, called TSANDS. SMS-compatible backup applications can take advantage of this agent for proper handling of NDS.

For backing up and restoring NetWare 4, Novell recommends that you use applications which fully support the SMS architecture. Applications that do not fully utilize SMS services may not be able to provide full support for all of NetWare 4's features. Before purchasing a backup solution for NetWare 4, verify how your preferred solution handles these features. (See Appendix B for a list of backup products that have been certified for NetWare 4.)


Note: Because implementation details vary from vendor to vendor, itis important to review the documentation and readme files includedwith the SMS backup application of your choice. If the solutionyou choose has been tested and approved by Novell Labs, you canalso obtain information on this product from Novell Labs Bulletins.(See the Research Index at the back of this AppNote edition forinformation on how to access these bulletins.)

The examples in this AppNote use Novell's SBACKUP as the backup/restore application. For instructions on using third-party backup programs, refer to the documentation provided by the vendors (see Appendix A for suggested references).

NetWare Directory Services (NDS)

In place of the server-centric bindery used to keep track of network resources in previous releases of NetWare, NetWare 4 uses a global, distributed name service called NetWare Directory Services. Through NDS, NetWare 4 provides unified network administration for NetWare users. NDS eliminates the allocation of network resources on a server-by-server basis and provides users access (based on their assigned rights) to files and resources throughout the network with a single NetWare login. Users no longer need to log in to separate servers or know the physical locations of print queues and print servers. Network resources are now managed and controlled as a single entity.

With NDS, logical "objects" are used to represent servers, users, groups, print queues, just as they did in NetWare 3. In NetWare 4, however, the number of objects has been expanded to include other types of resources, such as server volumes, directory maps, and so on. These objects are organized into a hierarchical structure that resembles an inverted tree, wherein objects representing groups of network resources branch downward from a single Root object.


Note: The word "directory" is often used as an abbreviated term for the NDS database as awhole. To avoid confusion with references to a directory in thefile system, this AppNote will use "Directory"(with a capital D) when referring to NDS. It will alsouse the term "NDS tree" rather than "Directory tree" to refer to the logical database structure.

The rules governing what types of objects can be stored in the NDS database and what attributes they can have are found in the Directory's schema. The schema is extensible to allow developers to define and use objects that aren't included in the default schema that comes with the NetWare 4 software.

There are many other concepts and features of NDS that are beyond the scope of this document (Appendix A lists some additional references). To keep this document focused, we'll highlight just the aspects of NDS that should be understood in order to safely recover from a loss of all or part of the NDS database. Two of these key aspects are partitioning and replication.

Partitions. NDS is a distributed naming service. You can divide the Directory information into portions called partitions and store these partitions on NetWare 4 servers throughout the network. Partitions are transparent to network users; to them the network appears as a single collection of objects and services. With partitions, no individual server needs to physically contain the complete NDS database. NetWare 4 maintains special links between partitions so that users can access information from anywhere in the NDS tree (provided the users have the appropriate access rights).

The main purpose of partitioning is to provide scalability for expanding networks. Partitioning allows NDS to accommodate networks ranging from one server to hundreds or thousands of servers. Thus the size of the NDS database is not an issue as your network grows. Partitioning also facilitates the placement of NDS data where it is needed for quicker access. In networks that span separate geographic sites, you can create copies of the partitions and place the copies on local servers to improve response time for users accessing the Directory. (These copies are called replicas, as explained under the next heading.)

Figure 2 illustrates the use of partitions in a sample network.

Figure 2: Partitioning example.


Note: In NetWare 4.1, the NDS tree name is equal to "[Root]"regardless of what name you assign at installation. The tree nameis used by the NetWare administrative utilities to distinguishone NDS tree from another on the same network.

Here are some important basics to keep in mind about partitions:

  • A partition is a subtree, or branch, within the NDS tree. Each partition is identified by the name of its top-most object (the one closest to the root of the tree).

  • A partition contains only NDS objects and related data. It does not include any information about file system data files or directories.

  • Partitions may not overlap. An NDS object can exist in one and only one partition.

You can create partitions in three ways:

  • During the initial installation of NDS onto the first server in a tree (via the NetWare 4 INSTALL.NLM utility)

  • Through the Partition Manager (PARTMGR) text utility

  • With the Partition Manager tool of the NetWare Administrator (NWAdmin) graphical utility

Replicas. One of the main reasons Novell designed the NDS database to be partitioned is so that Directory information can be easily replicated, or copied. A replica is simply an identical copy of a partition. Replicas allow multiple copies of each NDS partition to be stored on NetWare 4 servers around the network.

Replicas perform two primary functions in NetWare 4 networks:

  • They provide faster access to NDS information for users across a WAN data link. Placing replicas of a partition close to the users who most often access that NDS data can improve response time during authentication, Directory searches, and object modifications.

  • More importantly, replicas provide fault tolerance for NDS data by eliminating a single point of failure. If a server containing a replica goes down, a replica on another server can continue to authenticate users and to provide information on objects in that partition. A replica can also be used to copy NDS data onto a server that is being restored after a hardware failure.

The methods listed above for creating NDS partitions also produce the replicas. There are three types of replicas you can create with the NetWare utilities:

  • Master replica. This is the first replica created when the partition is defined. Itis a writable replica used to provide database integrity during partition operations (splits, joins, moves, rebuilds, and type changes). The master replica "locks" all replicas of the partition so that no other partition operations can be performed while that operation is in progress.

  • Read/Write replica. Subsequent replicas created for a partition are usually Read/Write replicas. These replicas can be used for authentication. Since they are writable, they can also be used for users' login requests.

  • Read-Only replica. This type of replica is not writable, so it can be used for authentication but not for login requests. It can only be updated from other replicas, not from a client application. Due to their limited functionality, Read-Only replicas are seldom used.

Figure 3 shows a typical example of replication on a sample network.

Figure 3: Replication example.

Here are some important concepts to keep in mind about replicas:

  • For each partition of the NDS tree, there can be only one master replica. (This is sometimes erroneously referred to as the "master partition").

  • You can have any number of read/write and read-only replicas of a partition. Novell recommends that you have at least three replicas of each partition (except in single-server networks, which rely on backups, not replication, for fault tolerance).

  • You can store more than one replica on a server, but you can have only one replica of the same partition per server. It is not necessary for one server to hold all of the replicas. Storing replicas on several servers will distribute the workload of updating and synchronizing NDS between servers.

  • A replica does not necessarily have to be stored on a server whose NDS object is located within the partition. Any replica can be stored on any server on the network. For example, Server S1 in Figure 3 holds a replica of the East partition even though its Server object is located in the Eng partition. It also holds replicas of the Root and Eng partitions.

As a group, all of the replicas of a given partition are referred to as a replica ring or replica list. With writable replicas of the NDS partitions spread throughout the network, it is essential that the information be kept in synch across the replicas of a partition. To accomplish this, all NDS changes - such as an administrator deleting a queue object or a user changing his or her password - are propagated to all replicas in the ring.

Subordinate Reference. Before we conclude this discussion of replicas, it is important to understand a fourth type of replica: the subordinate reference. NDS automatically creates and maintains subordinate reference replicas to link parent and child partitions in the tree. A subordinate reference replica is created whenever a parent partition exists on a server, but the child partition is not on that server.

A subordinate reference replica does not contain all of the NDS objects normally stored in a partition. Instead, it contains only a copy of the child partition's root-most object, including all of its attributes. The partition root object contains attributes necessary for locating other replicas and tracking replica synchronization.

Replication - Your First Line of Defense

Maintaining replicas of every partition provides an online backup and recovery safeguard for NDS information. In the event of an unforeseen loss of a server or volume, the network administrator can (by following the procedures outlined later in this AppNote) restore lost NDS data through an active replica. Replication also allows a replica that becomes damaged to be either rebuilt or recreated from another replica.

There are situations when replication can not or does not provide sufficient protection against the potential loss of NDS data. One such situation is a single-server network. Since you don't have another server to store a replica on, there is no online backup available through replication. Another case is when the network administrator (or any user with sufficient rights) accidentally deletes a valid NDS object. The deletion is propagated to all other replicas, making it impossible for the object to be recovered from a replica. A third situation could occur if a major catastrophe (such as a fire, flood, earthquake, or terrorist attack) destroyed an entire site, wiping out the servers that held all the replicas of an NDS partition.

To guard against loss of NDS data, it is absolutely essential that a backup of NDS be maintained on a regular basis. The remainder of this AppNote will concentrate on backing up and restoring NDS data using an SMS-based backup program.

Developing a Data Protection Plan

While maintaining tape backups is important, it is only part of what should be involved in a comprehensive data protection plan. To adequately protect valuable network data (including both file system and NDS database information), your overall plan should include provisions for the following:

  • Redundant hardware

  • NDS partitioning and replication

  • Backup and restore system

  • Disaster prevention and recovery

Redundant Hardware

Although the reliability of computer systems has improved considerably over the last several years, hardware failures still can - and will - occur. Numerous technologies are currently available to provide more reliable data storage and better protection against hardware faults. Many of these technologies involve hardware redundancy of some kind.

For example, RAID (redundant array of inexpensive disks) hard disk systems are capable of maintaining data even if one of the disks fails. NetWare's disk mirroring and duplexing feature also protects against hardware failures in the disk channel. NetWare SFT III takes fault tolerance a step further and allows two servers to be mirrored. If a failure occurs on one server, the other one continues to service the network without interruption.

Another possibility is to maintain a "standby" server to which you can attach your regular server's external disk subsystem in case the server experiences an internal hardware failure. Several third-party vendors offer standby-server products that allow a "hot copy" of data from one system to another.

NDS Partitioning and Replication

In a network with more than one server, NDS provides online backup of the NDS database through the placement of partition replicas on multiple servers. For example, in a two-server network with one partition, the NDS database is protected by placing a replica of the partition on each server. If one replica is lost because of a hard disk failure or because volume SYS is damaged on a server, NDS remains intact due to the replica on the other server.

If you lose a partition and you do not have a replica of thatpartition, you could lose access to a part of your NDS tree. Itis a good idea to have one replica stored on a server in an alternatelocation, if possible. (In certain situations this will increasenetwork traffic over wide-area links; you'll need to weigh the benefits and drawbacks to determine the bestNDS configuration for your network.)

Replication is the first line of protection for the NDS database. However, it does not provide sufficient protection in a single-server environment, or if replicas do not exist, or if all replicas become damaged. For these reasons, a regular backup of NDS must be maintained.

Backup and Restore System

While replication provides the fault tolerance needed to maintain a working NDS tree, you must also include a full, offline, SMS-based backup of NDS in your data protection plan. Keep in mind that NDS is a distributed name system that is dependent upon files stored on multiple servers. You cannot back up and restore the NDS files directly. You must use the Target Service Agent TSANDS.NLM which is used by SBACKUP and other SMS-based applications.


Note: It is highly recommended that the backup product used to backup your NetWare 4 servers utilize Novell'sTSANDS to back up NDS, and TSA410 (or TSA 400) to back up thefile system.

Performing regular NDS backups protects your NDS database from loss or failure in the following situations:

  • The partition in a single-server network fails (no online replica is possible).

  • Due to inadequate replication, you lose all replicas of a partition after a hardware failure or disaster.

  • A serious NDS failure occurs and, as a result, the replicas are in a state which renders the Directory nonfunctional.

If all servers are destroyed because of a disaster (such as a fire or flood), you must perform a complete restoration of NDS and file system data from your backups. Recommended procedures for doing this are given later in this AppNote.

Disaster Prevention and Recovery

A disaster prevention and recovery plan provides both preventative and responsive action to system or NDS failure caused by hardware failure in a NetWare server or by corruption in an NDS partition. Writing and testing efficient disaster recovery plans and procedures is essential for recovery from catastrophic failures (fire, floods, earthquakes, and so on). For information on disaster recovery plans, see the manufacturer's documentation for your backup system or contact your Novell support provider.

General NetWare 4/NDS Backup and Restore Issues

When dealing with NetWare 4 and NDS from a backup/restore perspective, there are several technical issues you need to be aware of. These issues are discussed in this section.

NDS is a global, distributed name service It is important to remember that with NDS, you are dealing with a global, distributed name service. The network of servers that comprise an NDS tree continually exchange updates and other time-sensitive information. Like the bindery in NetWare 3, the NDS "database" exists as a set of files that are stored on NetWare servers. The NDS files are stored on a server's SYS volume, and they are hidden so that users won't delete them or tamper with the contents of the Directory. However, you can't just back up the NDS files like you could the bindery files.

NDS backup is not server-centric If you are accustomed to the NetWare 3 environment, you are probably used to being able to back up your network on a server-by-server basis. For each server, you could specify what you wanted to back up - the data, the trustee assignments, the bindery - in any combination. It didn't matter if Server B was down while you were backing up Server A, or if user JDOE had an account and trustee rights assigned on both servers. NetWare 3 maintained the bindery, user account, and trustee rights information separately on each server (see Figure 4).

Figure 4: NetWare 3 backup is done on a server-by-server basis.

NDS is not server-centric, and neither are its backup and restore procedures. When backing up NDS, you are essentially backing up data that is spread out over multiple servers. A user in one partition may have trustee rights assigned on a server that doesn't hold a replica of the user's NDS object. To handle all the necessary links and dependencies between objects, the backup/restore system must be able to navigate the entire NDS tree. SMS-based backup products use the TSANDS agent to "walk the tree" and access the necessary data.

Object IDs are not backed up In both NetWare 3 and NetWare 4, a random ID number is assigned when an object is created. Both versions use object ID numbers to keep track of things like users' trustee rights to directories and files in the file system. These object IDs are listed in the Directory Entry Table (DET) on each server volume, and are thus server-centric. Object IDs are included in bindery information, which is not global. In NetWare 3, the object ID numbers are backed up along with file system data and other bindery information about objects.

In NetWare 4, SMS-compatible products store objects' full distinguished names on the backup media, not their ID numbers (see Figure 5).

Figure 5: In NetWare 4, SMS backup writes distinguished names, instead of object IDs, to the storage media.

An object's distinguished name is a unique identifier consisting of the names of each object between itself and the [Root] object of the tree, separated by dots. For example, the distinguished name of user Fred in the NDS tree shown in Figure 5 is "Fred.Eng.ABC".


Note: The name backed up is actually the typeful distinguishedname (.CN=Fred.OU=Eng.O'ABC). Typeless names are shown in thisAppNote for simplicity's sake.

To understand the reason for this, we need to examine how object IDs are used in more detail. We'll use the example of users' trustee rights assignments in the file system. In NetWare 3, if a person needs rights to files on several servers, a separate user account must be created on each server. Each user object has its own object ID that is specific to its host server. In NetWare 4, a user typically has only one user object in the NDS tree. However, each server on the network still generates an ID number for every object. Certain services in NetWare, such as file services, use these local object IDs maintained by a server to identify NDS objects. The local object ID numbers are not coordinated between servers, so the local ID numbers for the same object are different on each server.

One other concept is important to understand here. If an object with the same distinguished name as on the backup media already exists in the NDS tree, its object ID is not overwritten during a restore. If an object with the same name does not already exist in the tree, it is assigned a new object ID when restored (see Figure 6). This occurs on every server where the object is used.

Figure 6: If an object with the same name does not exist in the NDS tree, a new object ID number is assigned when the object is restored.

As stated above, trustee assignments are stored as part of the file system as an ID, and they are backed up by default when the file system is backed up with the SMS TSAs. If a User object is deleted or lost and then recreated or restored, its object ID will not be the same as it was before. This is why the SMS TSA410 and TSA400 modules use objects' full distinguished names to back up the trustee rights from the file system. If a User object is deleted and recreated 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 as on the backup media exists in the NDS tree when the file system is restored, the TSA can interact with NDS to rebuild the DET to reflect new object ID numbers. Note that for this to work, NDS objects must be restored before file system information is restored.

For additional information about object ID and trustee issues, see the section on "Special Cases to Watch Out For" in this AppNote.

Partition boundary information is not backed up In an NDS tree, replica information can change over time and is dependent on the current state of the Directory. It is impractical to assume that partitions and replicas will stay the same between a backup at one instant in time and a later restoration. Thus when NDS information is backed up, no information about partition boundaries (or replicas) is stored on the backup media. As shown in Figure 7, the "image" of the Directory stored on the backup media looks like a tree with everything in one partition.

Figure 7: Partition boundary information is not backed up.

Restoring NDS does not affect the current partitioning and replication in the tree. If partitions and replicas exist when NDS information is restored, those partitions and replicas will be fully utilized (see Figure 8).

Figure 8: When restoring to an existing NDS tree, current partitions are used and object IDs are preserved.

If partition information does not exist when a restore is performed (for instance, after a total loss of an NDS tree), the entire tree structure is placed into one partition (see Figure 9). You must then manually re-establish other partitions and replicas.

Figure 9: When restoring an NDS tree from scratch, all objects are restored into one partition and new object IDs are assigned.

Placeholder (Unknown) Objects

An NDS object is "unknown" whenever not enough information is known about the object, such as when one of its mandatory attributes is missing. (In NWAdmin, unknown objects appear with a "?" icon.) During a restore of NDS, unknown objects are created when restoring an object which has an Access Control List or any other attribute that refers to other objects that do not currently exist in the tree. This condition is common in a restore, since only one object can be restored at a time. When this condition arises, a "place-holder" (the unknown object) is created until the real object is restored.

As an example, say that object User1 has been given property and object rights to 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 ACL of User2 lists User1, which does not currently exist. 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 actual object for which the placeholder was created, the object will remain in the tree as type "unknown". You can expect to see unknown objects after a restore if all network resources (servers, volumes, and so on) are not in place before the restore is started. (See the section "Unknown Objects After a Restore" in this AppNote for more information.)

Central vs. Distributed Backup Administration

Since NDS is a distributed naming service, there can be multiple administrators who assist in maintaining the tree. In dividing up this responsibility, be sure to consider your backup needs and grant the necessary rights to those users who will perform the backup and restore operations. In many cases, it works well to have one overall administrator who has ultimate responsibility and a global view of the entire NDS tree for backup and restore purposes. Having a central backup administrator will help eliminate problems with incomplete backups resulting from the backup user not having sufficient rights to certain portions of the NDS tree.

Backup Considerations for Various Network Environments

Novell has identified four representative network environments, each of which has different ramifications on backup and restore strategies.

Single Server/Single Partition. In a single-server network, you can't have more than one replica. Further replication is not possible because there is no other server on which to store a replica. In this environment, you absolutely must maintain a full offline backup of NDS. This is the only way you'll be able to restore lost NDS data.

Multiple Servers/Single Partition. In a network with more than one server holding a single NDS partition, you should have at least two replicas of the partition, preferably three. Maintaining an offline backup of NDS is also essential. If the servers are all located at the same site, be prepared in the event of a disaster that could destroy all the servers at once. Store a complete set of your backup media at another location if possible.

Multiple Servers/Multiple Partitions. In this environment, both online replication and offline NDS backup are essential. Wherever possible, have at least three replicas of each partition located on servers throughout the network. Try to avoid having all replicas of a partition located on servers at the same site. It is a good idea to keep a complete set of your backup media off-site as well. Because SMS backup ignores partition boundaries, restoring the NDS tree (especially a partial restoration) is more involved. You'll need to keep a written record of how your partitions and replicas are set up.


Note: If you lose one partition and all its replicas, it is possibleto restore the objects that existed in that partition. However,the procedure for rebuilding the links to the lost portion ofthe NDS tree requires significant technical expertise and shouldbe performed with the assistance of a qualified technician. Fordetails, see the discussion of Scenario 4 under "ExampleRestore Scenarios" in this AppNote.

Multiple Servers/WAN Connections. In either of the above two environments, remote sites connected via WAN links require additional considerations for backing up the NDS tree. In particular, you should consider backup and restore needs when deciding how to administer the tree (either centralized with a single administrative user account that has full rights to the entire tree, or distributed with separate administrative accounts at each site). To minimize data traffic across WAN links and to speed up backup and restore operations, consider performing backups locally at the remote sites. You might also design your NDS tree so that you have replicas of every partition stored at the same site as the backup host server. Then you can back up and restore NDS without having data go across WAN links. If you do back up and restore NDS and file system data for remote sites from a central location, you should ensure that the WAN connections (routers, bridges, telecommunications links, and so on) are functional before you begin. If your host and target servers/work-stations are not able to communicate across the network, a complete backup or restore is not possible.

Backing Up NetWare 4

This section gives guidelines and procedures on how to obtain a "good" backup of the NDS database and file system data in a NetWare 4 network.

General Backup Procedures

How Often to Back Up NDS. In general, NDS should be backed up on a regular basis. The frequency of this backup depends on how often changes and updates are made. For a tree that changes often, you may want to perform an NDS backup every time you do a full backup of all servers on the network. You should definitely back up NDS prior to major tree modifications.

An NDS tree cannot be backed up entirely if all replicas of any partition are offline. To get a full backup, the entire NDS tree needs to be functioning (all partitions synchronizing normally). If not, you will have to include and exclude containers to get a usable backup.


Note: For more information about how to check your NDS tree for propersynchronization, refer to the accompanying document entitled "TroubleshootingTips for NetWare Directory Services."

Backing Up NDS. To back up NDS, the TSANDS.NLM module must be loaded on one server in the tree. Preferably it should be the server containing a replica of the largest partition. This will minimize network traffic during the backup process and improve performance when the backup program must perform name resolution across the NDS tree.

The version of TSANDS.NLM that shipped with NetWare 4.1 (and later versions) allows selective backup and restoration of an NDS tree. (Not all third-party backup applications support this option. Check with the application vendor for details on product features.) In SBACKUP, you can begin the backup of the Directory from any container object in the tree, and the process will continue from that point downward to the end of that portion of the tree. If the selected container is the Root of the tree, the entire NDS tree will be processed. This allows you to back up the entire tree or subsets such as a single branch, a single container, even a single leaf object. Also, a new scan option has been added which will allow backup of only those objects for which the backup user has supervisory rights.


Note: We recommend that you back up the entire NDS tree in a sessionwhenever possible. Although partial NDS backups and restores arenow possible, there are numerous precautions and additional issuesyou must take into account. (For more information, see the sectionon "Partial NDS Restores" in this AppNote.)

Backing Up the File System. 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. For NetWare 4.1 servers, load TSA410.NLM. (For NetWare 4.01 and 4.02 servers, load TSA400.NLM.) Once these SMS TSA modules are loaded, you can proceed to load the device drivers for your backup hardware and run the backup program of your choice.

To get a proper backup of file system information, make sure your backup application can handle the NetWare file system's name spaces, extended attributes, trustee rights, compression, and so on. It is also useful to have the ability to do a trustee-only backup (the option to exclude data streams).

Specific Steps for Backing Up NetWare 4 with SBACKUP

This section provides specific steps for backing up NetWare 4 - both NDS and the file system - using Novell's SBACKUP software.

Before starting the backup, make sure NDS is fully functional (all partitions synchronizing). Use the "Troubleshooting Tips for NetWare Directory Services" document as a guide. If your backup host and targets communicate across a WAN, check the status of the WAN links to verify that they are operating properly. All servers and workstations at remote sites that are participating in the backup must be able to communicate across the network.

Load the SMS TSAs

  1. At the designated server, load TSANDS.NLM (required on only one server in the tree, preferably one with a replica of the largest partition).

  2. Load TSA410.NLM on each NetWare 4.1 server for which a file system backup is to be created. (On NetWare 4.0x servers, load TSA400.NLM.)

Load SBACKUP and Its Supporting Modules

  1. At the server on which you will run the backup program, load supporting drivers for the backup tape device. The accompanying document entitled "SBACKUP Configuration and Usage Notes" provides more specific information.

  2. Load SBACKUP.NLM.

Back Up NDS

  1. From SBACKUP's main menu, choose the "Backup" option. The program displays a list of servers running SMS Target Service Agents; select the server that has TSANDS loaded on it. If the server has other TSAs loaded, select "NetWare 4.1 Directory" from the list of Target Services.

    Following the screen prompts, log in as the backup user, specifying the correct context if necessary. The username must be the typeful distinguished name (for example, .CN=Admin.O=ABC).

    Select the backup device and media, and set the location of your log and error files. From the Type of Backup menu, select "Full: All Data on Target" and then enter a description of this backup session. Press <F10< to save your choices and continue.

    SBACKUP asks whether you want to proceed with the backup now or later; make your choice. If necessary, you are prompted to enter a label for the backup media. As the backup begins, SBACKUP displays a screen showing the progress of the program and any errors encountered.

    After the entire NDS tree has been processed, you should see a prompt that says "The backup process was completed normally." Press <Enter< and then <Esc< to return to the main menu. Select "Log/error File Administration" and review both the log and error files to verify that the NDS backup was completed successfully.

    Step 5 needs to be performed only once per NDS tree (unless you are doing a selective backup).

Back Up the File System

  1. To back up the file system on each server, choose the "Change Target to Back Up From or Restore To" option from the main menu. From the list of servers with Target Services loaded, select the desired server. If the server has other TSAs loaded, select the "NetWare File System" target service.

    Following the screen prompts, log in as the backup user, specifying the correct context if necessary. The username must be the typeful distinguished name (for example, .CN=Admin.O=ABC).

    Select the backup device and media, and set the location of your log and error files. From the Type of Backup menu, select Full, Differential, Incremental, or Custom. By default, SBACKUP's Full option will back up all files, directories, and trustee rights. When prompted, enter a description of this backup session. Press <F10< to save your choices and continue.

    SBACKUP asks whether you want to proceed with the backup now or later; make your choice. If necessary, you are prompted to enter a label for the backup media. As the backup begins, SBACKUP displays a screen showing the progress of the program and any errors encountered.

    After the specified portion of the file system has been processed, you should see a prompt that says "The backup process was completed normally." Press <Enter< and then <Esc< to return to the main menu. Select "Log/error File Administration" and review both the log and error files to verify that the file system backup was completed successfully.

    Repeat Step 6 for each server on which you want to perform a file system backup.

Verifying the Backup in a Test Environment

Your ability to restore NetWare 4 NDS and file system information hinges on the reliability of your backup. At this time, it is not advisable to perform a partial NDS restore on your production network to verify that your backup system works. If possible, you should set up a small test environment with one to three non-production servers and use that to test your system's backup and restore capabilities. Verify that NDS can be restored from the backup media. Also make sure you can restore data that spans more than one tape (this is a quick way to ensure the integrity of backed-up data).

Restoring NDS Information

This section gives guidelines and procedures that have been tested and verified by Novell for restoring NDS information (and file system data) in a NetWare 4 network.

The most important issue to understand when there is a loss of NDS data is: What is really lost? Only when you know this can you take the proper steps to restore the NDS information. An overall understanding of how NDS works and an intimate knowledge of your particular tree (including proper records of how it is set up) are essential for success. For example, it is critical to have a record of where Server objects, partitions, master replicas, read/write replicas, volume objects, and Admin objects are located. Use the worksheet provided at the end of this AppNote to help you.

Backup and Restore Tips for NetWare 4


Use replication as the first level of protection for NDS. In multiple server networks, have at least three replicas of every NDS partition stored on various servers throughout the network. Use your offline SMS backup to restore NDS data only if it cannot be restored from a replica.

Choose a backup product that is certified for NetWare 4. To handle NDS and other NetWare 4-specific features, the third-party backup program you use should be certified by Novell Labs. It should also support SMS and its TSAs. (For product certification information, call Novell Labs FaxBack at 800-414-5227 or 801-429-2776.)

Make sure you have the latest versionsof backup-related software. Periodically check with Novell and with your third-party vendor to ensure you have the latest version of the backup program, device drivers, TSAs, and so on. Novell provides updates on NetWire, the World Wide Web, and the NSEProCD-ROM.

Stay current with the newest operating system patches and NLMversions. Periodically check Novell's electronic distribution sources (NetWire, World Wide Web, and NSEPro CD-ROM) for updates to the NetWare 4 operating system, Directory Services (DS.NLM), NDS utilities (such as DSTRACE and DSREPAIR), andso on.

Keep a record of whereNDS partitions and replicas are located. Restoring NDS is much smoother if you have a record of your partitions and replicas. Be sure to note the full name of the container into which each server is added and which replicas (if any) are stored on the server. To help you do this, a replication worksheet is included at the end of this AppNote. Or you can use DSREPAIR to record this information to a log file. (See the "Troubleshooting Tips for NetWare Directory Services"document for more information.)

Ensure that NDS is fully functional and WAN links areup before backing up or restoring. WAN links should be up and servers should be able to communicate with each other. All NDS partitions should be synchronizing without errors. (Refer to the "Troubleshooting Tips for NetWare Directory Services" documentfor more information.)

Back up NDS regularly. The frequency of backing up NDS depends on how often you make changes to your tree. For trees that change often, back up NDS every time you do a full network backup. Always back up NDS before making major modifications tothe tree.

Verify the completeness of each backup and restore session. After each backup and restore session, check the appropriate error and log files to make sure the process completed successfully and didn't skip crucial portionsof your data.

Don't changeNDS object names and contexts when restoring. Don't use a restore situation to "redesign" your NDS tree. The restore process will go much more smoothly if you keep the NDS tree the same and restore servers to thesame container objects as they were in before.

Always restore NDS information before restoringfile system information. File system trustee assignments will be affected by restoring NDS objects. To avoid problems, always restore NDS information before thefile system.

Remember to "re-update"your software when reinstalling servers. After reinstalling NetWare 4 or NDS from the original media, remember to reapply OS patches and recopy updated drivers, NLMs, utilities, etc. before proceeding with arestore.

General Restore Procedures

Whenever possible, use an active replica to restore what was lost from the NDS tree. If this is not feasible, follow this general process to restore from an SMS backup:

1. Restore NDS information first.

2. Restore file system data and trustees last.

It is vital that you perform these steps in the order indicated above. Restoring file system data and trustees before you restore NDS objects can result in lost or incorrect trustee rights.

NDS should be functional (partitions synchronizing normally) before you proceed with a restoration. It is difficult for an NDS restore to complete successfully in a dysfunctional tree. (See the accompanying document "Troubleshooting Tips for NetWare Directory Services" for help in verifying proper synchronization.)

When restoring file system trustees, objects with trustee rights being restored should exist in the tree at restore time. The object ID for the object on the server being restored will be used. A replica containing the object does not have to be on the server. NDS creates external references as necessary. (An external reference is a pointer to an NDS object not found locally on the server; it is used to authenticate and reference objects that are not local to the server.)

Example Restore Scenarios

The instructions in this section detail specific recovery procedures for the following scenarios:

  • Loss of a non-SYS volume

  • Loss of a SYS volume or an entire server

  • Loss of the entire NDS tree

  • Loss of a single partition within the NDS tree

With the NetWare 4.1 release (and later releases) of TSANDS, you can do a selective restore of NDS information. However, depending on what part of NDS you are trying to restore, certain precautions must be taken. Review these example restore scenarios and follow the steps that are appropriate for your situation.

Before proceeding with any of these procedures, read the additionalinformation discussed under "Special Cases to Watch Out For" in this AppNote.

Scenario 1: Loss of a Non-SYS Volume

If you experience a hard disk failure that does not involve volume SYS, you do not need to modify or reinstall NDS. All that is required is a restoration of file system data and trustee rights.

Procedure. To restore a volume after a hard disk failure not involving volume SYS, follow these steps:

  1. Do not delete the Volume object for the failed volume from the NDS tree.

    Leaving the Volume object intact preserves any references that other objects (such as Directory Maps and Queues) may have to that volume. If the Volume object is deleted and you had objects that depended on this volume, you will need to re-establish the relationships through a selective NDS restore according to the guidelines in the "Partial NDS Restores" section of this AppNote.

  2. Bring down the server and replace the bad hard disk(s).

  3. Bring the server back up and recreate the volume using INSTALL.

    At the server console, load INSTALL.NLM. Create a NetWare partition on the new disk and redefine the volume. INSTALL will prompt you to log in, after which it places the Volume object back into the NDS tree. When prompted, choose to mount the server volume(s).

  4. Restore the file system from your SMS backup.

    If you are using SBACKUP, select the Custom restore option, choose "Subsets of the session to be restored," and then choose "Include major TSA resources." Press <Ins< and select the desired volume from the list. Proceed with the restore as usual.

  5. (Optional) Verify proper restoration of the data, trustee assignments, file ownership, and other related information by spot-checking some of the restored directories and files.

    Commands that might be helpful include RIGHTS /T /S (displays users, groups and other objects that have explicit trustee assignments in a directory and its subdirectories) and NDIR (displays owners and other NetWare file information).

Scenario 2: Loss of a SYS Volume or an Entire Server

A hard disk failure involving volume SYS affects the entire server and halts all NetWare operating system activities. Because the NDS files are stored on volume SYS, loss of the SYS volume is equivalent to removing NetWare 4 and NDS from the file server. You must reinstall NetWare 4 and NDS before you restore your data.

The procedures for this scenario are divided into two cases: loss of the only server in a single-server network, and loss of a single server in a multiple-server network.

Scenario 2a: Single-Server Network In a single-server network, a failure in that server will bring all network operations to a halt. The same situation exists if the failure affects only the hard disk(s) containing the SYS volume. Since there are no replicas in a single-server network, you can't recover any NDS information from a replica. After repairing or replacing the failed hardware, you must restore the entire NetWare environment, including NDS, from an SMS backup.

Procedure. To restore the single-server network from a backup, perform the following steps:

  1. Correct the problem that caused the server hardware to fail.

  2. Reinstall NetWare 4 and NDS on the server through the INSTALL utility.

    Use the same server name, Admin parent container and password as were used when the backup was created. Make sure all hard disk partitions are at least as large as they were on the previous server, and that all volumes are defined as before. (Reconfiguring your server and volumes during a restoration is not recommended. Once your server is back up and running, you can make any changes that are necessary.)

    INSTALL should mount all volumes as part of the installation process.

  3. If the server had volumes other than SYS that were not affected by the failure, run DSREPAIR to purge the file system of invalid trustees on those volumes.

    This step is necessary to clean up the volume DETs so that trustee assignments can be restored correctly. Type LOAD DSREPAIR at the server console and choose the "Unattended full repair" option. (This automatically includes the option to purge invalid trustee information.)

  4. Load the SMS TSAs and the NLMs necessary for your backup/restore program.

    At the server console, type LOAD TSANDS and then LOAD TSA410 (on a NetWare 4.0x server type LOAD TSA400). On the backup host machine, load the backup device drivers and program software. If you are using Novell's SBACKUP, load the required backup device drivers and then type LOAD SBACKUP to start the program.

  5. Restore the entire NDS session from your SMS backup.

    You will have no session files to work from at this point. Choose the option to restore without session files.

  6. Restore the file system data to volume SYS from your SMS backup.

  7. If the server had other volumes that were unaffected by the failure, you may restore only the trustee assignments (without data streams) for those volumes.

    When the server is brought back up and file system data is restored on volume SYS, the trustee assignments on the other volumes no longer exist because the DETs were purged of invalid trustees in Step 3. If desired, you may restore just the directory structure without data streams on these volumes. Since the data files already exist, only the directory structure is needed to get the trustee assignments back. There are two methods for doing this with SBACKUP:

    Method 1. If session files exist, you can do a custom restore of the full session. (If session files don't exist, you must use Method 2.) Leave all options at default except "Exclude Files". Under Exclude Files, insert the following three patterns into the list:

    **.*.*

    This method is faster because SBACKUP can use the offsets recorded in the session file to position the tape for each parent.


    Note: If file level trustee assignments exist, they will notbe restored if you use this method.

    Method 2. The other method is to simply change the "Exclude Data Streams" option to YES under the "How to scan session to be restored" custom restore options. This method will work whether the session is being restored with or without session files. It is only as fast as a full session restore because SBACKUP must scan the entire tape sequentially. This method should be used when no session files exist and/or when file level trustee assignments have been used.


    Note: If you're not using SBACKUP, refer to your third-party backup program'sdocumentation for similar instructions.

  8. Run DSREPAIR in unattended mode on the server to verify the integrity of the NDS database.

  9. (Optional) Verify proper restoration of the data, trustee assignments, file ownership, and other related information by spot-checking some of the restored directories and files.

    Commands that might be helpful include RIGHTS /T /S (displays users, groups and other objects that have explicit trustee assignments in a directory and its subdirectories) and NDIR (displays owners and other NetWare file information).

Scenario 2b: Multiple-Server Network (Replica Still Intact) In a multiple-server environment, it is possible for one server to go down but for the rest of the servers in its replica list to remain intact. The same situation exists if the hard disk(s) containing the SYS volume on one server becomes damaged, causing the failure of the entire server.

The recovery process in this scenario consists of several phases:

  • PHASE 1: "Clean up" the Directory to reflect the fact that the server has been lost from the NDS tree. You should first delete the lost server's Server object and its associated Volume objects from the tree. If the server held the master replica of a partition, you must use DSREPAIR to cause a remaining replica to take over as themaster replica.


Removing a Functional Server from an NDS Tree NetWare 4 is a distributed network environment in which servers are constantly communicating with each other. If you need to permanently remove a functioning NetWare 4 server from an NDS tree, it must be done properly using INSTALL.NLM. Do not just disconnect the server from the network! If a server is removed incorrectly, it couldcause Directory synchronization problems.

1. Load the Install utility by typing LOAD INSTALL.

2. From the Installation Options menu, select "Directory Options (Install NetWareDirectory Services)."

3. From the Directory Services Options menu, select "Remove DirectoryServices from this Server."

Answer "Yes" to the confirmation prompt, and type the passwordfor an administrative user when prompted.

4. Respond to the on-screen prompts to continuethrough the process.

INSTALL checks to make sure it issafe to remove NDS from the server. If the server holds a master replica, the utility will take care of placing the master on another server and changing this one to a read/write replica. If no downed servers or links to servers in a replica list exist, INSTALL removes NDS and deletes the Server object and its associated Volume objects from the tree. When this process is finished,press <Esc<to exit Install.

5. In NETADMIN or NWAdmin, confirm that the Server object and its associated Volume objectshave indeed been removed from the tree.

Use the procedure outlined here only to remove the Server objectfor an inoperable server. For correct procedures on howto remove the Server object for an active server, see thesidebar "Removing a Functional Server from an NDS Tree".

  • PHASE 2: Reinstall NetWare 4 and NDS and re-establish replicas on the new server. Once you install the new server hardware, you must reinstall NetWare 4 and NDS on the server. You then re-establish the replica(s)on the server from one of the other servers in the replica list.

  • PHASE 3: Restore file system data on the server volume(s). This is the only part of this procedure that is done from an SMS backup. You need to restore the data and trustee assignments on each volume that was lost as a result of the server failure.

Procedure. Following are the steps to restore a server/SYS volume in a multiple-server network when replicas are intact. The steps are grouped according to the three phases identified above.

PHASE 1: Clean Up the Directory. To clean up the remnants of the failed server from the Directory, follow these steps:

  1. Using NWAdmin or NETADMIN, delete the Volume object(s) associated with the server that failed.

    If any NDS objects (such as Directory Maps or Queues) have dependencies on these volumes, make sure you have a current SMS backup of these objects before you delete the Volume objects.

  2. Using PARTMGR or the Partition Manager in NWAdmin, delete the Server object of the server that failed.

    Note: You can't delete a Server object from NETADMIN. Partition Manager will display a warning message asking you to confirm that you really want to delete the server. Answer Yes.

  3. Check replica synchronization.

    To do this, load DSREPAIR on one of the other servers in the replica ring. From the Available Options, select "Replica synchronization." When prompted, log in as the administrative user. The utility checks the status of each partition in the tree and displays the results on the screen. Look for "OK" under the Status column.

    Some synchronization errors (-625 errors or others) might appear while NDS is trying to connect to the server you deleted. This simply means that the deletion of the Server object has not yet been fully synchronized across the replica ring. Give it time and the errors should clear up.

  4. If the failed server held a master replica of any partition, use DSREPAIR to designate a new master replica on a different server in the replica list.

    Caution: (NetWare 4.02 only) Be sure to keep a record whenever you change a read/write or read-only replica to a master replica. If the server contain-ing the original master replica is later brought back up, it will cause problems because a partition cannot have two master replicas.

    To change the replica type, run DSREPAIR on another server in the replica list that has an active read/write replica of the partition. The steps are:

    1. Load DSREPAIR.

    2. Choose "Advanced options menu."

    3. Select "Replica and partition operations."

      Note: Normally you should use PARTMGR or the Partition Manager tool in NWAdmin to perform partition operations. This option in DSREPAIR is to be used only when the master replica of a partition is lost because of server or hardware failure.

    4. Select the partition you want to edit.

    5. Select "View replica ring" to see a list of servers that have replicas of the partition.

    6. Choose the server you want to hold the master replica and select "Designate this server as the new master replica."

  5. Check replica synchronization and, if necessary, remove replica pointers to the failed server.

    Check synchronization as described in Step 3 above. If synchronization errors persist, remove replica pointers to the failed server as instructed below.

    If performed improperly, the following operation can cause serious problems in NDS. Normally, you only need to perform this operation on the server containing the master replica. NDS should synchronize the deletion to the other servers in the replica list.

    The steps are:

    1. From the DSREPAIR Available Options menu, select "View replica ring."

    2. Select the name of the failed server.

    3. Select "Remove this server from the replica ring."

    4. Choose "Yes" to continue.

    5. Exit DSREPAIR.

      Check synchronization as described in Step 3 above. If following these steps doesn't clear up the errors, perform Steps 5a - e (to remove the failed server from the replica ring) on every server that contains a replica of the partition in question.

  6. PHASE 2: Reinstall NetWare 4 and NDS. Once you have removed the Server and Volume objects, cleaned up the Directory and resolved all synchronization errors, proceed as follows:

    1. Install the new hard disk or server hardware.

      Follow any instructions provided by the manufacturer to verify that the server's hard disks are working. The new hard disk should have the same (or larger) storage capacity as the drive it replaces.

    2. Reinstall NetWare 4 on the server.

      Run INSTALL.NLM and reinstall NetWare 4 on the new server. When prompted, install NDS on the server using the same server name and context as before. If INSTALL doesn't do it for you, set the bindery context on the server (if necessary for bindery emulation).

    3. Use Partition Manager and your replication records to re-establish replicas on the server (if desired, or if necessary for bindery emulation).

      Do not restore any NDS information from your SMS backup at this time! Allow the NDS information to be copied to the new server from another replica. The completion time needed to restore replicas depends on the speed of your LAN or WAN links.

      Note: If you need to get users back online quickly, you can wait to re-establish replicas until after you restore the file system.

    PHASE 3: Restore file system data on the affected volume(s). Continue the procedure by restoring file system data and trustee assignments on each volume that was lost due to the server failure.

    1. Restore the file system data to volume SYS from your SMS backup.

    2. If the server had volumes other than SYS that were unaffected by the failure, you may restore only the trustee assignments (without data streams) for those volumes.

      When setting up the restore session, be sure to go into Custom Restore and, under "How to scan the session to be restored". set the "Delete existing trustees before restoring" option to YES. This will purge existing trustees before restoring the backed-up trustee assignments from the backup.

      Note: This option is available in SBACKUP only if you are using TSA4xx.NLM version 4.06 or later. The latest SMS TSAs are available in the SMSUPx.EXE file (where x is a number that is incremented each time a new revision is released). See Appendix C.

      If desired, you may restore just the directory structure without data streams on these volumes. Since the data files already exist, only the directory structure is needed to get the trustee assignments back. There are two methods for doing this with SBACKUP:

      Method 1. If session files exist, you can do a custom restore of the full session. (If session files don't exist, you must use Method 2.) Leave all options at default except "Exclude Files". Under Exclude Files, insert the following three patterns into the list:

      **.*.*

      This method is faster because SBACKUP can use the offsets recorded in the session file to position the tape for each parent.

      Note: If file level trustee assignments exist, they will not be restored if you use this method.

      Method 2. The other method is to simply change the "Exclude Data Streams" option to YES under the "How to scan session to be restored" custom restore options. This method will work whether the session is being restored with or without session files. It is only as fast as a full session restore because SBACKUP must scan the entire tape sequentially. This method should be used when no session files exist and/or when file level trustee assignments have been used.

      Note: If you're not using SBACKUP, refer to your third-party backup program's documentation for similar instructions.

    3. Run DSREPAIR in unattended mode on the server to verify the integrity of the NDS database.

    4. (Optional) Verify proper restoration of the data, trustee assignments, file ownership, and other related information by spot-checking some of the restored directories and files.

      Commands that might be helpful include RIGHTS /T /S (displays users, groups and other objects that have explicit trustee assignments in a directory and its subdirectories) and NDIR (displays owners and other NetWare file information).

    5. If you had NDS objects such as Directory Maps, Queues, and others that depended on the affected volume, you will need to re-establish the relationships through a selective NDS restore. (Refer to the "Partial NDS Restores" section in this AppNote for details.)

Scenario 3: Loss of the Entire NDS Tree

If all servers on a network are destroyed because of a disaster, you must perform a complete restoration of NetWare 4, NDS, and file system data. This process will go much more smoothly if you have documented your NDS tree and the location of Server objects, partitions, and replicas. It is also a good idea to record bindery context settings and other relevant information.

Procedure. To restore an entire network from a full backup in a multiple-server environment, follow these steps:

  1. Reinstall NetWare 4 on the first server. By default, this server will hold the master replica of the Root partition.

    When INSTALL asks for the names for Organization (O) objects immediately under the Root object, use the same names as existed before in the tree. Otherwise you'll end up with new, empty containers in the restored NDS tree.

    When this installation is complete, you'll have a working NDS tree containing one NetWare 4 server with a master Root partition.

  2. Install the remaining servers to complete a "skeleton" of your network.

    Before restoring a full NDS session, you should create a "skeleton" of your network: all servers and volumes should be up and running; their NDS objects should exist in the NDS tree in the same context as they resided in before (INSTALL will ask which container you want each server to be placed into); all servers should be communicating with one another; and time synchronization should be working properly.

    Note: If you can get some of the servers back up, but not all of them, you can still proceed with the restoration. However, you may see errors and experience problems due to NDS objects having dependencies that cannot be resolved.

    The User object used to create the backup session (such as Admin or equivalent) should exist in the same container, with the same password, and with the same NDS rights, as when the backup was performed.

    Note: If applications are used which extend the schema, those should also be installed at this time. If the schema was extended when the backup was created, it should be extended before the restore is done. Otherwise, the new objects will not be restored correctly.

    Once this step is completed, you still have just one partition - the Root - but (because of the INSTALL program's defaults) you now have two replicas of that partition. These are stored on the second and third servers you installed.

    If your network is small and you have a server with enough free disk space to hold the entire NDS tree, the restoration will go faster if you do not re-establish your former partitions and replicas yet. Use PARTMGR or the Partition Manager tool in NWAdmin to remove the two default replicas created by INSTALL before proceeding.

    In larger networks, you may not have a server with enough disk space to restore the entire NDS tree without partitioning it first. If this is the case, you should re-establish your former partitions and replicas at this time and skip Step 5 below.

  3. Restore the full NDS session from your SMS backup.

    On the backup host machine, load the necessary drivers and support modules for your backup program. If you are using SBACKUP, start the program as usual. Since you have no session files to work from at this point, choose the option to restore without session files.

    Since TSANDS has no concept of partitions and replicas, the NDS tree structure is restored into the single Root partition.

  4. Restore file system information to each server.

    When setting up the restore session, be sure to go into Custom Restore and, under "How to scan the session to be restored". set the "Delete existing trustees before restoring" option to YES. This will purge existing trustees before restoring the backed-up trustee assignments from the backup.

    Note: This option is available in SBACKUP only if you are using TSA4xx.NLM version 4.06 or later. The latest SMS TSAs are available in the SMSUPx.EXE file (where x is a number that is incremented each time a new revision is released). See Appendix C.

    Choose the option to restore without session files. Restore each server's data onto the appropriate volumes. As you restore files, trustee assignments are also restored.

  5. Re-establish partition boundaries and distribute replicas to the other servers.

    Refer to your written documentation of the network. When you are finished, your NDS tree should exist as it did before the disaster, with all partitions and replicas in place.

  6. Run DSREPAIR in unattended mode on each server that contains a master replica to verify the integrity of the NDS database.

  7. (Optional) Verify proper restoration of the data, trustee assignments, file ownership, and other related information by spot-checking some of the restored directories and files.

    Commands that might be helpful include RIGHTS /T /S (displays users, groups and other objects that have explicit trustee assignments in a directory and its subdirectories) and NDIR (displays owners and other NetWare file information).

Scenario 4: Loss of a Single Partition

With adequate replication, your network should be protected against the most common losses of NDS data. This scenario covers the unlikely situation where you lose just one partition within the NDS tree and, for some reason, no replica of that partition exists. This should be an extremely rare circumstance.

To understand this scenario, consider the example network shown in Figure 10. This is the same NDS tree as in Figure 3, except that the administrator has inadvertently deleted all but the master replica of the "Sales" partition. This single replica is stored on server S3.

Figure 10: Having only one master or read/write replica of a partition is a risky configuration that is not recommended.

In this situation, NDS automatically creates subordinate reference replicas of the Sales partition on the other three servers in the tree. However, subordinate references are not full replicas. They contain only enough information to locate other replicas and track synchronization.


Note: As explained in the "Subordinate References"section of this AppNote, a subordinate reference is created wherevera parent partition exists on a server but a child partition ofthat parent is not on that server. In Figure 10, servers S1, S2,and S4 each hold a replica of the Root partition (the parent partitionof Sales), but not of Sales (a child partition of Root). Therefore,NDS creates subordinate reference replicas of Sales on these three servers.

If server S3 is lost due to hardware failure or disaster, you lose the only full replica of the Sales partition. In essence, you now have a "hole" in your NDS tree between the East partition and the Root partition. You cannot recover the partition from another read/write replica (since none exists).

To avoid getting into this situation, always follow the establishedguidelines for NDS partitioning and replication. Wherever possible,design your tree so that you don'thave all replicas of a partition located on servers at the samesite. Never delete replicas unless you have a specific need todo so. Store a duplicate set of your regular backups off-site.As always, having disaster recovery procedures in place can meanthe difference between getting a site back online quickly or havingto go through a painstaking tree re-creation process.

In this scenario, it is possible to rebuild the links to the lost portion of the NDS tree and then restore the objects from a backup. However, the procedure for doing this requires significant technical expertise and should be performed with the assistance of a qualified technician.

Procedure. If you lose a single partition in a multiple-partition tree and have no replicas of that partition, proceed as follows:

  1. Do not attempt any NDS recovery or repair procedures.

  2. Call Novell Technical Support at 1-800-NETWARE(638-9273) or 801-429-5588. Ask for assistance from the NDS Support group to rebuild the links to the missing partition in your tree.

  3. Once the partition links are rebuilt, the Technical Support Representative will guide you through the process of restoring the objects that were in the lost partition from your SMS backup.

Special Cases to Watch Out For

This section describes conditions that may arise in certain special cases involving the backup and restoration of NDS information.

Note: Unless stated otherwise, this information applies to the versions of NetWare 4, DS.NLM, SBACKUP, and SMS TSAs that were current at the time of publication (see Appendix C for a listing). Currently, you should have DS.NLM version 4.89 or later, and TSAs version 4.06 or later. New software revisions may make some of these concerns obsolete. Be sure to read the documentation and readme files that accompany any patches, updates, or revisions you receive from Novell.

Partial NDS Restores

The SMS TSAs released with NetWare 4.1 (and later versions) allow you to do selective restores from the backup media. However, partial restoration of NDS from a backup can have many subtle consequences, particularly when only a single object or a selected group of objects is restored. There are two main issues to keep in mind for partial NDS restores:

  • Object ID Numbers. If you restore objects that no longer exist in the tree, those objects receive new ID numbers when restored. New object IDs affect file system trustees, print queue directories, user mail directories, and so on.

    If you restore objects on top of objects that exist in the tree, the objects do not receive new ID numbers. These objects' current attribute and property information is overwritten with previous information from the SMS backup.

  • Objects that Depend on Other Objects. In the NDS schema, objects are defined to have certain attributes. Some of these attributes are mandatory (meaning they must contain a value); others are optional. For some NDS objects, the value for a particular attribute is a reference to another object upon which the object depends. A Queue object, for example, hasa Queue Directory attribute that contains the file system path to the queue directory. It also has a Host Server attribute that identifies the file server on which the queue directory resides. This information is used to determine the physical location of the resource.

The specifics of restoring objects vary depending on what type of object is involved and whether the object's dependencies are physical entities (servers and volumes) or logical entities. In some cases you can simply restore an object by itself and everything will work fine. In other cases, an object may restore but will not be functional unless you first restore its dependent object(s).

The paragraphs below describe restore procedures for the most commonly used NDS objects.

Directory Map Objects. These objects have a mandatory attribute called Host Server. To restore a Directory Map object properly, the server named in the Host Server attribute must be present in the NDS tree. If the Server object is not present when a restore takes place, the Directory Map object is restored but will not be functional. After the dependent Server object is reinstalled into the tree, you must do either of the following to make the Directory Map functional: (1) delete the nonfunctional Directory Map object and recreate it manually through the NetWare utilities, or (2) delete the Directory Map object and then restore it from your SMS backup.

Queue Objects. These objects have a mandatory attribute called Queue Directory. To restore a Queue object properly, the server and volume on which the queue resides must be present. If these objects are not present, the restore will place the Queue object in the tree but it will not be functional. After the dependent Server and Volume objects are reinstalled into the tree, you must do either of the following to make the queue functional: (1) delete the restored Queue object and recreate it manually through the NetWare utilities; or (2) delete the Queue object and then restore both the Queue object and its corresponding Printer object(s) from your SMS backup.

Other objects that may have dependencies (including objects defined in an extended schema) need to have their dependent objects in the tree when restoring. If the dependency is not in the tree when the restore takes place, the object gets created but is not functional. Once the dependency is in place, the object will have to be deleted and recreated manually through the NetWare utilities, or deleted and then restored from an SMS backup, before it is fully functional.


Trying to restore over existingobjects that depend on other objects will not resolve the dependenciesproperly. Once the dependencies are in place, these objects mustbe deleted and recreated by the NetWare utilities, or they mustbe deleted first and then restored from an SMS backup.

Print Server Objects. If a Print Server object is lost, there are two ways to bring it back. One way is to use the NetWare utilities to reassign the queues for the print server. The other way is to restore both the Print Server object and its associated Queue objects. A Queue object has an assignment indicating which print servers are authorized to service its print jobs. When the Print Server is lost, this authorized print server assignment gets deleted from the queue. This is why the Queue object has to be restored as well. Restoring both Print Server and Queue re-establishes this assignment and allows printing to function properly.

User Objects with Home Directory and Default Server Attributes. Home Directory and Default Server are optional attributes that are frequently assigned for User objects. These attributes are deleted from the Directory if the server they are dependent on is taken out of the tree. To get the attributes back after the server is reinstalled, restore the User objects from an SMS backup. This can be done by doing a custom restore that includes an object and subordinates by container name. This will restore over the existing User objects and fill in the Home Directory and Default Server attributes as they were at the time of the backup.

Other Objects. Objects such as Alias, Group, Organizational Role, and Profile have dependencies that are optional, not mandatory. When restoring these objects, if the optional dependency is not present in the tree, a temporary placeholder will be created until the dependent object is restored. For example, if a Group is restored but all its members (Users) do not exist in the tree, placeholder (Unknown) objects are created until the User objects are restored. At that time, the placeholder objects become real User objects and the User and Group objects are fully functional.


Note: In a network with many interdependent objects and trustee assignments,this manual restore process can become tedious. A partial restoreof NDS objects may not be the best option for recovery in thesecases. Recreating the objects through the NDS utilities mightbe a better solution. Another possibility for objects that referenceServer objects is to use the DSMAINT.NLM utility, described next.

Using DSMAINT.NLM to Recover Server References

Novell has developed a new utility called DSMAINT.NLM that can prove useful in dealing with partial NDS restores. With this utility, you can save references to a particular NetWare server object that are contained in NDS object properties and attribues. This information in written to a data file which can be backed up as part of your regular data backup procedures. If a hardware failure or disaster destroys that server, you can replace the server, reinstall it, and then use the data file to restore any references to that server throughout the Directory.

You can use DSMAINT to maintain server references during a brief server shutdown and to more easily handle the transfer of NDS data when replacing an old SYS volume disk drive. Refer to the documentation that comes with DSMAINT.NLM for detailed instructions.

DSMAINT is included as part of the DS Enhancement Pack, available from NetWire and from Novell's Web server on the World Wide Web. The DS Enhancement Pack also contains a number of other utilities and tools to assist you in working with NetWare Directory Services.

Partial Restores in a Mixed NetWare 4.0x - 4.1 Environment


The issues described under thisheading apply only to NetWare 4.1 with DS.NLM 4.77b and earlierversions. The problem has been fixed in DS.NLM 4.89 and laterversions.

In a mixed NetWare 4.0x and 4.1 environment, restoring over existing NDS objects on NetWare 4.0x servers can have undesirable consequences. The problem stems from the fact that NetWare 4.1 uses the creation time stamp as part of the object name. When an existing object is restored to a NetWare 4.1 server, the creation time stamp remains the same. When an existing object is restored to a NetWare 4.0x server, that object retains the same object ID but it always gets a new creation time stamp. The NetWare 4.1 server(s) will see this as a new object of the same name and location as one that already exists. This can result in the following problems:

  • Object renames

  • Users not able to log in to the NetWare 4.02 server

  • Lack of Directory synchronization between NetWare 4.0x and 4.1 servers (you will also see "-601/No such entry" errors in the Directory Services DSTRACE screen)

There are two possible workarounds for this situation (both of which are designed to keep the NDS tree-walking confined to NetWare 4.1 replicas):

  • In a mixed NetWare 4.0x - 4.1 environment, you should have a read/write replica of every partition on the NetWare 4.1 server you are going to restore to. (Be sure you connect to the TSANDS loaded on a NetWare 4.10 server, not a 4.02 server).

  • If the above method is not possible (because replicas are large, widely dispersed, or whatever), but replicas do exist on several NetWare 4.10 servers that together have a copy of every object, it is possible to DOWN all the 4.02 servers, restore to the 4.10 servers, then bring the 4.02 servers back up.

Invalid Trustee Assignments on a Server

Another case to be aware of can occur when you lose just a SYS volume, while other volumes on the server remain intact. In this case it is possible for a newly restored or created NDS object to be assigned an ID number that is identical to one used for an object that used to exist in the tree, but has since been deleted. If the DET (which holds the file system trustee assignments) is not purged to remove trustee assignments of objects that no longer exist, a newly created/restored object could possibly gain rights to files or directories where it shouldn't have rights.

To prevent this from happening, make sure you set the "Delete existing trustees before restoring" option to YES when setting up a restore session with SBACKUP. This option is only available with TSA4xx.NLM version 4.06 or later (see Appendix C).

Note: Invalid trustee assignments are also possible when a user or otherobject has file system trustee assignments on a volume, but thatvolume is dismounted when the object is deleted. In this situation,NDS cannot purge the object'strustee assignments because the volume was not accessible at thetime of the deletion. In the event that a newly-created objectis assigned the same object ID as the deleted object, the newobject may gain rights in files or directories where that objectshouldn't have rights. To prevent this, make sure all volumes are mountedprior to deleting NDS objects. If duplicate trustee assignmentshave already occurred, those assignments must be deleted manually.

Unknown Objects After a Restore

As explained earlier under the heading "Placeholder (Unknown) Objects", the process of restoring NDS can create unknown objects in the tree. Unknown objects are created when restoring any object which has an attribute that refers to other objects that do not currently exist in the tree. When this condition arises, NDS creates a "placeholder" (unknown) object to stand in for the referenced object until the real object is restored. If the referenced object is later restored, the real object will replace the placeholder (unknown) object. If the restore session does not include the actual object for which the placeholder was created, the object remains with the base class of "unknown".

You can expect to see Unknown objects in the tree if all resources (servers, volumes, and so on) are not in place before a restore is started. Objects which remain unknown after a restoration is completed are those for which NDS could not resolve the dependencies. Once the dependent objects or resources are in place, you can either delete the Unknown objects and recreate them, or do a selective restore to overwrite the Unknown objects.

Overwriting Updated Software

Many of the restore procedures in this AppNote instruct you to resinstall NetWare 4 after a server hardware failure that involves the SYS volume. Keep in mind that after you reinstall the operating system from the original media (CD-ROM or diskettes), your server will have the initial-release versions of the OS and all system and public files. If you have updated the OS or any of the NLMs included with the operating system since the initial release, these updates must be reapplied or selectively restored from the most recent backup.

It is especially critical to reapply any OS patches and to recopy new versions of DS.NLM, DSREPAIR.NLM, and other NDS utilities. Also make sure you have the latest backup device software and drivers.

Bindery-Based Objects and Applications

Because new object IDs are created for restored objects when identically-named objects do not exist in the tree, applications that depend on object ID numbers instead of object names will probably not function properly after the NDS object is restored. Applications that are affected are generally older, bindery-based applications. These may include third-party printing applications, E-mail applications, and even some backup applications. After restoring NDS, these applications may have to be re-installed or reconfigured.

Most bindery objects are converted into NDS objects during a migration from NetWare 2 or 3 to NetWare 4. In addition, login scripts for users are upgraded and stored in an attribute of the User object. You may still have to deal with bindery objects in a mixed NetWare 3-NetWare 4 environment, or when running bindery-based applications. NetWare 4's bindery services (bindery emulation) feature is designed to allow applications that need the bindery to continue to function in the NDS environment.


Note: Emulating the bindery should be seen as a temporary measure necessaryonly until NDS-aware applications are available. Whenever possible,use bindery emulation only to continue to support dynamic objectsthat are created or manipulated programmatically.

Bindery objects are NDS objects, so they are backed up and restored just like other NDS objects. However, bindery-based user objects will lose access to their login scripts after being restored. This occurs because login scripts for users created with non-NDS utilities such as SYSCON are not stored in the Directory; they are stored in subdirectories of SYS:MAIL. These mail subdirectories are named to match the user object ID numbers. However, when users are restored with a new object ID, their mail subdirectories are not renamed automatically. (See "User Mail Directories" below for a solution to this problem.)


Note: In a NetWare 4 environment it is strongly recommended that newusers be added through NETADMIN or NWAdmin as full NDS objects,not through SYSCON.

User Mail Directories. During an NDS restore of objects that do not currently exist in the tree, those objects will receive a new ID number. The name of the user's mail directory (if one exists), which is normally the same as the object ID number, is not renamed automatically during restore to match the new User object ID. This can be a problem if you have still have users doing bindery logins.

RENMDIRS.NLM is a tool which can be used to change the mail directory names (which are currently named according to the old object ID) to match the object ID of the newly restored users. This may be required for bindery login scripts, for proper operation of some applications that use the mail directories, or simply for the sake of consistency and ease of administration.

RENMDIRS.NLM checks the DET of each mail directory to see which user has rights to that directory. RENMDIRS uses the first user ID listed in the DET and changes the directory name to match that number.

Load RENMDIRS as follows:

LOAD RENMDIRS servername username password

where servername is the name of the server to have the mail directories renamed, username is a user that has rights to the MAIL directory and subdirectories, and password is the password of the username specified. The username must be the typeful distinguished name (for example, .CN=Admin.O=ABC).

To obtain RENMDIRS.NLM, go to the NSD area on CompuServe (GO NSD) and download the file RENMDR.EXE.

Bindery-Based Print Servers

Third-party bindery-based print servers can be configured in either of two printing modes: Queue Server mode or Remote Printer mode. In Queue Server mode, the third-party utilities access the queue using a queue ID. In Remote Printer mode, the third-party utilities function only as an NPRINTER, using the NetWare Print Server to access the queue. Even though these objects are bindery-based, they are NDS objects and are subject to the same restore procedures.

With that in mind, here are some guidelines for recovering bindery-based printing in the two modes for both full and partial NDS restore scenarios.

Queue Server Mode. If you lose NDS, follow the appropriate procedures to reinstall NDS, then restore the printing-related objects from your backup. Run the third-party setup utility to reconfigure the printing environment. In the utility you need to remove the old queue and add it again with the same name (because the queue ID has changed). This reassigns the new queue with the new queue ID to the existing print server. After running the utility, it may be necessary to reset the printer.

In a partial restore scenario, follow the guidelines for restoring Queue and Print Server objects given in the "Partial NDS Restores" section of this AppNote. You'll also need to run the third-party printer utility to remove the old queue and add it again with the same name (because the queue ID has changed). This reassigns the new queue with the new queue ID to the existing print server. Then reset the printer. Printing should now be functional.

Remote Printing Mode. If you lose NDS, simply restore the objects from tape after reinstalling NDS. Printing should be fully functional because in this mode the third-party utilities use the NetWare Print Server to access the queue.

In a partial restore scenario, follow the guidelines for restoring Queue and Print Server objects given in the "Partial NDS Restores" section of this AppNote.

Modifying the Default Admin Object

By default, the NetWare 4 installation process creates a User object named Admin that has Supervisor rights to the Root of the NDS tree. For security and management reasons, many customers choose to create other administrative user objects with rights to lower portions of the tree. Once this is done, these customers typically either delete the default Admin object or rename and modify it so it no longer has rights to the entire tree.

Novell strongly recommends that, before you modify the defaultAdmin object in any way, you create another object with Supervisorrights to the Root to use for backup and restore purposes.

Failure to follow this recommendation can lead to problems when NDS must be reinstalled prior to a complete NDS restoration from a backup. The scenario is as follows: You limit Admin's rights, and those limited rights are backed up when you back up NDS. You later start a restore and log in as user Admin because you presume it has all rights to the entire tree. However, since you are doing a complete NDS restore, the backed-up user Admin is restored over the default Admin and you no longer have the proper rights to complete the restore successfully.

The recommended solution here is to create a "backup" user that has the rights necessary to back up and restore NDS. After you reinstall NetWare 4, recreate the Backup user in the proper context (create the necessary containers if needed), and grant the Backup user the same rights that were granted it on the backup. You can then log in as the Backup user and proceed with the restoration.

Loss of Host Server for Certain Backup Products

Some third-party backup programs require that you restore from exactly the same context and using the same username as were in place when the backup was made. If the host server is lost, you need to replace it with a new server located in the same container of the NDS tree. Check with your backup system vendor for more information.

NDS Schema Extensions

Currently, extensions to the default NDS schema cannot be backed up, but objects created under an extended schema are backed up. In order for these objects to be restored correctly, the schema must first be extended in the same manner as existed at the time of the backup. If you extend the schema, it is recommended that you do so with an application or program that can be re-run before an NDS restore. If you are using an application to modify the default schema, it is important to make a record of the current version. In the unlikely event that you lose all the servers in your tree, you will need to use the application to make the same modifications to the schema before restoring the NDS objects.

Errors During Backup/Restore Procedures

Following are some of the most common errors you might see when backing up and restoring NDS with SBACKUP. (For information about error messages in third-party backup programs, refer to the vendor's documentation.)

-601 (invalid name) These errors indicate that SBACKUP could not read NDS data because an object name contained invalid characters. The backup session will typically terminate with these errors. Either exclude the indicated object or resolve the invalid name problem before attempting to back up NDS again.

-626 (all referrals failed) These errors indicate that an object could not be found. It is possible that the object exists, but the server could not communicate with a server holding a copy of the object or its parent. The communication problem needs to be resolved before attempting to back up NDS again.

-672 (access denied) These errors indicate that the backup program encountered data in the NDS tree which it did not have sufficient rights to access. Either grant the backup user rights to the entire tree or exclude the restricted portions of the tree prior to starting the backup.

For more information on these and other error messages, see the Novell System Messages manual. A more complete list of NDS errors is contained in the TNDSx.EXE file (where x is the revision number), available in Novlib 14 from NetWire on CompuServe or from Novell's ftp server on the Internet.

Conclusion

When the backup and restore issues discussed in this AppNote are understood and the recommended procedures are carefully followed, loss of NDS information can be avoided in almost every case. As further information becomes available, updates to the Novell-recommended backup and restore procedures documented in this AppNote will be disseminated through Novell's regular support channels.

Appendix A: Additional References

Following are some additional information resources on NetWare 4, NetWare Directory Services, SMS, and related topics.

  • Related AppNotes listed at the beginning of this document

  • Novell product manuals and readme files

  • SMS Solutions Guide(Novell part no. 482-000209-001; call 800-346-6855 or 801-373-6779)

  • Guide to NetWare 4.1: Design, Implementation,and Maintenance (Novell part no. 482-000219-002; call 800-346-6855 or 801-373-6779)

  • Quick Path to NetWare 4.1 Networks(Novell Press, call 1-800-227-2346 or 510-523-8233)

  • NCS Toolkit CD (Novell part no. 172-000239-001; call 800- 453-1267 ext 5837)

The following third-party documents may also be helpful:

  • Arcada Software, Inc. (407-333-7500) Doc. No. 308-X "UsingBackup Exec v5.01 to Backup and Restore NetWare Directory Servicesand File System Data in NetWare 4"

  • Cheyenne InfoFax (516-629-4675) Doc. No. 1002 "Storage Management Systems (SMS) Model" Doc. No. 1006 "Backup and Restore of NDS" Doc. No. 1007 "NetWare 4.x Directory Services Technical Tips"

  • IBM Storage Systems Division (408-281-5700) "ADSTAR Distributed Storage Manager from IBM"

  • Palindrome (708-505-3300) "Protecting NetWare 4.x Environments"

Classes on NDS design, implementation, and administration are available through Novell Authorized Education Centers. Call 800-233-3382 or 801-429-5508 for more information.

Appendix B: NetWare 4.1: Certified Backup Solutions

The following backup solutions have been certified by Novell Labs for use with NetWare 4.1 and NDS as of July, 1995.


Vendor
Product
Version

Novell800-638-9273801-429-5588

SBACKUP

4.11, 4.13

Arcada Software800-327-2232407-262-8000

Backup Exec for NetWare

5.01, 5.01a

Cheyenne Software800-243-9462516-484-5110

ARCserve for NetWare

5.01g for MS Windows

Hewlett-PackardLtd.303-635-1000

LABS for NetWare

C1565a (NLMS 3.50a)

IBM Corporation408-284-2214

ADSTAR Distributed Storage Manager

Ver. 1 Rel. 2 Level 0.3, 0.5

Legato Systems415-812-6000

Staccato

3.10

Networker for NetWare

3.1

Novastor818-707-9900

NovaBack-NLM

6.0

PalindromeCorporation708-505-3300

Network Archivist

3.1a

Backup Director

3.50a

Rememory Corporation800-644-2300714-708-0990

REMSERVE

1.96

Systems Enhancement Corp.314-997-7717

Total Network Recall

1.96

Xenon Technologies49 6172 953550

Profile

1.96

Appendix C: Current Software Versions

The following is a list of current versions of NetWare 4 and backup- related software as of the time of publication (July 1995). You should periodically check with Novell and third-party vendors for the latest software releases.

Novell product patches and updates are available through NetWire on CompuServe, by anonymous ftp to novell.ftp.com, or from Novell's World Wide Web server (www.novel.com) on the Internet. (The x in the filenames represents a number that is incremented each time a new revision is released.)


Description
Filename/Location
CurrentVersion as of Publication Date

NetWare 4.1

-

Initial release (11-08-94)

NetWare 4.1 OS Patches

410PTx.EXE / novlib 14

410PT1.EXE

NetWare Directory Services (DS.NLM)

41NDSx.EXE / novlib 14

41NDS2.EXE

(DS.NLM 4.89)

DSREPAIR.NLM utility

4X241.EXE / novlib 14

4.25f

SBACKUP and supporting files

SBACKx.EXE / novlib 14

SBACK3.EXE

SMS (TSAs, SMDR, and support NLMs)

SMSUPx.EXE / novlib 14

SMSUP2.EXE

Be sure to check out the helpful NDS utilities and tools contained in the DS Enhancement Pack, available on NetWire and on the World Wide Web.

NetWare Directory Services Replication Worksheet

(From Novell Application Notes, August 1995 - photocopy as needed)

Partitions

Site Name

Location

Server Name

Replicas (M = master,R/W = read/write)

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates