Simultaneous Backups

[Peter_Torrance]

Hi.

I have a server with about 1TB of stuff on it. We do a full system backup on it over a weekend, and a cut down one during the week.
I have attached to the server an ait autoloader with 2 drives, and 19 tapes (yes it's an SSL2020!)
I have created 2 partitions for the tapes, and 2 backup jobs. One backup job points to the 1st set of tapes, and the 2nd job to the other set of tapes.
The problem I have, is that as both jobs run at the same time (to minimise the backup window), one of the backups will fail with an OFO failure. This I presume is because the 1st backup has already created a cache file, and the 2nd job can't create one.

Is there a way around this - 2 cache files maybe?

Thanks!

Pete.

[Richard_Ibbotso]

There is a way round this...Have each job backup different volumes, or set 1 job to not use the OFO, and make sure that neither job has got the OFO folders selected for backup.

[Gauri_Ketkar]

Hi,

-can you please give details of the Data being backed up in each job?
-are you backing up any databases?
-it is a remote or local backeup?
-which option you have selected under AOFO from backup job setting ?

Please give detailed Information of your Environment and paste here the exact error message of failed backup job.

Update us on the same.

Thank you,
Gauri

NOTE : If we do not receive your reply within two business days, this post would be marked "assumed answered" and would be moved to "answered questions" pool.

[Peter_Torrance]

Hi - sorry for the delay in coming back to you- i've just got back from holiday...

The data is flat files - mainly jpg's and pdf's.
There are no databases.
It's a local backup.

The OFO is set to Automatic for both jobs.

This is some of the error message from the backup log.

Backup - \\ServerNameOFO: Initialization failure on: "E:". Advanced Open File Option used: Veritas Volume Snapshot Provider (VSP).
OFO: Volume specified is not snappable. Possible reasons: Not a fixed drive, or contains an active cache file or does not have a valid source or is write protected.
Backup - C: Unable to open the item C:\Documents and Settings\Administrator.GRIMSBY\Local Settings\Temp\Acr13BF.tmp - skipped.
Unable to open the item C:\Documents and Settings\Administrator.GRIMSBY\Local Settings\Temp\Acrobat Distiller 5\00000E78\dirlock.tmp - skipped.
Unable to open the item C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat - skipped.
Unable to open the item C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat - skipped.
Backup - E: DATAUnable to open the item E:\ARCHIVE\IMAGES\Rich\EDITPDF17\20_11_03 GYTGT__8.PDF - skipped.
Unable to open the item E:\ARCHIVE\IMAGES\Rich\EDITPDF17\21_04_03 GYTEL_T&C_1.PDF - skipped.
Unable to open the item E:\ARCHIVE\IMAGES\Rich\EDITPDF17\21_04_03 GYTEL_T&C_12.PDF - skipped.
Unable to open the item E:\ARCHIVE\IMAGES\Rich\EDITPDF17\21_04_03 GYTEL_T&C_16-17.PDF - skipped.
Unable to open the item E:\ARCHIVE\IMAGES\Rich\EDITPDF17\21_04_03 GYTEL_T&C_1_2.PDF - skipped.

The server has a pair of mirrored internal disks for the OS, and a raid 5 of about 1TB for the data. The data is all on one volume/drive letter.
The backup drive is an ssl2020 and the backup takes around 18 hours for the 1st job, and 24+ hours for the 2nd.


Thanks!

Pete.

[Richard_Ibbotso]

Peter,

Try running both backups without the OFO, and set the files to be backed up WITHOUT a lock if the file is open. The OFO needs to be on a separate volume to the data you are backing up, so in your case you would need a physically separate disk and drive letter, which I guess you don't have lying around?

You don't need to worry about the tmp files not being backed up, as they are not needed if you ever needed to do a full server restore. The same applies to the qmgr.dat files; they are not important.

Back to the important data...If you can run the backups successfully without the OFO then I would suggest you keep them like that unless you get failures due to important files being skipped. However, if you run without the OFO and backup any open files WITHOUT a lock then you should be able to restore when needed and have no problems. However, you should test this on a few files. If you backup with a lock then when you restore the files are still locked, and believe me this can cause far more problems than backing up without a lock. For one thing, you don't need to reboot the server to clear the locks after a restore.

Hope this helps, it certainly helped me with my 200 servers when I turned off OFO due to lack of resources and simultaneous backups that caused conflicts.

[Peter_Torrance]

Hi...

Thanks for that. I'll give it a try this weekend. I'll set one of the jobs with no OFO, but leave the other with it on, as it still does the C: & sys state.
I'll ensure both are set to 'without a lock'.


Thanks!

Pete.