"Make frequent backups" has become something of an oft-ignored litany in the world of computer publications. Countless authors have tried to emphasize the importance of frequent and reliable backups. When administering a network, however, backing up your systems becomes less a matter of convenience and more of an absolute requirement, if you intend to keep your job for any length of time.
Unfortunately, many erstwhile administrators learned this lesson in the same way that a student driver learns to drive a stick shift, that is to say, by stalling out in traffic. One day, you find yourself face-to-face with the boss, being told that the new guy in Accounting just deleted the master database file, and would you please restore it from yesterday's backup? No matter what the reason why not, if you don't have that file, you're about to learn a lesson that will remain with you for the rest of your brief career.
Backing up a stand-alone PC is more often a matter of preserving a carefully tuned environment, rather than protecting vital data, which can very likely be stored on a couple of floppies. The worst-case scenario would be having to reinstall and reconfigure all of the machine's applications. But, multiply this situation by dozens or hundreds of workstations, and add several servers full of vital company data, and the picture changes considerably.
There is no greater career pitfall than having to tell your supervisor that work needs to be redone because there is no backup. All of the computer jargon that you may have learned to throw at management up until now will be useless. They don't care why. At this point, they only see the dollar signs of lost production, as compared to the dollar signs of that expensive tape drive.
On a more serious note, it may not even be solely a matter of time or money. As more and more critical industries convert to client/server systems for their computing needs, the loss of data could lead to the interruption of vital services or, in a medical situation, even the loss of life. I can therefore safely add my voice to the chorus and say, with even greater emphasis, "Backup well, and backup often."
This chapter helps you towards that end by discussing the various criteria that should be considered before purchasing a network backup system. We will also discuss the general nature of network backup software, the configuration options available to help you devise a responsible long-term backup rotation scheme, some of the more common problems affecting network backups and solutions that can help you troubleshoot any problems that may arise. The hardware used for backup systems is covered elsewhere in this book. SCSI and other peripheral interfaces are discussed in chapter 5, "The Server Platform."
Unfortunately, making backups is not only more crucial on a local area network, it is also far more complex. It would obviously be impractical to furnish each workstation and file server on a network with its own means for backup. After all, sharing resources is what networking is all about, right? It is therefore a relatively simple matter to decide that there should be one or more backup drives located somewhere on the network, managed from a central interface. This is the last simple decision in the process.
The questions begin to come thick and fast at this point. "What kind of backup device should I buy?" "Where should the backup device be located?" "When should the backups be done?" "How can I make sure that they are done frequently enough?" And a dozen others. It is important to realize that most network backup systems utilize virtually every system that is pafigof the network, often stretching most of them to the limits of their capacity. There will be NLMs or services that run on the file server, a client program that runs on a workstation, and a level of data transfer between the two that greatly exceeds that of normal use. In short, there are a great many variables that must be considered in the process of backing up a LAN, and only you can determine which are the most important to the way that you, your department, and your company work.
In this chapter, we will first attempt to identify the right questions to ask in order to design and configure a centralized backup solution that is catered to your network's needs, and then discuss several possible network backup strategies in an attempt to answer them.
The first question is the easiest. Whenever possible, the best time to plan a backup strategy is while the network is being designed or upgraded. Unlike many backup systems designed for use with single PCs, which can easily be retrofitted to an existing installation and moved to a different machine if necessary, network backup products are designed to be completely integrated into the network environment, particularly on the hardware level. SCSI has become the de facto standard for network storage subsystems, primarily because of its ability to effectively process simultaneous requests from different sources to multiple devices.
There was a time when tales of SCSI device incompatibility were rampant, and many administrators ended up with file servers containing several SCSI adapters, each addressing a single device, because of difficulties in getting the devices to work together on a single bus. The current generation of SCSI hardware, though, has come a long way in addressing these problems which, truth to tell, were probably caused as much by improper configuration as they were by badly designed hardware. There should be no problem in running today's tape drives on the same SCSI bus as hard drives, CD-ROMs, and other devices, as long as all of the devices are purchased with an eye towards interoperability.
The majority of problems that arise in setting up backup systems come from attempts to add additional hardware to an existing system without fully researching the compatibility of the devices. It is essential that devices that are to reside on the same bus be compatible. Otherwise, a tape drive that has been band-aided onto an existing SCSI bus can cause problems with existing hard drive systems, leading to network interruptions and angry users.
This situation is particularly common when attempts are made to integrate the cutting edge of technology with older, legacy equipment. I encountered one case in which a person bought a brand new Pentium-based file server and a top of the line 4mm DAT tape drive, and then proceeded to stick his old ISA PIO-based SCSI card into the server. He then wondered why his hard drive volumes would frequently dismount and his backups run so slowly, if at all. For the want of a new $300 SCSI adapter, his $15,000 investment was going to waste.
Therefore, when adding a backup system to an existing network or file server, the single most important factor is compatibility. Before you even begin to shop for products, you should have prepared a complete list of all of the hardware that you already possess, and everything about that hardware that might be significant. If you have a properly documented network, this process is already done. If, as in most shops, you do not, you will never regret spending a Saturday afternoon opening up your file servers and identifying everything inside. Gather the model numbers of all of the components and, where applicable, the firmwares being used as well. Hard drives, SCSI adapters, tape drives, and motherboards all have firmwares or chipset specifications that can be crucial in determining the compatibility of various devices. While you have the case open, take down the serial numbers of everything as well, in case of theft. If you have ever been in the position of taking over for a LAN administrator who has left a company without maintaining such a list, you will appreciate its value and, hopefully, be a little kinder to the next guy in your job, okay?
You may find, as a result of this process, that some of the hardware in the server from which you intend to backup your network is older or less powerful than you thought it was. In cases like this, it may actually be a wiser decision to add another SCSI card to a server for connecting to a tape drive rather than add to the burden of an existing SCSI bus that cannot readily be replaced at this time. It may even be time to think about purchasing an additional machine to augment or replace an aging one, rather than jeopardize the functionality of your existing systems.
The best possible way to create an effective backup system for a local area network, however, is to integrate the backup device into a fully realized storage subsystem that has been designed in consideration of the company's data storage needs. Answering a few vital questions at the outset of the project can save considerable time, money, and aggravation. As you decide how much disk space your network will need, you should also consider the type of data to be stored, how much there is of it, how volatile the data is (that is, how often does it change), and how much time is available to back it up. These are the kind of questions that should influence your purchasing decisions regarding backup media, hardware, and software.
Successfully organizing a network is a task that does not conclude with the signing of the purchase orders. One must also plan the way in which the network is going to be used, and creating a network backup strategy must be fully integrated into that process. Storage needs can be broken down into two basic categories: applications and data. Purchasing decisions concerning backups should be made after it has been decided where the applications will reside and where the data will be stored. Backing up one hundred copies of a word processing application installed to individual workstation hard drives is quite a different proposition from backing up one shared network copy of the application. The difference between the two should heavily influence the decision as to what the capacity and speed of the backup device(s) should fig
Remember also that restoring an application that has been lost due to drive failure is not simply a matter of the cost of the software itself. You must consider the amount of time and effort needed to restore the network to itsfigeviously functional state. Multiple copies of an application are likely to have been tweaked by their users to a state in which they are most useful to each individual. This may involve a significant amount of time and labor to re-create. Therefore, the nature of the applications (and their users) must also be considered when deciding whether or not to back them up. Devoting an extra hour or two of backup time each night to files that could take dozens of hours to restore manually is well worth the tradeoff.
In the same way, if data is to be stored on the workstation hard drives, as opposed to those of the file server, then the frequency of workstation backups is affected. This may influence the purchasing process towards a software package that has more extensive support for workstations running different operating systems or one whose cost includes a license to back up an unlimited number of workstations. Data is usually far more costly to replace than applications, so policies should be established and enforced that dictate where data files will be stored by users. Backup routines can then be customized to accomodate these policies. It is only by asking questions such as these and carefully planning your network that an intelligent determination can be made as to your backup hardware and software needs.
The next question to ask when considering backup needs is how much total disk space there will be on the network. Even this question, though, gives rise to many other questions. In most businesses, it will not be necessary to back up every byte on every drive throughout the network every day. There is, therefore, usually no need to purchase a tape backup system with the storage capacity to back up the entire network onto one tape. After arriving at a total quantity of disk space for the entire enterprise, an attempt should be made to prioritize the available storage space in order to determine what the daily backup requirements will be. These daily backups should be able to be conducted as one unattended operation. If there is too much data to fit onto one tape, then multiple tape drives or a tape autochanger may be called for.
Data files, of course, should be given first priority, and should be backed up at least once a day, depending on the type and amount of data. Priorities should also be established as to what quantity of data files change on a daily basis, as opposed to others that might be accessed often, but remain unchanged for long periods.
Applications, as a general rule, do not need to be backed up as often as data files, but while executables do not change, many applications maintain configuration files, properties, and definitions that can be as volatile as the data files themselves. These files should be backed up more often than the applications themselves.
Another consideration is the physical location of the hard drives on the network. The original concept behind the local area network was to have several file servers spread hard drive space throughout the enterprise, thus allowing for system redundancy. Many shops, however, are now adopting the "super-server" concept; setting up a single server with a huge amount of disk space in one storage array instead. Conditions such as these should be accounted for when attempting to estimate the length of the backup window, due to the variations in backup throughput of various devices on the network.
The backup window is the amount of low usage time that your company's operating schedule makes available for backup jobs to be conducted. As shown in figure 17.1, the fastest and most efficient backup operations will occur when file server hard drives are backed up to a tape device on the same SCSI bus. Next in overall throughput would be remote server drives being backed up over a high bandwidth backbone such as FDDI, then server drives being backed up over a standard Ethernet or Token Ring LAN connection, and then workstation drives over the LAN connection. Using a tape drive connected to a workstation reduces the backup rate of all targets (except the drives within that workstation) to the slowest of these figures. Obviously, the more data there is to back up and smaller the backup window, then the faster the backup throughput must be.
Figure 17.1 These are backup targets and their relative throughputs.
Another wrinkle to the equation is increasing use of WAN links to interconnect remotely located networks. Even a fully dedicated T1 link provides only a 1.55 Mbps maximum transfer rate, as opposed to the 10 Mbps rate of standard Ethernet. For this reason, it becomes increasingly difficult to back up significant amounts of data over a WAN link within the limitations of a given backup window. Although a backup of selected data files from a remote office can be more economically efficient than the purchase of another entire backup system, only actual testing will tell just how much throughput can be achieved over a given link. You should not, for example, count on a backup rate of 1.55 M/sec over a T1. Other network traffic must be considered, and the specifications of the equipment usually yield estimates that are optimistic, to say the least.
One of the important factors in assessingfignetwork's backup needs is whether or not workstations need to be backed up and if so, how often. As a general rule, it is wise to have users store all of their data on file servers, rather than workstation drives. This helps to protect their files against the possibility of workstation crashes, accidental deletion, or theft. However, this does not necessarily mean that the workstations need not be backed up. In a case such as this, the frequency of workstation backups should depend on the company standards for the workstation environment.
If an organization has standardized on a particular workstation configuration and allows no individual software selection by users, then a master workstation replica can be stored on a server, and workstation backups can be omitted, except perhaps for Windows INI files and other unique configurational elements. Even a company that allows its users complete freedom of choice in software selection and configuration, however, should consider that backing up hundreds of identical DOS directories and useless Windows swap files is a waste of time, bandwidth, and media.
Whenever possible, system backups should occur at times when network usage is at its lowest. While, in some firms, this backup window may stretch from 5 p.m. until 9 a.m. the next morning, allowing plenty of time for backups, flextime hours, and multiple shifts can, in many cases, drastically reduce the amount of time available to back up the network. This is a crucial factor influencing purchasing decisions of both hardware and software. A faster tape drive (or multiple tape drives) may be called for when there is a large amount of data to be backed up in a small amount of time, and the capabilities of a software package's scheduling features should be considered to ensure that backup jobs can be configured to automatically begin at the correct time, only on the days that you want it to.
Once it has been determined how much data there is to be backed up, where that data is located, and when the backups should occur, the next decision concerns the location of the backup device and what system it is connected to. This is a crucial factor in terms of convenience, security, and especially cost. All of the repercussions of each option should be considered in relation to the way in which the network has been designed. Essentially, there are three possible solutions: a workstation-based tape drive, a drive attached to a production file server, and a dedicated backup server. The pros and cons of each method must be considered, as there is no definitive solution that will fit all cases. These methods are discussed in the following sections.
There are several advantages to a workstation-based backup solution, the most prominent one being cost. There are several good workstation-based backup software packages available that are capable of backing up multiple file servers, and even other workstations, when they are made accessible through a peer networking protocol such as Windows for Workgroups' NetBEUI. In fact, these packages can usually back up any drive that can be mapped to a workstation drive letter. Software such as this is usually quite inexpensive, costing anywhere from $100 to $300, approximately 10% of the cost of an average server-based software package, which is usually priced according to the number or user-level of the servers being backed up.
While there are a great many backup software packages designed to be used for individual PCs with attached tape drives, comparatively few of these products address the needs of networks. In the networking context with which we are concerned, a software product should be able to back up a server volume, as well as protect its system files, such as the Windows NT Registry, the NetWare bindery or the NDS database. Products like these are available from companies that are primarily devoted to developing backup software for the network environment, such as Cheyenne Software, Arcada, Legato, and Palindrome. All of these companies offer a wide array of solutions for different network types and operating systems.
Hardware, too, can be less expensive. While most of the same large capacity SCSI tape drives used on server-based systems can also be used with these lower-end software packages, there are also a large number of low-cost quarter-inch cartridge (QIC) tape drives on the market which are usually not recommended for server use, but which can be quite effective in this environment. Most of these, however, are obsolescing rapidly due to their limited capacity and the ever-increasing hard drive capacities being found on workstations and servers alike. When even an entry-level PC comes with a 500 M hard drive, a 250 or even a 500 M QIC tape drive does not appear to be a wise investment, especially for heavy use.
Another advantage of the workstation-based solution is the fact that, in a disaster recovery situation, a file server can be more easily restored from a remote system than from a drive that is attached to the file server itself. It would only be necessary to re-install enough of the network operating system to create the drive volumes and bind a network protocol. Everything else can be restored from the workstation. For this reason, many larger firms choose to assemble a redundant arrangement of backup hardware and software that can operate both on a workstation and a file server. Cheyenne Software, for example, markets software packages for both the workstation (ARCsolo) and the file server (ARCserve) that utilize the same interchangeable tape format. By purchasing external tape devices, the backup drive can swiftly be moved from file server to workstation in the event of a complete file server failure.
As you might expect, there are several major drawbacks to a workstation-based backup solution. The first and foremost is speed. Sending data from a file server to a workstation-based tape drive over a standard Ethernet or Token Ring IPX/SPX network connection will take far longer (roughly twice the time) than it would take to back it up to a tape drive installed on the file server itself, particularly when the hard drives and the tape drive are on the same SCSI bus. Another limitation is the fact that the workstation is limited to backing up only as many sources as can be mapped to its drives at any one time, which leads to the other major concern, which is security.
A workstation running software that schedules backups to occur during the night must be left logged in to all of the target servers with the appropriate rights to access all of their files. The memory resident application that is used to schedule the backups can also interfere with normal use of the workstation, so unless a computer is to be dedicated solely to backups and placed in a locked room, this sort of backup solution becomes less and less practical.
For a small business or workgroup consisting of a single server and a handful of workstations, however, this type of backup system is the most cost-efficient way of protecting the network against data loss. It is a mistake to let cost factors outweigh concerns for data integrity, but many small businesses allow themselves to be terrorized into the purchase of expensive, high-powered backup systems costing as much as their file servers, which are completely unnecessary for their current needs.
A good rule of thumb when making any purchasing decision in network computing is to base your purchase on what you need right now, and not on any future plans that extend more than two or three months ahead. Just about the only sure thing in the computer industry is that it continuously changes. No matter what you purchase today, there will be something available a few months from now that will be better, faster, and cheaper. There is nothing to be done about this except to try to keep current, and make the most intelligent decisions that you can, right now.
(c)File Server-Based Backups
The most common network backup configuration in use today is a NetWare NLM-based software package and one or more 4mm DAT tape drives attached to a file server's SCSI bus. When properly configured, this should allow approximately 15 to 20M of data to be backed up per minute onto tapes holding anywhere from 2 to 8G. This is usually sufficient protection for a medium-sized network, when the backup jobs are configured properly. Most of the major server-based backup software packages also allow multiple tape drives to run concurrently on the same SCSI bus, yielding cumulative backup rates of 100ñ150 M/min or more.
Depending on the number and current configuration of your file servers and your plans for future expansion, you may choose to add a backup system to an existing server or create a dedicated backup server. There are advantages and drawbacks to both alternatives. Adding a backup system to an existing server should only be done when that server has the resources available to support both the software and the hardware. Major NLM-based backup software packages may require up to 4M of memory to operate properly, in addition to what is already needed to support the operating system and the equipment already installed. Many packages, when actually processing a backup or restore job, spawn (or autoload) additional NLMs that are not resident when the software is loaded, but idle; so be sure to account for this when evaluating the additional load that such a system will add to your server. Another consideration may be processor utilization. Certain functions of backup software, especially database engines, can drastically increase the load on the server's CPU, at times. This can result in delayed access to users and even the temporary loss of the ability to communicate with the server.
In cases where it is felt that backup software places too much strain on an existing system, a file server dedicated to the performance of backups may be in order. A non-production server such as this, dedicated to network maintenance tasks (as opposed to servicing users), can also be the host for other network management products. As long as user access is restricted, then other network functions should not be disturbed by the backup process.
Another advantage to this concept is that, if it is absolutely necessary, backups can be scheduled to run during the workday. The problems caused by open files will still remain, as will a perceptible amount of network performance degradation, but in cases where there is no other choice, this method will minimize the impact of these problems.
The primary disadvantage to a dedicated backup server is the additional expense, not only for the hardware, but for the operating system as well. You must be sure that licensing considerations of the backup software allow you to back up all of your other servers. This may require you to purchase a network operating system license for a user level equivalent to that of your other servers, when there will actually be only a minimum number of users logged in to this server at any one time.
Another disadvantage may be that the speed of your backups will be negatively affected. A backup of a hard drive that is in the same machine as the backup hardware, or better yet, on the same SCSI bus, will always be faster than one that must travel over the network itself. If you have a high speed network backbone, or if the length of the backup jobs is not critical, then this may not be an issue. In general, if you have a great deal of data to back up, or if you will be running multiple backup devices simultaneously, a dedicated backup server may be a solution that will end up causing fewer administration problems and being more economical in the long run.
The following sections examine the basic components of network backup software, and identify the areas in which the various products may differ. Some packages may be better suited to your network's needs for economic reasons while some may offer features that you require that others do not yet possess. It should be noted, however, that software of this type is continually developing as the rest of the industry develops. The basic goals of all network backup software packages are essentially identical, that is, to be capable of backing up and restoring all of the data types that may be found on today's heterogeneous networks as quickly and efficiently as possible. New developments in hardware and operating systems will inevitably be accommodated by backup software, and you may wish to choose a software vendor that most responsively and reliably updates its products to accommodate these innovations.
Novell NetWare ships with a rudimentary file server utility called SBACKUP that will allow file servers and workstations to be backed up to a tape device. However, SBACKUP lacks nearly all of the advanced scheduling and convenience features found in any of the third-party products available. Consistency is everything in a reliable backup system, and SBACKUP, while it can effectively be used for a one-time job, leaves too many repetitive administration tasks to the operator to be a reliable everyday solution. Its use as a primary backup solution is therefore not recommended, but familiarity with its functions can be beneficial for two reasons.
First is the simple fact that every NetWare installation has it. In a situation when no other tools are available, such as that of a consultant visiting a remote site, the ability to perform a simple full backup of a server may be desirable and SBACKUP can come in very handy at times. The other benefit of knowing SBACKUP is that it relies on the Novell Storage Management Services (SMS) system to perform its backups. Many third-party backup products use SMS for their own backups, to some degree, so familiarity with its modules and concepts can be useful in evaluating these packages.
Storage Management Services is an open specification developed by Novell for a standard set of Application Programming Interfaces (APIs) designed to provide a reliable interface between backup and storage management products and the various data types found in the modern heterogeneous network environment. When creating this specification, Novell clearly planned for its adoption by third-party developers. While SBACKUP utilizes the specification, it was no more intended to be a comprehensive backup solution than the Windows Terminal program was intended to be a full-featured communications package.
The specification consists of several basic components, each of which may or may not be used by a third-party backup package:
ï The Storage Management Engine (SME) is the heart of any SMS compliant backup system and is the module most intended by Novell to be developed by other software vendors. It controls the communications with the backup hardware and provides the user interface by which backup jobs are created, scheduled, and administered. SBACKUP is Novell's implementation of an SME.
ï The Target Service Agents (TSAs) are, on the other hand, the modules that are most likely to be utilized as is by third-party developers. These are the memory resident modules that perform the basic file system communications with the targetsóthat is, the parts of the network that are to be backed up. The TSAs, operating remotely throughout the network, are the only part of the SMS system that is in direct contact with the target data. They process the files on their designated targets and send the data to the SME via the Storage Management Data Requester (SMDR). Novell has made TSAs available for all of the basic data types found on most networks, including DOS, Macintosh, OS/2's HPFS, FTAM, NFS, and NetWare volumes, as well as for NetWare 4.x's Directory Services database, SQL database engines, and print servers. Other manufacturers have released TSAs of their own that conform with the Novell standard APIs and that can effectively be used with any SMS-compliant storage management engine.
ï The System Independent Data Format (SIDF) is a specification for the actual data format used to store files on tape. The TSAs send the target data to the SME using the encoding scheme specified in the SIDF specification. The developer of the SME can then choose whether to actually write the data to tape in this format or convert it to a proprietary one. This format, which has been adopted in theory by many of the major backup software manufacturers, should allow for tapes made with one software package supporting the format to be restored by another package. This interchangeability, however, has not been found to be as simple and reliable as some of the software manufacturers would lead you to believe. In most cases, transferring tapes between software packages should not be relied upon as a regular practice, unless careful testing is done beforehand. However, the continuing development of the standard bodes well for the backup industry in general, and lends a measure of assurance to the user that they will not find themselves with a large library of tapes that have been abandoned by a manufacturer that has changed formats or gone out of business.
The interaction of the various modules is illustrated in figure 17.2
Figure 17.2 This is the Novell Storage Management Services MOdel.
The degree to which various backup software packages utilize SMS is highly variable. Novell has designated Level Two compliance to apply to any SME that fully utilizes the entire SMS specification. Some products, such as Palindrome's Network Archivist, offer such compliance. They are completely reliant on the SMS standards and are, in effect, guaranteeing the continued development of their product as long as Novell continues to support new data formats and operating systems with its TSAs. Palindrome has also written some of its own TSAs that are fully SMS compliant as well and can, therefore, be used with any other SMS-compliant software.
Level One compliance applies to software that can make use of the SMS TSAs to communicate with network targets. Many software developers use this as an optional feature for their products, or use the TSAs to enhance their range of services, employing proprietary communication methods for some file formats and using TSAs for others. It should be noted when evaluating products like these that any tape written using SMS can only be restored using SMS. Whether or not to choose a software package that is fully SMS compliant is a difficult question.
The main drawback to the specification is the greater amount of communications overhead involved than with most proprietary solutions, causing backup throughput speeds to be generally slower with SMS. I have not seen this difference in speed to be an overly dramatic one, however, and unless your installation requires the fastest possible backup speeds that you can achieve, this should not be a major factor influencing your purchasing decision. More attention should be paid to the present and future data types that you will be backing up and whether or not the package that you choose can support them.
Some backup systems provide the option of not utilizing SMS at all, but care should be taken to note the instances when SMS is positively required to perform a proper backup job in today's networking environments. An interesting case in point is the need to back up the NDS databases that are the heart of the NetWare 4.x network operating system. The continued development of the NDS, since the original NetWare 4.0 release, has caused an ongoing problem for the developers of network backup software. At this time, there is no other backup agent available that can provide the full range of services to a NetWare 4.x server that Novell's own TSAs can, which includes complete backup of the NDS database as well as full support for NetWare 4.x's native compression features. This means that all files compressed by the NetWare 4.x operating system can be backed up and restored as compressed files, greatly reducing the amount of data traveling from the target to the backup hardware. However, even implementing the use of these TSAs has caused developers severe problems when modifying their existing products. While all of the major developers were in the process of readying native NDS implementations of their software, this process entailed major code revisions, in most cases, and a temporary solution was needed to accommodate the needs of their users.
The way in which the various manufacturers worked to meet this need provides a good indication of their responsiveness to the market and the capabilities of their programmers to adapt their software to the changing needs of the industry. You may wish to ask how long it was before a particular manufacturer's product could be adapted to the backup of the NDS. You should also note the nature of the resulting product: was it a solution that was integrated into their existing software product, or an extra utility shipped to fill a temporary gap?
The average file server-based backup software package usually consist of a client application, a series of server modules, and a collection of agents. The "back end" or server portion will be packaged as NetWare NLMs or Windows NT services that perform three functions:
The client or "front end" portion consists of a manager program through which backup and restore operations are created, controlled, and scheduled, and a series of agents that allow networked resources on various platforms to be backed up. Examining these in greater depth will allow you to intelligently compare the feature sets available in the various packages and thereby judge which of several admittedly similar products best suits the needs of your network.
At the heart of any network backup program is the device interface modules, or the means by which the target data is sent to the tape drive itself. It would seem to be a fairly simple proposition to feed the data that is gathered from the various target drives over the SCSI bus to the tape drive, but the process is actually quite complex. Tape drives are sequential access devices; that is, data is written in a contiguous stream onto the tape and must be accessed in the same manner. This is unlike a random access device such as a hard drive, in which files may be broken into separate sectors depending on the nature of the free space available on the device.
A hard drive's platters spin continuously, with the heads making contact with the appropriate sectors on the platters only when a read or write is requested. This is why a hard drive's access time is measured in milliseconds, because the head simply has to proceed to the proper position, and move a tiny distance to make contact with the platter. With a tape drive, however, the tape is only in motion during the processing of a request, and must be traveling at the correct speed across the heads for data to be read or written correctly.
Every time that a tape drive stops moving the tape across the heads during an operation, there is a period of lag time while the drive spins up to the proper speed for reliable access. Earlier incarnations of magnetic tape storage applications would simply wait for the tape drive to achieve the proper speed before actually performing the read or write operation, slowing down their operational throughput considerably. With modern tape backup systems, however, data is fed to the tape drive at the proper rate of speed to keep the drive streaming, that is, moving the tape across the drive heads at a uniform rate of speed with no starts or stops. In this way, data will be transferred at the best possible speed with the least likelihood of data corruption. Tape servers do this by storing small amounts of data that have been accessed from the backup target devices in memory pools created on the file server from which they can be smoothly fed to the tape drive.
Another factor to consider is the wide range of tape devices that are supported by the major network backup software packages. The various QIC formats, 4mm, 8mm, and DLT drives, all function in radically different ways, and the tape server must accommodate any of them. For example, QIC drives pass tape across stationary heads at rates of 25 or 50 inches per second or more. Helical scan devices such as 8mm and 4mm DAT drives use heads rotating at 2000 rpm while tape is moved across them at approximately 1 inch every three seconds allowing nearly 2000 separate tracks to be written across a single inch of tape! The tape server must recognize the capabilities of the tape drive from an identifying signal sent across the SCSI bus, factor in the capabilities of the SCSI host adapter itself, recognize the resource constraints placed upon it by the configuration of the network operating system and file server hardware, and then come up with a solution that will feed the data arriving from the targets at the highest possible speed. Add to this the fact that most of these products can perform these functions for up to seven storage devices running seven separate jobs simultaneously, and their performance can be seen as no less than phenomenal.
It is important to consider that virtually no other operation stresses the limits of a network's communications, storage, and I/O systems more than backups do. Normal network usage makes regular but intermittent calls to a server's disk drives. Applications and data files may be loaded and unloaded at regular intervals on dozens of workstations, but rarely do applications call for a continuous stream of high-speed data transfer the way that a backup job does. When, for whatever reason, the data stream is slowed or interrupted, and the tape server has no data to feed to the drive, then the drive spins down to an idle state, and must spin up again before the data stream can be resumed. This condition is called data starvation and is one of the most common causes of unusually slow backup speeds and data corruption. For a smooth, continuous stream of data to be delivered to the tape drive at the correct speed, the interaction between the tape server module, the SCSI drivers, and the other devices on the SCSI bus must be consistent and predictable.
In addition to the transfer of data, a complex series of format conversions also takes place. Data is stored on NetWare volumes in blocks of a size specified during the creation of the volume. Workstation operating systems each have their own file systems that store data in different ways. All of this data, once it has arrived at the tape server, is written to the tape in blocks (of a different size and configuration) specified through negotiation between the tape server software and the tape drive itself. Some or all of the data may also be stored in a proprietary tape format that is specified by the software manufacturer.
Another major factor in this consideration is the existence of other devices on the SCSI bus. While it is perfectly practical to have a backup device on the same bus as hard drives, CD-ROMs, and other devices, the compatibility and configuration of these devices is vital for smooth concurrent operation. To mix devices such as these, a standard SCSI protocol must be used, such as the Advanced SCSI Programming Interface (ASPI), which was developed by Adaptec and has since become the de facto standard in the integration of different manufacturers' SCSI devices on the same bus.
An ASPI driver is configured to directly address the host adapter and is loaded into memory. Then, all subsequent drivers for the various SCSI devices on the bus, including the tape server, address the ASPI layer instead of the adapter itself. The use of ASPI allows for virtually any modern SCSI device to be placed on a SCSI bus without interference from other devices, despite the overlapping requests that are generated by a network environment. While it is quite possible to attach a tape drive to its own dedicated SCSI adapter and eliminate possible interference with other devices and their drivers, this adds expense and driver overhead to the file server that may not be justified in some cases.
Thus, you can see that the operation of the tape server portion of any network backup software is far more complicated than it first appears. Software and hardware modules from three or more manufacturers must be made to interact without interfering in each other's processes. The most important factor in assembling a SCSI installation that will function to its fullest capacity is to gather components that are all designed to work together. This is why most vendors of network backup software conduct rigorous testing and certification procedures for both SCSI adapters and tape drives, most of them going so far as to certify not only specific devices, but specific firmware and driver revisions to be used with these devices.
Before making any backup hardware or software purchase, be sure that the adapter and the tape drive, their component firmwares, and any accompanying drivers have been certified for use with the software you are considering. Also, if you are going to run multiple devices on one SCSI bus, make sure that all of the hardware involved is ASPI compatible (as nearly all are these days). Avoid locking yourself into a proprietary hardware manufacturer or SCSI protocol, and be particularly skeptical of new trends in hardware development.
Remember, your backups are your safety net for any experimentation with new network products that you may care to conduct in the future. This is not the place to gamble on that slick new bus-mastering, error-correcting, self-caching SCSI wonderbus. Stick to the tried and true here, and you can be fearless anywhere else.
While the tape server controls the actual transfer of data to and from the NOS to the tape drive, there must be another module responsible for seeing that the correct data is fed to the tape server at the correct time. This is the responsibility of the scheduler or backup manager. While a limited software solution like SBACKUP can initiate a single job at a specified time, all of the major third-party network backup packages can maintain and execute complete backup rotation schedules, allowing the administrator to create jobs that will launch at designated times and automatically reschedule themselves to repeat the next day, week, or month.
On a NetWare file server, this is usually accomplished using a job queue that is similar in nature to a network print queue. Jobs are created by a separate manager program and stored as encrypted files in coded directories located under the SYS:SYSTEM directory. The jobs are then executed at the appropriate time by a scheduling module that remains resident in file server memory. These same functions can be carried out by Windows NT services.
The most powerful of these products can maintain complete backup rotation schedules for up to seven different devices, running completely separate jobs at the same time. A virtually unlimited number of individual jobs can also be scheduled to run at any time, even months or years into the future. Many of these scheduling modules can also maintain a capability to perform scheduled copy jobs from one server volume to another. This would allow an administrator to schedule a regular "mirroring" job that would maintain an up-to-date replica of crucial files on another server at any interval desired.
When comparing the capabilities of the various software packages available, check on the different ways in which jobs can be stored and submitted to the queue in comparison with the layout of your network. While all should be able to submit jobs from a workstation-based manager program, others may also be able to submit them from a workstation's command line or from the file server console. This could be very useful if your servers are kept in a closet that doesn't contain a workstation. You should also be able to save a job configuration as a separate script file to be submitted at a later time. In this way, in a disaster recovery situation, complex backup rotations can easily be resubmitted to the queue.
All network backup products contain some means of tracking their activities. This is done to maintain a record of information such as when backup jobs were performed, what files were backed up onto which tape, and so on. Due to the sequential nature and slow seek times of magnetic tape devices, it is impractical to "browse" through a tape's contents in real time. It is therefore necessary to maintain a replica of each tape's contents in a database that will allow files to be chosen for restoration in the simplest and quickest possible manner. In addition to the file's existence on a tape, information as to its exact location will also be maintained. This will allow the tape server to utilize a high speed SCSI command to locate a particular file for restoration. An individual file can then be restored in seconds or minutes, rather than the several hours that may be required to read the entire tape, file by file, searching for the correct one.
Many products are also capable of maintaining database entries of other information concerning network backups, such as:
Care should be taken to examine what type of database is used by the various products being evaluated. Some vendors utilize commercial database engines such as Btrieve, while others have arrived at proprietary solutions. The use of a known database type has advantages in that there are likely to be third-party products available for database access and maintenance. Cheyenne Software's ARCserve, for example, ships with Crystal Reports, a reporting engine for Btrieve databases that provides extensive reporting and documentation capabilities as well as the ability to create customized reports. Their use of Btrieve also allows for the use of the maintenance utilities included with the Btrieve engine.
While Btrieve was originally developed by Novell and included as part of the NetWare package, it has since been sold by Novell and is now maintained by its own firm, Btrieve Technologies, Inc. This has had a positive effect on the overall product, and has resulted in the recent release of a solution to the primary drawback of the Btrieve client/server engine which is BREQUEST.EXE, the 75K DOS TSR requester that was required to be run at the workstation in order to access the server engine. A Windows DLL equivalent has recently been made available, which is quite effective and requires far less resources.
There are several other important factors to consider: What will the approximate size of database files be for the amount of data that you will be backing up? The database files will contain the name and location information for every file that is backed up during every job. These files can grow to be quite huge and steps may have to be taken to keep their size under control. A database engine should have the ability to be configured to purge database information when it has reached a certain age, shrinking the database files proportionately. Tools should also be available to repair databases that have become damaged or corrupted. Be aware that many database types will require a substantial amount of temporary drive space in order to perform such maintenance functions. Some products may allow these temporary files to be created on another volume, while others may not. Take these factors into account when planning an installation of these products.
In addition, there should be a means to restore files from a tape that does not exist in the databases. This may be done by addressing the tape directly, in order to perform a sequential search for the desired file, or to read the entire tape and assimilate its contents into the existing databases. A good database engine should have both of these capabilities, so that tapes made at an earlier time or at another installation can still be restored at will.
The use of a commercial database engine such as Btrieve provides extensive features and capabilities such as these to the application that utilizes it, but a trade-off must be expected in terms of both client and server resources as well as database size. If you are going to be backing up a relatively simple network and performing restores only in cases of the occasional mistakenly deleted file or disaster recovery situation, then such capabilities might fall into the realm of overkill. A product might therefore be called for that maintains a simple file and media index in which there is less possibility of corruption problems or system resource shortages.
Backup agents are software modules that run on the backup targets (that is, the devices to be backed up) that "package" the desired data and send it to the tape server where it is ultimately written to tape. Some backup software packages provide their own agents, while others utilize the TSAs provided by NetWare as part of the SMS specification. Some products may also use a combination of the two for coverage of various platforms or allow the user to choose between the two for a specific platform. Different agents are usually made available to address the various types of data to be backed up. These may include various workstation operating systems, server volumes supporting different file systems, and even special cases, such as live database files that must be backed up while in use. Obviously, you should ensure that the product you choose has agents available for all of the platforms that you wish to back up.
With today's heterogeneous networks, however, this may not be as simple as it sounds. Many of the packages have agents available for numerous flavors of UNIX workstations and OSs. With the growing popularity of 32-bit desktop operating systems such as OS/2, Windows NT, and Windows 95, you should carefully check whether your proposed backup software vendor has made agents available for all of the environments used on your network.
When evaluating agent coverage for your existing workstations, make sure that the product will function well with the way in which your users work. Remember, it is going to be the responsibility of the user to make sure that a workstation agent is loaded whenever a backup is scheduled. Whenever possible, it is a good idea to arrange your users' workstation configuration so that agent is loaded automatically. Most products will include both a DOS and a Windows agent, but the two are most likely to be exclusive. That is, the DOS agent will not function when Windows is loaded, and vice versa.
When conducting overnight backups, you must be conscious of the state in which your users leave their workstations at the end of the day. A DOS agent can be placed in the workstation's AUTOEXEC.BAT file or a Windows agent into the Windows Startup group, but neither will function if the workstation is turned off. Developing and enforcing a company policy in this respect will minimize the resource drain entailed by the loading of multiple agents and ensure that backups are performed reliably and on schedule.
Aside from coverage of all of the platforms on your network, there are also matters of price and performance to consider. Make sure of the agent's capabilities before you rely on them. For example, some Macintosh agent packages can back up and restore files to and from a Mac workstation, but cannot restore those files to a file server volume with MAC name space. Such limitations are obviously not well advertised by the manufacturers, but you should try to anticipate your backup and restore needs as completely as possible and determine if the products that you are considering can fulfill them.
Perhaps the most important consideration and the area in which you will find the most variance between vendors is in the price of agent coverage for your network. Most packages will ship with DOS, Windows, and OS/2 agents, but may not allow you to back up all of your workstations of those types with the base product license. Network backup products are usually priced either on a per server basis or in accordance with the NetWare user license installed. With Cheyenne Software's ARCserve, for example, you must purchase the same user level as that of the NetWare server that you will be installing it on, regardless of whether or not you wish to back up workstations at all. However, this license will allow you to back up an unlimited number of servers (of the same user level or less) or workstations. Legato Software's Networker is priced on a per server basis. The base package will run on any user level of NetWare, but it will only back up that one server and up to 50 workstations. Backing up additional server and workstations requires the purchase of additional licenses.
Both of these policies effectively overcharge a substantial portion of their user base. An installation with one 250-user server that needs only to back up the server drives should not have to pay several thousand dollars more for a backup package that supports a 250-user license, nor should an installation with many smaller server have to pay an equal amount of money for what amounts to nothing more than a piece of paper.
Another place in which additional charges for these products may accrue is in the purchase of additional agents. Most of the major packages ship with a small subset of their available agents and sell the others as add-on packages. Be sure to check the prices of these add-ons before committing to a particular product and also whether or not the additional cost includes a license for a single or an unlimited number of workstations.
In general, it would be a mistake to choose a particular software package on the basis of licensing issues alone, but being aware of these additional charges in advance can avoid severe budgeting problems later. It should also be noted that, with the release of NetWare version 4.1, Novell has altered its own pricing stratification system, allowing additional user licenses to be added to an existing server license. This will force the third-party backup software developers (particularly those who charge on a user level basis) to rethink and hopefully restructure their pricing plans so that users of all levels are paying a fair price.
Continued...
