Slow SLP Duplication to Tape

[peterblue]

 Every so often, we have an issue whereby duplications to Tape via SLP run incredibly slow.

These duplications are local - from Media Server to Fibre Attached Tape Drives connected via Brocade DCX's, from HPE StoreOnce to Quantum Scalar I6K.

This used to happen on our old Data Domains, and we knew it was an issue with Block Optimisation. So, if we got delays backing up the data initially, and that then had a knock on effect to the duplications, then the older the blocks, the poorer the optimisation. 

On the StoreOnce I am not sure if it suffers from the same issue, and neither are HPE !. Has anyone else seen this issue on their StoreOnce devices duplicating to tape.

When I say slow speeds, it is around 10 - 11Mb/sec. So, duplications that usually take around 6 to 7 hours for multiple terrabytes, can take around 55 hours.

[Tape_Archived]

How is HP StoreOnce connected to Media server?? I guess it's 10g.

[Mouse]

If you use a modern tape drive, say, LTO6 and above you will notice that you have to provide a solid stream to the tape drive. For LTO6 drives produced by HP, the minimal write speed is 54MBps, with average 2:1 compression it's 108MBps, so unless you are providing sufficient stream rate from a DD or HP StoreOnce, you will see a performance impact caused by tape shoe-shining which dramatically drops the transfer rate, 7x-10x.

To rule this out, try to add a step in SLP for the HP box to duplicate to Advanced Disk, a non-deduplicated device which is capable of delivering a consistent stream 150MBps+. And then duplicate from that device.

Many deduplication devices boast the number of backup streams they can handle (usually at 99% dedupe rate) and overall throughput but what is important for duplication to tape is single stream performance number and if it does not reach 100MBps then it might be the bottleneck.

This of course should be checked along with media server's performance, I've see people attaching both source and target storage through the same HBA on the same PCI-E bus and no wonder the I/O performance was poor.