Re: Enable verbose time/date logging on interactive dsmc commands?
On Oct 9, 2008, at 4:52 PM, Clark, Robert A wrote: We're working on changing some backups from command schedules to incrementals with pre/post commands. Between now and when we complete the work, is there any way to enable verbose time/date stamps per line in the interactive backup output? Robert - As noted in ADSM QuickFacts, there is no published way of achieving that, unfortunately. Richard Sims
AIX backup failing
Has anyone seen the following. I have a few servers that report this every couple of nights, it is not always the same mount point that fails, but always a TCP/IP connection failure: 10/08/08 20:10:44 Retry # 1 Normal File--> 12,288 /etc/objrepos/CuAt Changed 10/08/08 20:10:47 ANS1228E Sending of object '/home' failed 10/08/08 20:10:47 ANS1017E Session rejected: TCP/IP connection failure 10/08/08 20:10:47 ANS1809W A session with the TSM server has been disconnected . An attempt will be made to reestablish the connection. 10/08/08 20:11:02 ... successful 10/08/08 20:11:30 Retry # 2 Directory--> 4,096 / [Sent] 10/08/08 20:11:30 Retry # 2 Normal File--> 102 /.Xauthority [Sent] Here are the version I am running IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface Client Version 5, Release 5, Level 0.6 Client date/time: 10/10/08 09:45:47 (c) Copyright by IBM Corporation and other(s) 1990, 2008. All Rights Reserved. Node Name: XXX Session established with server TSM8: AIX-RS/6000 Server Version 5, Release 5, Level 0.3 Server date/time: 10/10/08 09:46:42 Last access: 10/09/08 20:07:20 bash-3.2# oslevel -s 5300-07-03-0811
Re: Find clients which are sending large files.
Eric - File size (actually, Aggregate size) is in the Contents table - which is the worst of all TSM database tables to have to trawl. If you must, do so with as fully qualified search as possible, to minimize sequential traversals. An alternative would be to inspect tapes recently used by the suspect client, using the Query CONtent command, which is optimized for fast info retrieval. From the TSM accounting records, you may be able to discern such clients by the number of backup objects being comparatively few relative to the amount of backup data. Richard Sims
Re: Find clients which are sending large files.
Hi Richard! Thanks you very much for your help! Indeed it's the worst of all. I just did a select * from contents where volume_name='just on of my volumes' on my very small test environment. Output is returned quite fast, but as soon as you hit c to cancel the output, you loose the cursor for several minutes. My guess is that this table has no index... The output of the Query CONtent command is useless for me, because the file size is not listed. Bummer. Thanks anyway!!! Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: vrijdag 10 oktober 2008 14:58 To: ADSM-L@VM.MARIST.EDU Subject: Re: Find clients which are sending large files. Eric - File size (actually, Aggregate size) is in the Contents table - which is the worst of all TSM database tables to have to trawl. If you must, do so with as fully qualified search as possible, to minimize sequential traversals. An alternative would be to inspect tapes recently used by the suspect client, using the Query CONtent command, which is optimized for fast info retrieval. From the TSM accounting records, you may be able to discern such clients by the number of backup objects being comparatively few relative to the amount of backup data. Richard Sims ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **
Re: Find clients which are sending large files.
On Oct 10, 2008, at 9:51 AM, Loon, EJ van - SPLXM wrote: The output of the Query CONtent command is useless for me, because the file size is not listed. Bummer. When using TSM commands, always be mindful of the availability of Format=Detailed with many commands, to provide more extensive info where needed. :-) Richard
Re: AIX backup failing
I see no failure. What I see is that your client is taking quite long to find a changed file, so it needs to reconnect the data session (usually a different session from the 'control session that is used to download the list of active files from the server). You could increase the idletimeout setting on your server, but I see no harm in this behaviour. On 10 okt 2008, at 14:51, Jeff Brunt wrote: Has anyone seen the following. I have a few servers that report this every couple of nights, it is not always the same mount point that fails, but always a TCP/IP connection failure: 10/08/08 20:10:44 Retry # 1 Normal File--> 12,288 /etc/objrepos/CuAt Changed 10/08/08 20:10:47 ANS1228E Sending of object '/home' failed 10/08/08 20:10:47 ANS1017E Session rejected: TCP/IP connection failure 10/08/08 20:10:47 ANS1809W A session with the TSM server has been disconnected . An attempt will be made to reestablish the connection. 10/08/08 20:11:02 ... successful 10/08/08 20:11:30 Retry # 2 Directory--> 4,096 / [Sent] 10/08/08 20:11:30 Retry # 2 Normal File--> 102 /.Xauthority [Sent] Here are the version I am running IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface Client Version 5, Release 5, Level 0.6 Client date/time: 10/10/08 09:45:47 (c) Copyright by IBM Corporation and other(s) 1990, 2008. All Rights Reserved. Node Name: XXX Session established with server TSM8: AIX-RS/6000 Server Version 5, Release 5, Level 0.3 Server date/time: 10/10/08 09:46:42 Last access: 10/09/08 20:07:20 bash-3.2# oslevel -s 5300-07-03-0811 -- Remco Post [EMAIL PROTECTED] +31 6 24821 622
Find clients which are sending large files.
Hi *SM-ers! We are using a EMC Disk Library (virtualizing a LTO tape library) for quite some time now. Since tape mount and data seek times are about two seconds on such a device, we have collocation tuned off for the storage pools. Every now and then customers call me because they started a restore, which seems to hang. It's always the same cause: I do a q sess and see that their session is in the MediaW status. The q sess f=d shows which tape the restore is waiting for and in all cases this tape is in use for a reclamation or a backup stgpool. This process is canceled by TSM, but it finishes the file it is working on. In some cases this is a very large file and thus the restore has to wait for a (very) long time. I guess this is the way TSM works, although I think TSM should cancel any process immediately for a restore and retry the reclaim or backup for the specific file at a later time. Anyway, I would like to know which client in my shop is creating backup files of 120 Gb. Does anybody know where the client backup file size is kept in the TSM database? I'm unable to find it... Thank you very much for your help in advance! Kindest regards, Eric van Loon KLM Royal Dutch Airlines ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **
Re: Find clients which are sending large files.
Hi Richard! Oeps... Missed that option... Thanks!! Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: vrijdag 10 oktober 2008 16:00 To: ADSM-L@VM.MARIST.EDU Subject: Re: Find clients which are sending large files. On Oct 10, 2008, at 9:51 AM, Loon, EJ van - SPLXM wrote: > The output of the Query CONtent command is useless for me, because the > file size is not listed. Bummer. When using TSM commands, always be mindful of the availability of Format=Detailed with many commands, to provide more extensive info where needed. :-) Richard ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **
Re: ANS5013E Not enough memory for backup operation
Zoltan - This, of course, is the historic "Many small files" challenge. Recommendations on it are summarized in ADSM QuickFacts, based upon our communal pursuit of it in our shops. You've provided no information about the client system itself, where memory and swap space contribute to the issue, but the larger factors being the Windows level and the bitmode of the OS and hardware. A system like that cries out for 64-bit, latest OS, and lots of memory. Richard Sims
Re: Find clients which are sending large files.
Hi Eric, we use the following steps to identify large files in last nights backup: Step 1 - Query the volumes used in last nights backup select volume_name as Volume, stgpool_name as Stgpool, date(last_write_date) as "Date", - time(last_write_date) as "Time" from volumes where - last_write_date > timestamp(date(current_date-1 day),'19:00:00') and - last_write_date < timestamp(date(current_date),'10:00:00') and - stgpool_name in (select stgpool_name from stgpools where pooltype='PRIMARY') Step 2 - List all files on volumes returned by Step 1 > x Bytes select node_name as Node, - filespace_name as Filespace,- file_name as Filename,- file_size as Size - from contents - where volume_name='$1' and - file_size>$2 Or we list the number of files and summarized size per node of a volume. So you see nodes with a small number of files but lots of gigas backed up: select node_name as Node, - filespace_name as Filespace,- count(file_name) as Files,- sum(file_size) as Size - from contents - where volume_name='$1' - group by node_name, filespace_name - order by files desc HTH Thomas Rupp Vorarlberger Illwerke Aktiengesellschaft ein Unternehmen von illwerke vkw Rechtsform: Aktiengesellschaft, Sitz: Bregenz, Firmenbuchnummer: FN 59202m Firmenbuchgericht: LG Feldkirch, DVR 0008753, UID-Nr.: ATU 36737402 Vorarlberger Kraftwerke Aktiengesellschaft ein Unternehmen von illwerke vkw Rechtsform: Aktiengesellschaft, Sitz: Bregenz, Firmenbuchnummer: FN58920y Firmenbuchgericht: LG Feldkirch, DVR 0027961, UID-Nr.: ATU 36737304
Fw: Find clients which are sending large files.
If you know that a suspect file is being moved (reclaim, not backup stgpool), use this command with the volser of the source tape: query content VOLSER count=1 f=d That will show you the node, file name, size, and a few other details on the first file on the volume, which is the one being moved. For with copied data (backup stgpool), use the target volser, and this command JUST after the file finishes: query content VOLSER count=-10 f=d That will list off the last 10 files on the volume. The file in question may have already gotten out of the list of 10, so you can go higher, but that's getting to be a lot of output. And you can tell the size of the file being moved from the "query process" output. Nick Cassimatis - Forwarded by Nicholas Cassimatis/Raleigh/IBM. on 10/10/2008 01:38 PM - "ADSM: Dist Stor Manager" wrote on 10/10/2008 08:58:18 AM: > [image removed] > > Re: Find clients which are sending large files. > > Richard Sims > > to: > > ADSM-L > > 10/10/2008 09:06 AM > > Sent by: > > "ADSM: Dist Stor Manager" > > Please respond to "ADSM: Dist Stor Manager". > > Eric - > > File size (actually, Aggregate size) is in the Contents table - which > is the worst of all TSM database tables to have to trawl. If you > must, do so with as fully qualified search as possible, to minimize > sequential traversals. An alternative would be to inspect tapes > recently used by the suspect client, using the Query CONtent command, > which is optimized for fast info retrieval. From the TSM accounting > records, you may be able to discern such clients by the number of > backup objects being comparatively few relative to the amount of > backup data. > > Richard Sims
NDMP (Not exactly a TSM question)
I am setting up NDMP backup of a Celerra and I am having trouble getting the Celerra to see the tape drives. Has anyone made this work with the equipment listed? Celerra - NS80 Tape Library - IBM3494 Tape Drive - 3592 TSM - 5.4.2.0 Andy Huebner This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
Re: NDMP (Not exactly a TSM question)
On Oct 10, 2008, at 22:02 , Huebner,Andy,FORT WORTH,IT wrote: I am setting up NDMP backup of a Celerra and I am having trouble getting the Celerra to see the tape drives. Has anyone made this work with the equipment listed? I've had some experience with a nsx and T10K drives, just plugging the drives into the aux port (ok zoning the drive and the nsx together), enabling the port and rebooting the nsx did it iirc. Celerra - NS80 Tape Library - IBM3494 Tape Drive - 3592 TSM - 5.4.2.0 Andy Huebner This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you. -- Met vriendelijke groeten, Remco Post [EMAIL PROTECTED] +31 6 248 21 622
