ADSM-L

Re: dirmc and multiple storage pools

1998-12-28 17:40:28
Subject: Re: dirmc and multiple storage pools
From: Andy Raibeck <storman AT US.IBM DOT COM>
Date: Mon, 28 Dec 1998 14:40:28 -0800
The reason that directories are bound to the management
class with the longest retention is that there is no
guarantee that the files beneath it will all be bound to
the same management class. A simple example: suppose I
have a directory called C:\ANDY with two files in it,
like this:

C:\
   ANDY\
        PRODFILE.TXT
        TESTFILE.TXT

Now suppose I have this in my include/exclude list:

INCLUDE C:\ANDY\PRODFILE.TXT MC90DAYS
INCLUDE C:\ANDY\TESTFILE.TXT MC15DAYS

So which management class should C:\ANDY be bound to?
The question becomes even more interesting if a new
file is introduced to the C:\ANDY directory and an
include statement binds it to, say, the MC180DAYS
management class.

Binding directories to the management class with the
longest retention is how ADSM can assure that the
directory is restorable no matter which management
class the files under that directory are bound to.

Yes, normally directory entries will be stored in the
database, but entries that require more storage may
end up in a storage pool, not the database. This is
probably what is happpening with your NT backups
(these are probably NTFS volumes).

The way around this is just as your customer found:
use DIRMC to bind the directories to a management
class that resides on disk. Alternatively they could
create the disk management class such that it has the
longest retention, and thus negate the need to code
DIRMC.

One "gotcha": be careful when creating new management
classes or updating exising existing management
classes. You will always want to ensure that the
disk management class has the longest retention.

And yes, I strongly recommend using copy storage
pools to back up your disk storage pools. You can back
up the disk storage pools to the same copy storage
pool you use to back up your tape pools, if you wish.

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

Greetings,
    I have searched the archives for help with this, but to no avail.
    I have a customer with a ADSM NT server running version 3.1.2.0,
backing
up NT clients running version 3.1.0.5 of the ADSM client.  This server
has
various management classes set up with various retention
characteristics,
from a few weeks to several months.  These management classes point to
storage pools that use different tapes.
    When a backup starts on some clients, ADSM exhibits a strange
behavior.
It mounts a tape, writes for awhile, unmounts, mounts a different tape,
writes for awhile, umounts that tape, then mounts the first tape again,
writes for awhile, then goes to the second tape again, and so on,
switching
back and forth between these two tapes.  This of course causes terrible
performance.
    What seems to be happening, and this is only surmise at this point,
is that the directories are being backed up to one storage pool, and the

data to the other storage pool.  The default mgmt class has a longer
retention period than the mgmt class they are using, and according to
what I read in the manual, directories by default get bound to the
management class with the longest retention period.  Why do this?
Shouldn't the more logical behavior be to bind the directories to
the same management class as the files they refer to?  Wouldn't you
want the directories to end up on the same media as their files?
    Also, I heard someone in this forum say recently that by default
the directories all go in the ADSM database, not to a storage pool.
The only exceptions to this were things like ACLs that would not fit
on the ADSM database record.  How does it work under NT?  Shouldn't
the directories go in the ADSM database?
    What the customer did to get around this behavior is set up a disk
storage pool, and put a  'dirmc diskmgmtclass' in the client's dsm.opt
file
to force the directories to backup to a mgmt class that uses only disk.
This has "fixed" the problem, but is far from an ideal solution, unless
they start using a backup tape storage pool to back up the disk storage
pool.  Otherwise they are going to loose that disk someday and all their

directories, too.
    The reason this is such a problem is that on this particular NT
client,
they need to back up data to different storage pools, and therefore they

can't just put a 'dirmc' statement in the dsm.opt file that points to
the same mgmt class that the data is going to; there is more than one
mgmt class in effect on the same node.

Can anyone tell me the correct way to back up to multiple storage pools
without getting this behavior?  Any tips and tricks would be
appreciated.

Thanks in advance,

John

jdschn AT ibm DOT net
<Prev in Thread] Current Thread [Next in Thread>