Part of the issue is with the question: in general, there is no such thing as "retention for node xxx". With TSM, retention is handled at the file/object level, not at the node level. For example, you can have two files on your system, c:\file1 and d:\file2. Using include/exclude statements, you can bind c:\file1 to one management class, and d:\file2 to another management class. The management classes can have backup copy groups with differing retention and version settings.
Of course, if you have only *one* management class, then this is the trivial case where all files have the same retention settings. One way to convey the data would be to provide him with the management class names and their respective backup copy group's VEREXISTS, VERDELETED, RETEXTRA, and RETONLY settings. Then get the include/exclude settings for the node, and use that info to summarize which file/file patterns are excluded, which are backed up to specific management classes, and the rest get the default management class. So you could generate a table with columns like "file or file pattern", "excluded (y/n)", "management class name", "versions if file exists", "versions if file is deleted", "retain extra versions", "retain only version". If you need specifics for each and every file, then go to the node and do the following: 1. Issue "dsmc query filespace" to list the file spaces. 2. For each file space, issue "dsmc query backup <filespace>\ -subdir=yes" where <filespace> is the file space name. For example: dsmc query backup c:\ -subdir=yes dsmc query backup \\storman\myshare\ -subdir=yes I suggest redirecting the output of each command to a separate file. For each backed up file, the output will show the management class name, which can then be mapped to the corresponding copy group attributes. Then provide the results of the queries to management, along with the management class/copy group settings above. You could also do SELECT * FROM BACKUPS WHERE NODE_NAME='YOUR_NODE_NAME', but as others have said, that is a very long-running command, and not something you'd likely want to do on a regular basis. Lastly, it should be noted that the latest backup version is always kept, regardless of age, unless you exclude the file from backup, delete it from the client file system, or issue the "dsmc delete backup" command for that file. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] IBM Tivoli Storage Manager support web page: http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. "ADSM: Dist Stor Manager" <[email protected]> wrote on 01/24/2007 06:53:08 AM: > 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.
