Hi Chris,
the issues with lots of small files are twofold:
- Quasi-random access to the backend storage vs. spinning rust
- Metadata load to the IDB
Do you really not see source storage saturation when running such a backup? On 2008R2 use the resource monitor and closely look at the disk duty cycle/highest active time. Unless that stays below 50% for significant times, you are simply source storage bound. Regarding IDB metadata load, try to run a copy of your full backup spec, changed to No Log for all the file systems in question, pointed to a Null device. If that completes way faster than the normal backup, retry it to your tape drive. If it stays fast, it's probably time to ponder upgrading to 8.12 for the IDB enhancements...
--- Veeam server (7.0 TB) Few large files
Now that is interesting. Please use resource monitor to see if this is also source storage bound. If so, the problem is typically the access scenario of such backup-to-disk software: It is writing few large files, but when the disk fills up, some of the older ones are deleted and more large files are written. This quickly results in massive free space fragmentation that turns into file fragmentation. When multiple such files are written in parallel, that adds interleave fragmentation to the picture. There are two ways to fight this: Make sure parallel writes go to different volumes, and make sure the NTFS is formatted with 64KiB cluster size. You can check if fragmentation really is the issue here by silencing writes to that volume, doing a full defrag, and then testing if a backup of that volume speeds up.
HTH,
Andre.
