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:[EMAIL PROTECTED] (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:[EMAIL PROTECTED] Behalf Of
Zlatko Krastev/ACIT
Sent: Sunday, March 16, 2003 5:07 PM
To: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED]
13.03.2003 18:59
Please respond to ADSM: Dist Stor Manager
To: [EMAIL PROTECTED]
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
[EMAIL PROTECTED]
