Hey Andy,
The example that you've outlined here has to do with files that reside on one
system. I can understand TSM working this way.
What I don't understand is the following:
System A:
/tmp/
/logs/logfile1
/logs/logfile2
/usr/
System B:
/home/
/export/home/
/export/home/myfile
Both systems are part of the same policy domain. I have two management classes.
One is called STANDARD and the other is called LOG_POLICY-MC.
Managementclass STANDARD is the default.
I included the following line in my include/exclude file on System A:
INclude /logs/.../* LOG_POLICY-MC
This would mean that all the directories below /logs/ and including /logs would
be bound to managementclass LOG_POLICY-MC
All other directories and files should be bound to the managementclass STANDARD
because that is the default and I have not specified anything alse in my
include/exclude file.
This goes for /tmp/ en /usr/ on System A.
And now System B:
System B has nothing to do with the LOG_POLICY-MC. I haven't specified it
anywhere in my include/exclude file nor in a client option set.
But yet, directories /home/ and /export/home/ are bound to LOG_POLICY-MC.
File /export/home/myfile is bound to managementclass STANDARD as you would
expect.
So I completely agree with the example that you just gave me.
But in your example the files and directories reside on the same system.
In my example you have two separate systems and they are both affected by the
LOG_POLICY-MC managementclass.
I think that's odd!
Kind regards,
Jerry Caupain
>>> storman AT US.IBM DOT COM 10/26/01 05:09PM >>>
Hi Jerry,
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 DSM_DIR 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. Note that the /logs directory and
its subdirectories will also be bound to the STANDARD management class
(the DSM_DIR option is absolute, and the INCLUDE statement binds only the
*files* to the specified management class), so you could run into the
problems I describe 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.
Jerry Caupain <j.caupain AT ONL.PINKROCCADE DOT NL>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
10/26/2001 06:52
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Strange behaviour????
But why EVERY directory of EVERY system, even the ones that have nothing
to do with this managementclass?
Why don't all other systems just use the default managementclass?
Do I really need to specify a dirmc for every system in order to get the
policy I need?
Regards,
Jerry Caupain
>>> Rene.Lambelet AT NESTLE DOT COM 10/26/01 12:05PM >>>
hi,
it will be used for directories if the retonly value is the highest in
this
DOMAIN,
> -----Original Message-----
> From: Jerry Caupain [SMTP:j.caupain AT ONL.PINKROCCADE DOT NL]
> Sent: Friday, October 26, 2001 11:12 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Strange behaviour????
>
> Hello everyone,
>
> I have noticed something strange. In my policy domain I have two
> management classes. One is called STANDARD and the other is called
> LOG_POLICY-MC. I want to use the last one only for my log server so I
> included the following line in my include/exclude file:
> INclude /logs/.../* log_policy-mc
>
> Managementclass STANDARD is the default managementclass.
>
> Why is it that all my other systems also use the LOG_POLICY-MC
> managementclass? It seems that the directories on my other systems are
> all bound to this managementclass. This can't be normal............can
> it???
>
> Jerry Caupain
|
