Thanks Richard I can confirm that the files and dirs are bound to the correct policy values and that we do not have a DIRMc setting in place.
Thanks for your help and I'll have a look at that technote now. Regards Farren |-----------------------------+-------------------------------------------| | Richard Sims <[EMAIL PROTECTED]> | | | Sent by: "ADSM: Dist Stor | | | Manager" | To| | <ADSM-L@VM.MARIST.EDU> | ADSM-L@VM.MARIST.EDU | | | cc| | 27/01/2006 14:07 | | | | Subject| | Please respond to | Re: [ADSM-L] Mac | | "ADSM: Dist Stor | Client 5.2.3.12 point | | Manager" | in time problem | | <ADSM-L@VM.MARIST.EDU> | | | | | | | | | | | | | | | | | |-----------------------------+-------------------------------------------| On Jan 27, 2006, at 8:36 AM, Farren Minns wrote: > Hi Richard > > Well, looking at the dirs and files I can see the following :- > > 'Files' are bound to the following backup copy group. > > Version Data Exists - 3 > Versions Data Deleted - 1 > Retain Extra Versions - 180 > Retain Only Version - 60 > > 'Dirs' are bound to the following (this backup copy group was > created for > something else but as far as I'm aware dirs automatically bind to the > backup copy group with the highest retention settings). ...unless instructed otherwise via DIRMc, per client manual and Admin Guide. > > Version Data Exists - 3 > Versions Data Deleted - 1 > Retain Extra Versions - 180 > Retain Only Version - 751 > > So, looking at the above I can see no reason why there would ever be a > situation where a required dir would not exist for a required file > as we > always keep the only last remaining copy for 751 days. > > Also, when using the GUI, I can still see the files when viewing > active/inactive, just not when adding in the point in time too. Adding PIT makes the operation much more restrictive, and requires existence of the directory instance which matches that time period. Irregularities can screw this arrangement up, as for example system clock values having been incorrect at backup time. Rather than inspecting current policy values and what you think should have happened, you need to inspect the actual assignments of the (surviving) directory objects in TSM storage. Current policy values are just that: changes to policies over time, and unexpected bindings, can be the cause of expired objects. Have a look at Technote 1162784 as well, where IBM lays out the issue. Richard Sims ###################################################################### The information contained in this e-mail and any subsequent correspondence is private and confidential and intended solely for the named recipient(s). If you are not a named recipient, you must not copy, distribute, or disseminate the information, open any attachment, or take any action in reliance on it. If you have received the e-mail in error, please notify the sender and delete the e-mail. Any views or opinions expressed in this e-mail are those of the individual sender, unless otherwise stated. Although this e-mail has been scanned for viruses you should rely on your own virus check, as the sender accepts no liability for any damage arising out of any bug or virus infection. ######################################################################