What you will learn from this tip: Today's high-speed tape drives can outrun a network, causing the drive to have
to wait for a data stream. This shoeshining effect can be overcome, but only if you make disk your primary backup target.
With so many disk-to-disk backup options available, it just doesn't make sense to back up directly to tape over the network.
A LAN-based backup system can't deliver the throughput required to stop a modern tape drive from "shoeshining." Simply put, you can't back up via a LAN directly to today's high-speed tape drives without an interruption in the data stream; this requires the tape to be repositioned on the drive's heads, which causes a "stop-start" or "shoeshine" motion on the tape device that slows performance.
To record a high-quality signal to tape, the recording head must be moved across the media very quickly. This is why modern tape drives have a minimum speed; if they went slower than their rated minimum, they wouldn't record a good quality signal and would lose data. This is an unchangeable fact about tape drives: They have a minimum usable speed.
That's why all tape drives designed for large-scale backups have two speeds: stop and very fast. This also applies to variable-speed tape drives. If you have a 50 megabytes per second (MBps) tape drive and you send it a data stream at 25 MBps, it doesn't write at 25 MBps. Instead, it fills up a buffer and writes short bursts at 50 MBps; it then stops, rewinds and prepares itself to write another short burst at 50 MBps. The process of stopping, rewinding and getting back up to speed is called repositioning or backhitching. Each reposition/backhitch can take as long as a few seconds. If you backhitch a lot, it's called shoeshining because the tape activity mimics the movement of a cloth being used to shine shoes.
The further you operate from the drive's target throughput rate, the less time you spend writing data. Send a 50 MBps tape drive a 40 MBps data stream and it will actually write at 35 MBps because it's spending at least 20% of its time shoeshining. Send it data at 30 MBps and it will write at 20 MBps; send data to the drive at 20 MBps and it will write at 10 MBps; and if you send it at 10 MBps, you may see the tape drive write at a rate of less than 1 MBps.
Variable-speed tape drives
You may be wondering about variable-speed tape drives. You've likely heard that some tape drives, such as IBM Corp.'s System Storage T1120 (104 MBps) and Sun Microsystems Inc.'s StorageTek T10000 (120 MBps), have the ability to slow down to adjust to incoming data rates. You may even have heard from these vendors that this feature eliminates shoeshining. While these drives help keep up with slower incoming data rates, they can't change the basic rule that tape drives have a minimum speed they must use to get a good signal-to-noise ratio. This means they can slow down, but they can't slow way down. IBM's T1120 can slow to a native speed of 40 MBps, while the StorageTek T10000 can slow to a native speed of 50 MBps.
It's time for some math. Let's consider the T1120 the fastest of these drives, with a native throughput of 104 MBps. Now let's throw some compression into the mix. Remember that in addition to increasing your capacity, tape drive compression also increases your effective throughput. Based on what I've seen in hundreds of companies, I'm comfortable with using 1.5:1 as an average compression ratio in open-systems environments. If we use 1.5:1, the T1120 is actually a 180 MBps tape drive. If we allow it to slow to 50% of that, this tape drive can write as slowly as 90 MBps without shoeshining. But if you send it something at a rate of less than 90 MBps, it will backhitch. If you send it something at a rate significantly less than 90 MBps, it will shoeshine. The same logic applies to other variable-speed drives.
The perfect storm
We've now established that the slowest these tape drives can go is between 60 MBps and 75 MBps -- but they should really be going between 158 MBps and 180 MBps. Let's compare these numbers to the ability of a backup server to receive that amount of data via a Gigabit Ethernet network card. Based on what I've seen, most backup servers tend to hover around 50 MBps to 60 MBps. Servers don't tend to get much faster with multiple network interface cards (NICs) because the problem is the number of interrupts Ethernet requires. Yes, there are exceptions to this, but this is what I usually see. Chances are it's what you'll see if you test your backup server.
The fastest tape drive wants a stream of approximately 180 MBps, but will operate efficiently at a rate as slow as 90 MBps. If the backup server is linked to that tape drive with a Gigabit Ethernet connection, it probably won't receive data much faster than 60 MBps.
It's important to carefully examine the number of tape drives that simultaneously share the same network connection. The speed of the tape drive on the back end needs to match the speed of the pipe on the front end. Use multiple tape drives and you're asking all of those drives to share the 50 MBps to 60 MBps pipe, which means each drive gets a fraction of what it needs to stream.
Even if you had an Ethernet NIC capable of receiving 180 MBps, would you want to stream a tape that fast? Remember that we're still backing up fragmented file systems, and the throughput of each individual network backup is often going to be less than 10 MBps, so you're going to need 20 or more simultaneous backup streams multiplexed together to stream that drive. Can you imagine how slow your restore performance would be if you were reading only one stream from a backup tape with 19 other jobs multiplexed to it?
This means that it's impossible to follow the best practice and back up only to tape. If you put a single 180 MBps tape drive behind a 50 MBps to 60 MBps pipe, you're just asking for trouble. It also means that if you simply improve the speed of your tape drives, your backups will take longer to complete.
That's why disk-to-disk-to-tape makes so much sense. If you back up to disk across the network, speed isn't an issue. It's no problem to back up highly fragmented file systems at a few megabytes per second; once the backup completes, take the fragmented file system and put it on a contiguous section of disk on the backup server. The backup server should then be able to copy that backup to tape much faster than it would have backed it up to tape across the network.
The great thing is that you can do all of this without using multiplexing. The disk is moving data from local, contiguous sections of disk directly to tape. Think about what that does for your restore speeds. Disk-based backup is now a necessity. At this point, it's impossible to properly design a backup system without it. You can still use tape -- just don't back up directly to tape across the network.
This article originally appeared in Storage magazine.