Thanks for your suggestions.
Yes, I had available drives. The only other process using a drive was a DB backup.
Yes, the disk pool is shared and was full enough that the 5G would not fit, so that
explains the tape mount attempt. But I can still find no reason for the job to fail.
We do have plenty of scratch tapes available. There were no errors related to tape
problems or other problems during the 4 to 5 minutes this backup was trying to run. I
have forced migration of the storage pool. It was only about half full, so had not
triggered a migration yet. The backup seems to be running to the storage pool ok.
This pool is not collocated, but we have seen backups wait for a tape being used by
migration when the storage pool was migrating for a collocated pool.
The last comment in your note
>>you allow client backups to tape drives (a setting I believe...)?
does trigger an idea. We have recently seen a problem with some Novell backups of
large files that tried to go to tape. They appeared to fail because the MAXNUMMP
setting apparently came in with our upgrade to 3.7, but existing nodes got set with
MAXNUMMP=0 instead of the default of 1. They failed with ANS1312E error that clearly
referenced the MAXNUMMP setting. I'm wondering if this problem is the Unix client
version. This client is an existing AIX client that also was left with the MAXNUMMP=0
after the upgrade.
----------------------------------------------------------------------------------------------------------------
Louis J. Wiesemann 502-852-8952
----------------------------------------------------------------------------------------------------------------
The "Daily Word For Reflection" is a free service and a non-discussion
list intended primarily to allow personal reflection on the Word of God.
SUBSCRIBE/UNSUBSCRIBE at:
http://monica.cin.org:81/guest/RemoteListSummary/daily_word
________________________________________________________
>>> [EMAIL PROTECTED] 03/23/01 10:10AM >>>
Do you have available tape drives at that time (it appears that your
are going straight to tape). IF you are not going straight to tape, the DISK
area that you are trying to backup to can't hold your 5+GB file.
Mind you, that if the DISK pool is shared...it could be some percent full
from other
backups? Another thought..colocation on?...tape in use by another
process (it shouldn't matter...but...)...available scratch tapes?
FYI Thanks Tim
you allow client backups to tape drives (a setting I believe...)?
