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 "shoe-shining." 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 "shoe-shine" 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 50MB/sec tape drive and you send it a data stream at 25MB/sec, it doesn't write at 25MB/sec. Instead, it fills up a buffer and writes short bursts at 50MB/sec; it then stops, rewinds and prepares itself to write another short burst at 50MB/sec. 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 shoe-shining 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 50MB/sec tape drive a 40MB/sec data stream and it will actually write at 35MB/sec because it's spending at least 20% of its time shoe-shining. Send it data at 30MB/sec and it will write at 20MB/sec; send data to the drive at 20MB/sec and it will write at 10MB/sec; and if you send it at 10MB/sec, you may see the tape drive write at a rate of less than 1MB/sec.
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 (104MB/sec) and Sun Microsystems Inc.'s StorageTek T10000 (120MB/sec), have the ability to slow down to adjust to incoming data rates. You may even have heard from these vendors that this feature eliminates shoe-shining. 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 40MB/sec, while the StorageTek T10000 can slow to a native speed of 50MB/sec.
It's time for some math. Let's consider the T1120 the fastest of these drives, with a native throughput of 104MB/sec. 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 180MB/sec tape drive. If we allow it to slow to 50% of that, this tape drive can write as slowly as 90MB/sec without shoe-shining. But if you send it something at a rate of less than 90MB/sec, it will backhitch. If you send it something at a rate significantly less than 90MB/sec, it will shoe-shine. 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 60MB/sec and 75MB/sec--but they should really be going between 158MB/sec and 180MB/sec. 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 50MB/sec to 60MB/sec. 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 180MB/sec, but will operate efficiently at a rate as slow as 90MB/sec. If the backup server is linked to that tape drive with a Gigabit Ethernet connection, it probably won't receive data much faster than 60MB/sec.
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 50MB/sec to 60MB/sec pipe, which means each drive gets a fraction of what it needs to stream.
Even if you had an Ethernet NIC capable of receiving 180MB/sec, 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 10MB/sec, 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 180MB/sec tape drive behind a 50MB/sec to 60MB/sec 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.
Dig Deeper on Tape backup and tape libraries
Microsoft forced to investigate Windows Phone 7 data bug complaints
The pros and cons of tape media storage for backup and recovery in SMB environments
Symantec Veritas NetBackup best practices: Using the maximum jobs per client setting
Performance implications of transaction log autogrowth in SQL Server