I have four servers all plugged into an HP 4/40 library via SCSI to its own drive, with one of the systems acting as the Cell Manager. Right now we stagger each of the daily backups so that at no time they run backups at the same time (in threory, anyway!)
Does anyone have any experience having two or more backups running concurrently? I am interested if it is possible from the OB database point of view, as well as performance expectations on the Cell Manager.
i have a 10/588 Libray with three DLT7000 drives which are connected each to a different server. At 7:00 pm i start three backups and have no problem with it. My Cell server is a K220 with 2 proc. and 1GB memory and i see no crititals on the system when OB does concurrent backups.
We have a 2/15 and are able to backup both servers at the same time. If you don't already have it, you will need a single drive license for each drive that will be in use concurrently. In your case, if you want to have three concurrent backups, you will need three single drive licenses. If you do attempt to initiate a fourth concurrent backup, the OBII will hold the job until one of the first three backup jobs complete or until the waiting job times out.
Omniback can indeed do multiple backups to multiple tape drives - but you are correct in asking if the DATABASE will slow us down or is a constraint.
Often you will find the network is a bigger constraint.
However it is possible that the database is a constraint. There are a few things you can do.
Obviously, you could slow Omniback down, using settings like network load, and concurrency (or fewer tape drives.) this would allow more backups to run at the same time - but each would run slower than it's 'best case.'
You could also lower the database usage by LOGGING less information - our default is to log full path and filename, date, etc... ('log all.') If you choose directories or none - this will reduce the amount of catalog data - and so the database has less to do. The database will also not grow as fast if you reduce this logging.
If your database is smaller, of course access to it is quicker. It will be important then to keep only the data that you really need, and do database maintenance frequently. Don't use permanent protection, purge out unneeded data, do the omnidbutil -writeascii / readascii processes regularly.
If you are running backups from the command prompt (omnib) use the -no_monitor syntax - monitoring sessions need to query the database - the fewer monitoring sessions, the less competition for database access.
The omniback database is a database - if performance is an issue look to things like moving it to a faster hard drive (or hard drives) memory management, and so forth.
Finally - if you keep Omniback so busy that the database LOCKS - you are keeping Omniback too busy - reschedule jobs, log less, etc.
If you do get locking issues, that can be tweaked a bit so that Omniback doesn't hang up prematurely - but it can't really be fixed. Locking issues will slow down Omniback under some circumstances. This is regarded generally as a performance issue, and the advice would be to spread your backups over time, slow them down, etc...
By the way - remember that Omniback is a database. If you add an index to a database, does that improve performance? For some things yes, for other things it slows it down...
Guess what? We improved 3.1. And for some things it is slower - it is more noticably slower if you are upgrading from 2.55.
As always..check patches. There is a performance issue for OB II 3.1 addressed in a current patch.