ADSM-L

Re Expiration of Files and Directories

2005-04-20 11:07:49
Subject: Re Expiration of Files and Directories
From: Farren Minns <fminns AT WILEY.CO DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 20 Apr 2005 16:07:18 +0100
OK, thanks for that, and I can understand that there is a need for a dir to
be required for files that are to be contained within it, but I have
another problem with this.
Let's say I want create the new management class that I want to use to keep
just a certain directories files for a certain length of time ( and also
that the retain only setting will be higher than the standard mc we are
currently using ). Now, what I don't like here is that fact that the retain
only setting is then applied to all dirs on the client being backed up. Why
does this not just get applied to the directory (and sub dirs), in
question, and is there a way to stop this from happening?

Many thanks again

Farren Minns
Solaris System Admin / Oracle DBA
IT - Hosting Services

John Wiley & Sons, Ltd.




Direcories may expire, but files never end up in "limbo". Examine the
BACKUPS table: each object is fully identified by filespace and its
full path, which obviously includes its containing directory. Backing
up a directory, as an object, is usually rather meaningless in a Unix
environment as such directories have no supplementary info. In a
Windows environment, there is a lot of supplementary info, which is why
Windows directories end up in storage pools while traditional Unix
directories are simply identified in the TSM database.

In a restoral, surrogate replacement directory info is planted where
either the dir is not in the TSM db, or has not yet been encountered in
Restore Order. The absence of a directory in TSM is problematic in GUI
restorals, where the GUI wants to present each dir as you navigate down
the path tree: this can cause the GUI to go no further. TSM wants
directories to exist at least as long as contained objects, for a
reason.

   Richard Sims

On Apr 20, 2005, at 9:56 AM, Farren Minns wrote:

> Hi all TSMers
>
> Running TSM 5.1.6.2 on Solaris and have a question regarding the
> different
> way that directories and files are dealt with. I have always been used
> to
> excluding files, directories, file spaces etc and also including them
> with
> different management classes should the need arise for something other
> than
> our standard retention settings. However, I have only just learnt
> about the
> dirmc setting and this has lead me to believe that we probably a few
> million entries in our TSM db for directories that are no longer
> relevant (
> the deleted files having been expired after 60 days but the directories
> having been bound to one of our higher retention man classes ). So
> here is
> my question.
>
> Lets say I have a retention policy on a dir that states that the only
> copy
> of a file (after deletion), should be kept in backup for 365 days but
> that
> I have a dirmc setting in the clients dsm.sys files that will expire
> all
> deleted directories after just 60 days, how does TSM handle this? What
> happens re expiration after 60 days? Do the directories get expired
> and the
> files just end up in some kind of limbo?
>
> Many thanks in advance


######################################################################
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.
######################################################################