ADSM-L

Re: Management Classes

2004-04-16 15:17:11
Subject: Re: Management Classes
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 16 Apr 2004 08:10:10 -0600
Sam,

Obviously there are two different sets of headaches: one involves how you
minimize the data that gets into your DR pool to begin with, and the other
involves the logistics of moving tapes in and out of the 3583. My vote
(not that I get one) says that the latter headache is the lesser of the
two!   :-)

Changing the management classes around wouldn't be of any use. In this
situation, rather than trying to change the default management class, I
would just update the existing copy group DESTINATION setting (for each
management class) to point to the 3583 pool, thus avoiding the management
class rebinding issue that Kent mentioned.

But that, too, is problematic. For example suppose a file is changed daily
and thus is backed up daily. The backups from Monday - Friday get put into
the local pool, and then you switch to the DR pool for Saturday's backup,
after which the tapes are shipped offsite. Now come Monday, your user
needs to restore the file from the version that was created on Saturday.
You've either got to retrieve the tape, or else your user is out of luck.

Another problem with this scenario is it assumes that a current backup
copy will exist in the 3583 pool, which may very likely not be the case.
Maybe a file that changes little, if at all, has a version in the local
pool. Thus in DR scenario, no version exists in the 3583 pool. Uh oh.

One suggestion that was made is to register a different node name for each
client and have those nodes back up on a weekly basis to the 3583 pool.
You can use a copy group MODE setting of ABSOLUTE to do "full" backups.
This would work, at the expense of creating redundant backups; perhaps a
compromise would be to do this for mission critical systems only. For
non-mission critical systems, back up your storage pools (via BACKUP
STGPOOL) to the 3583 pool, so during a DR restore they will need to have
tapes checked in and out of the library.

I'm sure that you are not the only hardware-constrained TSM user. Others
might be able to lend their own insight as to how they deal with this
issue.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/[email protected]
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.



Sam Rudland <Sam.Rudland AT INGDIRECT.CO DOT UK>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/16/2004 00:14
Please respond to
"ADSM: Dist Stor Manager"


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: Management Classes






Thanks for your information/ideas guys. The reason behind this
requirement is a bit messy. My company has a 3584 library on site with a
3583 at our DR site. Obviously we couldn't fit all the DR media into the
3583 at one time so the plan is to put data from key nodes into a
separate tape pool so that in a DR scenario those tapes can be loaded
into the 3583 and we can do restores without having to check tapes in
and out repeatedly.

I was hoping it would be a simple option I could use on the server side
fo things. I have a little TSM knowledge but not a lot so I think we are
going to get an expert in for a couple of days to relook at our
configuration and help design a new standard to ensure we are following
best practice.

Thanks for your help again,

Sam

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Andrew Raibeck
Sent: 15 April 2004 15:54
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Management Classes

Kent, your questions are very good ones and you make legitimate points.
My intent was to provide an answer to the question that was asked, which
was how to change the MC. Even then, your points notwithstanding, that
answer does not work if uses more than one MC at a time. But then
followed on with an invitation to be more specific about what he wanted
to do, and an admonition against modifying MC's in this fashion. If that
wasn't clear, then I should have probably emphasized that point first
and more strongly.
  :-)

As you point out, there are multiple ways to deal with this sort of
thing, but rather than speculate or write at length on the topic, I
think it better to understand the real need first.
Best regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew
Raibeck/Tucson/[email protected] 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.



Kent Monthei <Kent.J.Monthei AT GSK DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/15/2004 06:43
Please respond to
"ADSM: Dist Stor Manager"


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: Management Classes






Andy, if the clients/filesystems overlap with the other schedules, won't
this lead to excessive/unintended management class rebinding?
If they don't overlap, it would make more sense to just define a new
domain.  If they do overlap, it might be safer to configure an alternate
node name for each client, for use with the special schedules - but this
can lead to timeline continuity issues that will complicate future
point-in-time restores.   Would it be safer to follow your plan, but
just
toggle the existing MC's COPYGROUP settings and do the ACTIVATE
POLICYSET, instead of toggling between two MC's?

Kent Monthei
GlaxoSmithKline




"Andrew Raibeck" <storman AT US.IBM DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
15-Apr-2004 09:24
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: Management Classes






Why not define admin schedules that change the default management class
prior to the scheduled backup (create server macros that run ASSIGN
DEFMGMTCLASS followed by ACTIVATE POLICYSET, then schedule the macros)?

If that does not provide sufficient granularity, then it would help to
have more specific information on what you wish to do, and, just as
important, why. Normally I would recommend against flip-flopping
management classes in this fashion, at least not without knowing a lot
more about your scenario.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew
Raibeck/Tucson/[email protected] 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.



Sam Rudland <Sam.Rudland AT INGDIRECT.CO DOT UK> Sent by: "ADSM: Dist Stor
Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/15/2004 06:06
Please respond to
"ADSM: Dist Stor Manager"


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Management Classes






I have looked everywhere but been unable to find a solution to my needs.
I have am running the TSM server 5.1.8 and I have one policy domain with
several management classes. There is a default class that data goes to
but I want the data from selected schedules to go to a separate
management class, and in turn a separate tape pool. Both this and the
default MC are incremental backups.

Are there any options I should be employing the use of?

Many thanks in advance,

Sam Rudland



-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you receive
this message by mistake, you are hereby notified that any disclosure,
reproduction, distribution or use of this message is strictly
prohibited. Please inform the sender by reply transmission and delete
the message without copying or opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the files have
NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>