Lingo Explained: tape shoe-shining (and how to avoid?)

Shoe-shining or backhitching – a term used in backup context – is a repeated back-and-forth-motion a tape device makes when the data flow is interrupted or is too slow. The process itself is destructive for the tape device, as well as for the tape cartridge.

A tape cartridge is a sequential medium requiring a continuous flow of data to keep the internal band in motion. When the data stream gets interrupted or the backup server is sending data slower than the tape drive processor, the tape device is obligated to stop. The stop  causes an offset of the writer and when resuming the device is required to position the writer back to the spot containing the blocks of the last write operation. The process: stop (end-of-data-stream), reposition (finding the right spot again), write (continue data stream) and repeat is what is called shoe-shining.

Earlier in this post, I mentioned shoe-shining is destructive for the tape device and tape cartridge. Besides the backup tend to be slower which causes a performance degradation, additionally it causes an excessive wear on the tape device and cartridge caused by the robotic operations.

Shoe-shining can be avoided by using the following rules of thumb!

First of all, choose the right tape device!
Check the theoretical speed of the tape device and calculate the uncompressed in-stream speed. The in-stream speed is about one-third (1/3) of the full stream speed. When data is slower delivered than the in-stream speed, the tape device will perform shoe-shining.

Keep in mind, the numbers provided by the hardware (tape) vendors are backend performance. 160MB/sec means the data is received non-compressed (1:1), when the tape device performs compression (2:1) it will still write out 160MB/sec in the backend, but then you need to receive 320MB/sec.

For example when you are using an LTO-6 tape device we can state:

Maximum uncompressed full-stream speed: 160MB/sec 9,3GB/min
Maximum uncompressed in-stream speed: 50MB/sec 2,9GB/min
Maximum compressed (2:1) full-stream speed: 320MB/sec 18,6GB/min
Maximum compressed (2:1) in-stream speed: 100MB/sec 5,8GB/min

If we compare the speeds with enterprise-class tape devices, we can say we will walk the boundaries. For example an Oracle StorageTek T10000D tape device can work on 252MB/sec or 14,8GB/min uncompressed. So… the frontend needs to be able to deliver these performance as well!


Think about activating multiplexing on your tapes.
However… address this very carefully! Multiplexing will combine several data streams onto one tape. It will increase the speed of your backups, but it can give you a kickback with regards of data restoration because it needs to skip blocks (but still reads them) when restoring data. In case you need to do a full system restore and the data is protected with multiplexing set on ‘2’, the tape needs to be read twice!

What about a backup-to-disk-archive-to-tape strategy?
Nowadays everything just gets faster and faster. LTO-7 is assumed to work on 315MB/sec uncompressed. LTO-8 is assumed to work on 472MB/sec uncompressed. It’s obvious we need to change the way we address our backup/recovery and realize a regular backup-to-tape strategy will not be sufficient anymore.

My advise here is to store the backup-to-disk location (software engines or appliance) in a separate location (cfr. the backup room) together with the tape library. This provides the ability to do a weekly copy to tape requiring less data streamers.

By using a backup disk, you can do full system restores from a disk device (random access = faster performance). Tape will be used for granular restores or point-in-time recovery. These restores are assumed to be less critical.. so for the copy operations there is less impact in activating multiplexing!

Leave a Reply