Novell Network Management: NetWare 6

Chapter 12: Perform Backup and Restore Tasks with NetWare 6 Backup Utilities

Objectives:

This chapter concerns performing backup and restores in a NetWare 6 environment. The objectives important to this chapter are found on page 12-1:

  1. Set up SMS for SBCON and NWBACK32
  2. Back Up Data with SBCON and NWBACK32
  3. Restore Data with SBCON and NWBACK32
  4. Identify eDirectory Recovery Procedures
Concepts:

Set up SMS for SBCON and NWBACK32

Novell Storage Management Services (SMS) is the category of services that include backup and restores. By establishing this type of service on the network, Novell enables an administrator to use Novell's own backup utilities, or install and use a preferred utility, as long as it is SMS compliant.

It is possible to make backup copies for eDirectory, the network file system, and workstation file systems. The text begins the discussion of doing this by describing the components of SMS.

The text explains that the first SMS component is a Storage Management Engine, which has three parts:

  • Two user interfaces are provided for backups and restores: SBCON, which runs on the server console, and NWBACK32, which can be run on a Windows workstation.
  • QMAN is short for Q Manager. It is a utility for managing a queue of jobs from eDirectory. Loading this NLM will load the third component.
  • The text explains that the Backup Engine completes the jobs from the queue. It does not state what NLM holds it.

The second SMS component is the Target Service Agent. Some terminology is required to understand what this is. If we are performing a backup:

  • a host is a server that contains the software used to make the backup or perform the restore
  • a target is a server or client workstation whose data will go into the backup or be restored
  • a storage device is the actual medium used to receive the data being backed up or provide the data being restored

A Target Service Agent is software for a specific kind of target. NetWare 6 provides several TSAs for specific targets:
Target TSA module
NetWare 6 files TSA600.NLM
DOS partition on a server TSADOSP.NLM
eDirectory TSANDS.NLM
Windows 9x workstation W95TSA.EXE
Windows NT or 2000 workstation TSAPREFS.EXE
TSAMAIN.EXE
TSAPROXY.EXE
GroupWise GWTSA.NLM

This is a rather unusual use of the word target, but it makes sense in that a target holds the data you are backing up or restoring.

It would be too simple if the software already described was sufficient, so the third component of SMS is introduced: the Storage Management Data Requester (SMDR) fits between a TSA the the SME.

Finally, the fourth and fifth components are storage device interfaces and drivers, to enable the SME to save or read data that is saved.

Data Sets

The concept of data sets applies to eDirectory and to file systems. Data sets and subsets can be defined to make specific backups of data. In general, a data set can be a parent or a child. Parent data sets contain other data elements, child data sets do not. This is different from the usual definition of parent and child. Under this definition, a child is only a collection of files or eDirectory leaves. Any object that contains other data objects is a parent, regardless of what we would normally refer to as its child relationship to a higher object.

For example, the SYS: volume is a parent data set, and so is any directory in it. Those directories are not considered children of SYS: under this odd definition.

Backups can use include and exclude options. Use the include option to back up only a small part of the data system. Mark the part you want to be included. Use the exclude option to back up everything except the part you mark to be excluded. You can combine include and exclude instructions to customize how much information will be backed up.

Enabling SMS to Use SBCON and NWBACK32

The text gives a three part procedure to use the backup utilities with SMS. Note that SMS is not loaded until the third part.

  1. Load Controller and Device Drivers - Controller filenames typically end with .HAM, device drivers typically end with .CDM. These files can be loaded from the server console, from STARTUP.NCF, or from the menus in NWCONFIG. After loading new .HAM and .CDM files from a console, it may be necessary to issue two commands to the system:
    LIST DEVICES
    SCAN FOR NEW DEVICES
    These commands will verify that the device files are loaded, and will register the device for system use.
  2. Load necessary TSAs - The TSA files noted above are loaded as needed.
    Some Guidelines about TSA loading are offered:
    • You only need to load TSANDS once; it goes on a server with a replica of the largest partition.
    • You need to load TSA600 on every server whose file system you are working on.
    • The TSAs for workstations are loaded on the workstations.
    • To automate loading these files, load them on servers from the STARTUP.NCF file. Load on workstations from the NET.CFG file, AUTOEXEC.BAT (for DOS), and Startup Folder (for OS/2).
  3. Load SMS - the command to load the NLMs for SMS is SMSSTART.

To use SBCON, load it at a server console. When done, exit the program interface, then unload SMS related NLMs with the command SMSSTOP. The text notes that you could get an error message with this command, that an NLM you are trying to unload is in use. If you get a message like this, and tell the server to unload the NLM, you could abend the server.

NWBACK32 is used from a workstation. To use NWBACK32, you should log in to the server that runs SMS. In its Public directory, find and run the NWBACK32.EXE program. Use and exit the program as you would any other Windows program. At the end of the session, issue the SMSSTOP command, making sure not to abend the server, as explained above.

Guidelines for Backup Utilities

We are given guidelines for using NetWare Backup/Restore. To summarize them:

  • Log in to the network as a user with Supervisor rights to the servers
  • Allow lots of temporary file space on the target server. The text suggests that 1 or 2 MB may be enough.
  • Do not mount or dismount volumes while backing up or restoring them.
  • Use the correct name space and the correct syntax when referring to files in those spaces. The kinds of name space listed are: DOS, FTAM, Macintosh, and OS/2. The syntax for referring to a Macintosh file is:
    volume::directory:directory:filename
    The syntax for all other name spaces is:
    volume:/directory/directory/filename
  • Path and file names may be case sensitive. The text recommends using the original case when restoring a file or directory.
  • If you are running the backup unattended, make sure the tape is big enough. This is because the process will pause to ask for a new tape, if needed. While waiting for a new tape, anyone walking by the server might give it a command with the authority of an administrator, because the session it is running requires administrator privileges.
  • SBCON requires that you electronically label a tape before you use it.

When you run a backup or restore, log and error files are created in the SYS:\SYSTEM\TSA directory. These files can be accessed from SBCON and from NWBACK32.

Log and error files from a backup procedure are stored under SYS:\SYSTEM\TSA\LOG, unless you tell the server to store them elsewhere.

Log and error files from a restore procedure are stored under SYS:\SYSTEM\TSA\RESTORE. This location cannot be changed.

Back Up Data with SBCON and NWBACK32

The next topic repeats some of the information above, and adds some new details.

Using SBCON to perform a backup:

  1. At a server console, enter SBCON
  2. You will see a menu. Choose Job Administration | Backup
  3. Choose Target Service. This will call up a list of servers running TSAs.
  4. Choose a host/server. Your choice is based on what you want to back up.

    Target to back up: Choose this host:
    A server's file system The server that holds that file system.
    eDirectory Any server running TSANDS. This should be a server that holds a replica of the largest partition.
    A workstation The workstation's host server, and the workstation. Both will be running TSAs.

  5. Choose a target service
  6. Enter a user name. This will probably need to be a user with Supervisor rights to whatever you are backing up. The name may need to be a distinguished name.
  7. Enter a password.
  8. Press Enter to proceed.
  9. Choose What to Back Up. You will see a list of resources.
  10. Press a key you probably have forgotten is even on the keyboard: Insert. Select the data you want to back up, then press Esc.
  11. Enter a description label for this backup session. Make this descriptive enough that you will know what is in the backup.
  12. Choose Device/Media Name. You will see a list of available backup media. Choose one.
  13. If you need to set a label on the backup medium, press Insert.
  14. If you want to perform any kind of backup other than full, choose Advanced Options. Full backup is the default. (This is not defined until later in the chapter. See notes below.)
  15. If your device supports appending data, choose Append Session. You will be asked a question. Choose Yes to append this session, preserving anything already on the backup medium. Choose No to overwrite anything already on the backup medium.
  16. Press Enter. This will save your choices, and submit the backup job to SMS.
  17. You can watch the progress of the backup. Choose Job Administration | Current Job List.
  18. Press Insert to watch the progress.
  19. When the backup is finished, press Esc until you see the main menu.
  20. Select Exit and Yes to exit SBCON.
  21. Enter the command SMSSTOP.

NWBACK32 is run from a workstation:

  1. Run NWBACK32. You will see the Quick Access window.
  2. Choose Backup.
  3. This step is like number 9 above. Choose What to Back Up. Select whether it is NDS, a NetWare Server, or a Workstation. Locate the server associated with this back up. Authenticate as a user with Supervisor rights. (You may already be logged in to the network. You are authenticating to this resource as an additional security measure.) Drill down to the resource you are backing up.
  4. Choose Where to Backup. Change context if necessary. In the correct context, find Queues. Drill down into Queues and select a backup device. Select Backup | Submit the Job.
  5. Watch the progress of the job through Job Administration. Drill down through the context, Queues, and view the queue you sent the job to.
  6. When the job completes, return to the Quick Access window.
  7. Exit the Quick Access window.
  8. Issue the SMSSTOP command.
Verifying a Backup

You can verify that a completed backup job has no errors from either the SBCON or NWBACK32 interface. There are many steps to do so, and you should be aware that the real test of a backup is to perform a restore.

Backup Strategies

Three backup strategies, or schedules, are explained. You should know all three. First some terms:

  • Full - a backup of all files in the target
  • Incremental - a backup of target files that are new or changed since the last backup
  • Differential - a backup of all files new or changed since the last Full backup

This needs more explanation. Assume we use a tape drive to make backups. In a Full backup strategy, the entire target is backed up to tape every time we make a backup tape. This strategy consumes the most time and the most tapes to carry out a backup. To restore, we simply restore the most recent tape(s). This is the least time consuming strategy for restoring, but the most time consuming for creating backups.

The second method, Incremental backup, means that we start with a Full backup of the target, and then each successive backup tape we create only backs up the elements that are new or changed since the last backup was created. This means that successive backups will not always be the same length. Therefore, this is the least time consuming backup, but the most time consuming restore. To restore, we must first restore the last Full backup made, and then restore EVERY tape made since then, to ensure getting all changes. (Incremental backups can only be done for file systems, not for eDirectory.)

The last strategy, Differential backup, also starts with a Full backup tape. Then each successive tape made will contain all the files changed since the last Full backup was made. This means that we will have to restore only one or two tapes in a restore operation. If the last tape made was a Full tape, we restore only that one. If the last tape made was a Differential tape, we restore the last Full tape, then the last Differential tape. (Differential backups can only be done for file systems, not for eDirectory.)

In both Incremental and Differential backup strategies, you will typically use a rotation schedule. For example, you could have a one week cycle. Once a week, you make a Full backup, then every day after that you make the other kind, Incremental or Differential.

To keep them straight in your mind, remember that:

  • a Full backup copies everything
  • an Incremental backup copies everything different from the last backup
  • a Differential copies everything "different from Full". (Different from the last Full backup.)

The time required to create backup tapes should be considered along with the time to restore a backup. When you consider the two concepts as two sides of the answer to a question (What method should I use?), the answer may be the most common choice: Differential. It is the best compromise in terms of backup time versus restore time. Note also, that all three methods require a full backup on a regular cycle. The recommendation is usually to run a Full backup tape weekly.

A new note in this edition of the text is that trustee rights in the file system are backed up with the file system. Trustee rights saved in the file system are associated with eDirectory distinguished object names. The point seems to be that if you restore a file system, rights to files and directories will automatically be applied to eDirectory objects as long as objects exist in the tree with distinguished names that match the names saved in the file system.

SYS Volume Backup

A special note is made about information stored on the SYS: volume. Backing up this volume will back up several special purpose files:

  • SERVDATA.NDS - This file contains eDirectory data about this server.
  • DSMISC.LOG - This file contains a list of replicas stored on this server, including their types.
  • STARTUP.NCF - One of two files run at server start. It typically contains basic hardware settings, commands to load a hard disk driver, names spaces, and other SET commands. Its function is similar to the function of config.sys on a DOS machine.
  • AUTOEXEC.NCF - One of two files run at server start. It typically contains commands to load NLMs, and other configuration settings for the server, like the LAN driver and time zone settings. Its function is similar to the function of autoexec.bat on a DOS machine.
  • VOL$INFO.TXT - This file lists the volumes on the server, the name spaces loaded, compression and migration information.

These files can be backed up separately from backing up the rest of the volume. They need to be restored by name if the SYS: volume must be restored.

eDirectory Backup Guidelines
  • Even though eDirectory replicas are saved in hidden files on a server's SYS: volume, making a backup of SYS: does not make a backup of these replicas.
  • Back up eDirectory at least once a week, and before any major changes to the tree structure.
  • Partitions should be monitored to make sure they are synchronized. If you restore eDirectory data to a corrupted partition, that data will go to the Root partition. The result of a bad restore will be corruption of the tree.
  • You can back up the schema of your tree separately, or you can back it up as part of a full eDirectory backup.
Object IDs

The chapter explains in two places that eDirectory objects have object IDs, which are described as random numbers that are assigned to objects when they are created. The randomness of a number would appear to be a security feature, so the numbers are not predictable.

When an object is restored from a backup, one of two things can happen.

  • If the restored object has the same distinguished name as an object already in the tree, the object is overwritten in the tree, but the object ID is not.
  • If the restored object does not have the same distinguished name as an object already in the tree, a new object ID is created for it.
Novell Commercial Message?

The text makes a point that Novell's backup utilities allow selective backup and restore to your tree, but this feature is not found in all third party backup utilities. You are allowed to back up the entire tree, everything from a specific container to all its leaves (a branch), one container, or one leaf. This assumes that you have supervisor rights to all objects in the tree. If you do not, the utilities can scan for all objects to which you have supervisor rights in order to back them up.

The information above suggests the next topic: you can assign various users the supervisor right to various containers, which will allow them to make backups of those containers and the objects in them. To make this easier for these users (Novell calls them "backup administrators"), you create a file called SYS:\SYSTEM\TSA\TSANDS.CFG. Each line in this file will hold the typeful distinguished name of a container. Put a line in the file for each container that you assign to a backup administrator. This will make it easier for the backup administrators to back up only the branches they are responsible for.

Restore Data with SBCON and NWBACK32

Some of the same information needed when making a backup is needed when performing a restore. The chart in your chapter is merely a repeat of the one from the backup section. It should probably look more like this:

Target to restore: Choose this target:
A server's file system The server that holds that file system.
eDirectory Any server running TSANDS. This should be a server that holds a replica of the largest partition.
A workstation The workstation's host server, and the workstation. Both will be running TSAs.

The steps to perform a restore using SBCON and NWBACK32 are approximately the same as those for performing a backup.

Identify eDirectory Recovery Procedures

In the last section of the chapter, some advice is offered about restoring eDirectory. It is better to allow the replicated nature of eDirectory to make repairs than to perform restores. However, this is not always possible, so some general rules apply. If you lose eDirectory data:

  1. Delete data you know is corrupted.
  2. Allow the replicas time to recognize the deletion.
  3. Restore from tape.

If you lose a volume other than the SYS: volume, there is no direct damage to eDirectory, so a file restore is all that is needed.

If you lose a SYS: volume, or your only server, that server cannot run. The server will have to be reinstalled (both NetWare and eDirectory), and then restored from backup. The basic recovery procedure is:

  1. Repair or replace hardware as necessary.
  2. Install NetWare and eDirectory.
  3. Restore eDirectory.
  4. Restore file system.

The procedure is a bit different if this is one server in a large tree. Procedure:

  1. Repair or replace hardware.
  2. Restore the SERVDATA.NDS file from the failed server to another server on the network. The book does not state why this is done.
  3. Reinstall NetWare on the repaired server, then restore SERVDATA.NDS to its new SYS: volume.
  4. Restore eDirectory.
  5. Restore file system.
  6. Restore any replicas that should be on the server.

If you lose the entire tree, due to a disaster that harms all your servers:

  1. Repair or replace hardware.
  2. Install NetWare on the first server you replace/repair. You will create a tree from this server.
  3. Install NetWare on the other servers. These server will join the tree created on the first server. You will want to do specifically on the servers that will hold replicas.
  4. Restore eDirectory.
  5. Restore the file system to each server.
  6. Repartition the network, and place replicas as needed.