Re: Policy Domain ...

[M KIRAN KUMAR]

We read in some document that RETONLY should be greater than or equal to
RETEXTRA (RETONLY>=RETEXTRA)



Regards,

Kiran.



-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
ADSM-L
Sent: Friday, October 29, 2010 1:06 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Policy Domain ...



Valid for what exactly? What is it that you require it to do in terms of
retaining your clients' data? Then we can tell you if it meets your
requirements.

___

David Mc

London



On 29 Oct 2010, at 07:14, M KIRAN KUMAR  wrote:



> Hi, please check the policy domain that we have configured in TSM5.5.0.
Let

> me know is it a valid configuration?

>

>

>

> PolicyPolicyMgmt  Copy  Versions Versions   Retain  Retain

>

> DomainSet Name  Class Group Data DataExtraOnly

>

> NameName  NameExists  Deleted Versions Version

>

> - - - -    ---

>

> HUBDOMAIN ACTIVESTANDARD  STANDARD 31   90  30

>

> HUBDOMAIN STANDARD  STANDARD  STANDARD 31   90  30

>

>

>

>

>

> Regards,

>

> Kiran.

>

> Disclaimer:

> This email message (including attachments if any) may contain privileged,
proprietary, confidential information, which may be exempt from any kind of
disclosure whatsoever and is intended solely for the use of addressee (s).
If you are not the intended recipient, kindly inform us by return e-mail and
also kindly disregard the contents of the e-mail, delete the original
message and destroy any copies thereof immediately. You are notified that
any dissemination, distribution or copying of this communication is strictly
prohibited unless approved by the sender.

>

> DQ Entertainment (DQE) has taken every reasonable precaution to minimize
the risk of transmission of computer viruses with this e-mail; DQE is not
liable for any damage you may sustain as a result of any virus in this
e-mail. DQE shall not be liable for the views expressed in the e-mail. DQE
reserves the right to monitor and review the content of all messages sent to
or from this e-mail address

Disclaimer:
This email message (including attachments if any) may contain privileged, 
proprietary, confidential information, which may be exempt from any kind of 
disclosure whatsoever and is intended solely for the use of addressee (s). If 
you are not the intended recipient, kindly inform us by return e-mail and also 
kindly disregard the contents of the e-mail, delete the original message and 
destroy any copies thereof immediately. You are notified that any 
dissemination, distribution or copying of this communication is strictly 
prohibited unless approved by the sender.

DQ Entertainment (DQE) has taken every reasonable precaution to minimize the 
risk of transmission of computer viruses with this e-mail; DQE is not liable 
for any damage you may sustain as a result of any virus in this e-mail. DQE 
shall not be liable for the views expressed in the e-mail. DQE reserves the 
right to monitor and review the content of all messages sent to or from this 
e-mail address

Re: Policy Domain ...

[ADSM-L]

Valid for what exactly? What is it that you require it to do in terms of 
retaining your clients' data? Then we can tell you if it meets your 
requirements.
___
David Mc
London

On 29 Oct 2010, at 07:14, M KIRAN KUMAR  wrote:

> Hi, please check the policy domain that we have configured in TSM5.5.0. Let
> me know is it a valid configuration?
> 
> 
> 
> PolicyPolicyMgmt  Copy  Versions Versions   Retain  Retain
> 
> DomainSet Name  Class Group Data DataExtraOnly
> 
> NameName  NameExists  Deleted Versions Version
> 
> - - - -    ---
> 
> HUBDOMAIN ACTIVESTANDARD  STANDARD 31   90  30
> 
> HUBDOMAIN STANDARD  STANDARD  STANDARD 31   90  30
> 
> 
> 
> 
> 
> Regards,
> 
> Kiran.
> 
> Disclaimer:
> This email message (including attachments if any) may contain privileged, 
> proprietary, confidential information, which may be exempt from any kind of 
> disclosure whatsoever and is intended solely for the use of addressee (s). If 
> you are not the intended recipient, kindly inform us by return e-mail and 
> also kindly disregard the contents of the e-mail, delete the original message 
> and destroy any copies thereof immediately. You are notified that any 
> dissemination, distribution or copying of this communication is strictly 
> prohibited unless approved by the sender.
> 
> DQ Entertainment (DQE) has taken every reasonable precaution to minimize the 
> risk of transmission of computer viruses with this e-mail; DQE is not liable 
> for any damage you may sustain as a result of any virus in this e-mail. DQE 
> shall not be liable for the views expressed in the e-mail. DQE reserves the 
> right to monitor and review the content of all messages sent to or from this 
> e-mail address

Re: Policy Domain Question

[Thomas Denier]

-Eric J. Jones wrote: -

>I have a question on Policy Domain Name for the clients.
>On 1 of our TSM servers the Administrator created a different Policy
>Domain Name than is standard which is now being used.
>It is being used by a number of clients and has been for some time.
>Is there a way to rename the Policy Domain or is the only option to
>create a new one and change it on all the clients?  I'm trying to
>find the easiest way to get it back so we are using our standard
>naming convention.

As far as I know, there is no way to rename an existing policy
domain. The 'copy domain' command will create a new domain with
the same policy sets, management classes, and copy groups as an
existing domain. Note that it will not copy client schedules or
associations.

When you perform an 'update node' command to move a node to the
new policy domain you may need to have the client system
administrator restart the client scheduler service (Windows) or
process (Unix/Linux) after the update. My best guess, based on my
experience and postings from other sites, is that this is necessary
with prompted scheduling and is not necessary with polling
scheduling.

Re: Policy Domain..

[Cory Heikel]

it should never expire as it would be covered by the versions data exists.
 
Cory Heikel
Tivoli Systems Administrator
Hershey Medical Center
(717) 531-7972

>>> Lawrence Barr <[EMAIL PROTECTED]> 6/6/2008 9:54 AM >>>
How long do really need this data to be kept for ?

2008/6/6 MAHENDER <[EMAIL PROTECTED]>:

> Iam using TSM V5.4.I want to set Backup Copy group policy with the below
> conditions.
>
>
>
> Policy Domain Name POL_DOM
>
> Policy Set Name ACTIVE
>
> Mgmt Class Name STANDARD
>
> Copy Group Name STANDARD
>
> Versions Data Exists 3
>
> Versions Data Deleted 1
>
> Retain Extra Versions 120
>
> Retain Only Version 30
>
>
>
> I have a query that if a file is backed up only once and never modified,
> still on the Client file system, when will that file expire according to
> the
> policy which I have configured as the above.
>
>
>
> Regards,
>
> Kiran.
>

Re: Policy Domain..

[Lawrence Barr]

How long do really need this data to be kept for ?

2008/6/6 MAHENDER <[EMAIL PROTECTED]>:

> Iam using TSM V5.4.I want to set Backup Copy group policy with the below
> conditions.
>
>
>
> Policy Domain Name POL_DOM
>
> Policy Set Name ACTIVE
>
> Mgmt Class Name STANDARD
>
> Copy Group Name STANDARD
>
> Versions Data Exists 3
>
> Versions Data Deleted 1
>
> Retain Extra Versions 120
>
> Retain Only Version 30
>
>
>
> I have a query that if a file is backed up only once and never modified,
> still on the Client file system, when will that file expire according to
> the
> policy which I have configured as the above.
>
>
>
> Regards,
>
> Kiran.
>

Re: Policy Domain..

[Richard Sims]

On Jun 6, 2008, at 8:48 AM, MAHENDER wrote:


I have a query that if a file is backed up only once and never
modified,
still on the Client file system, when will that file expire
according to the
policy which I have configured as the above.


That's the definition of the Active version of a file, which stays in
TSM storage indefinitely.  See the Admin Guide manual.

  Richard Sims

Re: Policy domain concept

[Paul Zarnowski]

At 09:11 PM 8/14/2007, Wanda Prather wrote:

The 2 tricky things, as Paul noted:


That was three.  :-)  Thanks for elaborating..



--
Paul ZarnowskiPh: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801Em: [EMAIL PROTECTED]

Re: Policy domain concept

[Kelly Lipp]

I didn't read, thoroughly, the original note, but my two cents is to remember 
the KISS principal when configuring these things: Keep It Simple Stewpid.
 
Always leave the Standard domain behind.  That way you can use open 
registration.
 
 
Kelly Lipp
CTO, VP Manufacturing
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
www.storserver.com  
719-266-8777



From: ADSM: Dist Stor Manager on behalf of Paul Zarnowski
Sent: Tue 8/14/2007 3:19 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Policy domain concept



I'm sure there are many ways to organize and use TSM Policy Domains,
and I look forward to seeing the responses to your inquiry.  Here at
Cornell, we make heavy use of Policy Domains as you are thinking of
doing - along organizational lines.  Each department here who makes
any significant use of TSM is given their own Policy Domain.  This
allows us to change the default management class, and provide any
number of management classes or schedules that are customized to suit
their requirements.

One thing that we did that I think worked out well is that we tried
to keep the default STANDARD Policy Domain as simple as possible.  If
a single user from a new department came along, we just put them into
the STANDARD domain.  If, later, they requested specialized
requirements, at that time we would move them into their own policy
domain and change the management classes in their private
domain.  Similarly, if that department later added additional systems
to be managed by TSM, we would at that time move them into their own
private domain.  To create their private domain, we would simply use
the COPY DOMAIN and COPY SCHEDULE commands.  This all works, so long
as you ensure that the STANDARD domain is always a proper subset of
all your other domains.  This makes it safe to move a node out of
STANDARD and into a new domain.  Otherwise, you risk orphaning the
management class that an existing file is associated with (i.e., the
new domain doesn't have the same management class that the old domain
had).  One other caution is that before you move the node to a new
domain, check which schedule it is associated with, because the act
of moving a node to a new domain will break all schedule associations.

One other thing I've noticed over the years, related to management
class definitions.  We started out defining management classes
according to their attributes.  E.g., name "1YEAR" was used for an
archive management class that had a 1 year retention.  This works for
the most part, but now and then we get a large archive user who
starts out using a management class, only to later want to change the
retention.  It's not easy to change the retention of files that are
already archived.  But - if all the files whose retention you want to
change are all using the same management class, and none other are,
then you can simply change the definition of the management
class.  For example, if you want to have a common management class
for all logfiles, choose a name called "LOGFILES".  Then you can
change the name of that management class to change the backup/archive
policy for all logfiles, without worrying about what other uses it
might have.  It's much less likely that you will want to change the
definition of a management class named "1YEAR" to mean that files
have a 2 year retention period!

I look forward to seeing what others' experiences are..

..Paul


At 04:32 PM 8/14/2007, Keith Arbogast wrote:
>There may be more suitable or more helpful organizing concepts. We
>would be glad to know them.
>
>How do other TSM admins organize their domains and policy sets
>conceptually?  What does a TSM policy domain correspond to in real
>life? Is it a customer department, a client OS, the production/test
>status of the client, a set of retention parameters?  How can the
>hierarchy of policy domain, policy set, management class be
>implemented so that it is the most helpful in managing a large set of
>clients with diverse owners, retention demands and backup schedules?


--
Paul ZarnowskiPh: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801Em: [EMAIL PROTECTED]

Re: Policy domain concept

[Wanda Prather]

I agree with Paul.

There are 2 technical reasons to split clients into domains:

1) Dividing authority:  you can create TSM administrators with "Policy" or
domain-level authority.  They don't have the ability to modify TSM storage
pools or devices, but they can create nodes, passwords, and schedules for
clients in ONLY their own domains.

2) Management classes:  Clients in a domain all have the same default
management class.

I have some customers that have only 1 domain, because all the clients use
the same default management class; they have few exceptions to the
default, and those are implemented via INCLUDES in teh dsm.opt file.
That's fine from TSM's point of view.  However, once you have a large
group of clients that all need different management class rules, it
frequently becomes easier to create a new domain than to handle everything
by exception.

In an environment like Paul's, where you have many distinct groups of
customers, it is usually going to be easier for YOU to manage if you put
those groups of customers in a domain of their own, because as Paul says,
eventually they are likely to want management classes or schedules that
are customized for them.

If you think you may eventually need to split your TSM server, it is also
easier to split out a group of clients that all have the same
requirements.

Changing the domain for a client is extremely easy:  you just do UPDATE
NODE x DOMAIN=yy.

The 2 tricky things, as Paul noted:

-Schedules belong to a particular domain, so when you change a client's
domain, it is no longer associated with a schedule

-When you change a client from one domain to another, if the target domain
doesn't have management classes with the same NAMES that the client was
using in the source domain, files bound to the missing management class
will go back to the default management class in the target domain, which
may not be what you wanted.

-If you move a client from one domain to another, it's data doesn't move,
even if the mananagement classes in the new domain point to a different
destination storage pool.  Already-backed up data stays where it is; only
new incoming data gets directed to the new storage pools.

W






> I'm sure there are many ways to organize and use TSM Policy Domains,
> and I look forward to seeing the responses to your inquiry.  Here at
> Cornell, we make heavy use of Policy Domains as you are thinking of
> doing - along organizational lines.  Each department here who makes
> any significant use of TSM is given their own Policy Domain.  This
> allows us to change the default management class, and provide any
> number of management classes or schedules that are customized to suit
> their requirements.
>
> One thing that we did that I think worked out well is that we tried
> to keep the default STANDARD Policy Domain as simple as possible.  If
> a single user from a new department came along, we just put them into
> the STANDARD domain.  If, later, they requested specialized
> requirements, at that time we would move them into their own policy
> domain and change the management classes in their private
> domain.  Similarly, if that department later added additional systems
> to be managed by TSM, we would at that time move them into their own
> private domain.  To create their private domain, we would simply use
> the COPY DOMAIN and COPY SCHEDULE commands.  This all works, so long
> as you ensure that the STANDARD domain is always a proper subset of
> all your other domains.  This makes it safe to move a node out of
> STANDARD and into a new domain.  Otherwise, you risk orphaning the
> management class that an existing file is associated with (i.e., the
> new domain doesn't have the same management class that the old domain
> had).  One other caution is that before you move the node to a new
> domain, check which schedule it is associated with, because the act
> of moving a node to a new domain will break all schedule associations.
>
> One other thing I've noticed over the years, related to management
> class definitions.  We started out defining management classes
> according to their attributes.  E.g., name "1YEAR" was used for an
> archive management class that had a 1 year retention.  This works for
> the most part, but now and then we get a large archive user who
> starts out using a management class, only to later want to change the
> retention.  It's not easy to change the retention of files that are
> already archived.  But - if all the files whose retention you want to
> change are all using the same management class, and none other are,
> then you can simply change the definition of the management
> class.  For example, if you want to have a common management class
> for all logfiles, choose a name called "LOGFILES".  Then you can
> change the name of that management class to change the backup/archive
> policy for all logfiles, without worrying about what other uses it
> might have.  It's much less likely that you will want to ch

Re: Policy domain concept

[Paul Zarnowski]

I'm sure there are many ways to organize and use TSM Policy Domains,
and I look forward to seeing the responses to your inquiry.  Here at
Cornell, we make heavy use of Policy Domains as you are thinking of
doing - along organizational lines.  Each department here who makes
any significant use of TSM is given their own Policy Domain.  This
allows us to change the default management class, and provide any
number of management classes or schedules that are customized to suit
their requirements.

One thing that we did that I think worked out well is that we tried
to keep the default STANDARD Policy Domain as simple as possible.  If
a single user from a new department came along, we just put them into
the STANDARD domain.  If, later, they requested specialized
requirements, at that time we would move them into their own policy
domain and change the management classes in their private
domain.  Similarly, if that department later added additional systems
to be managed by TSM, we would at that time move them into their own
private domain.  To create their private domain, we would simply use
the COPY DOMAIN and COPY SCHEDULE commands.  This all works, so long
as you ensure that the STANDARD domain is always a proper subset of
all your other domains.  This makes it safe to move a node out of
STANDARD and into a new domain.  Otherwise, you risk orphaning the
management class that an existing file is associated with (i.e., the
new domain doesn't have the same management class that the old domain
had).  One other caution is that before you move the node to a new
domain, check which schedule it is associated with, because the act
of moving a node to a new domain will break all schedule associations.

One other thing I've noticed over the years, related to management
class definitions.  We started out defining management classes
according to their attributes.  E.g., name "1YEAR" was used for an
archive management class that had a 1 year retention.  This works for
the most part, but now and then we get a large archive user who
starts out using a management class, only to later want to change the
retention.  It's not easy to change the retention of files that are
already archived.  But - if all the files whose retention you want to
change are all using the same management class, and none other are,
then you can simply change the definition of the management
class.  For example, if you want to have a common management class
for all logfiles, choose a name called "LOGFILES".  Then you can
change the name of that management class to change the backup/archive
policy for all logfiles, without worrying about what other uses it
might have.  It's much less likely that you will want to change the
definition of a management class named "1YEAR" to mean that files
have a 2 year retention period!

I look forward to seeing what others' experiences are..

..Paul


At 04:32 PM 8/14/2007, Keith Arbogast wrote:

There may be more suitable or more helpful organizing concepts. We
would be glad to know them.

How do other TSM admins organize their domains and policy sets
conceptually?  What does a TSM policy domain correspond to in real
life? Is it a customer department, a client OS, the production/test
status of the client, a set of retention parameters?  How can the
hierarchy of policy domain, policy set, management class be
implemented so that it is the most helpful in managing a large set of
clients with diverse owners, retention demands and backup schedules?



--
Paul ZarnowskiPh: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801Em: [EMAIL PROTECTED]

Re: Policy Domain & Include Statement Question

[Karel Bos]

Hi,

I think it is because default directories are bound to the management class
having the longest retention period.

Regards,

Karel


-Oorspronkelijk bericht-
Van: Farren Minns [mailto:[EMAIL PROTECTED]
Verzonden: maandag 12 januari 2004 11:49
Aan: [EMAIL PROTECTED]
Onderwerp: Policy Domain & Include Statement Question


(I'm sending this again because it keeps getting returned telling me I have
already sent the same message. But I wrote this this morning for the very
first time, so that can't be. Thanks. Farren)

Hi All

Running TSM 5.1.6.2 on Solaris 2.7

I have been trying to add a new management class to just one dir and all
sub-dir's on one of our Solaris clients. I have been doing this with the
following steps :-

1) Create a new management class called RETDEL750 under the STANDARD policy
domain. The STANDARD backup copy group under the new man class looks as
follows :-

Policy Domain Name                STANDARD
Policy Set Name                STANDARD
Mgmt Class Name                RETDEL751
Copy Group Name                STANDARD
Versions Data Exists                3
Versions Data Deleted                1
Retain Extra Versions                180
Retain Only Version                750

Ok, so I'm happy that this means keep files deleted from the client backed
up for 750 days.

2) Now, I validate and then activate the STANDARD policy set. This works
fine.

3) Assign the new management class to the required dir with an include
statement. As follows :-

include /app/production/.../* retdel750

Now, the problem I have is that the backup for the following night shows
some strange behaviour for all clients using the STANDARD policy domain in
that all clients see a lot of files being rebound. But I would expect to
only see rebound files for the client and dir with the include statement.

Is this a bug, or am I missing something here (or just being stupid and
doing something wrong)?

Many thanks in advance

Farren Minns - John Wiley & Sons Ltd





*

This email transmission is confidential and intended for the person or
organisation it is addressed to. If you are not the intended recipient, you
must not copy, distribute, or disseminate the information, open any
attachment, or take any action in reliance of it. If you have received this
message in error please notify the sender.

Any views expressed in this message are those of the individual sender,
except where the sender specifically states otherwise.

Although this email has been scanned for viruses you should rely on your
own virus check, as the sender takes no responsibility for any damage
arising out of any bug or virus infection.

*

Re: Policy Domain Question

[Richard Sims]

>My motivation was to keep the backup database size small.
>
>We have to archive about 5,000,000 small files off our NT servers every month.
>I found that our database size was growing by about 5GB per month as a result.
>At that rate I would have had a database that was about 100GB in a year.
...

That is always a vexing situation; but rather than thinking only of server-side
means of addressing it, consider also client-side methods.  The oft-cited best
method is for the client to combine large groups of files into one, as via the
Unix 'tar' command or various personal computer bundling packages.  At the same
time as making server storage less insane, it allows the client to reduce an
unwieldy number of individual files into smaller, manageable groups.  In that
most Archive files are seldom retrieved, bundling makes a lot of sense.  If
there is resistance from the client, bring the issue to the attention of your
company management, regarding what it is costing in terms of database
management, additional disk space (incl. mirroring), prolonged db backups,
increased TSM recovery time, etc.

  Richard Sims, BU

Re: Policy Domain Question

[Mark Ferraretto]

My motivation was to keep the backup database size small.

We have to archive about 5,000,000 small files off our NT servers every month.  I 
found that our database size was growing by about 5GB per month as a result.  At that 
rate I would have had a database that was about 100GB in a year.

I considered using 2 hostnames as I know a lot of others do this.  But our database 
would still have grown to the same size.  Using the second instance enabled us to keep 
the backup instance's database small.  This speeds up disaster recovery and also makes 
offsite tape processing faster (simply because the database backup is smaller).  Also 
Tivoli don't recommend you let your database grow past 60GB.

I've had this configuration running for 2 months now.  My backup database is about 
18GB and shouldn't grow much past that.  The archive instance's database is already at 
30GB.  I'm not sure how much more it would grow as we're using incrementals to do our 
archives now.  We'll know after a year!

I agree about the restore issue.  But we don't restore off archives too often.  Also, 
we keep the archive pool onsite so restore might take a while but at least we don't 
have to call a tape in.

Mark

--
Mark Ferraretto
Unix Systems Administrator
Deutsche Bank Hong Kong
w: +852 2203 6362m: +852 9558 8032f: +852 2203 6971
[EMAIL PROTECTED]



  [EMAIL PROTECTED]
  TTo:   [EMAIL PROTECTED]
  Sent by: cc:
          [EMAIL PROTECTED]Subject:  Re: Policy Domain Question
  EDU


  08/07/03 05:07 PM
  Please respond to
  ADSM-L






All right, this approach was discussed many times on this list with only
one exception - you are the first one willing to do it on separate
instance. What others do: 1 node for backups and 1 or more nodes for
different archival requirements (each node can belong to different policy
domain), both stanzas in dsm.sys (UNIX) or both dsm.opt (Win) files point
to same server instead of two. This eliminates the hassle with unnecessary
virtual volumes - when you need to restore a single small file, the
satellite TSM server "mounts" a virtual volume which results on main
server restore from tape of whole file/volume.
What is the rationale which drove you to two instance implementation?

Zlatko Krastev
IT Consultant






Mark Ferraretto <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
07.08.2003 03:17
Please respond to "ADSM: Dist Stor Manager"


To: [EMAIL PROTECTED]
cc:
Subject:Re: Policy Domain Question


Bill,

I wanted exactly the same thing.  Unfortunately, implementing it is quite
difficult in TSM.

* You need to archive to a primary storage pool
* then you need to checkout the tapes from that storage pool manually and
send them offsite.  You can't use DRM to keep track of the volumes as DRM
only works for copy pools and db backups
* You need to manually work out which tapes are required for reclamation
(see the query below) and manually request those tapes back onsite for
reclamation as necessary

In the end I gave up on this and I did the following:
* I created a second TSM instance on our TSM server for managing archive
data only
* I use virtual volumes so the 2nd instance stores its data on the main
instance which has sole control of the tape library
* Instead of archiving data, I use incremental backups on the 2nd
instance.  I use a different management class on the 2nd instance (1 year
instead of 1 month)
* because I'm using incremental backups to perform 'archiving' only about
20% of data changes each month and so the 2nd instance uses much less
space that doing a regular monthly archive
* because the space used is so much less (over a year it's about 400%
less) I've created a copy pool for my archive data as well.  I can afford
to 'waste' the extra tapes and I get quite a few advantages namely:
* I can manage the 2nd instance copy pool the same way as I manage the
main copy pool
* DRM takes care of onsite and offsite tapes
* You can do offsite reclamation - just like a regular copy pool
* The operators don't need to learn any new procedures for managing the
archive tapes
* The archive data is always onsite which makes for easier restoring

Finally, here's the query I mentioned above:

tsm: SM040>q scr q_reclaim_preview f=r
/* Script comment */
/* List volumes in stgpool $1 to be reclaimed  */
/* if threshold was set to $2% */
/* */
/* Script Name: Q_RECLAIM_PREVIEW  */
/* Author:  Mark Ferraretto*/
/* Parameter:   storage_pool, threshold*/
/* Example: run Q_RECLAIM_

Re: Policy Domain Question

[Prather, Wanda]

Instead of going to all that hassle, try Autovault.

It is a VERY INEXPENSIVE replacement for DRM that will vault primary pools
as well as copy pools if you tell it to.

You can download a trial at www.coderelief.com.
Very easy to install, provides everything that DRM does except the
server-to-server license.
No hooks into TSM, can't hurt your server.  Great technical support.

We found it CHEAPER to replace DRM with Autovault than to write and maintain
the front end automation scripts the we needed to have our operators
automatically run vaulting without having to be TSM admins.

It also handles some other issues better than DRM does, contact me if you
want more information.
And no, I don't sell the software.
I have just found it to be a better value and more bulletproof than DRM for
my sites.

Wanda Prather
Johns Hopkins University Applied Physics Laboratory
443-778-8769

"Intelligence has much less practical application than you'd think" -
Dilbert/Scott Adams


-Original Message-
From: Mark Ferraretto [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 06, 2003 8:17 PM
To: [EMAIL PROTECTED]
Subject: Re: Policy Domain Question


Bill,

I wanted exactly the same thing.  Unfortunately, implementing it is quite
difficult in TSM.

* You need to archive to a primary storage pool
* then you need to checkout the tapes from that storage pool manually and
send them offsite.  You can't use DRM to keep track of the volumes as DRM
only works for copy pools and db backups
* You need to manually work out which tapes are required for reclamation
(see the query below) and manually request those tapes back onsite for
reclamation as necessary

In the end I gave up on this and I did the following:
* I created a second TSM instance on our TSM server for managing archive
data only
* I use virtual volumes so the 2nd instance stores its data on the main
instance which has sole control of the tape library
* Instead of archiving data, I use incremental backups on the 2nd instance.
I use a different management class on the 2nd instance (1 year instead of 1
month)
* because I'm using incremental backups to perform 'archiving' only about
20% of data changes each month and so the 2nd instance uses much less space
that doing a regular monthly archive
* because the space used is so much less (over a year it's about 400% less)
I've created a copy pool for my archive data as well.  I can afford to
'waste' the extra tapes and I get quite a few advantages namely:
* I can manage the 2nd instance copy pool the same way as I manage the main
copy pool
* DRM takes care of onsite and offsite tapes
* You can do offsite reclamation - just like a regular copy pool
* The operators don't need to learn any new procedures for managing the
archive tapes
* The archive data is always onsite which makes for easier restoring

Finally, here's the query I mentioned above:

tsm: SM040>q scr q_reclaim_preview f=r
/* Script comment */
/* List volumes in stgpool $1 to be reclaimed  */
/* if threshold was set to $2% */
/* */
/* Script Name: Q_RECLAIM_PREVIEW  */
/* Author:  Mark Ferraretto*/
/* Parameter:   storage_pool, threshold*/
/* Example: run Q_RECLAIM_PREVIEW C3 50*/
/* */
select -
VOLUME_NAME as "$1 pool at $2% reclamation" -
from VOLUMES -
where STGPOOL_NAME = upper('$1') -
and PCT_RECLAIM >= $2 -
order by VOLUME_NAME


--
Mark Ferraretto
Unix Systems Administrator
Deutsche Bank Hong Kong
w: +852 2203 6362m: +852 9558 8032f: +852 2203 6971
[EMAIL PROTECTED]



  [EMAIL PROTECTED]
  JOHNS.COMTo:
[EMAIL PROTECTED]
          Sent by: cc:
  [EMAIL PROTECTED]Subject:  Re: Policy Domain
Question
  EDU


  08/06/03 10:13 PM
  Please respond to
  ADSM-L






I am wanting to set up new Policy Domains, with respective Management
classes, and respective Backup and Archive Copy Groups.  I want my Archives
to go straight to offsite and not be onsite.  Anybody got ideas and how to
do it?

Thank You,
Bill Rosette
Data Center/IS/Papa Johns International
WWJD





--

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

Re: Policy Domain Question

[Zlatko Krastev]

All right, this approach was discussed many times on this list with only
one exception - you are the first one willing to do it on separate
instance. What others do: 1 node for backups and 1 or more nodes for
different archival requirements (each node can belong to different policy
domain), both stanzas in dsm.sys (UNIX) or both dsm.opt (Win) files point
to same server instead of two. This eliminates the hassle with unnecessary
virtual volumes - when you need to restore a single small file, the
satellite TSM server "mounts" a virtual volume which results on main
server restore from tape of whole file/volume.
What is the rationale which drove you to two instance implementation?

Zlatko Krastev
IT Consultant






Mark Ferraretto <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
07.08.2003 03:17
Please respond to "ADSM: Dist Stor Manager"


To: [EMAIL PROTECTED]
    cc:
Subject:Re: Policy Domain Question


Bill,

I wanted exactly the same thing.  Unfortunately, implementing it is quite
difficult in TSM.

* You need to archive to a primary storage pool
* then you need to checkout the tapes from that storage pool manually and
send them offsite.  You can't use DRM to keep track of the volumes as DRM
only works for copy pools and db backups
* You need to manually work out which tapes are required for reclamation
(see the query below) and manually request those tapes back onsite for
reclamation as necessary

In the end I gave up on this and I did the following:
* I created a second TSM instance on our TSM server for managing archive
data only
* I use virtual volumes so the 2nd instance stores its data on the main
instance which has sole control of the tape library
* Instead of archiving data, I use incremental backups on the 2nd
instance.  I use a different management class on the 2nd instance (1 year
instead of 1 month)
* because I'm using incremental backups to perform 'archiving' only about
20% of data changes each month and so the 2nd instance uses much less
space that doing a regular monthly archive
* because the space used is so much less (over a year it's about 400%
less) I've created a copy pool for my archive data as well.  I can afford
to 'waste' the extra tapes and I get quite a few advantages namely:
* I can manage the 2nd instance copy pool the same way as I manage the
main copy pool
* DRM takes care of onsite and offsite tapes
* You can do offsite reclamation - just like a regular copy pool
* The operators don't need to learn any new procedures for managing the
archive tapes
* The archive data is always onsite which makes for easier restoring

Finally, here's the query I mentioned above:

tsm: SM040>q scr q_reclaim_preview f=r
/* Script comment */
/* List volumes in stgpool $1 to be reclaimed  */
/* if threshold was set to $2% */
/* */
/* Script Name: Q_RECLAIM_PREVIEW  */
/* Author:  Mark Ferraretto*/
/* Parameter:   storage_pool, threshold*/
/* Example: run Q_RECLAIM_PREVIEW C3 50*/
/* */
select -
VOLUME_NAME as "$1 pool at $2% reclamation" -
from VOLUMES -
where STGPOOL_NAME = upper('$1') -
and PCT_RECLAIM >= $2 -
order by VOLUME_NAME


--
Mark Ferraretto
Unix Systems Administrator
Deutsche Bank Hong Kong
w: +852 2203 6362m: +852 9558 8032f: +852 2203 6971
[EMAIL PROTECTED]



  [EMAIL PROTECTED]
  JOHNS.COMTo: [EMAIL PROTECTED]
      Sent by: cc:
  [EMAIL PROTECTED]Subject:  Re: Policy Domain
Question
  EDU


  08/06/03 10:13 PM
  Please respond to
  ADSM-L






I am wanting to set up new Policy Domains, with respective Management
classes, and respective Backup and Archive Copy Groups.  I want my
Archives
to go straight to offsite and not be onsite.  Anybody got ideas and how to
do it?

Thank You,
Bill Rosette
Data Center/IS/Papa Johns International
WWJD





--

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

Re: Policy Domain Question

[Stapleton, Mark]

From: William Rosette [mailto:[EMAIL PROTECTED] 
> I am wanting to set up new Policy Domains, with respective Management
> classes, and respective Backup and Archive Copy Groups.  I 
> want my Archives
> to go straight to offsite and not be onsite.  Anybody got 
> ideas and how to do it?

You'll have to set up a primary tape pool that gets vaulted. There isn't
any way to send data from the client directly to a copy pool tape
volumes.
 
--
Mark Stapleton ([EMAIL PROTECTED])
Berbee Information Networks
Office 262.521.5627

Re: Policy Domain Question

[Mark Ferraretto]

Bill,

I wanted exactly the same thing.  Unfortunately, implementing it is quite difficult in 
TSM.

* You need to archive to a primary storage pool
* then you need to checkout the tapes from that storage pool manually and send them 
offsite.  You can't use DRM to keep track of the volumes as DRM only works for copy 
pools and db backups
* You need to manually work out which tapes are required for reclamation (see the 
query below) and manually request those tapes back onsite for reclamation as necessary

In the end I gave up on this and I did the following:
* I created a second TSM instance on our TSM server for managing archive data only
* I use virtual volumes so the 2nd instance stores its data on the main instance which 
has sole control of the tape library
* Instead of archiving data, I use incremental backups on the 2nd instance.  I use a 
different management class on the 2nd instance (1 year instead of 1 month)
* because I'm using incremental backups to perform 'archiving' only about 20% of data 
changes each month and so the 2nd instance uses much less space that doing a regular 
monthly archive
* because the space used is so much less (over a year it's about 400% less) I've 
created a copy pool for my archive data as well.  I can afford to 'waste' the extra 
tapes and I get quite a few advantages namely:
* I can manage the 2nd instance copy pool the same way as I manage the main copy pool
* DRM takes care of onsite and offsite tapes
* You can do offsite reclamation - just like a regular copy pool
* The operators don't need to learn any new procedures for managing the archive tapes
* The archive data is always onsite which makes for easier restoring

Finally, here's the query I mentioned above:

tsm: SM040>q scr q_reclaim_preview f=r
/* Script comment */
/* List volumes in stgpool $1 to be reclaimed  */
/* if threshold was set to $2% */
/* */
/* Script Name: Q_RECLAIM_PREVIEW  */
/* Author:  Mark Ferraretto*/
/* Parameter:   storage_pool, threshold*/
/* Example: run Q_RECLAIM_PREVIEW C3 50*/
/* */
select -
VOLUME_NAME as "$1 pool at $2% reclamation" -
from VOLUMES -
where STGPOOL_NAME = upper('$1') -
and PCT_RECLAIM >= $2 -
order by VOLUME_NAME


--
Mark Ferraretto
Unix Systems Administrator
Deutsche Bank Hong Kong
w: +852 2203 6362m: +852 9558 8032f: +852 2203 6971
[EMAIL PROTECTED]



  [EMAIL PROTECTED]
  JOHNS.COMTo:   [EMAIL PROTECTED]
  Sent by:         cc:
  [EMAIL PROTECTED]Subject:  Re: Policy Domain Question
  EDU


  08/06/03 10:13 PM
  Please respond to
  ADSM-L






I am wanting to set up new Policy Domains, with respective Management
classes, and respective Backup and Archive Copy Groups.  I want my Archives
to go straight to offsite and not be onsite.  Anybody got ideas and how to
do it?

Thank You,
Bill Rosette
Data Center/IS/Papa Johns International
WWJD





--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.

Re: Policy Domain Question

[William Rosette]

I am wanting to set up new Policy Domains, with respective Management
classes, and respective Backup and Archive Copy Groups.  I want my Archives
to go straight to offsite and not be onsite.  Anybody got ideas and how to
do it?

Thank You,
Bill Rosette
Data Center/IS/Papa Johns International
WWJD

Re: policy domain suggestion

[Andrew Raibeck]

Based on your copygroup settings:

> The backup of the Friday has to be retained for 4 weeks.

For the above case, your copygroup settings guarantee that you will be 
able to recover any backup version up to 33 days ago, which exceeds the 4 
week (28 day) requirement.

> The backup of the first of every month has to be retained for 13 months.

The above case is more of an archive requirement than backup requirement. 
You could create backupsets on the first of every month, which will 
include all the active versions as of that day. Alternatively, you could 
consider scheduling an ARCHIVE command to run on the first of every month 
to archive the required data and retain it for 400 days (a nice, even 
number that comes out to almost exactly 13 months).

Another possibility is to create a schedule that runs an incremental 
backup on the first of every month, define a second node for the machine, 
and associate that new node with the monthly schedule. You will also need 
to create a management class and copy group for this new node that has 
version and retention settings to accommodate your 13 month requirements. 
On the client machine, create a new options file with the second node name 
in it and an INCLUDE statement to bind the files to the new management 
class, and a second scheduler for the new node.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: [EMAIL PROTECTED]

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




"[EMAIL PROTECTED]" 
02/01/2002 06:35
Please respond to "ADSM: Dist Stor Manager"

 
To: [EMAIL PROTECTED]
cc: 
Subject:policy domain suggestion

 

A client asked me to create the following policy domain:
The incremental backup of every night has the copy group
*) Versions Data Exists = nolimit
*) Versions Data Deleted = nolimit
*) Retain Extra Version = 33
*) Retain Only Version = 33

The backup of the Friday has to be retained for 4 weeks.
The backup of the first of every month has to be retaind for 13 months.

Is the policy domain achievable?
Do you have any suggestion to realize the policy domain?

Every suggestion is welcome.
Every review is much more welcome.

Paolo Nasca
Cleis Technolgy srl
Via E. Raggio, 4
16124 Genova ? Italy
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Genoa switchboard: +39 010 24858.11
Milan switchboard: +39 02 66740.11