Columbia’s SnapBack Set The Stage For Solid LAN Backups

lanbdThere are three main reasons that network administrators back up LAN-based data: to conserve disk space through migration, to aid users who mistakenly delete crucial files (invariably the CEO, according to backup vendors), and to prepare for disaster recovery.

The first two reasons dictate choosing a backup package that ensures highly reliable data tracking, with query tools that support multiple search methods for rapid file location and retrieval.

However, when attempting to prepare for recovery from such catastrophes as total server failure or a natural disaster, the real push for swift restoration comes from the dollars ticked off on the lost-productivity clock.

This is where the simplicity and strength of Columbia Data Products Inc.’s SnapBack can pay off in spades. Instead of conventional file-by-file backups, SnapBack creates an image backup of an entire disk drive.

The recovery process is normally tedious and requires multiple steps. For instance, reviving a NetWare server first entails restoring DOS, then restoring NetWare, restoring the backup utility, and restoring all user files. SnapBack supplants this process by inserting one bootable floppy disk that will restore the image of an entire drive at speeds of 50M bytes per minute or more.

PC Week Labs examined Version 2.11a of SnapBack, which began shipping in October, and found the $995 product fast and effective. It eschews the fancy interface and complex database of conventional backup programs, relying instead on an easy-to-configure DOS front end.

Unfortunately, SnapBack doesn’t yet support tape changers (tape spanning across multiple drives is supported), and it allows only one backup per tape. In addition, Version 2.11a lacks software compression, provides no verification option, and experiences some difficulty with certain IDE drives or SCSI drives more than 8G bytes in size.

All these shortcomings are being addressed, according to Columbia Data Products officials.

A version designed to allow image storage on any DOS or DOS-redirected drive is also in the works.

Speed counts

When faced with restoring the entire file server on which your company depends, speed becomes a key factor. NetWare administrators know the drill: First create and format a DOS partition, next reload NetWare, and in most cases, reinstall the backup software. Only after this can users’ files be restored from tape.

The process for other operating systems, such as Windows NT or Unix, is similar, though perhaps more arduous.

Using SnapBack, we were able to restore our NetWare 3.12 server’s entire 510M-byte SCSI drive, the boot sector, DOS partition, and NetWare partition in one smooth operation. Furthermore, we did it in less than 8 minutes with one bootable floppy and one tape.

We achieved this speed by using the hardware compression that accompanies our Hewlett-Packard Co. DAT (digital audiotape) drive. Nonetheless, we still managed to restore the entire drive in less than 20 minutes with the compression deactivated. Using 8mm or digital linear tape drives would boost these speeds even higher.

Regular backups still needed

SnapBack creates only partition images, so individual file restoration isn’t possible. Because of this, it is an effective adjunct to, but not a substitute for, conventional backup utilities. On the other hand, because it performs image backup, SnapBack can work on drives that are running nearly any operating system.

SnapBack itself runs from DOS. Through the use of a scheduling NLM, SnapBack can bring down a NetWare file server, execute the backup of preselected drives, and then reload NetWare.

But before SnapBack can run, it must be able to access all disk drives the NOS will use. Under DOS, SCSI drives are made accessible using ASPI (Advanced SCSI Programming Interface)-compatible drivers.

You’d expect this to be a problem — after all, how can DOS-based ASPI device drivers be loaded onto a NetWare server? Normally, these drivers are loaded via the CONFIG.SYS file, but under NetWare, DOS disk device drivers conflict with NLM-based drivers. SnapBack’s solution is to enable these device drivers with a clever LOAD utility, run its backup, and then unload them before relaunching NetWare.

Scheduling the operation

We had mixed results using the automated backup method. For starters, we had our tape drive on an Adaptec Inc. 1742 EISA SCSI controller, but the disk drives were on an embedded Adaptec AIC-7770 controller. Attempts to load the second device driver failed, prompting “out of memory” errors. A revised version of the LOAD command (supplied by Columbia Data Products) worked intermittently, forcing us to put all the devices on a single controller.

Those who know the vagaries of mixing fast and slow SCSI devices on a single chain wisely configure their servers with several SCSI channels, and we hope a permanent fix to the multiple-load problem is offered soon.

The scheduling of backup jobs can be done at the server console or from a remote DOS workstation via the SnapTime utility. Unfortunately, the utility lacked any security features for the remote connection. Anyone gaining access to SnapTime can view or change the schedule, a security breach PC Week Labs didn’t appreciate.

Administrators who use the NetWare REMOVE DOS command won’t be able to capitalize on the automatic mode, because SnapBack requires DOS to be available when the server is down.

Organizations operating around the clock will likely be unable to use SnapBack’s automatic mode. This is unfortunate, because those sites would probably benefit the most from SnapBack’s rapid-recovery prowess.

We’d encourage Columbia Data Products to consider implementing an NLM-based SnapBack, equipped with the ability to dismount NetWare volumes. This would allow selected volumes to be brought off-line, backed up, and then returned to duty without losing basic NetWare services.

The SnapBack main program can also operate in manual mode. We used this method to choose which drives to back up and how the software should handle read failures, and even to search the tape for binary or ASCII strings.

During the manual operation, the screen displayed instantaneous and average data rates, the number of partitions completed, and the total number selected. A log file is also created that tracks any errors during backup or restoration.

Installation not quite a snap

We installed SnapBack on a Zenith Data Systems Inc. Z-Server LT equipped with 32M bytes of RAM and a 60MHz Pentium processor, running NetWare 3.12.

Four Seagate Technology Inc. 510M-byte drives were attached to the embedded Adaptec SCSI controller. Our HP 35480A DAT drive was externally connected to an Adaptec 1742A EISA SCSI controller.

Installing SnapBack was a two-step process. First, we installed the main executables to our server’s DOS partition. After this, we brought the server back up and ran a second install process that modified our AUTOEXEC.NCF and copied the scheduling NLM, two utility NLMs, and the SnapTime program to the SYSTEM directory.

On our test server, the SCANSCSI and TAPEUTIL NLMs both proved useless. Columbia Data Products’ tech-support personnel explained it as a compatibility issue with our ASPI manager, which is strange, given that Adaptec developed ASPI.

Following the examples presented in the manual, we then modified our server’s AUTOEXEC.BAT file to facilitate automatic backups. The scheduler was easy to navigate, allowing only a single time entry per day.

This entry was posted in Servers. Bookmark the permalink.

One Response to Columbia’s SnapBack Set The Stage For Solid LAN Backups

  1. Frankie Bonner says:

    It was a great product. Really a great one. Not entirely sure what happened to the company, but man, that SnapBACK was a winner when there really was very little else when it came to backing stuff up.

    A true innovator!

Leave a Reply

Your email address will not be published. Required fields are marked *