Hi,
Its amazing how none of these issues ever seem to have a resolution.. Is there any update here?
I think that's more of an effect of discussion on public forums by people who are too overworked to give feedback when they finally solve an issue, people who were just doing a test installation and moved on elsewhere, people who found their peace with the warts of a certain installation, etc. In cases I investigated myself directly, there is an explanation and often also a solution, most of the time. So far I ran into exactly one as-yet unexplained mystery case of a backup running slow sometimes, I detailed that before in this thread - because it's an exception. I'm convinced that even this is fundamentally an infrastructural problem exposed by the backup, only one I didn't nail yet.
Generally, backup applications, specifically complex, distributed enterprise backup systems, tend to expose all sorts of infrastructure problems that you didn't notice before. This leads to admins confronted with those issues blaming the backup system, when only some of that blame is actually deserved. Issues of LAN design and infrastructure (specifically DNS), attempts to solve them using multihoming to a backup LAN which are extremely hard to get right (specifically when a certain OS from Redmond is involved), an almost religious belief that certain issues cannot exist ("my disks were **bleep** expensive, so they must be fast, no way they are the choke point"), cargo cult ("it's SAN so it must be fast, the thing that is slow is LAN, everybody knows that") etc. pp. all intermingle and create a melange where it's easier to blame the messenger than to fix the underlying issues. The latter can also get impossibly complicated or expensive when infrastructures have grown warts and hairs organically over the years, further and further away from any sane DC and LAN design. IMO that explains 80% or more of the "this **bleep** software is slow" postulates you are confronted with in the wild, specifically in public discussion forums. Sadly it drowns out the really interesting 20% or less, where there actually might be an issue that has to be fixed by the vendor, not by the local IT staff.
That being said, I see one thing so far in this thread that DP might really have a card in: When local backup on a file server to a connected library using some other product is way faster than a VBDA profile of the same source volumes towards a null device, there may be something wrong. That can be demonstrated, and there should be a fix for it from the vendor (that's why we pay for the support). Separating out such cases from the background noise of infrastructural reasons for slow backups is the hard part.
Just some thoughts,
Andre.