The HP SureStore Ultrium 230 Tape Drive
The HP Ultrium 230 low-voltage differential (LVD) tape drive is fast. It can write tape faster than your disk subsystem can supply data. If you want to stream, you'll need several systems feeding it at once, which made it a good choice for our application of backing up several systems each night. The 230 is about twice as fast as the 215 model, but also costs significantly more.
We bought one of the first HP Ultrium generation 1 tape drives, together with the Qualstar TLS-8211 tape library robot. Both are connected to an Adaptec PCI SCSI controller. It has been in service since December 2000, and we have done both file and system restores for the systems it protects.
The robot and tape drive are available in standalone and rackmount configurations. We ultimately chose the rackmount, and I advise others to do the same: something this big sitting on the floor will draw attention from the cleaning people. In the rack, the device occupies 36.75" (21U) of space, and it is a two-man job to get it installed. It is best to mount the cabinet with the robot, and then install the tape drive and magazine. The magazine has an 11-tape capacity. The tape drive slides easily into place once the cabinet is mounted.
Our selection of the device was driven by two considerations. First, the device had to be able to hold all of our data. The single-largest server potentially holds over 200GB of data, uncompressed, and the other servers roughly match that. The second requirement was that the data had to be written during the off-hours. We cannot have backups running during the day. We prefer full backups; restoration is much simpler in this case. Since periodic full backups must be made anyway, we do it consistently.
This drove us to a trial of the LVD tape subsystem, which promised to write 50GB/hour and hold 100GB (raw) on a tape. Our informal tests show that the drive can really stream data at these speeds. Unfortunately, these same tests show that none of our systems can supply data at this rate! The tape drive can accept data far, far faster than a RAID-5 controller can supply them.
Our solution was to prepare a backup aggregation program. It collects backup streams from several computers and writes them all to tape together with headers identifying their origins. Several computers, combining their efforts, come closer to keeping the tape drive streaming. A companion program deaggregates the streams, providing the desired stream for restoration. Each system supplies a tar stream, and on restore the system receives the same.
Our installation combined the tape drive with a tape-loading robot. We use the mtx program to operate the robot, under the control of a fairly simple shell script. The shell script determines the next tape number, invokes the robot to load the tape, and starts the backup program. When the tape program is done, another script unloads the tape. For convenience, we throw a sheet on the printer showing the date and tape number used.
The robot and tape drive can be moody, and like small children will misbehave in order to receive attention. Loading and unloading the tape require care. If not done correctly, the subsystem will achieve a state in which one must manually extract the tape. Sometimes a power cycle is even required.
The tape drive tracks usage to decide when it needs cleaning. When the tape drive wants to be cleaned, it really wants to be cleaned: be sure you have a cleaning tape in the shop.
Preparing to use a tape consists of two stages: directing the robot to pick a tape and put it in the drive, and then encouraging the tape drive to do the actual load. The mtx command handles the former. In order to use the tape, however, you must then wait for it to become ready. We use a shell loop, waiting until the mt rewind command returns successfully when the drive has loaded the tape.
After the tape is written, we want to unload it and put it back in the magazine. Normally, when the tape-writing program finishes and closes the device, it will wait some time for the tape to rewind. The tape will be left in a loaded state, and in this drive the robot cannot remove it and return it to the magazine.
You must use mt rewoffl or something similar to ensure that the tape is rewound and unloaded. Our experience is that, due to the length of the tape, the first issuance of the command may return prematurely. To avoid problems, wait several seconds and re-issue the command. The rule “This time, for sure!” applies.
Only when the tape is really unloaded can the robot pluck it from the drive and return it to the magazine. We have found that occasionally, if the robot tries to pluck the tape prior to unloading, the tape drive will get grumpy. This can sometimes be cured by manually pressing the unload button and waiting; it is often necessary to cycle power and then press the unload button.
So as long as you don't do anything to upset its routine, the robot will take good care of your tapes. The drive is big and fast. If you have a regular need to back up a lot of data, this combination may be right for you.
The tape drive and library are available from Zzyzx. They were kind enough to provide us with an evaluation unit that we kept for about a month, in order to determine suitability. We found that we would require the optional bar code reader, and we preferred a rackmount model over the freestanding unit. Zzyzx took back the evaluation unit and supplied the rackmount unit, with a bar code reader. While we have not needed to do so, the unit can be painlessly upgraded with a second tape drive, and/or more tape cartridges.
Tanner Andrews is a longtime civic activist in the DeLand/West Volusia area. He regularly points, laughs and jeers (www.payer.org) at bad government. When he's not fighting the good fight, Andrews works at Learning-Soft in Miami, Florida as a network guru and programmer. For nearly 20 years, Andrews has been counselling users on the importance of regular, reliable backups.
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
- Using tshark to Watch and Inspect Network Traffic
- September 2015 Issue of Linux Journal: HOW-TOs
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Firefox Security Exploit Targets Linux Users and Web Developers
- Where's That Pesky Hidden Word?
- A Project to Guarantee Better Security for Open-Source Projects
- Build a “Virtual SuperComputer” with Process Virtualization
- My Network Go-Bag
- Doing Astronomy with Python