Backup To Disk with concurrent Jobs

And you did have free space on your backup device when jobs were in loading media state?

Does all of your backup jobs use the same media set?

You shouldn't run 16 jobs at same time to your backup device, if you dont have there 16 physical disks, dedicated only for backups. One physical spindling disk for one backup job at same time. 4 spindling disks=4 jobs same time, 7 spindling disks=7 jobs same time and so on.

My problem was due to the global overwrite policy, which I had returned to the original value of no overwrite protection once I had set up the media for this set of jobs. (Cause of first problem - only one file per job). The second problem, waiting for media to load, was down to the media prompting before overwriting after another setting change. I now have the global setting to full overwrite protection (no prompting) and it is all working swimmingly.
I see some suprisingly low transfer rates, perhaps these are down to running concurrent jobs as you suggest, but my undestanding was that one of the main advantages of writing to hard disk was the support for concurrent jobs. If you can point me to literature suggesting otherwise I'd be most grateful.

Regards,

Mike

Hi Mike,

For some reason there's no "Best practices" for backup-to-disk-folders on BE Admin Guide. Neither on Backup Exec's Best Practices web site.

That's something i've read from Backup Exec course materials, and also that was asked when completing BE Trainer approval session.

I'm sure that Symantec's support knows where to find that public information, at least i hope they do know:)

Of course there's no technical reasons why you couldn't run 16 jobs at same time.

As there are two many variations of hardware vendor and how disk storage could be setup and connected to the server - it is extremely unlikely that any official Symantec benchmark tests have been done for concurrent backup to disk operations - especially as the server specificiation will also be part of the equations.

I would suggest that you need to see how long 1 job takes to run with not other jobs running and then do some tests with adding a few other jobs to start at the same time in order to see the effect

IMO 16 write intensive operations to a single volume would be expecetd to slow things down if your servers specification and storage arrays are not the latest optimal technology and configuration. As you are running an old version of Backup Exec is this an indication that other elements of your environment are a little dated?

Hi,
Thanks both for the input.
The system we're using is pretty basic, and indeed fairly dated. The "server" is actually my dev machine, and old p4. I'm writing to a mirrored sata array (essentially a single disk) via a pci sata raid card, and then there's a SCSI LTO2 to copy from that once the backup to disk has been taken, the main idea being that we can get all machines backed up to disk overnight, and then archive to tape without disprupting anyone.

As I mentioned we do see some pretty low transfer rates for some jobs. One advantage though is that these slower jobs don't hold up the others, so that in itself is a major benefit. i.e one slow machine may still be backing up when I get in, rather than the queue of machines behind it I used to see when writing to tape.
The low rates appear to be consistently attributed to specific machines, so I'm hopeful the concurrency isn't the major influence there (we are talking low teens in MB/min).
I hope to bench various levels of concurrency, as you've suggested, in the near future.

Thanks again

Ahh OK if you see slow rates from specific machines, then the bottlenck is more likely to be the  remote system or the network path from the remote affacted system.

Worth doing some individual testing with only the backup from one of the slow systems running to compare with the concurrent backups - just in case though.