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]