Backing Up and Restoring Files

Although current storage technologies, such as RAID, hot-swappable hard drives, and network-attached storage are making servers ever more secure in their capability to maintain data, there are still many ways in which data can be lost or corrupted. For those situations, it is necessary to have a backup of your network data so that lost files can be recovered.

OES Linux provides a data backup-and-restore infrastructure known as Storage Management Services (SMS). SMS makes it possible to copy your network data, including files, directories, the eDirectory database, and even data from other servers and clients, to an offline storage system such as tape or optical disk. With a well-developed backup strategy, you can be confident that you will always have a current copy of your network data, so you can restore files should the unthinkable occur.

There are several network backup solutions for Linux on the market today. Unfortunately, at the time of this writing, none of them builds upon this SMS foundation to deliver a comprehensive backup solution. This means that with third-party backup tools on Linux, you will be able to back up your filesystem, but extended data, like NSS ACLs, cannot be part of that backup. However, SMS is designed with networking environments in mind. Because of this, SMS-compliant backup programs running on other operating systems can effectively back up OES Linux servers. This means that another operating system, NetWare or Windows, is required for an enterprise-level backup solution, but obtaining complete backups is worth the trouble.

OES Linux does include a fairly basic Linux server-based, SMS-aware backup interface called nbackup. This utility will back up the data correctlyincluding extended databut it lacks many of the conveniences, such as flexible scheduling options, that third-party products have. This situation shouldn't last long, as third-party vendors are expected to release native Linux backup programs supporting SMS in the near future.

A solid backup strategy is critical to the well-being of your network. The following section describes backup strategies that can be employed to protect your valuable data. Although the majority of these strategies are explained from the perspective of using an enterprise-level backup software program, the essential features of nbackup are also discussed.

Planning a Backup Strategy

Planning is critical to developing an effective backup strategy. A well-planned backup strategy will avoid those headaches associated with finding and restoring files if that becomes necessary. It will reduce the time it takes to perform data backups and help keep your network humming along. When planning your backup strategy, consider the following:

How frequently should you make backups?
What type of medium are you going to use to back up your data?
How should you rotate your backup media?
Where will your backup copies be stored?
How and when will you test the restore procedure?

TIP

Although it is possible to back up eDirectory database files, restoring them is a prescription for major grief. Rather than trying to restore eDirectory objects from tape, use partition replication to restore objects to a server. For more information on eDirectory design and replication, see Chapter 7, "Novell eDirectory Management."

PLANNING A BACKUP SCHEDULE

An important part of determining how often you need to back up your data revolves around how rapidly significant changes to your data occur, and how important those changes are. A lot of this depends on your line of business. If your data changes rapidly, and those changes must be protected, you should plan on daily backups of that information. If your data changes more slowly, or if re-creating the lost data isn't a big deal, perhaps a weekly backup schedule will do the trick.

Enterprise backup products let you determine not only when to back up your network, but also what types of information you back up each time. There isn't much point in backing up all your network data every night if only a few of the files are changing each day.

If you don't need a full backup every time, you can perform what is known as an incremental backup. In an incremental backup, changed files are detected, and only those files are backed up. One particularly efficient way of backing up your network involves both incremental and full backup routines.

One day a week, you perform a full backup of the network. Then, on each subsequent day during that week, perform an incremental backup of only those files that have changed. Using this strategy, you can restore your entire system, if necessary, by first restoring the weekly backup, and then applying each daily backup to get your files back to their state the day prior to the system failure. This achieves full data protection while minimizing the time it takes to perform the daily backup routines.

Finally, a differential backup is a twist on the incremental backup. Differential backups are the same as incremental backups except that the archive bit is not reset as part of the backup process. This means that each differential backup will include all changed data since the last full backup, eliminating the need to restore multiple backup sessions in order to recover all file changes since the last full backup.

TIP

Backup products that are NSS-aware can speed up incremental backups significantly by leveraging the NSS Modified File List (MFL). The MFL maintains a list of changed files so that the backup software doesn't have to review every file manually to see which files have changed since the last backup.

Another tip for minimizing backup time is to organize your directory (folder) structure so that often-changed files are separate from seldom-changed files. For example, there's no point in wasting your time by frequently backing up files such as applications and utilities, which seldom change. If you put applications in one directory and work files in another, you can skip the application directory completely during incremental backups, making the process go faster.

Finally, be sure to document your backup schedule and keep a backup log. A written record of all backups and your backup strategy can help someone else restore the files if you aren't there.

CHOOSING YOUR BACKUP MEDIUM

Before purchasing a backup device, you must decide what kind of backup medium you want to use. Many manufacturers' backup products can back up data onto a variety of storage media, but it's a good idea to know what you want before you buy something that limits your choices. The medium you choose will probably depend on the following factors:

How much you're willing to spend.
How large your network is.
How long you need to retain your backed-up data. (Some media deteriorate after a few years; other media have a 100-year guarantee.)

Tape is still the most common backup medium in use today, especially in small- to medium-sized businesses. Tapes are relatively easy to use, can be used in any size network, and are fairly inexpensive.

NOTE

One of the downsides of tape is that backup manufacturers may use different, proprietary tape formats that aren't compatible with each other. Two tape standards have been established (one from Novell and another from Microsoft), so some efforts have been made to standardize on one or the other, but there are still differences between manufacturers. Be sure any backup product you buy is compatible with any other system with which you need to share tapes.

You should study the pros and cons of the various tape formats to find the best balance between cost and performance before making a decision.

If you are interested in very long-term storage, tapes suffer because they will break down over time. Optical storage such as writeable CDs and DVDs provide a storage medium that is much more resistant to the ravages of time. However, these solutions typically are significantly more expensive than tape solutions.

If you are unsure about the best storage medium for you, talk to your resellers about your specific needs, and let them help you choose the best fit for your storage needs. You should also verify that your backup server and software support the hardware you are planning to use.

PLANNING THE MEDIA ROTATION

When you are using rewriteable media, such as tapes, plan to have multiple sets of backup media that can be rotated. This way you keep multiple datasets available at all times. If your current backup is corrupted for any reason, you can still fall back to an older copy. Many network administrators use three or more sets of backup media and cycle through them, one each week. That way, three or more backup datasets are available at any given time. The number of tapes or disks you need depends on the rotation schedule you select.

Some backup products offer preset rotation schedules for you. They will automatically prompt you for the right set of media and keep track of the schedule.

DECIDING WHERE TO STORE THE BACKUPS

Another important aspect of your backup strategy is to plan where to store your backups. If you have backups of noncritical data, you might be comfortable keeping them onsite. However, when storing backups onsite, you should at least store them in a room separate from the server's room. If a fire breaks out in the server room, your backup tapes won't do you much good if they're lying melted beside the server.

For mission-critical data, you might need to keep backups in an off-site location. That way, if a physical disaster occurs (such as a fire, flood, or earthquake), they'll be safe. If the data is critical enough to store off-site, but you also want to have immediate access to it, consider making two copies and storing one off-site and the other on-site.

TESTING THE RESTORE PROCESS

A backup is useful only if the data in it can be restored successfully. Too many people discover, too late, a problem with their backups when they're in the middle of an important data restore process. One way to avoid this is to practice restoring files in a lab environment. This will not only familiarize your staff with the process, but will also test the quality and integrity of your backup data. By practicing, you can identify problems you didn't realize you had. Don't wait until it's too late.

The correct frequency for testing your restore process is dependent upon the frequency of your backups and the criticality of your data. For very sensitive systems, monthly tests might be necessary, but for most environments, a quarterly test of your restore process will probably be sufficient.

Storage Management Services (SMS)

As previously mentioned, Storage Management Services (SMS) provides a data backup-and-restore infrastructure to OES Linux. This infrastructure is built upon two main components:

Storage Management Data Requester (SMDR) The Storage Management Data Requester is responsible for providing connectivity between a backup application and a Target Service Agent (TSA). The daemon responsible for this process is smdrd. As incoming requests are received by smdrd, new processes are spawned to handle each request. Each process then loads the TSA required for the backup operation.
Target Service Agent (TSA) A Target Service Agent is responsible for providing backup capabilities for a specific resource. This resource could be a filesystem (such as NSS) or application (such as GroupWise). The TSA does this by abstracting the data of the resource and providing that data to the backup service using the ECMA standard System Independent Data Format (SDIF). The TSA provided with OES is tsafs, which provides TSA services for the NSS filesystem.

The most important aspect of the SMS infrastructure is that the TSA understands details of the backup target that normal, file-only backup services cannot understand. More specifically, tsafs understands extended characteristics of NSS because it was written to communicate with NSS through NSS APIs. The end result is that a backup taken through an SMS-aware backup program will be able to preserve NSS characteristics that normal, file-only backups will miss.

TUNING SMS COMPONENTS

Both the SMDR and TSA components can be tuned for operational and performance reasons. This tuning is normally performed through iManager, as shown in Figures 11.9 and 11.10.

Figure 11.9. SMDR Configuration page in iManager.

Figure 11.10. TSA Configuration page in iManager.

The main configuration file for the SMDR daemon is /etc/opt/novell/sms/smdrd.conf. If necessary, this file can be edited manually. If any changes are made to this file, refresh smdrd using the rcnovell-smdrd refresh command.

The main configuration file for the filesystem TSA is /etc/opt/novell/sms/tsafs.conf. If necessary, this file can be edited manually. If any changes are made to this file, refresh the TSA using the smsconfig utility. The syntax for refreshing the TSA using smsconfig is smsconfig r tsafs.

THE `nbackup` UTILITY

The nbackup is a console-based utility that is included in the SMS component of OES Linux. This utility is an SMS-compliant backup that is intended to provide basic backup services for OES Linux.

By default, this utility is located in the /opt/novell/sms/bin directory (along with all the other SMS binaries). This directory is not normally on your path, so it must be executed using the full path (that is, /opt/novell/sms/bin/nbackup). To avoid this situation, you can add this directory to your path using the following command:

 export PATH=$PATH:/opt/novell/sms/bin

As mentioned before, at the time of this writing, nbackup is the only Linux-based SMS-aware backup utility. As nbackup is intended for basic backup functions, it may be difficult to build an entire enterprise-level backup process around this utility. If you want a more complete solution, any SMS-aware backup product, running on any OS, should be able to connect to the local TSA and back up your OES Linux NSS volumes.

Proper usage of nbackup is demonstrated later in this chapter. For more information on nbackup, and the other SMS components, see the online OES Linux documentation.

Preparing to Back Up

There are four major steps involved in configuring an SMS backup system for use:

1.	Install the Storage Management Services (SMS) on your OES Linux server. SMS is the collection of files and utilities that comprise the OES backup solution. It also provides a foundation and common interface for third-party vendors that allow their backup applications to communicate with OES.
2.	Set up a host server (backup server) by installing a backup device and loading any required device's drivers. This can be a server or any workstation with the appropriate software. NOTE Although this server can be your OES Linux server, be aware that the only SMS-aware backup utility for Linux is `nbackup`. For additional flexibility and features of a comprehensive backup product, you may want to use a NetWare or Windows machine as your backup server.
3.	Configure your OES Linux server by loading the SMS components. If additional servers or workstations are to be backed up, ensure that they have the proper TSAs loaded. These servers and workstations are called targets.
4.	Begin the backup using a Storage Management Engine (SME) on either the host server or a workstation. The SME is the interface from which you will run backup and restore operations. `nbackup` is an SME that is available with OES Linux.

You will perform these basic steps whether you choose to use nbackup or some other utility as your preferred SME. Several third-party vendors offer backup/restore utilities that function as SMEs. Should you choose a third-party backup solution, ensure it is SMS-compliant.

The following sections provide details on each of these four documented backup steps.

INSTALLING STORAGE MANAGEMENT SERVICES

You can install SMS during the installation of OES Linux, by choosing it as an optional OES service. You also can install SMS after the fact through YaST. To install SMS through YaST, complete the following steps:

1.	Access YaST from a terminal using `yast`, or from a graphical environment using `yast2` or the YaST launcher from the application menu.
2.	Select the System category in YaST. From within this category, locate and select the SMS module. This module will detect that the RPMs for SMS are missing and ask if you want to install them. Select Continue to install the necessary packages.
3.	At the conclusion of the software installation, `SuSEconfig` is executed to update the system configuration. When this completes, the configuration of the OES component will begin automatically.
4.	At the SMS LDAP Server Configuration screen, enter the following information and click Next: Local or Remote Directory Server Select the radio button that indicates whether eDirectory is running on the local server or a remote server. Directory Server Address If a remote eDirectory server is in use, enter the IP address for this server. Admin Name with Context Enter the eDirectory administrator's credentials using fully qualified dot notation, for example, `cn=admin.o=novell`. Admin Password Enter the password for the administrator user. Port Details If necessary, select this button to change the configured ports for the eDirectory server you specified earlier. The default LDAP port for unencrypted communications is `389` and port `636` is used for SSL-encrypted communications.

With SMS installed, you are now ready to configure the backup/restore environment on your OES Linux server.

SETTING UP THE HOST SERVER

Before you can perform any type of backup, you must first prepare the host server that will be responsible for performing the backup and writing data to the backup media. The following steps summarize this process:

Attach the backup device (tape or disk drive) to the host server, following the manufacturer's instructions.

Load the necessary backup device drivers on the host server, again following manufacturer's instructions. For example, to manually load the driver for a generic SCSI tape device, execute the following command:

 modprobe st

Confirm that the device is loaded, and recognized using the mt command as follows:

 mt f /dev/st0 status

TIP

To load the SCSI tape device modules upon system startup, edit the /etc/sysconfig/kernel file and add the module names to the MODULES_LOADED_ ON_BOOT directive. For example, for the generic st device, this entry should appear as:

 MODULES_LOADED_ON_BOOT="st"

When these steps are completed, the host server is prepared, and the target server must be configured. For more information on configuring your host device, refer to the documentation supplied with your backup hardware.

SETTING UP TARGETS

Backup targets can be your OES Linux server, or any other server or workstation with the necessary TSA. The following steps describe the process for configuring your OES Linux server as a backup target:

Load the SMDR daemon on your OES Linux server using the following command:

 rcnovell-smdrd start

This will load the SMDR daemon (smdrd) and register the NSS TSA (tsafs) with SMDR. These components were explained earlier in this chapter.

If you would like these services to be loaded upon server startup, use insserv to add this service to the startup process of your OES machine. The syntax for this command is

 insserv novell-smdrd

(Optional) If you are going to back up any other target servers, you need to load the appropriate TSA(s) on each target. The SMS modules for other OES Linux servers must all be loaded as explained in step 1. For other NetWare servers that might be functioning as a target server, load the following modules:

TSAFS Load on OES NetWare target servers.
TSA600 Load on NetWare 6 target servers.
TSA500 Load on NetWare 5 target servers.
TSA410 Load on NetWare 4 target servers.

When these steps are completed, the target preparation is complete, and the target server is ready to be backed up.

BACKING UP FILES WITH `nbackup`

After you've loaded the necessary drivers and software on the host server and loaded a TSA on the OES Linux target server (or other servers or workstations), you are ready to back up the target's files. OES Linux provides nbackup as a console-based utility for backing up network data.

To use nbackup to back up files, complete the following steps:

1.	Identify the backup target you would like to back up. This should be the full path to a location under the mount point of the NSS volume. To back up a specific directory, use the full path to the directory itself. To back up all data on an NSS volume, use the full path to the mounted volume, followed by an asterisk (). For example, to back up all files on `NSSVOL1`, which is mounted at `/media/nss/NSSVOL1`, the backup target would be `/media/nss/NSSVOL1/`.
2.	Determine the filename or backup device you would like to write the data to. If you are writing the backup to a backup device, the device name should be in the format of `/dev/st0`.
3.	Determine a username to use for authentication to the TSA. This is normally your eDirectory admin user. This name should be entered in the format of `admin.novell`.
4.	Begin the `nbackup` process using the information retrieved in steps 13. The command line should appear as follows: nbackup cvf <Backup_File_Or_Device> -U <Username> <Backup_Target>

nbackup can also be used to restore backup archives using the x command-line parameter in place of c. The t command-line parameter can be used to view the contents of backup files and tapes.

Although nbackup is not a full-featured backup product, it does have one advantage. It is completely command-line-driven and therefore fully useable through scripts. These scripts can then be scheduled for execution through CRON. This combination makes for a simple, yet effective, backup solution. For more information on nbackup, see the man page or online OES Linux documentation.