The reason that TSM works this way is to help ensure that when restoring
deleted files, at least the most recent directory for those files will
still be available.
For example, suppose you had a directory structure like this:
c:\mydir\file1
c:\mydir\file2
Suppose you have two management classes, A and B. A is the default, and
has a RETONLY setting of 10 days. B has a RETONLY setting of 30 days.
Now suppose (for whatever reason) you decide to bind file2 to management
class B. If TSM did not behave as I describe, then you have this:
c:\mydir bound to A
c:\mydir\file1 bound to A
c:\mydir\file2 bound to B
Next, you delete the c:\mydir directory (and its files, of course). The
next incremental backup detects that these files are deleted, and marks
the backup versions inactive. In 10 days, the backups for c:\mydir and
c:\mydir\file1 will be deleted from TSM's inventory. In 30 days, the
backup for c:\mydir\file2 will be deleted from TSM's inventory.
Now suppose it is 15 days later and you wish to restore c:\mydir\file2.
The following would be true:
- You won't be able to restore via the GUI, because using the GUI to
navigate to c:\mydir\file2 means that you need to be able to first
navigate to c:\mydir. Since no backups exist for c:\mydir, you will not be
able to navigate to it, and thus you will not be able to navigate to
c:\mydir\file2.
- You can restore c:\mydir\file2 via the command line, but the c:\mydir
will be created with default attributes vs. restored from TSM's inventory
with its original attributes (because no backup for it exists).
So this is why we make TSM behave the way it does.
You could use DIRMC to tell TSM to bind the directories to your STANDARD
management class, but I would not recommend it unless you have a very
controlled environment, and you understand and are willing to accept the
ramifications as I have described above.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Farren Minns <fminns AT WILEY.CO DOT UK>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/12/2004 07:11
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Strange Policy Domain Question
Hi there
Well that looks like it could well be the exp0lnation, but still doesn't
make any real sense. Surely If I create a new man class and specify
exactly
what I want to bind it to, that should be it.
Anyway, thanks to all for the answers.
All the best
Farren :)
|+--------------------------------+---------------------------------------|
|| Andrew Raibeck | |
|| <storman AT US.IBM DOT COM> | |
|| Sent by: "ADSM: Dist Stor | To: ADSM-L AT VM.MARIST DOT EDU |
|| Manager" | cc: |
|| <ADSM-L AT VM.MARIST DOT EDU> | Subject: Re: Strange
|
|| | Policy Domain Question |
|| 01/12/2004 01:48 PM | |
|| Please respond to "ADSM: Dist| |
|| Stor Manager" | |
|| | |
|+--------------------------------+---------------------------------------|
> ... all clients see a lot of files being rebound.
See http://msgs.adsm.org/cgi-bin/get/adsm0110/1061.html for the likely
explanation. Less likely (but not inconceivable) is that you inadvertently
assigned the new management class as the default management class.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Farren Minns <fminns AT WILEY.CO DOT UK>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/12/2004 03:19
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Strange Policy Domain Question
Hi All
Running TSM 5.1.6.2 on Solaris 2.7
I have been trying to add a new management class to just one dir and all
sub-dir's on one of our Solaris clients. I have been doing this with the
following steps :-
1) Create a new management class called RETDEL750 under the STANDARD
policy
domain. The STANDARD backup copy group under the new man class looks as
follows :-
Policy Domain Name STANDARD
Policy Set Name STANDARD
Mgmt Class Name RETDEL751
Copy Group Name STANDARD
Versions Data Exists 3
Versions Data Deleted 1
Retain Extra Versions 180
Retain Only Version 750
Ok, so I'm happy that this means keep files deleted from the client backed
up for 750 days.
2) Now, I validate and then activate the STANDARD policy set. This works
fine.
3) Assign the new management class to the required dir with an include
statement. As follows :-
include /app/production/.../* retdel750
Now, the problem I have is that the backup for the following night shows
some strange behaviour for all clients using the STANDARD policy domain in
that all clients see a lot of files being rebound. But I would expect to
only see rebound files for the client and dir with the include statement.
Is this a bug, or am I missing something here (or just being stupid and
doing something wrong)?
Many thanks in advance
Farren Minns - John Wiley & Sons Ltd
*****************************************************************************
This email transmission is confidential and intended for the person or
organisation it is addressed to. If you are not the intended recipient,
you
must not copy, distribute, or disseminate the information, open any
attachment, or take any action in reliance of it. If you have received
this
message in error please notify the sender.
Any views expressed in this message are those of the individual sender,
except where the sender specifically states otherwise.
Although this email has been scanned for viruses you should rely on your
own virus check, as the sender takes no responsibility for any damage
arising out of any bug or virus infection.
*****************************************************************************
*****************************************************************************
This email transmission is confidential and intended for the person or
organisation it is addressed to. If you are not the intended recipient,
you
must not copy, distribute, or disseminate the information, open any
attachment, or take any action in reliance of it. If you have received
this
message in error please notify the sender.
Any views expressed in this message are those of the individual sender,
except where the sender specifically states otherwise.
Although this email has been scanned for viruses you should rely on your
own virus check, as the sender takes no responsibility for any damage
arising out of any bug or virus infection.
*****************************************************************************
|
