Views

How fast should my tape drive go? (i.e. what does it mean to "stream" a tape drive?)

This Wiki is brought to you by Backup Central, where you can find the Mr. Backup Blog, Forums, and a mailing list for each forum!

Backup FAQs Service Providers Backup Software Backup Hardware Backup Book Wiki Free Stuff Miscellaneous


First off, keep the following conversion in mind:

1 MegaBytes/sec = 3.6 GigaBytes / hour 100 Megabits/sec = 12.5 MegaBytes/sec = 45 GB/hr

If you're not getting at least "native speed" (e.g. 5MB/sec or 16GB/hr from a DLT 7000 drive) performance from your tape drives, there is very likely some fixing that needs to be done to your backup system.

Many tape drives are "streaming" drives, which means that the drive's native speed should be considered a MINIMUM incoming data rate. If one of these types of drives is always getting data at a fast enough rate, it's said

to be "streaming".   If the drive doesn't get data at that speed, it is

"NOT streaming" and a performance penalty results.

The source of this performance penalty (as I understand it) is basically time wasted due to contant head repositioning. Below is my "quick and dirty" explanation of what happens when a streaming-type tape drive doesn't get fed fast enough:

    1-incoming data stream begins
    2-tape spins up to write the incoming data
    3-the data buffer is written to tape
    4-look for more data, but it's not arrived yet!

(the tape is spinning fast enough that we've gotten a bit ahead of ourselves

at this point)
    5-stop the tape, rewind to the last bit that got written
    6-go back to step 1 (or more likely step2, more data probably arrived and

piled up during step 4)


the end result is that your tape drive writes even more slowly than the incoming stream of data.

The solution: depends on the problem, but it's probably one or more of the following:

   -tweaking the buffer sizes on the media server.  tweaking the netbackup

data buffers is discussed in this FAQ and on the veritas-bu mailing list.

   -use of multiplexing
   -improvement of network bandwidth into the media server
   -use of FlashBackup (if your backup happens to be slow because of a large

number of small files)

First off, keep the following conversion in mind:

1 MegaBytes/sec = 3.6 GigaBytes / hour 100 Megabits/sec = 12.5 MegaBytes/sec = 45 GB/hr

If you're not getting at least "native speed" (e.g. 5MB/sec or 16GB/hr from a DLT 7000 drive) performance from your tape drives, there is very likely some fixing that needs to be done to your backup system.

Many tape drives are "streaming" drives, which means that the drive's native speed should be considered a MINIMUM incoming data rate. If one of these types of drives is always getting data at a fast enough rate, it's said to be "streaming". If the drive doesn't get data at that speed, it is "NOT streaming" and a performance penalty results.

The source of this performance penalty (as I understand it) is basically time wasted due to contant head repositioning. Below is my "quick and dirty" explanation of what happens when a streaming-type tape drive doesn't get fed fast enough:

    1-incoming data stream begins
    2-tape spins up to write the incoming data
    3-the data buffer is written to tape
    4-look for more data, but it's not arrived yet!  (the tape is spinning
      fast enough that we've gotten a bit ahead of ourselves at this point)
    5-stop the tape, rewind to the last bit that got written
    6-go back to step 1 (or more likely step2, more data probably arrived and
      piled up during step 4)


The end result is that your tape drive writes even more slowly than the incoming stream of data.

The solution: depends on the problem, but it's probably one or more of the following:

   -tweaking the buffer sizes on the media server.  tweaking the netbackup
    data buffers is discussed in this FAQ and on the veritas-bu mailing list.
   -use of multiplexing
   -improvement of network bandwidth into the media server
   -use of FlashBackup (if your backup happens to be slow because of a
    large number of small files)