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.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- The Secret Password Is...
- RSS Feeds
- New Products
- All the articles you talked
22 min 7 sec ago
- All the articles you talked
25 min 14 sec ago
- All the articles you talked
26 min 34 sec ago
4 hours 51 min ago
- Keeping track of IP address
6 hours 42 min ago
- Roll your own dynamic dns
11 hours 55 min ago
- Please correct the URL for Salt Stack's web site
15 hours 7 min ago
- Android is Linux -- why no better inter-operation
17 hours 22 min ago
- Connecting Android device to desktop Linux via USB
17 hours 51 min ago
- Find new cell phone and tablet pc
18 hours 49 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?