Re: Directory Structures are going to the wrong place.



Hi Kyle,

ADSM will bind the directories to the management class that has the
longest retention - specificially, the longest RETONLY setting. In
the event that you have multiple management classes with the same
RETONLY setting (and that value happens to be the largest of all
your management classes), then ADSM will use one of those management
classes. Which one it uses is unpredictable. That is, in a given
policy configuration, it will always use the same management class,
but you can not tell initially which one it will be.

Example: If you have a management class DISKMC with RETONLY=30 and
another management class TAPEMC with RETONLY=60, then ADSM will
bind directories to TAPEMC.

Example: If you have a management class DISKMC with RETONLY=30 and
another management class TAPEMC with RETONLY=30, then you can not
initially tell which management class will be used. But if ADSM
starts to use TAPEMC, then it will always use TAPEMC unless your
policy configuration changes, at which time it may start using a
different management class.

The reason ADSM uses the management class with the longest retention
for directories is to ensure that when you do a file restore, it can
always restore the directory. For example, if you have the following
directory structure:

   DIRA
      FILE1
      FILE2

If your policies are such that, say, FILE1 is bound to a management
class with a 30 day retention, and FILE2 is bound to a management
class with a 60 day retention, then ADSM needs to keep DIRA at least
60 days. If it only kept DIRA for 30 days, then if you needed to
restore FILE1, it is possible that there might not be a backup available
for DIRA if it has reached its 30 day retention. This is why it ADSM
always uses the management class with the longest retention.

Unfortunately the ADSM client does not know what kind of device the
management class's copygroup writes to, so in the event of a "tie"
for longest retention, it might pick a management class that does
indeed go to tape.

(Note that I've simplified the discussion a bit to keep this
already long post from getting even longer.)

So... take a look at the RETONLY setting for your copy groups.
I suspect that the tape copy group's setting is at least as
long as your disk copygroup's setting. If the settings are the
same, then you can use the DIRMC option in DSM.OPT to force the
directories to be bound to the disk management class. Alternatively,
you can create a special management class and copy group for
directories that has the longest retention and goes to a disk
pool. Then use DIRMC to point to this new management class.

Regards,

Andy

Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com
"The only dumb question is the one that goes unasked."

ADSMers,
        We have a very simple installation of ADSM.  First we are using the
 default
"Standard" Policy Domain, "Standard" Policy Set, "Standard" Management
Class
and "Standard" Backup Copy Group.  The backup copy group in the Standard
Management class pointing to BACKUPPOOL (disk).  At this point if we run a
backup everything goes to disk as it should.  Next we add another
management
class called "Tape" to the "Standard" Policy Set.  In the "Tape" management
class we create a backup copy group which points to DLTPOOL1 (tape).  Now
when we run a backup the data goes to disk as it should but the directory
structures are now being rebound and sent to tape.
        During our testing we took everything out of the dsm.opt file
except 4
lines needed for communications and the same thing happens.  We also have
more than enough disk space so we are not reaching our thresholds.  We
verified our thresholds.  Also we were on a support call with ADSM support
yesterday for 4 hours.  They helped us rule out almost everything but they
didn't seem to believe we were having this problem.  Not that I blame them
because it is a mystery to me why this is happening.
        If you want to try and recreate this please do the following:
1) Create a new Policy domain and Policy set.
2) In the new Policy set create a management class and backup copy group
pointing to disk.
3) Register a node to that Policy domain.
4) do a q occ on that node to see where it currently has files and how many
are there (this is key).
5) run a backup
6) do another q occ on that node.  All that should have increased is the
occupancy on disk.
7) now add another management class and copy group pointing to tape.  Make
sure it is not the default.
8) run another backup
9) do yet another q occ. Did the occupancy on tape increase?  If yes then
this is a problem.

        In our case we have ADSM server on NT and AIX.  In both cases where
 this
happened to us we had NT clients one workstation and one server.  We are
not
sure if this has anything to do with the problem or not.

Thanks,
        Kyle
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kyle Payne
Berbee Information Networks Corp.
4000 W. Spencer Street
Appleton WI, 54914
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
payne AT berbee DOT com        - e-mail
pgpayne AT berbee DOT com      - pager e-mail
(920) 586-3014          - pager
(920) 450-0413          - cell
(920) 997-9420 x.46     - work
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~