Are you using more than one stream in Avamar when you backup these SQL servers?  If so, you might try reducing the backup stream count and see if that results in an acceptable level of host IO.  It would also be interesting to watch the physical disk performance counters in perfmon while a backup is running; watch for split IOs and response times.  Also, double check SQL storage best practices and see if anything is configured suboptimally.  I've seen big jumps in performance from formatting NTFS volumes with a 64 KB allocation unit size instead of 4 KB, for instance.  Is each database broken out into multiple separate storage volumes (data, tempdb, logs, etc)?  Are multiple databases which are being backed up at the same time on the same back-end disks?  Backups can be very IO intensive and expose other issues that have been lurking.  Does a native SQL backup to a fast local disk generate a comparable amount of IO on the source database volumes?

Thanks a bunch for the reply.  I've tried various stream and buffer sizes and all yield the same result.  Interesting thought about the file system unit size, will certainly check that out.  And hopeful there isn't some underlying issue but who knows.... looking into that now.  But I have a couple of environments which I can test with but it's hard for me to wrap my head around the fact that performing a backup of one DB at a time, even on a system with very little load, my 'test environment', would put us in this situation.  I'll be testing a bit tonight and will watching permon closely.  Also going to try an older 6.1 version of the client as see if that turns up anything different.