Re Chris,
- Your lots-of-small-files backups seem to not be source storage I/O bound then, which they typically are - very interesting.
- If you already run these backups with Log folders only, you should not starve the backups due to IDB load. The usual symptom of IDB starvation is phases of several seconds (up to minutes) of rds.exe going 100% CPU on a single core, during which the GUI stops to update anything and no data is flowing any more from DAs to MAs.
Given these circumstances, I think using Null device backups is a good way to isolate the issue, starting with the source host exactly as you describe. Push a MA there if it isn't already installed and test a "local loopback" Full backup to get a baseline eliminating the LAN and the tape drives.
If your evidence starts to point to the Tape drive end of the chain, check if the block size is 256KiB or larger. I've seen backups and copies crawl when 64KiB (default) block size meets a CPU-wise underpowered MA host. If you see bma.exe processes with more than 60% CPU usage for some time, that might be the culprit.
It would also be a good idea to check LAN throughputs from DA hosts to MA hosts, I recommend NetIO and/or iperf for this. I typically find the LAN is not guilty (even though it's the usual suspect with most customers), but there are exceptions (like, say, faulty cables and even switches).
Also check Software Compression isn't enabled for your backup specs. It's single threaded and I've seen it max out one core of the DA host in question, resulting in laughable overall throughput.
HTH,
Andre.
