Also, you might try running a backup using -dirsonly option?  This, at least, 
would re-establish the directory info -- you can then restore the 
data/file-tree structures, but you'd likely have trouble using point-in-time 
parameters for a restore that includes the lost (older) directory objects.

For the future, I'd advise your Dirdisk be copy-pooled TWO (or even THREEE) 
times -- one to it's own storage pool (that stays in the silo), then once to 
the same copypool as the primary data.  I assume you've already configured 
sequential (FILE) primary pool for migration from the primary (DISK) pool -- to 
mitigate reclamation performance for copypool volumes marked "offsite".

HTH!

Don France
Technical Architect -- Tivoli Certified Consultant
Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390
San Jose, Ca
(408) 257-3037
mailto:don_france AT ayett DOT net (change aye to a for replies)

Professional Association of Contract Employees 
(P.A.C.E. -- www.pacepros.com)



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Zlatko Krastev/ACIT
Sent: Sunday, March 16, 2003 5:07 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Dirdisk stgpool volume deleted


If *all* your storage pools have reuse delay and this reuse delay has not
passed since you started the show there is still a chance: restore again
the DB, restore only the dirdisk stgpool, perform regular incrementals.

If reuse delay have passed (it is if equals to 0) and after reclamation
some volumes are overwritten: you still can restore the DB, mark them as
destroyed and restore them from copypool.

But if you have made some backups/archives which TSM must not lose there
is no good answer - old backups/archives are inconsistent due to lack of
directories info; TSM DB restore cannot be made because it would forget
that important backups/archives.
Now which backups are "must-not-lose" is up to you. And archives with
deletion definitely fall in the category. Now you have the hard task to
evaluate the damages - for 300+ servers it would take lot of time.

Zlatko Krastev
IT Consultant






Brenda Collins <brenda.collins AT US.ING DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
13.03.2003 18:59
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Dirdisk stgpool volume deleted


We have a dilemma!

We made changes to our disk a few weeks back and unfortunately the
diskpools for the database and dirdisk were reformatted along with the
rest of the
work being done.  As a result, we had to restore the database.  Due to the
fact that the dirdisk volume was reformatted, it was assumed the data was
no good anyways and then started the deletion process of getting rid of
the data.  This was stopped in the middle because we then determined we
would
lose the copy of the data also.

To correct the situation, we put the volume offline to TSM and thought if
we went through a night's backup, it would pick up all the missing
directories.  No such luck!  When trying to restore some clients, we
determined that we were still missing a lot of directory data.  At this
time, we
figured it was because there was data still on the offline volume and
regardless of being offline, TSM still knew it.

Next step, we deleted all the data on that old dirdisk volume and then ran
through backups again.

Now we are trying to restore clients and getting very inconsistent
results.  It appears that the directories are not in sync with the data
needed to
restore.  If we restore directories only and then files only, we seem to
get around it is some cases.  We have had a couple servers so far where
this
does not work either and it is making people very nervous.

If we would have thought of it immediately, the best answer would have
been to restore the stgpool.  Unfortunately, expiration and reclamation
have
run so that is not an answer.

Any ideas on how to get out of this condition?  It appears that even
though all the directories should be backed up again, they are not
necessarily in
sync with the old data that is there.  I have an open pmr on this but no
answers yet.  Do we have to run a full backup on every server?  (300+)

Thanks,

Brenda Collins
ING
612-342-3839
brenda.collins AT us.ing DOT com