There are a number of factors that can individually or collectively affect the data transfer speed of a tape restoration. They are:

• The tape technology employed.
• The interface technology employed i.e. SCSI or Fibre.
• If the tape is compressed or not, uncompressing creates more data for the interface to cope with.
• The data block size, large blocks fast, small blocks slow.
• The SCSI or fibre adapter card type and setup.
• The adapter card firmware.
• The operating system driver for the tape unit.
• The number of devices that may be connected to the same SCSI bus. It's an arbitrated buss system and will share out available bandwidth.
• The file size, open system can create millions of small files, each needs to be catalogued or referenced.
• The processor power and adapter card bus speed.
• The consistency of the media. Poor media will cause retries and medium /media errors.
• The structure of the data i.e. a large single Exchange data base is faster than a brick by brick backup.
• The methodology of the backup, striped data or multi server.

Because of the sheer number and complexity of all the above variables its common for many tape restores to take significantly longer than the designed restore/ data transfer speed of the tape device employed. The newer and faster high capacity tape drives and cartridges due to their higher transfer speed can appear be more accommodating in that they are inherently fast, however, they suffer from all the same issues as older drives.

We can however, take a few typical scenarios where many of the variables listed above would fall under what we could call a "typical setup".

Example 1

• DLTIV media backed up using a DLT8000 tape drive. A Windows file and print server is backed up. The restore server is a dual processor Pentium with a 160MB low voltage SCSI adapter card with an optimum firmware driver. The DLT drive will transfer data at a maximum speed of 3MB/sec native and 6MB/sec compressed and the cartridge will hold typically 40GB of native data. The software and hardware (i.e. the processor) may prove to be the bottle neck in this scenario as the tape is likely to hold millions of small files and may be written at a relatively small block size typically 32KB At optimum speed the tape will take 3.7 Hours to restore. This will only occur if the drive is allowed to stream the data off the tape. Any errors on the tape which result in a back itch or a retry, or input port buffers overflowing in the adapter card will slow the system down.

Example 2

• If we consider one of the later technology drives such as an Ultrium LTO2 drive used in compressed mode. This has been used to perform full backups of large Oracle data base (i.e. large files). The restore server has a number of fibre channel LTO2 drives connected via a 1 GB switch fabric. The switched fibre fabric will at the most transfer on the fabric at 100MB per sec. If a number of drives or other data movement engines are working at the same time then this available bandwidth would need to be shared out among the different users. The LTO2 tape drive will typically compress data in a ratio of 2 to 1 hence doubling the capacity and the data transfer rate across the interface. Therefore this drive would present data to the host server at 70MB/sec. It can be seen that if two drives are running at the same time there is insufficient bandwidth for both drives to run in streaming mode. This results in a reduction in throughput and an increase in restore time. When all the other variables are also considered it can clearly be seen why optimum minimum restore time is seldom achieved.

Typical data restore/transfer time due to the above points

Note: Tape restore times significantly different to the above would suggest that either the data is not typical (i.e. the data block size is very small) or millions of small files exist. Alternatively the drive, server, adapter card, firmware etc. is not optimized