Hi,
just some thoughts:
- Whenever I read something about <1MB/s throughput, the first question is: Can your source feed any faster? The archetypical office file server with lots of small files often can't, as a file system traversal for read is deteriorating into pure random access patterns. So, did Backup Exec read faster? If so, how much faster?
- People often blame the LAN, I found that it is extremely unlikely to be the culprit (disk is way more likely, but for some reasons, nobody wants to believe how slow disk can become when not reading linearly). That being said, the LAN has to be tested. I prefer NetIO tests between the client and the server (media agent box) to tell me true expectable TCP throughput. With 1000Base interfaces, you should see something like 110MB/s in both directions. If you see significantly less than 80MB/s with all of the block sizes, fix the LAN first.
- With lots-of-small-files, an unexpected source of contention used to be the IDB. It was single threaded and when it maxed out the core it run on, everything else came to a screeming halt. That, however, should be over with 8.x since the new IDB scales better and does things differently (file metadata in DCBFs mostly). Look for IDB disk contention anyway, as in practice, theory and practice aren't always the same.
- I would increase disk agent buffers (I always bump that to 32) and I think 50GB segment size might be a little large (even though it shouldn't hurt, it's mainly a question of fast positioning vs. read throughput on physical tape). I tend to use 8GB for that.
From what I know (even with 8.1 of which I know very little), your throughput is not typical and I would start to search for the reason at the source. You need a tool that can monitor storage duty cycle, in 2008R2 just open the task manager and from that call the resource monitor, have a look on the storage tab and check if a device operates beyond 80% saturation. In earlier Windows releases, best use perfmon which opens with a disk usage (Time%) graph automatically.
BTW, sometimes (but not very often) you will find no obvious source of a throughput issue, yet it remains - I've run into one such mystery myself. It's a backup session to tape, involving some TBs of VMDKs from a well performing (RAID 5) properly non-fragemented drive via GE. It typically runs at 90MB/s. There are, however, days when it chooses to run at another speed, and it will keep this slower speed for the entire session (which is several hours to more than a day). Speeds observed so far have been 60MB/s, 40MB/s and in some cases just 12MB/s. I repeat, it is not getting any faster when it once started to run at 12MB/s, even though there is no CPU bound process, no disk saturation and not LAN throughput issue at all when this happens. I do have a theory that involves the RAM the media agent server is equipped with, which isn't entirely optimal (two 16GB modules attached to a 3-channel Xeon), where the layout in memory of the two processes that make up the BMA plays a role. But that's a theory, and like cold dark matter, it's not become less of a mystery by just theorizing. So far the only cure has been babysitting: If it runs too slow, abort the session and start it again. You will hit the proper throughput after some restarts, usually on the first or second try. Once achieved, it will stay fast the same way it always stays slow when it started thusly...
HTH,
Andre.