There in lies my confusion! You guys got me on the right track. Apparently our TSM was setup so that each node uses a single mgmt class. Some do not have include statements at all and thus use the default for the domain. We have some boxes however that have included a specific mgmt class with *.* after it. So it looks like we're not setup like you guys, or possibly how we should be. I understand now where you guys are coming from completely... As I've said in the past, this is a system I inherited and some of the configuration has had me confused.
Looks like I will have to visit each node and check their respective include/exclude statements to see what they have. Once again, this is the best resource for TSM I have and I thank you all for some great information. DO you guys think we should start restructuring our environment to utilize different mgmt classes for a single node? What's the best way to start a project like that and are there any good pointers? Thanks again!! -Dug Resident TSM Newbie On 1/24/07, David McClelland <[EMAIL PROTECTED]> wrote:
Doug, But with TSM retention just isn't done on a node by node basis - on any given node, you can have *some* files backed up to a management class which keeps inactive files for 30 days, yet *another* set of files on that same node bound to a management class keeping files for 10 years. I've worked with clients where there have been up to a dozen different management classes managing a single node's data, covering not only retention for regulatory purposes but serialization (handling of open logfiles etc). To confuse your management even further, particularly if they're used to other backup methodologies/products, tell them that files that get backed up and don't change will never get backed up again and will *never* expire ;o) Let's flip the coin the other way up - how is your client in question configured? Are there any includes in the include/exclude list which direct objects to specific management classes or does it all go to the default management class? I'd say that was a good starting point (unless you've got TDP Oracle on there were you wouldn't necessarily control the expiration of objects - RMAN would) - if everything is bound to the default management class, then your retention is as per your default management classes retentions etc (for backups anyhow - I don't know if you have archives present for this client as well). HTH, David McClelland London, UK -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Doug Fox Sent: 24 January 2007 13:53 To: [email protected] Subject: Re: [ADSM-L] Query MGMT Class Membership? So if I want to report to my manager how long the retention is on XXX node within a Domain that has multiple mgmt classes how would I give him the correct information? We're in the process of documenting our DR practices and this is a piece of information that has to be included. They want to know the retention on files and servers of everything. More or less to CYA :) So are you saying there's no way to find out what the retention is on a node? That doesn't seem right... I guess I'm lost. Your help is greatly appreciated and hopefully you guys can set me straight here. -Dug On 1/24/07, Markus Engelhard <[EMAIL PROTECTED]> wrote: > > Hi Doug, > > querying the backups- and archives table has been discussed to some > extend in this forum. It is certainly NOT a query I would issue as a > daily report, as it is VERY time-consuming and puts some strain on > your TSM database; be ready to wait quite a while for the output; > DON´T issue it if your db is very big or very full: > > select distinct class_name from backups where > node_name='YOUR_NODENAME_IN_UPPER_CASE' > > The only time I would want to issue this command is before moving the > client to another server, to double check if all management classes > needed are in place. The same applies for the archives table. Take > great care not to omit the where clause, as this could have heavy > impact on the TSM-server. > > > Take care, > Markus > > > -- > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den > Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren > sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. > > Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko > der Verbreitung virenbefallener Software oder E-Mails zu minimieren, > dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge > an dieser Nachricht durchzuführen. Wir schließen außer für den Fall > von Vorsatz oder grober Fahrlässigkeit die Haftung für jeglichen > Verlust oder Schäden durch virenbefallene Software oder E-Mails aus. > > Jede von der Bank versendete E-Mail ist sorgfältig erstellt worden, > dennoch schließen wir die rechtliche Verbindlichkeit aus; sie kann > nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Bank > ausgelegt werden. > ______________________________________________________________________ > > 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 unauthorised copying, disclosure or distribution of the material > in this e-mail or of parts hereof is strictly forbidden. > > We have taken precautions to minimize the risk of transmitting > software viruses but nevertheless advise you to carry out your own > virus checks on any attachment of this message. We accept no liability > for loss or damage caused by software viruses except in case of gross > negligence or willful behaviour. > > Any e-mail messages from the Bank are sent in good faith, but shall > not be binding or construed as constituting any kind of obligation on > the part of the Bank. This email was sent to you by Reuters, the global news and information company. To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
