I brought this up as an integrity issue on deaf ears.  Most folks do a "q
volume * acc=unavailable" daily to see if they have any tapes in this state
and either change them to readonly or readwrite.  This is caused when a tape
drive fails and TSM does not know what the state of the tape could
potentially be.  It can also happen to primary pool tapes and then they do
not get copied to the copypool.  No error messages other than to say it
skipped over it because it is unavailable.  I said the backup stg command
should at least get a RC=4 when this happens.

Anyway, we do not use the TSM scheduler.  We use an external scheduler that
a staff monitors 7x24.  I setup my own jobs to issue the commands figure out
what was going on and generate escalation processes to fix the stuff so we
would never lose anything.

Sorry, I do not have a better answer.  But, I will talk to TSM development
because I told them once this was a severe issue and customers would not
find out about it until it was too late.  I see you are one of those.  I
would call this in as a SEV 1 problem, call your Tivoli Rep, and turn in a
requirement to have it fixed.

Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180


-----Original Message-----
From: Kliewer, Vern [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 10, 2002 3:53 PM
To: [EMAIL PROTECTED]
Subject: DRM Volume contains files that cannot be restored


How do I track down what is going on here?

After restoring the database and most of the DISKPOOL from tape using DRM
procedures, I get one DISK volume left over. It appears to contain a very
limited amount of data from a single node.

We back up our DISK and TAPE pools to COPYPOOL. We then
back-up the database, first with a DBFULL backup that stays in the library,
and then with a DBSNAPSHOT that gets exported and sent to offsite storage.

I realise this leaves a window between the time the DISKPOOL was backed up
to the COPYPOOL and when the DBSNAPSHOT was started where, if NODE backups
were active, they might put some data in the DISKPOOL that the database
knows about when the DBSNAPSHOT is taken, but did not get into the COPYPOOL.

How do I eliminate all other possibilities?

The reason I ask, is that several COPYPOOL tapes, which were marked
UNAVAILABLE, but had not yet been sent off-site at the time of the
DBSNAPSHOT did NOT get marked as READ-ONLY by the recovery process.
Therefore it appeared that we could not restore a great chunk of our
DISKPOOL, until I discovered I had tapes that were marked "UNAVAILABLE".
Once I marked those as READ-ONLY I got almost all of our DISKPOOL back,
except for these few files on one volume.


<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Werner (Vern) Kliewer
Sr. ITS Analyst
Mid-Range Support
Manitoba Public Insurance
(204)-985-7745
[EMAIL PROTECTED]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

(Sorry if this is a double post. I cannot tell if the first one arrived at
the list)

Reply via email to