27 Sep 10 9:58
There are a number of factors that will impede your backup speed and overall performance. This day in age the drives are so fast that most of the time you will be able to almost exclude them from the equation fairly early in the performance game, unless they really stand out and being the sole cause of the problem - however sounds like you tried to upgrade your way out of a performance problem, so think the drive might be ok :) - the 432GB/Hour is more or less only achievable in test setups where pretty much everything is designed for the purpose of pushing data to the drive.
You mention a number of clients - W2K, NT4 and W2K8, so sounds like your backups are all pulled via the LAN. No problem running it this way, just adds a couple of extra layers to the diagnoses of the problem.
Firstly - I haven't really worked with VBE for a while, so can't really comment on any ongoing issues or general problem, so taking a very overall perspective on this.
You say LTO-4 Library - is this Fibre or SCSI based? As this sounds like a general issues across the board, I'll assume that the library is SCSI based and backups are more or less running 24x7 to try and keep up. I'll also assume that the library isn't attached to a RAID controller and lastly I'll assume that the backups consist of 'normal' data (not million upon million of tiny files scattered across hundreds of servers all over the globe).
I find the best way to identify the bottleneck is to break the task into smaller chunks: Drive, drive interconnect (SCSI/Fibre), backup server, interconnect (LAN), clients!
Initially check that the backup server is actually capable of delivering data at the rate you are expecting. Try and see if you can locate a small util call PAT12.exe - This tool allows you to simulate a datatransfer locally and see what the system will allow as the maximum throughput on the current workload. If the performance is decent, try and generate a chunk of data (HPcreatedata excellent for this purpose. It basically allows you to generate data in a selective folder depth in a perfect 2:1 compressible structure), or simply grab a file of a fairly decent size - or even a number of files to make up a good transfer size and try and copy this from the individual clients to the backup server. If 300mb/min is what you get here, then you will need to look at the network or the client itself rather than the tape drive. A reduction in speed from a particular client will be a good indicator on where to start.
If I were in your shoes I would start a little like this:
1. Run PAT12.exe on the backup server - if result is well above the current backup transfer leave for now, or if no PAT12, run a local backup of a couple of GB's to ensure that the backup server is actually capable of throwing data at the library/drive at a decent rate. If this is slow - try alternative SW (Ntbackup, Windows Backup...basically whatever you have available to test). If this is slow as well - check SCSI settings etc. If still slow - try tape drive on different controller and host!
2. Copy data from the individual clients - any client particularly slow or speed the same across the line?
2a. if a single client is slow - try PAT12.exe on client and see what it yields (or copy from e.g. C: -> D: to get an indication of disk delivery - check network setting, CPU workload, memory usage, available updates (firmware/driver), high fragmentation etc.
2b. if general issue across the line, then this poses a bit of a challenge as you might be looking at a highly congested network or a problem on you backup server keeping track of all the data coming in. With current parts costs an extra NIC in a couple of clients or the backup server itself (perhaps on a separate backup LAN) will go a long way..