ADSM-L

Re: Question on defeating TSM strengths: due to budget constrain ts << solved

2003-05-22 22:27:44
Subject: Re: Question on defeating TSM strengths: due to budget constrain ts << solved
From: "Seay, Paul" <seay_pd AT NAPTHEON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 22 May 2003 22:26:58 -0400
The two node approach is the easiest and most acceptable way to handle this.

-----Original Message-----
From: Steven Pemberton [mailto:stevep AT IBK.COM DOT AU]
Sent: Thursday, May 22, 2003 8:09 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Question on defeating TSM strengths: due to budget constraints
<< solved


On Friday 23 May 2003 07:41, William F. Colwell wrote:

No, no, no! This is _so_ wrong I don't know where to begin... :)

> I think this is one of the rare cases where policysets are useful.
> Policysets can implement time based policies. Just copy your STANDARD
> policyset to WEEKLY.  Edit the STANDARD mgmtclas (copygroup) to have
> the new parameters, i.e. mode=absolute.

Although multiple policy sets are *sometimes* useful, this isn't one of
those
occasions.

Muliple policy sets are only useful when you are using the configuration
manager to replicate a policy domain to another TSM server. You could then
define two different policy sets on the configuration manager, replicate the

policy domain, and then activate a different policy set on each TSM server.

> Now setup  an admin schedule to activate the WEEKLY policyset at the
> right time, and another to activate STANDARD.  This works because the
> client queries the server for policy information at the start of each
> backup, which is different for the problems the scheduler has with
> include/exclude lists which need a scheduler restart to take effect.

If you activate a different policy set, then the management class/copy group

parameteres in *THAT* policy set will control how the data is retained. Only

the policy set which is active at the time *EXPIRE INVENTORY* is run will
control whether the data is retained or expired. It doesn't matter (much)
which policy set was active at the time of the client backup.

> >Ken_Sedlacek AT KYRUS DOT COM said...

> >I was saying my rosary this morning, and by divine revelation (so to
> >speak), just realized that all I need to do is make a schedule with
> >the new mgmt class. This is so simple, I could just spit!

Remember, if you change the management class being used for backup objects
it
will rebind all the existing backup objects to the new management class.

> >1) How do I get the client servers to execute this FULL_Backup Mgmt
> >class on a weekend schedule, while maintaining the STANDARD Mgmt
> >class for M-F?

There are several ways to do something like this. The simplest is probably
to
just define two client accounts per node. Create two client scedules
(possibly in different policy domains...) and backup the node (using the
"normal" management class) every day, and backup the "other" node (using the

"special" management class once per week (or so).

You *really* need to buy a second tape drive. :)

PS/ You *REALLY* need to buy a second tape drive. :)

Regards,
Steven P.

--
Steven Pemberton                                      Mobile: +61 4 1833
5136
Innovative Business Knowledge                   Office: +61 3 9820 5811
Senior Enterprise Management Consultant    Fax: +61 3 9820 9907

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Question on defeating TSM strengths: due to budget constrain ts << solved, Seay, Paul <=