SV: Sloooow Novell Backups
smime.p7m Description: application/pkcs7-mime
Re: Can I insall a TSM client on a machine with OS Unicos ??
Yes, but there are many unsupported clients which work fine. And for many not-so-popular OSes the client is not available for the current version. In fact TSM is not very multi-platform, ADSM was. TSM can just use ADSM clients. My opinion, nobody else's. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Re: Can I insall a TSM client on a machine with OS Unicos ?? If the operating system is not listed at the following URL, the operating system is not supported. http://www.tivoli.com/products/index/storage-mgr-enterprise/platforms.html Sias --- rachida elouaraini [EMAIL PROTECTED] wrote: Hi, it's an urgent question, thank you very much for giving me an answer. I would like to know if I can Install a TSM client on a machine with OS Unicos. I know that TSM could be installed on several machines, but CRAY (OS Unicos) I don't know. Thank you __ Bonte aux lettres - Caramail - http://www.caramail.com __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Re: Tuning TSM
Just a point TCPWindowsize parameter is measured in kilobytes not bytes. And according to Administrator's reference it must be between 0 and 2048. If not in range on client complains with ANS1036S for invalid value. On server values out of range mean 0, i.e. OS default. However this are side remarks. The main question is why client is idling. Have you monitored the node during to disk and to tape operation? Is migration starting during backup? Are you using DIRMC. You wrote client compression - what is the processor usage (user)? What is the disk load - is the processor I/O wait high? Is the paging space used - check with svmon -P. You should get much better results. For example recently we've achieved 500 GB in 3h10m - fairly good. It was similar to your config - AIX nodeserver, client compression, disk pool, GB ether. Ether was driven 10-25 MB/s depending on achieved compression. The bottleneck was EMC Symmetrix the node was reading from but another company was dealing with it and we were unable to get more than 60-70 MB/s read. Resourceutilization was set to 10. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Re: Tuning TSM Zlatko: Here are the answers: Have you tested what is the performance of FAStT 500 disks? Those were mid-class disk storage originally designed for PC servers market and later modified to be compatible with rs6k/pSeries. This is completely true: IBM installed FastT500 instead of SSA disks (they said they were faster). We have done a re-cabling of these devices, and got a better IO balance on the controllers. Try some simple tests on the TSM server when quiet: - 'date; dd if=/dev/zero of=/fastt_fs/test_file bs=262144 count=16384; date' to test write speed. Use large file to simulate TSM heavy load. - 'date; dd if=/fastt_fs/test_file of=/dev/null' to check read speed In a test like you proposed, FastT500 brings a peformance of about 60MB/sec Also check your Gb Ether - are you using Jumbo frames, have you enabled in AIX 'no -o rfc1323=1', what are sendreceive bufsizes, what is TCPWindowsize of TSM serverclient. Have you measured LANdisk load during backup? Yes, we're using this parameters: from no tcp_sendspace = 1048576 tcp_recvspace = 1048576 udp_sendspace = 64000 udp_recvspace = 64000 rfc1323 = 1 from TSM server TCPWindowsize 1310720 What I've observed is that during a client backup session, TSM seems to be idled for a long time (and the server machine has not constraint problems for memory or I/O) I can send other data. Thank you all. Ignacio Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Tuning TSM Hi: I'm managing a pretty small TSM installation with 4 RS/6K machines (2 6M1 and 2 6H1) running AIX 4.3.3 (ML9). TSM software consists of the server (running in a 6M1 - 7Gb RAM), and the clients running in the same machine and on the others. I´ve got the following situation: - the total of data backed up is about 200Gb's, - 4 servers are connected using gigabit ethernet links (and have 6Gb RAM and 7Gb RAM each model 6H1 and 6M1 respectively) - TSM uses a storage pool of 240Gb on FastT500 disks (those are connected by FC channels) - TSM uses a 3581 library (LTO) with 1 drive, The fact is (for the same set of information): When I do an archive backup operation with TSM, the time elapsed rounds 5 hours (TSM writes right to the tape). When I do an incremental backup operation, TSM uses about 6:30hs for it (TSM writes to storage pool). I'm looking for a rational approach to solve this problem: isn't it more fast writing to storage pool (disk) that to tape? Anyone had the same performance problem? Is it really a performance problem? I would like some commentaries about this, I can provide some info about the configuration of TSM and the AIX servers. Regards Ignacio
Antw: Re: TDP 2.2 for Exchange remote control
Thanks for information. Have a nice weekend! Wolfgang There is no remote client like the TSM web client for the TDPs. We know about the requirement and it is logged in our requirements database. It is on our list of things to do. Until then, you will need to use remote utilities like Terminal Services, PCAnywhere, ReachOut, VNC, etc. Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] - Leave everything a little better than you found it. - Smile a lot: it costs nothing and is beyond price.
tdpoconf error ANU2534E
Hi List, I`ve been trying to install TDP for Oracle for AIX 2.2.1 in a AIX 5.1 box, but I can not make the utility TDPOCONF work, it seems that my tdpo.opt file is not right but I cant not find where the problem is, when I issue and tdpoconf showenv or try to set the password I get an ANU 2534E Option file error the file tdpoerror.log is not very helpful, can somebody send me a working tdpo.opt/dsm.opt/dsm.sys set so i can use them as example? thanks for your help. Luis _ Join the world s largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: Archive failures due to disk storage pool filling up...
You can setup backupcopy group to point the disk pool but archive group to send direct to tape. Isn't this an option? Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Re: Archive failures due to disk storage pool filling up... Thanks for the confirmation on the termination of the archive...drat..I was hoping it wasn't so. The pool was empty when we started. Simply not enough room. I will have to expand and/or have the user do the archive in pieces.. We don't do a lot of archiving. This is why the pool is so small. Don't have the DASD to just sit there and not be used but once in a while... David Longo [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 05/16/2002 02:07 PM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: Archive failures due to disk storage pool filling up... Your step number 2 is not exactly true, it won't wait for migration to empty space. If you are setup for client to go directly to tape, it will do that IF tape mounts etc are available. And your last question is correct - it is terminated. Simplest solution is to increase diskpool or if that's not an option, adjust schedules to update migration percentages so pool will be emptier when this clients schedule comes around. (I've done a good bit of this tuning.) David Longo [EMAIL PROTECTED] 05/16/02 01:20PM Environment: TSM OS/390 server - V4.1.4 Linux Client - V4.1.4 Been trying to archive a client node. The archive disk pool is not as large as the amount of data to be archived. Received a failure on the archive. This is one of the messages: 05/16/2002 10:43:20 ANS1228E Sending of object '/usr/local/blackboard/docs/courses/1/INFO-360-002-2002Spring/content/_65742_1/360web_ontime2.zip' failed I looked into the server log and found the related message: 05/16/2002 10:43:01 ANR0534W Transaction failed for session 62 for node ATHENA.VCU.EDU (Linux86) - size estimate exceeded and server is unable to obtain additional space in storage pool SPARCHIVE. Yes, I looked up the ANR0534W message. It talks about both a possible COMPRESSION issue as well as insufficient space in the storage pool. Yep, the compression for this session was -5%. So..Big deal.I would not think this would/should cause a permanent failure and lack of archiving of the file in question. Yes, I realize the storagepool filled up. My understand has always been, and please correct me if I am wrong, that is a storagepool fills up/reaches the HI value, 2 things occur: 1. Migration is kicked off, moving data to the defined NEXTPOOL (which is did) 2. The CLIENT is told to Whoa..Stop Sending Data..Hang on while I move stuff out of the storagepool to make more roomOK Client, you can send me more data, now.. Am I way off on this or is this some sort of problem ? Also, the book says : System Action: The specified session is ended and server operation continues. Does this mean the archive was killed and did not finish successfully ? Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 MMS health-first.org made the following annotations on 05/16/02 14:22:26 -- This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ==
Reclaim_ANR1092W
Hi all Reclamation for a Volume does not work, ANR1092W will be showed. I did a audit vol yesterday. Today the Volume is not longer under TSM Control ! Do i realy need to call the service representative, like explained in the message 1092? How about to clean up the table entry in the TSM DB? Env: TSM Server 4.2.1.9 on OS/390 2.9 What i have done: 16.05.2002 11:58:46 ANR5216I CARTRIDGE L60099 is expected to be mounted (R/O). 16.05.2002 11:58:46 ANR1142I Moving data for collocation cluster 1 of 2 on volume L60099. 16.05.2002 12:00:27 ANR1092W Space reclamation terminated for volume L60099 - internal server error detected. 16.05.2002 12:06:18 ANR2017I Administrator P001PSC issued command: AUDIT VOLUME l60099 fix=yes 16.05.2002 12:06:35 ANR1199I Removable volume L60099 is required for audit process. 16.05.2002 12:06:36 ANR5216I CARTRIDGE L60099 is expected to be mounted (R/O). 16.05.2002 12:06:36 ANR2312I Audit Volume (Repair) process started for volume L60099 (process ID 417). 16.05.2002 12:07:36 ANR4132I Audit volume process ended for volume L60099; 525 files inspected, 0 damaged files deleted, 0 damaged files marked as damaged, 0 objects updated. 16.05.2002 12:08:19 ANR5217I Dismounting volume L60099 - 1 minute mount retention expired. 16.05.2002 12:08:19 ANR5209I Dismounting volume L60099 (read-only access). 17.05.2002 04:00:34 ANR1040I Space reclamation started for volume L60099, storage pool BACK_LO_TAPE (process number 429). 17.05.2002 04:00:35 ANR1044I Removable volume L60099 is required for space reclamation. 17.05.2002 04:00:35 ANR5216I CARTRIDGE L60099 is expected to be mounted (R/O). 17.05.2002 04:00:35 ANR1142I Moving data for collocation cluster 1 of 2 on volume L60099. 17.05.2002 04:04:24 ANR1092W Space reclamation terminated for volume L60099 - internal server error detected. 17.05.2002 09:15:53 ANR2017I Administrator P001PSC issued command: QUERY CONTENT l60099 17.05.2002 09:15:53 ANR2401E QUERY CONTENT: Volume l60099 is not defined in a storage pool. TIA Joachim Joachim Paul Schaub Abraxas Informatik AG Beckenhofstrasse 23 CH-8090 Zürich Schweiz / Switzerland Telefon: +41 (01) 259 34 41 Telefax: +41 (01) 259 42 82 E-Mail: mailto:[EMAIL PROTECTED] Internet: http://www.abraxas.ch
Re: Sloooow Novell Backups
Stephen, You may add these parameter these will improve speed The will increase the comm buffers TXNBYTELIMIT25600 TCPWINDOWSIZE63 -Original Message- From: Firmes, Stephen [mailto:[EMAIL PROTECTED]] Sent: vrijdag 17 mei 2002 0:05 To: [EMAIL PROTECTED] Subject: Slw Novell Backups TSM server 4.2.1.9 on Solaris 8 TSM 5.1 client on Novell 5.1 Backing up a volume with 500,000 files approx 1k each. The files are being transfered to the tsm server approx 1/sec. This is just a little too sloow. When using ftp to transfer these same files, either by getting/putting the transfers fly. This is leading me to believe that the issue is with the TSM server/client settings. Does anybody have any ideas on any settings in the dsm.opt that could be changed to enhance performance? Also I want to bind all objects in two of the volumes to a specific mgt class. All that is being bound to it is the dirs. Long day. What am I doing wrong??? Here is the dsm.opt *** COMMMETHODTCPip TCPSERVERADDRESS catamount TCPPORT 1500 tcpclientaddressxxx.yy.z.zzz NODENAME novell_test INCLUDE sys:* tape9940 INCLUDE extravol1:* tape9940 EXCLUDE sys:\system\secaudit.log EXCLUDE sys:\system\events.log EXCLUDE sys:\system\system.log EXCLUDE sys:\system\btrieve.trn EXCLUDE SYS:\system\tsa\err$hst.* EXCLUDE sys:\system\tsa\err$log.* EXCLUDE sys:\system\tsa\skip$log.* EXCLUDE sys:\system\tsa\tsa$temp.* EXCLUDE sys:\system\sys$log.err EXCLUDE sys:\_swap_.mem EXCLUDE sys:\vol$log.err EXCLUDE sys:\tts$log.err NWPWFILE YES passwordaccess generate managedservices schedule webclient Thanks. Stephen Firmes TSM Engineer Tivoli Certified TSM Consultant StorageNetworks, Inc Work: 781-622-6287 http://www.storagenetworks.com
Re: SV: Sloooow Novell Backups
Hi: I would like to know where to get more info about that parameters (txnbytelimit/txngroupmax/tcpbufsize/etc...) and tuning them (of course). Thanks Ignacio -Mensaje original- De: Flemming Hougaard [mailto:[EMAIL PROTECTED]] Enviado el: Viernes, 17 de Mayo de 2002 07:59 Para: [EMAIL PROTECTED] Asunto: SV: Slw Novell Backups Hi Stephen I have some general experiences with the TSM client, and here goes: - Never use compress always! - The INCLUDE SYS:* wont work... you have to use SYS:...\* - I know it's supposed to be the same... but it isn't! - Tune on the following parameters: #TXNBYTELIMIT #TXNGROUPMAX #TCPBUFFSIZE #TCPWINDOWSIZE - Set MEMORYEFFICIENTBACKUP NO in the DSM.OPT file (should be standard, but...) Regards Flemming Hougaard Certified Novell Engineer -Oprindelig meddelelse- Fra: Firmes, Stephen [mailto:[EMAIL PROTECTED]] Sendt: 17. maj 2002 00:03 Til: [EMAIL PROTECTED] Emne: Slw Novell Backups TSM server 4.2.1.9 on Solaris 8 TSM 5.1 client on Novell 5.1 Backing up a volume with 500,000 files approx 1k each. The files are being transfered to the tsm server approx 1/sec. This is just a little too sloow. When using ftp to transfer these same files, either by getting/putting the transfers fly. This is leading me to believe that the issue is with the TSM server/client settings. Does anybody have any ideas on any settings in the dsm.opt that could be changed to enhance performance? Also I want to bind all objects in two of the volumes to a specific mgt class. All that is being bound to it is the dirs. Long day. What am I doing wrong??? Here is the dsm.opt *** COMMMETHODTCPip TCPSERVERADDRESS catamount TCPPORT 1500 tcpclientaddressxxx.yy.z.zzz NODENAME novell_test INCLUDE sys:* tape9940 INCLUDE extravol1:* tape9940 EXCLUDE sys:\system\secaudit.log EXCLUDE sys:\system\events.log EXCLUDE sys:\system\system.log EXCLUDE sys:\system\btrieve.trn EXCLUDE SYS:\system\tsa\err$hst.* EXCLUDE sys:\system\tsa\err$log.* EXCLUDE sys:\system\tsa\skip$log.* EXCLUDE sys:\system\tsa\tsa$temp.* EXCLUDE sys:\system\sys$log.err EXCLUDE sys:\_swap_.mem EXCLUDE sys:\vol$log.err EXCLUDE sys:\tts$log.err NWPWFILE YES passwordaccess generate managedservices schedule webclient Thanks. Stephen Firmes TSM Engineer Tivoli Certified TSM Consultant StorageNetworks, Inc Work: 781-622-6287 http://www.storagenetworks.com
TSM Cient 4.2.1.20 + NT4 Cluster
Hello, i'am using TSM client version 4.2.1.20 for several NT4 SP6a and W2K clusterd environments. There is no problem with the functionality for backup/archive etc. But during the scheduled backup for the disks of a cluster group resource i receive the following message within the according dsmerror.log file. 05/17/2002 00:52:32 GetFileShareInfo(): connectRegistry() for machine SERVERName failed, rc=5. Registry will not be backed up. Error is ignored. I'am receiving this message only in the NT4 clustered environments, and i can't find this message on any of our W2K clusters using version 4.2.1.20. Does someone know what is causing this message? Or is this a message like sessOpen: error 137 from signon authentication. which can be ignored according to the readme ?? I'am using the following dsm.opt settings: PASSWORDACCESS GENERATE TCPSERVERADDRESS TSMServer-Name DOMAIN Q: NODENAME Virtual Node-Name for Cluster Group Resource CLUSTERNODE YES ERRORLOGNAME Q:\ADSM\dsmerror.log SCHEDLOGNAME Q:\ADSM\dsmsched.log SCHEDLOGRETENTION 10 TCPBUFFSIZE 32 TCPWINDOWSIZE 63 TXNBYTELIMIT 25600 TCPNODELAY Y BACKUPREGISTRY NO RESOURCEUTILIZATION 6 COMPRESSION OFF LANGUAGE AMENG Mit freundlichen Grüßen / Best Regards Uwe Schreiber
a serious problem with HSM
Hi all; It's a question for people who know the products : TSM/HSM and GPFS (Global Parallel File System). It's a problem with HSM : Tivoli Space Manager. When the product HSM is associated with GPFS , it causes a great increase of memory utilisation on the machine TSM server. In few days, the memory grow up 95% and the TSM/HSM server goes down. What do you think the source of the problem? Thank you very much. Rachida Elouaraini System administrator MAROC METEO Casablanca __ Boîte aux lettres - Caramail - http://www.caramail.com
Re: Hi, help me!!
Herfried, yes, he did. Maybe you missed it because this was explained in other thread (Client shceduler). If the date is not accepted the server will run as the date/time is not changed at all and there would be no problem. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Re: Hi, help me!! hi, just a hint : did you issue a acc date on the TSM Server ? -herf Zlatko Krastev [EMAIL PROTECTED]@VM.MARIST.EDU on 16.05.2002 11:14:21 Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Hi, help me!! Hi, was the answer of Tim Rushforth of no help? Usually pending is for polling mode and means it is time for the schedule to start but schedule is not yet started due to randomization (according to server clock). According to node clock schedule is at later time if it did not contacted server since. Wait for schedprompt interval. what is the schedmode for the clients? They may need to contact server once to get new time of the schedule. This new time from node's point of view is similar to re-schedule. On second attempt they should be fine. I hope this helps a bit. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Hi, help me!! Hi, Krastev, I'm sorry that I'm sending this urgent mail. I don't have nobody to ask. I have TSM server on AIX. I had to reboot TSM and AIX due to time zone change. Then I noticed all the client schedules missed. I tested restarting baclient on one of client node and its event worked, but not others. When it reaches the scheduled time, it gives status msg 'pending'. Do all baclients need to be restarted to pick up the new time and start their regular schedules? Thanks for help. Jin Bae Chi (Gus) Data Center 614-287-2496 614-287-5488 Fax e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] 05/15/02 05:14PM Are you able using dd if=/dev/zero to create file of this size. If you can problem is in TSM. But until then you cannot be sure there is something in HP-UX settings. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:HP-UX restore problem We recently ran into an odd problem restoring files to an HP-UX 11.0 system with 4.1.2.0 client software. The TSM server is at 4.2.1.9 and runs under OS/390. We received the following error messages: 05/05/02 11:57:26 ANS4025E Error processing '/db/tjfrev6/MUMPS.EXT': file exceeds user or system file limit 05/05/02 11:57:26 ANS4025E Error processing '/db/tjfrev6/MUMPS.EXT': file exceeds user or system file limit 05/05/02 12:56:15 ANS4025E Error processing '/db/tjfserv6/MUMPS.EXT': file exceeds user or system file limit 05/05/02 12:56:15 ANS4025E Error processing '/db/tjfserv6/MUMPS.EXT': file exceeds user or system file limit We discovered that each of the restored files was 2,147,483,136 bytes long. The dsmsched.log entries for the backups of the files were still around, and showed a length of 2,147,483,647 bytes for each of the files, which is 511 bytes more than the length of each of the restored files. The original length turns out to be 2**31-1. The HP-UX administrator contacted HP, who had him check a variety of system settings. After reviewing the settings HP was adamant that there was nothing in the system configuration to prevent TSM from writing files of the original length. The restore process had one unusual feature. When the files were backed up /db/tjfrev6 and /db/tjfserv6 were file systems. When the files were restored /db/tjfrev6 and /db/tjfserv6 were ordinary directories within the /db file system. The loss of 511 bytes had no visible effect on the application that used the files. This is not quite as surprising as it sounds. The application treats each of its database files as a collection of 2048 byte blocks. The original length would have included 2047 bytes that did not fit into a block. Even though we dodged the bullet in this case, we are worried about running into this problem in the future. Is this a known problem?
Re: Performance again!!!
Backup direct to tape involves the communications. Migration is purely server process. So its check can eliminate some TCP bottlenecks (if any). For local client there should be no big difference. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Re: Performance again!!! Hello, we didn't try that one ... Is there any reason for the migration from disk to tape to be faster than backup from disk to tape? thx Sandra --- Zlatko Krastev [EMAIL PROTECTED] wrote: How long does the migration to tape take after backup to disk? Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Performance again!!! Hello everybody, It seems like TSM performance problems will neer end!!! Here is the new problem: The customer is running TSM 4.2.1.0 on a Windows 2000 server machine . An IBM rack case 82XX which contains a Quantum DLT8000 tape drive is connected to the server. The driver version for the Quantum DLT drive is 1.5 and is installed on the W2K machine. We tried a backup of 350MB on the local server with the Windows 2000 Backup utility and it took us approximately 75 seconds . Next , we tried the same Backup from TSM using its Device Driver and it took us about 9 minutes . We tried switching TSM to use the Native device driver but still we got the same performance result . So we upgraded to 4.2.2 ; In the Device Manager for TSM,we can see that TSMSCSI.exe is upgraded to 4.2.2.25 and the ADSMSCSI.sys is 4.2.2.3 . The server has a version of 4.2.2.25 . Still , we obtained poor backup performance . We suspected that maybe it was a database bottleneck ( eventhough it is still empty) ; so we tried the same Backup using TSM but the destination was on the HardDisk. The performance was good and the backup finished within 75seconds . So, we can eliminate the database problem. Also, we noticed with version 4.2.2.0 that it is crashing frequently . It was exiting abnormally . On the site of tivoli, the latest version of TSM server is 4.2.2 . We do not have the 5.1 release . does anyone have a suggestion? thx a lot Sandra __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
multipath 3575
Hello, does anybody knows how to disable multi-path feature on IBM 3575 library? I have big troubles with this feature; the id of the lib manager is the same of the drive 1, and there seems to be communications problem. I'd like to have different ids and the only way to do it is to disable multi-path. Thanks Nicolas Duchêne Telematics Services Europe Advanced Technical Services Secured Storage Services Boulevard E. Paepsemlaan , 18E 1070 Brussels Rue du Commandant Naessens, 23 4431 Loncin BELGIUM Tel: +32.2.556.27.40 +32.4.263.16.37 see us also on our Web site : see us on the web at www.telematicsandservices.com TS did open its official SAN SOLUTION CENTER in October 2000, at its laboratory in Paepsem.
Re: TSM 422 client gone from ftp server?
Hello, please could you describe the problem. I am in the middle of an update to TSM 4.2 and currently I am using the AIX 4.2.2 client on a couple of boxes. Bye Rainer Tammer On Thu, 16 May 2002 15:16:50 -0700, Jim Smith wrote: Bob, We have determined that there is a problem with the 4.2.2 UNIX backup-archive clients and they have been pulled from the ftp server. We are working to correct the problem. Expect to see a flash from IBM Tivoli shortly. Thanks, J.P. (Jim) Smith TSM Development Has someone reported this? I have not heard anything about UNIX clients at 4.2.2 having problems.. The Windows client still has the 422 directory and LATEST link. IBM/Tivoli? bob On Thu, May 16, 2002 at 04:24:14PM -0400, David Longo wrote: Perhaps because there seems to be some problems with some of the 4.2.2. stuff? David Longo [EMAIL PROTECTED] 05/16/02 03:59PM I went out there earlier today myself and found what you found too. I'm curious too. Dave Pearson -Original Message- From: Bob Booth - UIUC [SMTP:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 12:37 PM To: [EMAIL PROTECTED] Subject: TSM 422 client gone from ftp server? Does anyone know why or where the TSM 4.2.2 clients for some platforms are now missing from the IBM ftp server? 422 and LATEST are no longer out there for AIX, Solaris .. Among others.. Whats up? thanks, bob MMS health-first.org made the following annotations on 05/16/02 16:39:37 -- This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ==
netbackup site?
Hello TSMers, Do you have any idea if a netbackup site like this one exists? Thanks. Nicolas Duchêne Telematics Services Europe Advanced Technical Services Secured Storage Services Boulevard E. Paepsemlaan , 18E 1070 Brussels Rue du Commandant Naessens, 23 4431 Loncin BELGIUM Tel: +32.2.556.27.40 +32.4.263.16.37 see us also on our Web site : see us on the web at www.telematicsandservices.com TS did open its official SAN SOLUTION CENTER in October 2000, at its laboratory in Paepsem.
Re: Sloooow Novell Backups
I made the tcpip performance changes to the dsm.opt and I am still getting slow transfer times. I tested via ftp and was able to tranfer 40,000 files in a few minutes. So it appears that the TSM client is still not working. here are the stats from my last selective backup: Total number of objects inspected: 600 Total number of objects backed up: 600 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 0 Total number of bytes transferred: 230.73 KB Data transfer time:0.00 sec Network data transfer rate:0.00 KB/sec Aggregate data transfer rate: 0.21 KB/sec Objects compressed by:0% Elapsed processing time: 00:18:06 here is the new improved dsm.opt COMMMETHOD TCPip TCPSERVERADDRESScatamount TCPPORT 1500 tcpclientaddressxxx.xx.x.xxx txnbytelimit25600 tcpbuffsize 32 tcpwindowsize 63 largecommbuffersyes processorutilization15 MEMORYEFFICIENTBACKUP no NODENAME novell_test INCLUDE sys:...\* tape9940 INCLUDE extravol1:...\* tape9940 EXCLUDE sys:\system\secaudit.log EXCLUDE sys:\system\events.log EXCLUDE sys:\system\system.log EXCLUDE sys:\system\btrieve.trn EXCLUDE SYS:\system\tsa\err$hst.* EXCLUDE sys:\system\tsa\err$log.* EXCLUDE sys:\system\tsa\skip$log.* EXCLUDE sys:\system\tsa\tsa$temp.* EXCLUDE sys:\system\sys$log.err EXCLUDE sys:\_swap_.mem EXCLUDE sys:\vol$log.err EXCLUDE sys:\tts$log.err NWPWFILE YES passwordaccess generate managedservices schedule webclient Thanks for any help. Stephen Firmes TSM Engineer Tivoli Certified TSM Consultant StorageNetworks, Inc Work: 781-622-6287 http://www.storagenetworks.com -Original Message- From: Flemming Hougaard [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 6:59 AM To: [EMAIL PROTECTED] Subject: SV: Slw Novell Backups Hi Stephen I have some general experiences with the TSM client, and here goes: - Never use compress always! - The INCLUDE SYS:* wont work... you have to use SYS:...\* - I know it's supposed to be the same... but it isn't! - Tune on the following parameters: #TXNBYTELIMIT #TXNGROUPMAX #TCPBUFFSIZE #TCPWINDOWSIZE - Set MEMORYEFFICIENTBACKUP NO in the DSM.OPT file (should be standard, but...) Regards Flemming Hougaard Certified Novell Engineer -Oprindelig meddelelse- Fra: Firmes, Stephen [mailto:[EMAIL PROTECTED]] Sendt: 17. maj 2002 00:03 Til: [EMAIL PROTECTED] Emne: Slw Novell Backups TSM server 4.2.1.9 on Solaris 8 TSM 5.1 client on Novell 5.1 Backing up a volume with 500,000 files approx 1k each. The files are being transfered to the tsm server approx 1/sec. This is just a little too sloow. When using ftp to transfer these same files, either by getting/putting the transfers fly. This is leading me to believe that the issue is with the TSM server/client settings. Does anybody have any ideas on any settings in the dsm.opt that could be changed to enhance performance? Also I want to bind all objects in two of the volumes to a specific mgt class. All that is being bound to it is the dirs. Long day. What am I doing wrong??? Here is the dsm.opt *** COMMMETHODTCPip TCPSERVERADDRESS catamount TCPPORT 1500 tcpclientaddressxxx.yy.z.zzz NODENAME novell_test INCLUDE sys:* tape9940 INCLUDE extravol1:* tape9940 EXCLUDE sys:\system\secaudit.log EXCLUDE sys:\system\events.log EXCLUDE sys:\system\system.log EXCLUDE sys:\system\btrieve.trn EXCLUDE SYS:\system\tsa\err$hst.* EXCLUDE sys:\system\tsa\err$log.* EXCLUDE sys:\system\tsa\skip$log.* EXCLUDE sys:\system\tsa\tsa$temp.* EXCLUDE sys:\system\sys$log.err EXCLUDE sys:\_swap_.mem EXCLUDE sys:\vol$log.err EXCLUDE sys:\tts$log.err NWPWFILE YES passwordaccess generate managedservices schedule webclient Thanks. Stephen Firmes TSM Engineer Tivoli Certified TSM Consultant StorageNetworks, Inc Work: 781-622-6287 http://www.storagenetworks.com
Re: Sloooow Novell Backups
Try moving your TCPBUFFSIZE to 512 instead of 32. Brandon Eckmann Network and Technology Services Wayne State College Wayne NE. |-+ | | Firmes, Stephen| | | Stephen.Firmes@STORAGENE| | | TWORKS.COM | | | Sent by: ADSM: Dist Stor| | | Manager | | | [EMAIL PROTECTED] | | || | || | | 05/17/2002 07:26 AM | | | Please respond to ADSM: | | | Dist Stor Manager | | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Slw Novell Backups | --| I made the tcpip performance changes to the dsm.opt and I am still getting slow transfer times. I tested via ftp and was able to tranfer 40,000 files in a few minutes. So it appears that the TSM client is still not working. here are the stats from my last selective backup: Total number of objects inspected: 600 Total number of objects backed up: 600 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 0 Total number of bytes transferred: 230.73 KB Data transfer time:0.00 sec Network data transfer rate:0.00 KB/sec Aggregate data transfer rate: 0.21 KB/sec Objects compressed by:0% Elapsed processing time: 00:18:06 here is the new improved dsm.opt COMMMETHOD TCPip TCPSERVERADDRESScatamount TCPPORT 1500 tcpclientaddressxxx.xx.x.xxx txnbytelimit25600 tcpbuffsize 32 tcpwindowsize 63 largecommbuffersyes processorutilization15 MEMORYEFFICIENTBACKUP no NODENAME novell_test INCLUDE sys:...\* tape9940 INCLUDE extravol1:...\* tape9940 EXCLUDE sys:\system\secaudit.log EXCLUDE sys:\system\events.log EXCLUDE sys:\system\system.log EXCLUDE sys:\system\btrieve.trn EXCLUDE SYS:\system\tsa\err$hst.* EXCLUDE sys:\system\tsa\err$log.* EXCLUDE sys:\system\tsa\skip$log.* EXCLUDE sys:\system\tsa\tsa$temp.* EXCLUDE sys:\system\sys$log.err EXCLUDE sys:\_swap_.mem EXCLUDE sys:\vol$log.err EXCLUDE sys:\tts$log.err NWPWFILE YES passwordaccess generate managedservices schedule webclient Thanks for any help. Stephen Firmes TSM Engineer Tivoli Certified TSM Consultant StorageNetworks, Inc Work: 781-622-6287 http://www.storagenetworks.com -Original Message- From: Flemming Hougaard [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 6:59 AM To: [EMAIL PROTECTED] Subject: SV: Slw Novell Backups Hi Stephen I have some general experiences with the TSM client, and here goes: - Never use compress always! - The INCLUDE SYS:* wont work... you have to use SYS:...\* - I know it's supposed to be the same... but it isn't! - Tune on the following parameters: #TXNBYTELIMIT #TXNGROUPMAX #TCPBUFFSIZE #TCPWINDOWSIZE - Set MEMORYEFFICIENTBACKUP NO in the DSM.OPT file (should be standard, but...) Regards Flemming Hougaard Certified Novell Engineer -Oprindelig meddelelse- Fra: Firmes, Stephen [mailto:[EMAIL PROTECTED]] Sendt: 17. maj 2002 00:03 Til: [EMAIL PROTECTED] Emne: Slw Novell Backups TSM server 4.2.1.9 on Solaris 8 TSM 5.1 client on Novell 5.1 Backing up a volume with 500,000 files approx 1k each. The files are being transfered to the tsm server approx 1/sec. This is just a little too sloow. When using ftp to transfer these same files, either by getting/putting the transfers fly. This is leading me to believe that the issue is with the TSM server/client settings. Does anybody have any ideas on any settings
recovery log and ckpt
Hi all Firstly let me thank those who helped me out last night getting my server back up after the recovery log filled.much better than IBM support...! I have found the culprit that caused the log to fill. It seems that when the incremental backups are running for a win2k cluster the log gets written to at approx 2.2Gb an hour. The incremental didn't even backup that much data, in terms of size but I guess there must have been loads of small files in there. The problem I have now is, how can I back up this cluster if it is going to fill the recovery log everytime. The log is 5196 Mb so cannot grow much bigger, alas we're on 4.1.5 Server and yes I've made management aware that we need to upgrade to take advantage of the new recovery log size features. Looking back through adsm.org people have mentioned the ckpt command. Does anyone know how well this works in rollforward mode?? Many Thanks again Chris _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: Sloooow Novell Backups
How much of this data are you trying to send direct to tape? That's what it looks like your includes are trying to do, and that will obviously be slower that going to disk. Are you ftp'ing to disk but backing up to tape? I think, to get all the objects (files and folders) in sys: and extravol1: to your tape mgmt class you need the following: include sys:*.* tape9940 include sys:* tape9940 include sys:\...\* tape9940 include sys:\...\*.* tape9940 and the same construct for the extravol1 Firmes, Stephen wrote: I made the tcpip performance changes to the dsm.opt and I am still getting slow transfer times. I tested via ftp and was able to tranfer 40,000 files in a few minutes. So it appears that the TSM client is still not working. here are the stats from my last selective backup: Total number of objects inspected: 600 Total number of objects backed up: 600 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 0 Total number of bytes transferred: 230.73 KB Data transfer time:0.00 sec Network data transfer rate:0.00 KB/sec Aggregate data transfer rate: 0.21 KB/sec Objects compressed by:0% Elapsed processing time: 00:18:06 here is the new improved dsm.opt COMMMETHOD TCPip TCPSERVERADDRESScatamount TCPPORT 1500 tcpclientaddressxxx.xx.x.xxx txnbytelimit25600 tcpbuffsize 32 tcpwindowsize 63 largecommbuffersyes processorutilization15 MEMORYEFFICIENTBACKUP no NODENAME novell_test INCLUDE sys:...\* tape9940 INCLUDE extravol1:...\* tape9940 EXCLUDE sys:\system\secaudit.log EXCLUDE sys:\system\events.log EXCLUDE sys:\system\system.log EXCLUDE sys:\system\btrieve.trn EXCLUDE SYS:\system\tsa\err$hst.* EXCLUDE sys:\system\tsa\err$log.* EXCLUDE sys:\system\tsa\skip$log.* EXCLUDE sys:\system\tsa\tsa$temp.* EXCLUDE sys:\system\sys$log.err EXCLUDE sys:\_swap_.mem EXCLUDE sys:\vol$log.err EXCLUDE sys:\tts$log.err NWPWFILE YES passwordaccess generate managedservices schedule webclient Thanks for any help. Stephen Firmes TSM Engineer Tivoli Certified TSM Consultant StorageNetworks, Inc Work: 781-622-6287 http://www.storagenetworks.com -Original Message- From: Flemming Hougaard [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 6:59 AM To: [EMAIL PROTECTED] Subject: SV: Slw Novell Backups Hi Stephen I have some general experiences with the TSM client, and here goes: - Never use compress always! - The INCLUDE SYS:* wont work... you have to use SYS:...\* - I know it's supposed to be the same... but it isn't! - Tune on the following parameters: #TXNBYTELIMIT #TXNGROUPMAX #TCPBUFFSIZE #TCPWINDOWSIZE - Set MEMORYEFFICIENTBACKUP NO in the DSM.OPT file (should be standard, but...) Regards Flemming Hougaard Certified Novell Engineer -Oprindelig meddelelse- Fra: Firmes, Stephen [mailto:[EMAIL PROTECTED]] Sendt: 17. maj 2002 00:03 Til: [EMAIL PROTECTED] Emne: Slw Novell Backups TSM server 4.2.1.9 on Solaris 8 TSM 5.1 client on Novell 5.1 Backing up a volume with 500,000 files approx 1k each. The files are being transfered to the tsm server approx 1/sec. This is just a little too sloow. When using ftp to transfer these same files, either by getting/putting the transfers fly. This is leading me to believe that the issue is with the TSM server/client settings. Does anybody have any ideas on any settings in the dsm.opt that could be changed to enhance performance? Also I want to bind all objects in two of the volumes to a specific mgt class. All that is being bound to it is the dirs. Long day. What am I doing wrong??? Here is the dsm.opt *** COMMMETHODTCPip TCPSERVERADDRESS catamount TCPPORT 1500 tcpclientaddressxxx.yy.z.zzz NODENAME novell_test INCLUDE sys:* tape9940 INCLUDE extravol1:* tape9940 EXCLUDE sys:\system\secaudit.log EXCLUDE sys:\system\events.log EXCLUDE sys:\system\system.log EXCLUDE sys:\system\btrieve.trn EXCLUDE SYS:\system\tsa\err$hst.* EXCLUDE sys:\system\tsa\err$log.* EXCLUDE sys:\system\tsa\skip$log.* EXCLUDE sys:\system\tsa\tsa$temp.* EXCLUDE sys:\system\sys$log.err EXCLUDE sys:\_swap_.mem EXCLUDE sys:\vol$log.err EXCLUDE sys:\tts$log.err NWPWFILE YES passwordaccess generate managedservices schedule webclient
linux client on zseries 390
I have an admin that is trying to get the TSM client (TSM420_LINUX390.tar.Z) running on: 3. The version of linux we are using is a 64-bit implementation of red hat linux 2.4.7 called ThinkBlue. It was done by Millenux which is a partner with IBM Germany in its porting and is specifically done for a zseries machine. Except, TSM support says they only support kernel v 2.2 and this distribution is shipping the 2.4 kernel and a later version of glibc. Has anyone been able to get this working? I suggested that the admin try a --nodeps install on a test region - I'm hoping someone else can give me some pointers.
Re: multipath 3575
I don't know how to go back but when we went from single path to multipath the ROM chips in the library had to be changed. So I assume that to go back you have to get single path chips. The robot should be set to a different lun but same target as a drive. What type of problem are you having? We have not had any problems with communication. I say it that way because we have had a lot of problems with tapes and drive errors but not any with communication. -- Phillip Ford Senior Software Specialist Corporate Computer Center Schering-Plough Corp. (901) 320-4462 (901) 320-4856 FAX [EMAIL PROTECTED] -Original Message- From: Nicolas Duchene [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 3:53 AM To: [EMAIL PROTECTED] Subject: multipath 3575 Hello, does anybody knows how to disable multi-path feature on IBM 3575 library? I have big troubles with this feature; the id of the lib manager is the same of the drive 1, and there seems to be communications problem. I'd like to have different ids and the only way to do it is to disable multi-path. Thanks Nicolas Duchêne Telematics Services Europe Advanced Technical Services Secured Storage Services Boulevard E. Paepsemlaan , 18E 1070 Brussels Rue du Commandant Naessens, 23 4431 Loncin BELGIUM Tel: +32.2.556.27.40 +32.4.263.16.37 see us also on our Web site : see us on the web at www.telematicsandservices.com TS did open its official SAN SOLUTION CENTER in October 2000, at its laboratory in Paepsem. *** This message and any attachments is solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use, or distribution of the information included in this message is prohibited -- please immediately and permanently delete this message.
Re: How to limit drive usage when writing to a copypool
Make a new device class, set a max drive limit for it, and change your copypools to use that device class.
Re: Tuning TSM
Zlatko: OK: tcpwindowsize is in KBytes (actually my setting is 1280). I have the same question (why client is idling?). We have users working on that server from 9:00 until 22:00 (every day...), backup jobs start about 00:15/01:15 I've monitored the nodes in disk i/o operations and network transfers, in different moments of the day. About cpu load/memory usage/pagination: the values are all OK, for example: - cpu load (usr) has an average of 5~7 during all day - memory usage (have 7GB RAM) is not a problem (about 30~40% for computational the same for noncomp) - pagination: max use may be 10~12% (mostly of the day 0.5%, peaks during user's work time) Viewing your results (500GB in 3:10hs), and trying to compare: we're backing up 250GB starting 00:15 and ending 07:00... 250GB in 6:45hs (it's not good) Yesterday I set resource utilization = 10 too, and performance was the same (really a bit worst). I think there are multiple problems (and our provider -IBM- cannot help us): First of all: disk performance (IBM should tell us how to get the best from FastT500), we have from 15 to 25 MB/sec in the storage... Then: all TSM nodes in our installation have not the same file configuration. I explain a bit more this: we have nodes merging a lot of files (25) with an average size of 40KB each and a few files (1000) with an average size of 50MB (it's Oracle Financials: the database server keeps datafiles and files belonging to application and DB motor). We have 4 nodes such as just described, with a total of 35~40GB for each (average and growing...) Well, here was a brief description. I'm listening for new ideas. Thanks Ignacio -Mensaje original- De: Zlatko Krastev [mailto:[EMAIL PROTECTED]] Enviado el: viernes, 17 de mayo de 2002 5:29 Para: [EMAIL PROTECTED] Asunto: Re: Tuning TSM Just a point TCPWindowsize parameter is measured in kilobytes not bytes. And according to Administrator's reference it must be between 0 and 2048. If not in range on client complains with ANS1036S for invalid value. On server values out of range mean 0, i.e. OS default. However this are side remarks. The main question is why client is idling. Have you monitored the node during to disk and to tape operation? Is migration starting during backup? Are you using DIRMC. You wrote client compression - what is the processor usage (user)? What is the disk load - is the processor I/O wait high? Is the paging space used - check with svmon -P. You should get much better results. For example recently we've achieved 500 GB in 3h10m - fairly good. It was similar to your config - AIX nodeserver, client compression, disk pool, GB ether. Ether was driven 10-25 MB/s depending on achieved compression. The bottleneck was EMC Symmetrix the node was reading from but another company was dealing with it and we were unable to get more than 60-70 MB/s read. Resourceutilization was set to 10. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Re: Tuning TSM Zlatko: Here are the answers: Have you tested what is the performance of FAStT 500 disks? Those were mid-class disk storage originally designed for PC servers market and later modified to be compatible with rs6k/pSeries. This is completely true: IBM installed FastT500 instead of SSA disks (they said they were faster). We have done a re-cabling of these devices, and got a better IO balance on the controllers. Try some simple tests on the TSM server when quiet: - 'date; dd if=/dev/zero of=/fastt_fs/test_file bs=262144 count=16384; date' to test write speed. Use large file to simulate TSM heavy load. - 'date; dd if=/fastt_fs/test_file of=/dev/null' to check read speed In a test like you proposed, FastT500 brings a peformance of about 60MB/sec Also check your Gb Ether - are you using Jumbo frames, have you enabled in AIX 'no -o rfc1323=1', what are sendreceive bufsizes, what is TCPWindowsize of TSM serverclient. Have you measured LANdisk load during backup? Yes, we're using this parameters: from no tcp_sendspace = 1048576 tcp_recvspace = 1048576 udp_sendspace = 64000 udp_recvspace = 64000 rfc1323 = 1 from TSM server TCPWindowsize 1310720 What I've observed is that during a client backup session, TSM seems to be idled for a long time (and the server machine has not constraint problems for memory or I/O) I can send other data. Thank you all. Ignacio Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Tuning TSM Hi: I'm managing a
Re: multipath 3575
Refer to the IBM manual Magstar MP 3575 Tape Library Dataserver OPERATOR GUIDE GA32-0381. Chap 2 explains how to change this stuff from the LCD panel. Also after making changes, halt TSM and restart so it will read new config. May need to make some OS level changes also (devices) and reconfirm correct device names defined in TSM. All this depending on what changes you make. David B. Longo System Administrator Health First, Inc. 3300 Fiske Blvd. Rockledge, FL 32955-4305 PH 321.434.5536 Pager 321.634.8230 Fax:321.434.5525 [EMAIL PROTECTED] [EMAIL PROTECTED] 05/17/02 04:52AM Hello, does anybody knows how to disable multi-path feature on IBM 3575 library? I have big troubles with this feature; the id of the lib manager is the same of the drive 1, and there seems to be communications problem. I'd like to have different ids and the only way to do it is to disable multi-path. Thanks Nicolas Duchêne Telematics Services Europe Advanced Technical Services Secured Storage Services Boulevard E. Paepsemlaan , 18E 1070 Brussels Rue du Commandant Naessens, 23 4431 Loncin BELGIUM Tel: +32.2.556.27.40 +32.4.263.16.37 see us also on our Web site : see us on the web at www.telematicsandservices.com TS did open its official SAN SOLUTION CENTER in October 2000, at its laboratory in Paepsem. MMS health-first.org made the following annotations on 05/17/02 10:23:38 -- This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ==
Re: Sloooow Novell Backups
Stephen, Did you check on the half / full duplex setting on the network card ? Full-duplex advised If possible.. Did you also try to backup a large single file size ca 10mb's or larger, what is the performance then ? Regards marco -Original Message- From: Firmes, Stephen [mailto:[EMAIL PROTECTED]] Sent: vrijdag 17 mei 2002 15:11 To: [EMAIL PROTECTED] Subject: Re: Slw Novell Backups I made the tcpip performance changes to the dsm.opt and I am still getting slow transfer times. I tested via ftp and was able to tranfer 40,000 files in a few minutes. So it appears that the TSM client is still not working. here are the stats from my last selective backup: Total number of objects inspected: 600 Total number of objects backed up: 600 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 0 Total number of bytes transferred: 230.73 KB Data transfer time:0.00 sec Network data transfer rate:0.00 KB/sec Aggregate data transfer rate: 0.21 KB/sec Objects compressed by:0% Elapsed processing time: 00:18:06 here is the new improved dsm.opt COMMMETHOD TCPip TCPSERVERADDRESScatamount TCPPORT 1500 tcpclientaddressxxx.xx.x.xxx txnbytelimit25600 tcpbuffsize 32 tcpwindowsize 63 largecommbuffersyes processorutilization15 MEMORYEFFICIENTBACKUP no NODENAME novell_test INCLUDE sys:...\* tape9940 INCLUDE extravol1:...\* tape9940 EXCLUDE sys:\system\secaudit.log EXCLUDE sys:\system\events.log EXCLUDE sys:\system\system.log EXCLUDE sys:\system\btrieve.trn EXCLUDE SYS:\system\tsa\err$hst.* EXCLUDE sys:\system\tsa\err$log.* EXCLUDE sys:\system\tsa\skip$log.* EXCLUDE sys:\system\tsa\tsa$temp.* EXCLUDE sys:\system\sys$log.err EXCLUDE sys:\_swap_.mem EXCLUDE sys:\vol$log.err EXCLUDE sys:\tts$log.err NWPWFILE YES passwordaccess generate managedservices schedule webclient Thanks for any help. Stephen Firmes TSM Engineer Tivoli Certified TSM Consultant StorageNetworks, Inc Work: 781-622-6287 http://www.storagenetworks.com -Original Message- From: Flemming Hougaard [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 6:59 AM To: [EMAIL PROTECTED] Subject: SV: Slw Novell Backups Hi Stephen I have some general experiences with the TSM client, and here goes: - Never use compress always! - The INCLUDE SYS:* wont work... you have to use SYS:...\* - I know it's supposed to be the same... but it isn't! - Tune on the following parameters: #TXNBYTELIMIT #TXNGROUPMAX #TCPBUFFSIZE #TCPWINDOWSIZE - Set MEMORYEFFICIENTBACKUP NO in the DSM.OPT file (should be standard, but...) Regards Flemming Hougaard Certified Novell Engineer -Oprindelig meddelelse- Fra: Firmes, Stephen [mailto:[EMAIL PROTECTED]] Sendt: 17. maj 2002 00:03 Til: [EMAIL PROTECTED] Emne: Slw Novell Backups TSM server 4.2.1.9 on Solaris 8 TSM 5.1 client on Novell 5.1 Backing up a volume with 500,000 files approx 1k each. The files are being transfered to the tsm server approx 1/sec. This is just a little too sloow. When using ftp to transfer these same files, either by getting/putting the transfers fly. This is leading me to believe that the issue is with the TSM server/client settings. Does anybody have any ideas on any settings in the dsm.opt that could be changed to enhance performance? Also I want to bind all objects in two of the volumes to a specific mgt class. All that is being bound to it is the dirs. Long day. What am I doing wrong??? Here is the dsm.opt *** COMMMETHODTCPip TCPSERVERADDRESS catamount TCPPORT 1500 tcpclientaddressxxx.yy.z.zzz NODENAME novell_test INCLUDE sys:* tape9940 INCLUDE extravol1:* tape9940 EXCLUDE sys:\system\secaudit.log EXCLUDE sys:\system\events.log EXCLUDE sys:\system\system.log EXCLUDE sys:\system\btrieve.trn EXCLUDE SYS:\system\tsa\err$hst.* EXCLUDE sys:\system\tsa\err$log.* EXCLUDE sys:\system\tsa\skip$log.* EXCLUDE sys:\system\tsa\tsa$temp.* EXCLUDE sys:\system\sys$log.err EXCLUDE sys:\_swap_.mem EXCLUDE sys:\vol$log.err EXCLUDE sys:\tts$log.err NWPWFILE YES passwordaccess generate managedservices schedule webclient Thanks. Stephen Firmes TSM Engineer Tivoli Certified TSM Consultant StorageNetworks, Inc Work: 781-622-6287 http://www.storagenetworks.com
Re: DISASTER Client Restores Slow
I am sure TSM will wait. And while we're on this subject, we are looking at Disaster Recovery plans and the path we must take using TSM to recover a couple hundred servers. It looks bleak. We are finding that, due to incremental forever backups, recovery times are extremely long because of tape mount after tape mount after tape mount. In a real disaster, we expect to take an entire day or more to recover a single server. With a limited number of tape drives the recovery time required for 100 servers could take weeks. Has anyone else run into this dilemma? What is TSM's direction? How can I speed up the recovery process? John G. Talafous IS Technical Principal The Timken CompanyGlobal Software Support P.O. Box 6927 Data Management 1835 Dueber Ave. S.W. Phone: (330)-471-3390 Canton, Ohio USA 44706-0927 Fax : (330)-471-4034 [EMAIL PROTECTED] http://www.timken.com
Please Help Me !!!
After a very bad manipulation several nodes as well as their associated filespaces was destroyed. I make a migration forced with my diskpools on my tapepools every evening I make a backup of my diskpools on one short_tapepool every evening I make a copy of my tapepool on one long_tape pool every evening I make a backup of the base TSM every evening. Exist it a solution so that I recupere nodes detruits associated with filespaces Best regards Frédéric Rigoulay
tdpoconf, error, ANU2534E
Luis, I apologize, that is a pretty useless message (and not very helpful). But regardless, I think I can help you out. First off, are you using the tdpo.opt in the installation directory or are you defining it in your own directory? To start, I would use default installation directory /usr/tivoli/tsm/client/oracle/bin with the following in my tdpo.opt, substituting for your environment: In your /usr/tivoli/tsm/client/oracle/bin/tdpo.opt: DSMI_ORC_CONFIG /usr/tivoli/tsm/client/oracle/bin/dsm.opt TDPO_NODE node TDPO_OWNER owner In your /usr/tivoli/tsm/client/oracle/bin/dsm.opt: Servername your dsm.sys stanza servername In your /usr/tivoli/tsm/client/api/bin/dsm.sys: servername match from dsm.opt commm tcpip tcpport your TSM Server port number tcpsyour TSM Server address You should be able to establish a connection with your server with these basic settings. Then you should run tdpoconf password. Hope this helps. -- Date:Fri, 17 May 2002 03:23:15 + From:Luis Tapia [EMAIL PROTECTED] Subject: tdpoconf, error, ANU2534E Hi List, I`ve been trying to install TDP for Oracle for AIX 2.2.1 in a AIX 5.1 box, but I can not make the utility TDPOCONF work, it seems that my tdpo.opt file is not right but I cant not find where the problem is, when I issue and tdpoconf showenv or try to set the password I get an ANU 2534E Option file error the file tdpoerror.log is not very helpful, can somebody send me a working tdpo.opt/dsm.opt/dsm.sys set so i can use them as example? thanks for your help. Luis Regards, Neil Rasmussen Software Development TDP for Oracle [EMAIL PROTECTED]
Re: DISASTER Client Restores Slow
It will wait for the tape. Normally that is. If there is a problem with the tape (access=unavailable for instance) it will skip it. If another client is currently restoring from this tape, it will wait till tape is free. If tape is not in library, generally TSM will issue a request for the tape. David Longo [EMAIL PROTECTED] 05/17/02 10:25AM Hi Just want to verify AT my DISASTER REC.SITE we have a smaller lto library as compared to the one on our production site if its looking for a tape while restoring and not able to do so, does it wait till the tape is mounted before proceeding with the rest of the client restore? or does it skips restoring that file and moves on Pls let us know thanks in advance This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courriel est confidentiel et protege. L'expediteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) designe(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immediatement, par retour de courriel ou par un autre moyen. MMS health-first.org made the following annotations on 05/17/02 11:31:44 -- This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ==
Re: DISASTER Client Restores Slow
And using another backup solution won't result in many tape mounts as well? TSM might be more mounts than others, but you only have to do one restore. Remember, not using incremental forever means that you must resotre a machine at least two times. How about using backup sets if time is that much of an issue? If you have a couple hundred servers, I assume you have enough tape drives to make this feasible? Using, say 5 drives, to restore 100 clients is probably a pipe dream. Also, do you run multiple servers? You can easily pass the bus throughput of most machines when trying to restore this much data. I guess what I'm saying is that people argue that tsm mounts a lot of tapes and appears slow during DR restores, but in reality, the people that complain are usually trying to restore a lot of clients on a severely under-sized configuration. I think matching your DR hardware setup to your production setup is not a good idea. Most production setups are for speed in backing up. This usually means they are not optimized for restore speed. Also, prioritizing restores is key. I've cut DR times from originally 2 1/2 days of nightmare when I came here to about 17 hours with a fairly big setup. In other words, don't just start all restores at once and let 100 clients fight for 6 drives. Of course it's gonna look slow! -Original Message- From: Talafous, John G. [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 10:34 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow I am sure TSM will wait. And while we're on this subject, we are looking at Disaster Recovery plans and the path we must take using TSM to recover a couple hundred servers. It looks bleak. We are finding that, due to incremental forever backups, recovery times are extremely long because of tape mount after tape mount after tape mount. In a real disaster, we expect to take an entire day or more to recover a single server. With a limited number of tape drives the recovery time required for 100 servers could take weeks. Has anyone else run into this dilemma? What is TSM's direction? How can I speed up the recovery process? John G. Talafous IS Technical Principal The Timken CompanyGlobal Software Support P.O. Box 6927 Data Management 1835 Dueber Ave. S.W. Phone: (330)-471-3390 Canton, Ohio USA 44706-0927 Fax : (330)-471-4034 [EMAIL PROTECTED] http://www.timken.com This e-mail including any attachments is confidential and may be legally privileged. If you have received it in error please advise the sender immediately by return email and then delete it from your system. The unauthorized use, distribution, copying or alteration of this email is strictly forbidden. This email is from a unit or subsidiary of EMI Recorded Music, North America
Re: Hi, help me!!
Hi, all, I need to say big thank-you to all of you. Thanks for your advice and patience with a novice with me. Everything is backing up normally. I'm learning a lot! Thanks. Gus. Jin Bae Chi (Gus) Data Center 614-287-2496 614-287-5488 Fax e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] 05/17/02 07:07 AM Herfried, yes, he did. Maybe you missed it because this was explained in other thread (Client shceduler). If the date is not accepted the server will run as the date/time is not changed at all and there would be no problem. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Re: Hi, help me!! hi, just a hint : did you issue a acc date on the TSM Server ? -herf Zlatko Krastev [EMAIL PROTECTED]@VM.MARIST.EDU on 16.05.2002 11:14:21 Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Hi, help me!! Hi, was the answer of Tim Rushforth of no help? Usually pending is for polling mode and means it is time for the schedule to start but schedule is not yet started due to randomization (according to server clock). According to node clock schedule is at later time if it did not contacted server since. Wait for schedprompt interval. what is the schedmode for the clients? They may need to contact server once to get new time of the schedule. This new time from node's point of view is similar to re-schedule. On second attempt they should be fine. I hope this helps a bit. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Hi, help me!! Hi, Krastev, I'm sorry that I'm sending this urgent mail. I don't have nobody to ask. I have TSM server on AIX. I had to reboot TSM and AIX due to time zone change. Then I noticed all the client schedules missed. I tested restarting baclient on one of client node and its event worked, but not others. When it reaches the scheduled time, it gives status msg 'pending'. Do all baclients need to be restarted to pick up the new time and start their regular schedules? Thanks for help. Jin Bae Chi (Gus) Data Center 614-287-2496 614-287-5488 Fax e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] 05/15/02 05:14PM Are you able using dd if=/dev/zero to create file of this size. If you can problem is in TSM. But until then you cannot be sure there is something in HP-UX settings. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:HP-UX restore problem We recently ran into an odd problem restoring files to an HP-UX 11.0 system with 4.1.2.0 client software. The TSM server is at 4.2.1.9 and runs under OS/390. We received the following error messages: 05/05/02 11:57:26 ANS4025E Error processing '/db/tjfrev6/MUMPS.EXT': file exceeds user or system file limit 05/05/02 11:57:26 ANS4025E Error processing '/db/tjfrev6/MUMPS.EXT': file exceeds user or system file limit 05/05/02 12:56:15 ANS4025E Error processing '/db/tjfserv6/MUMPS.EXT': file exceeds user or system file limit 05/05/02 12:56:15 ANS4025E Error processing '/db/tjfserv6/MUMPS.EXT': file exceeds user or system file limit We discovered that each of the restored files was 2,147,483,136 bytes long. The dsmsched.log entries for the backups of the files were still around, and showed a length of 2,147,483,647 bytes for each of the files, which is 511 bytes more than the length of each of the restored files. The original length turns out to be 2**31-1. The HP-UX administrator contacted HP, who had him check a variety of system settings. After reviewing the settings HP was adamant that there was nothing in the system configuration to prevent TSM from writing files of the original length. The restore process had one unusual feature. When the files were backed up /db/tjfrev6 and /db/tjfserv6 were file systems. When the files were restored /db/tjfrev6 and /db/tjfserv6 were ordinary directories within the /db file system. The loss of 511 bytes had no visible effect on the application that used the files. This is not quite as surprising as it sounds. The application treats each of its database files as a collection of 2048 byte blocks. The original length would have included 2047 bytes that did not fit into a block. Even though we dodged the bullet in this case, we are worried about running into this problem in the future. Is this a known problem?
Re: TSM 422 client gone from ftp server?
I am not privy to why it is not out there, but the AIX 4.2.2 client has big problems. About 1/3 of all the files it backed up were rejected for filenme too long. I suspect that is why it is gone. Andy Carlson|\ _,,,---,,_ Senior Technical Specialist ZZZzz /,`.-'`'-. ;-;;,_ BJC Health Care|,4- ) )-,_. ,\ ( `'-' St. Louis, Missouri '---''(_/--' `-'\_) Cat Pics: http://andyc.dyndns.org/animal.html On Thu, 16 May 2002, Bob Booth - UIUC wrote: Does anyone know why or where the TSM 4.2.2 clients for some platforms are now missing from the IBM ftp server? 422 and LATEST are no longer out there for AIX, Solaris .. Among others.. Whats up? thanks, bob
Re: TSM 422 client gone from ftp server?
Well, that certainly explains that problem. Does anyone have a word if this problem is fixed in 5.1? I had plenty of people reporting that problem with Linux after upgrading to 4.2.2. Big whoops! thanks, bob On Fri, May 17, 2002 at 10:43:06AM -0500, Andrew Carlson wrote: I am not privy to why it is not out there, but the AIX 4.2.2 client has big problems. About 1/3 of all the files it backed up were rejected for filenme too long. I suspect that is why it is gone. Andy Carlson|\ _,,,---,,_ Senior Technical Specialist ZZZzz /,`.-'`'-. ;-;;,_ BJC Health Care|,4- ) )-,_. ,\ ( `'-' St. Louis, Missouri '---''(_/--' `-'\_) Cat Pics: http://andyc.dyndns.org/animal.html On Thu, 16 May 2002, Bob Booth - UIUC wrote: Does anyone know why or where the TSM 4.2.2 clients for some platforms are now missing from the IBM ftp server? 422 and LATEST are no longer out there for AIX, Solaris .. Among others.. Whats up? thanks, bob
Re: DISASTER Client Restores Slow
An idea to think about: We are looking at the possibility of changing our hardware config to take care of this issue. We are considering MOVING our TSM server out of the data center into a different building. With today's fiber connections the technology exists to do that. The primary pool tapes would stay in the tape robot, in bldg 2. Racks in the data center would be used as the vault for the copy pool tapes. If we lose the data center, the TSM server stays up and is ready to go, with collocated tapes available for restores. If we lose bldg 2, who cares, our data center is OK. We can take our time rebuilding a TSM server. The technology is out there so that we all probably start thinking about solutions like this. If all you have to work with is a DR site where you have to rebuild from scratch, this idea won't help you, I know. In that case I think backupsets + incremental restore-by-date to current is probably the fastest way to go. Creating backupsets periodically can be automated. It's not reasonable to do for ALL your servers, but for your most critical ones it's a fine idea. Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] Intelligence has much less practical application than you'd think - Scott Adams/Dilbert -Original Message- From: Walker, Thomas [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 11:08 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow And using another backup solution won't result in many tape mounts as well? TSM might be more mounts than others, but you only have to do one restore. Remember, not using incremental forever means that you must resotre a machine at least two times. How about using backup sets if time is that much of an issue? If you have a couple hundred servers, I assume you have enough tape drives to make this feasible? Using, say 5 drives, to restore 100 clients is probably a pipe dream. Also, do you run multiple servers? You can easily pass the bus throughput of most machines when trying to restore this much data. I guess what I'm saying is that people argue that tsm mounts a lot of tapes and appears slow during DR restores, but in reality, the people that complain are usually trying to restore a lot of clients on a severely under-sized configuration. I think matching your DR hardware setup to your production setup is not a good idea. Most production setups are for speed in backing up. This usually means they are not optimized for restore speed. Also, prioritizing restores is key. I've cut DR times from originally 2 1/2 days of nightmare when I came here to about 17 hours with a fairly big setup. In other words, don't just start all restores at once and let 100 clients fight for 6 drives. Of course it's gonna look slow! -Original Message- From: Talafous, John G. [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 10:34 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow I am sure TSM will wait. And while we're on this subject, we are looking at Disaster Recovery plans and the path we must take using TSM to recover a couple hundred servers. It looks bleak. We are finding that, due to incremental forever backups, recovery times are extremely long because of tape mount after tape mount after tape mount. In a real disaster, we expect to take an entire day or more to recover a single server. With a limited number of tape drives the recovery time required for 100 servers could take weeks. Has anyone else run into this dilemma? What is TSM's direction? How can I speed up the recovery process? John G. Talafous IS Technical Principal The Timken CompanyGlobal Software Support P.O. Box 6927 Data Management 1835 Dueber Ave. S.W. Phone: (330)-471-3390 Canton, Ohio USA 44706-0927 Fax : (330)-471-4034 [EMAIL PROTECTED] http://www.timken.com This e-mail including any attachments is confidential and may be legally privileged. If you have received it in error please advise the sender immediately by return email and then delete it from your system. The unauthorized use, distribution, copying or alteration of this email is strictly forbidden. This email is from a unit or subsidiary of EMI Recorded Music, North America
Re: DISASTER Client Restores Slow
AS far as tsm is concerned , when there is no copy pool tape at the disaster recovery site at time of restore will result in request of mount tape until it is provided to that site! is this what I'm hearing? it will skip unless it is unavailable Thanks -Original Message- From: David Longo [SMTP:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 11:16 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow It will wait for the tape. Normally that is. If there is a problem with the tape (access=unavailable for instance) it will skip it. If another client is currently restoring from this tape, it will wait till tape is free. If tape is not in library, generally TSM will issue a request for the tape. David Longo [EMAIL PROTECTED] 05/17/02 10:25AM Hi Just want to verify AT my DISASTER REC.SITE we have a smaller lto library as compared to the one on our production site if its looking for a tape while restoring and not able to do so, does it wait till the tape is mounted before proceeding with the rest of the client restore? or does it skips restoring that file and moves on Pls let us know thanks in advance This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courriel est confidentiel et protege. L'expediteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) designe(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immediatement, par retour de courriel ou par un autre moyen. MMS health-first.org made the following annotations on 05/17/02 11:31:44 -- This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. == This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courriel est confidentiel et protege. L'expediteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) designe(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immediatement, par retour de courriel ou par un autre moyen.
Re: DISASTER Client Restores Slow
I would say that technically, that sounds good. Except for one thing. How close are the two buildings? I wouldn't want all my eggs on the same campus. David Longo [EMAIL PROTECTED] 05/17/02 12:49PM An idea to think about: We are looking at the possibility of changing our hardware config to take care of this issue. We are considering MOVING our TSM server out of the data center into a different building. With today's fiber connections the technology exists to do that. The primary pool tapes would stay in the tape robot, in bldg 2. Racks in the data center would be used as the vault for the copy pool tapes. If we lose the data center, the TSM server stays up and is ready to go, with collocated tapes available for restores. If we lose bldg 2, who cares, our data center is OK. We can take our time rebuilding a TSM server. The technology is out there so that we all probably start thinking about solutions like this. If all you have to work with is a DR site where you have to rebuild from scratch, this idea won't help you, I know. In that case I think backupsets + incremental restore-by-date to current is probably the fastest way to go. Creating backupsets periodically can be automated. It's not reasonable to do for ALL your servers, but for your most critical ones it's a fine idea. Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] Intelligence has much less practical application than you'd think - Scott Adams/Dilbert -Original Message- From: Walker, Thomas [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 11:08 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow And using another backup solution won't result in many tape mounts as well? TSM might be more mounts than others, but you only have to do one restore. Remember, not using incremental forever means that you must resotre a machine at least two times. How about using backup sets if time is that much of an issue? If you have a couple hundred servers, I assume you have enough tape drives to make this feasible? Using, say 5 drives, to restore 100 clients is probably a pipe dream. Also, do you run multiple servers? You can easily pass the bus throughput of most machines when trying to restore this much data. I guess what I'm saying is that people argue that tsm mounts a lot of tapes and appears slow during DR restores, but in reality, the people that complain are usually trying to restore a lot of clients on a severely under-sized configuration. I think matching your DR hardware setup to your production setup is not a good idea. Most production setups are for speed in backing up. This usually means they are not optimized for restore speed. Also, prioritizing restores is key. I've cut DR times from originally 2 1/2 days of nightmare when I came here to about 17 hours with a fairly big setup. In other words, don't just start all restores at once and let 100 clients fight for 6 drives. Of course it's gonna look slow! -Original Message- From: Talafous, John G. [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 10:34 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow I am sure TSM will wait. And while we're on this subject, we are looking at Disaster Recovery plans and the path we must take using TSM to recover a couple hundred servers. It looks bleak. We are finding that, due to incremental forever backups, recovery times are extremely long because of tape mount after tape mount after tape mount. In a real disaster, we expect to take an entire day or more to recover a single server. With a limited number of tape drives the recovery time required for 100 servers could take weeks. Has anyone else run into this dilemma? What is TSM's direction? How can I speed up the recovery process? John G. Talafous IS Technical Principal The Timken CompanyGlobal Software Support P.O. Box 6927 Data Management 1835 Dueber Ave. S.W. Phone: (330)-471-3390 Canton, Ohio USA 44706-0927 Fax : (330)-471-4034 [EMAIL PROTECTED] http://www.timken.com This e-mail including any attachments is confidential and may be legally privileged. If you have received it in error please advise the sender immediately by return email and then delete it from your system. The unauthorized use, distribution, copying or alteration of this email is strictly forbidden. This email is from a unit or subsidiary of EMI Recorded Music, North America MMS health-first.org made the following annotations on 05/17/02 13:33:33 -- This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by
Re: TSM 422 client gone from ftp server?
The problem is reported in IC33645 and is only a problem with the TSM 4.2.2 backup/archive client; it has been addressed in TSM 5.1.0. We are working to provide more information about the specifics of the problem. Thanks, Jim J.P. (Jim) Smith TSM Client Development Well, that certainly explains that problem. Does anyone have a word if this problem is fixed in 5.1? I had plenty of people reporting that problem with Linux after upgrading to 4.2.2. Big whoops! thanks, bob On Fri, May 17, 2002 at 10:43:06AM -0500, Andrew Carlson wrote: I am not privy to why it is not out there, but the AIX 4.2.2 client has big problems. About 1/3 of all the files it backed up were rejected for filenme too long. I suspect that is why it is gone. Andy Carlson|\ _,,,---,,_ Senior Technical Specialist ZZZzz /,`.-'`'-. ;-;;,_ BJC Health Care|,4- ) )-,_. ,\ ( `'-' St. Louis, Missouri '---''(_/--' `-'\_) Cat Pics: http://andyc.dyndns.org/animal.html On Thu, 16 May 2002, Bob Booth - UIUC wrote: Does anyone know why or where the TSM 4.2.2 clients for some platforms are now missing from the IBM ftp server? 422 and LATEST are no longer out there for AIX, Solaris .. Among others.. Whats up? thanks, bob
Re: DISASTER Client Restores Slow
Yes, they are on the same campus. And I agree, if we were in an earthquake zone, that wouldn't be far enough away. But that's really a management decision - what disaster coverage do you require? Currently, our copy pool tapes are stored in the other building, and management believes that provides sufficient distance. We are covered for fire, flood, explosion. We are not in an earthquake or hurricane zone. We are NOT covered for a regional power outage such as would occur in a florida-like hurricane zone. But in that case we can take our tapes and move them elsewhere, and what we lose is time, not data. If this were a commercial enterprise, that time would be a larger concern. As with any DR situation, you have to figure out YOUR exposures and your requirements for resolving them. With our traditional methods of creating primary pool tapes onsite and moving copy pool tapes offsite, you have the slow/uncollocated restore problem. All I am suggesting here, is if we can use newer technnology to overcome the communicaiton limits, and think outside the box a bit, we should put the TSM library offsite, and keep the copy pool tapes onsite. That would provide equal coverage and eliminate the slow/uncollocated restore problem. (AND you eliminate the up-front time required to rebuild the TSM server.) Just something to think about. -Original Message- From: David Longo [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 1:18 PM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow I would say that technically, that sounds good. Except for one thing. How close are the two buildings? I wouldn't want all my eggs on the same campus. David Longo [EMAIL PROTECTED] 05/17/02 12:49PM An idea to think about: We are looking at the possibility of changing our hardware config to take care of this issue. We are considering MOVING our TSM server out of the data center into a different building. With today's fiber connections the technology exists to do that. The primary pool tapes would stay in the tape robot, in bldg 2. Racks in the data center would be used as the vault for the copy pool tapes. If we lose the data center, the TSM server stays up and is ready to go, with collocated tapes available for restores. If we lose bldg 2, who cares, our data center is OK. We can take our time rebuilding a TSM server. The technology is out there so that we all probably start thinking about solutions like this. If all you have to work with is a DR site where you have to rebuild from scratch, this idea won't help you, I know. In that case I think backupsets + incremental restore-by-date to current is probably the fastest way to go. Creating backupsets periodically can be automated. It's not reasonable to do for ALL your servers, but for your most critical ones it's a fine idea. Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] Intelligence has much less practical application than you'd think - Scott Adams/Dilbert -Original Message- From: Walker, Thomas [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 11:08 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow And using another backup solution won't result in many tape mounts as well? TSM might be more mounts than others, but you only have to do one restore. Remember, not using incremental forever means that you must resotre a machine at least two times. How about using backup sets if time is that much of an issue? If you have a couple hundred servers, I assume you have enough tape drives to make this feasible? Using, say 5 drives, to restore 100 clients is probably a pipe dream. Also, do you run multiple servers? You can easily pass the bus throughput of most machines when trying to restore this much data. I guess what I'm saying is that people argue that tsm mounts a lot of tapes and appears slow during DR restores, but in reality, the people that complain are usually trying to restore a lot of clients on a severely under-sized configuration. I think matching your DR hardware setup to your production setup is not a good idea. Most production setups are for speed in backing up. This usually means they are not optimized for restore speed. Also, prioritizing restores is key. I've cut DR times from originally 2 1/2 days of nightmare when I came here to about 17 hours with a fairly big setup. In other words, don't just start all restores at once and let 100 clients fight for 6 drives. Of course it's gonna look slow! -Original Message- From: Talafous, John G. [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 10:34 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow I am sure TSM will wait. And while we're on this subject, we are looking at Disaster Recovery plans and the path we must take using TSM
Re: DISASTER Client Restores Slow
Nikolai Sonin System Architect ESI Group 28381 Encina Drive Suite 100 Winters CA, 95694-9007 530-795-0200 ext. 235 Talafous, John G. [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 05/17/2002 07:33 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: DISASTER Client Restores Slow You can use backup sets to create point in time restores of machines. Also with that few tape drives have you considered collocation. That way especially with LTO a small server and several incrementals will fit on one tape. Our CEO's PC is backed up using TSM with Collocation to an LTO drive and after a month of incrementals all his data sits on one tape. A test restore of his workstation took less than 3 hours. Also if you have over 100 servers you need to get more tape drives. I am sure TSM will wait. And while we're on this subject, we are looking at Disaster Recovery plans and the path we must take using TSM to recover a couple hundred servers. It looks bleak. We are finding that, due to incremental forever backups, recovery times are extremely long because of tape mount after tape mount after tape mount. In a real disaster, we expect to take an entire day or more to recover a single server. With a limited number of tape drives the recovery time required for 100 servers could take weeks. Has anyone else run into this dilemma? What is TSM's direction? How can I speed up the recovery process? John G. Talafous IS Technical Principal The Timken CompanyGlobal Software Support P.O. Box 6927 Data Management 1835 Dueber Ave. S.W. Phone: (330)-471-3390 Canton, Ohio USA 44706-0927 Fax : (330)-471-4034 [EMAIL PROTECTED] http://www.timken.com
Reclamation is not happening - HELP!
My tape use is going up, but nothing is being reclaimed from my copy pool. I must have done something wrong, but where do I go to look for whatever is wrong first? What am I missing? I can find nothing in the activity log, and even when I do a update stg copypool rec=5 and it should recover a lot, nothing happens. Sometimes the process starts up, but will sit for hours and nothing gets reclaimed. Running TSM 4.1.5 on NT, with 3583 library and LTO drives. It has been working, but stopped earlier this week. ... TIA ... Jack
TSM 5.1 Techinical Guide
JFYI, there is a new RedBook: Tivoli Storage Manager Version 5.1: Technical Guide. Here's the link. http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/sg246554.html?Open Mahesh
Re: DISASTER Client Restores Slow
AT my DISASTER REC.SITE we have a smaller lto library as compared to the one on our production site if its looking for a tape while restoring and not able to do so, does it wait till the tape is mounted before proceeding with the rest of the client restore? or does it skips restoring that file and moves on If your tapes tapes are not checked in, but in state Read-Write or Read-Only, then the TSM server will issue a message requiring the checkin of a tape. Then you can safely checkout libvol a tape to make room in the library and checkin libvol the requested tape. There is a time limit: look at the Mount Wait time of the device class - default is 60 minutes. Only if the state of a tape is Unavailable or Offsite, the files will be skipped. Tschau Alex
TSM FLASH: UNIX BACKUP-ARCHIVE CLIENT V4.2.2
Problem Description: The TSM 4.2.2 UNIX backup-archive clients may produce error messages similar to the following when performing incremental backup of files with hard links: ANS1228E Sending of object 'filename' failed ANS4018E Error processing 'filename': file name too long where filename is the name of the file that failed to back up. It is important to note that file names experiencing this problem are NOT too long. Message ANE4018E (same text as ANS4018E above) may also be logged to the TSM server. This problem affects files that have hard links. For affected files, the problem occurs only during incremental backup. SELECTIVE backup of these files works correctly. For files that have hard links, both the link and the original file may be affected by this problem: If the original file does not have a backup version on the TSM server, then the original file will experience the problem. If the hard link does not have a backup version on the TSM server, then the hard link will experience the problem. Files with hard links where the file already has a backup version (regardless of whether the link has a backup version) are unaffected. Hard links where the link already has a backup version (regardless of whether the original file has a backup version) are unaffected. Files that have no hard links are unaffected. Client APAR IC33645 has been opened to address this problem. The version 4.2.2 UNIX clients have been removed from the FTP download site. They will soon be replaced with newer client code that fixes this problem. Circumvention: Use SELECTIVE backup to back up those files that are affected by this problem. They can be identified by reviewing the ANS1228E and ANS4018E messages in the dsmerror.log file. The backup-archive GUI may also be used to back up these files. From the GUI, be sure to select the Always backup option (located in the drop-down list to the left of the Help button). Alternatively, customers who were running an earlier 4.2.x version of the client can remove 4.2.2 and reinstall the earlier version. Customers who upgraded from version 4.1.x or below can not back off, and must use the circumvention described above. We plan on having a fix available soon, so this circumvention is viewed as being very short-term. Users Affected: All TSM 4.2.2 UNIX backup-archive clients. Recommendation: Apply fixing code when available. We anticipate that the fix will be delivered on or before the end of May 2002. This statement was prepared by TSM Backup-Archive client development and system test
Expanding our system
We currently have a 3494 library with two 3490E1A drives attached to a WinNT4 box running quad Xeon 550's and a gig of RAM. TSM is version 4.2. We have about 30-40gig of data coming in over about an eight hour time window each evening and night. Things are fine for now. We are looking to do some improvements in the next several months. First thing we would like to do is to reload the server with Win 2000 and TSM version 5.xx. In our shop, we can only speak MS. Other OS's aren't an option. This we would like to do in 3-4 months. I think we can handle this ourselves. Next on the agenda, we are working towards getting some kind of a SAN in the budget for the first of the year. I don't know all of the details at the moment but they are talking about 3-4 terabyte capacity. Don't know how this will impact on new data coming into TSM. But the boss man wants to see about adding another complete library with two more tape drives. The people we that installed our original system are gone so we can't go back to them for more hardware. Any suggestions on someone to do this for us? David Tyree Microcomputer Specialist South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Ordering license upgrades
We have a TSM 4.2.1.9 server running under OS/390. We are about to order more client licenses. The last time we did this IBM and/or Tivoli required us to tell them how the new licenses would be divided among different platforms: how many for Windows NT, how many for AIX, and so on. The charge per client license is the same regardless of operating system. The 'register license' command does not provide any means for distinguishing between Windows NT licenses, AIX licenses, and so on. Why in the world do we need to provide platform information in order to get more client licenses?
Re: Backing up Active Directory on Win2000
Thanks, Tim, What's a Q systemobject? That command doesn't seem to produce anything, do I have it wrong? Thanks, Julie Rushforth, Tim [EMAIL PROTECTED] To: [EMAIL PROTECTED] IPEG.MB.CA cc: Sent by: ADSM: Subject: Re: Backing up Active Directory on Win2000 Dist Stor Manager [EMAIL PROTECTED] DU 05/16/2002 05:48 PM Please respond to ADSM: Dist Stor Manager Incremental backup process all of the system ojbects on our Windows 2000 Domain Controllers. I've done full restores with many client versions including 4.2.1.20 and 4.12.12. The default is to include system objects with DOMAIN ALL-LOCAL. What is your domain statement? Have you done a q systemobject from the b/a command line? Tim Rushforth City of Winnipeg -Original Message- From: Julie Phinney [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 4:11 PM To: [EMAIL PROTECTED] Subject: Backing up Active Directory on Win2000 Hi all, I'm not familiar with Active Directory on Win2000 but I've been told by one of our Win2000 guys : There is a System Object selection list that includes the following items to backup using TSM: Active Directory, COM+ DB, Event Log, Registry, RSM, System Files, System Volume But it appears like only the following System Objects are currently being selected for backup: Event Log Registry RSM I'm wondering if by default, incremental backup does not back up all of the System Objects? Do I need to specify something in the DSM.OPT file or in a client optionset to get it to do all the system objects in Active Directory? Thanks, Julie Phinney
Re: Expanding our system
Nikolai Sonin System Architect ESI Group 28381 Encina Drive Suite 100 Winters CA, 95694-9007 530-795-0200 ext. 235 Tyree, David [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 05/17/2002 12:21 PM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Expanding our system We currently have a 3494 library with two 3490E1A drives attached to a WinNT4 box running quad Xeon 550's and a gig of RAM. TSM is version 4.2. We have about 30-40gig of data coming in over about an eight hour time window each evening and night. Things are fine for now. We are looking to do some improvements in the next several months. The 3494 can be upgraded to 3590E1A using direct Fibre Channel attach. I do not know if the 3490's can coexist with the Fibre Channel 3590's, but I do have customers that have 3494's with both SCSI 3490's and SCSI 3590's in the same library. They can not be in the same frame, but if they are in separate frames it works well. First thing we would like to do is to reload the server with Win 2000 and TSM version 5.xx. In our shop, we can only speak MS. Other OS's aren't an option. This we would like to do in 3-4 months. I think we can handle this ourselves. Next on the agenda, we are working towards getting some kind of a SAN in the budget for the first of the year. I don't know all of the details at the moment but they are talking about 3-4 terabyte capacity. Don't know how this will impact on new data coming into TSM. But the boss man wants to see about adding another complete library with two more tape drives. For 3-4 Terabytes in 8 hours you would need 10 SCSI attached 3590E1A's. For fibre channel you might be able to use less, but realistically you are probably running what 20 - 30 Windows servers. You will 10 drives just to be able to do the tape copy pools and DRM management The people we that installed our original system are gone so we can't go back to them for more hardware. Any suggestions on someone to do this for us? David Tyree Microcomputer Specialist South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: TSM FLASH: UNIX BACKUP-ARCHIVE CLIENT V4.2.2
Jim, I would like to thank you for publishing this information. We got bit by the windows client at 4.2.1.20 and 4.2.1.26 failing half way through a backup because of a locked file and the backup looking successful. The result was we lost many backups for about 10 days without realizing it. The problem was fixed by the 4.2.2 Windows client. I recommend everyone go to that level if they are running 4.2.1.15 server (anything higher than 4.2.1.11). We think the problem was introduced by us going to that level of the server. It would be really nice if the action you took here for this problem had been taken for this backup integrity problem as well. It is really unacceptable to lose backups or have backups with integrity problems because of not having the information on a known problem. This forum is documented everywhere and used by many customers. It is a great way to get this kind of information out. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -Original Message- From: Jim Smith [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 3:57 PM To: [EMAIL PROTECTED] Subject: TSM FLASH: UNIX BACKUP-ARCHIVE CLIENT V4.2.2 Importance: High Problem Description: The TSM 4.2.2 UNIX backup-archive clients may produce error messages similar to the following when performing incremental backup of files with hard links: ANS1228E Sending of object 'filename' failed ANS4018E Error processing 'filename': file name too long where filename is the name of the file that failed to back up. It is important to note that file names experiencing this problem are NOT too long. Message ANE4018E (same text as ANS4018E above) may also be logged to the TSM server. This problem affects files that have hard links. For affected files, the problem occurs only during incremental backup. SELECTIVE backup of these files works correctly. For files that have hard links, both the link and the original file may be affected by this problem: If the original file does not have a backup version on the TSM server, then the original file will experience the problem. If the hard link does not have a backup version on the TSM server, then the hard link will experience the problem. Files with hard links where the file already has a backup version (regardless of whether the link has a backup version) are unaffected. Hard links where the link already has a backup version (regardless of whether the original file has a backup version) are unaffected. Files that have no hard links are unaffected. Client APAR IC33645 has been opened to address this problem. The version 4.2.2 UNIX clients have been removed from the FTP download site. They will soon be replaced with newer client code that fixes this problem. Circumvention: Use SELECTIVE backup to back up those files that are affected by this problem. They can be identified by reviewing the ANS1228E and ANS4018E messages in the dsmerror.log file. The backup-archive GUI may also be used to back up these files. From the GUI, be sure to select the Always backup option (located in the drop-down list to the left of the Help button). Alternatively, customers who were running an earlier 4.2.x version of the client can remove 4.2.2 and reinstall the earlier version. Customers who upgraded from version 4.1.x or below can not back off, and must use the circumvention described above. We plan on having a fix available soon, so this circumvention is viewed as being very short-term. Users Affected: All TSM 4.2.2 UNIX backup-archive clients. Recommendation: Apply fixing code when available. We anticipate that the fix will be delivered on or before the end of May 2002. This statement was prepared by TSM Backup-Archive client development and system test
Re: DISASTER Client Restores Slow
In North Carolina we've been advised that 7 miles is an 'adequate' distance for off-site storage for DR. And Wanda, be careful about how you view a 'hurricane zone'! Here in Chapel Hill, NC we're some 200 miles inland and got whomped by Hurricane Fran in '96. Power was out on campus for 3 days. I would think Md. might have similar susceptibility. But I am in total agreement, separate the TSM server and the tape library and eliminate so much physical tape movement. Prather, Wanda wrote: Yes, they are on the same campus. And I agree, if we were in an earthquake zone, that wouldn't be far enough away. But that's really a management decision - what disaster coverage do you require? Currently, our copy pool tapes are stored in the other building, and management believes that provides sufficient distance. We are covered for fire, flood, explosion. We are not in an earthquake or hurricane zone. We are NOT covered for a regional power outage such as would occur in a florida-like hurricane zone. But in that case we can take our tapes and move them elsewhere, and what we lose is time, not data. If this were a commercial enterprise, that time would be a larger concern. As with any DR situation, you have to figure out YOUR exposures and your requirements for resolving them. With our traditional methods of creating primary pool tapes onsite and moving copy pool tapes offsite, you have the slow/uncollocated restore problem. All I am suggesting here, is if we can use newer technnology to overcome the communicaiton limits, and think outside the box a bit, we should put the TSM library offsite, and keep the copy pool tapes onsite. That would provide equal coverage and eliminate the slow/uncollocated restore problem. (AND you eliminate the up-front time required to rebuild the TSM server.) Just something to think about. -Original Message- From: David Longo [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 1:18 PM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow I would say that technically, that sounds good. Except for one thing. How close are the two buildings? I wouldn't want all my eggs on the same campus. David Longo [EMAIL PROTECTED] 05/17/02 12:49PM An idea to think about: We are looking at the possibility of changing our hardware config to take care of this issue. We are considering MOVING our TSM server out of the data center into a different building. With today's fiber connections the technology exists to do that. The primary pool tapes would stay in the tape robot, in bldg 2. Racks in the data center would be used as the vault for the copy pool tapes. If we lose the data center, the TSM server stays up and is ready to go, with collocated tapes available for restores. If we lose bldg 2, who cares, our data center is OK. We can take our time rebuilding a TSM server. The technology is out there so that we all probably start thinking about solutions like this. If all you have to work with is a DR site where you have to rebuild from scratch, this idea won't help you, I know. In that case I think backupsets + incremental restore-by-date to current is probably the fastest way to go. Creating backupsets periodically can be automated. It's not reasonable to do for ALL your servers, but for your most critical ones it's a fine idea. Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] Intelligence has much less practical application than you'd think - Scott Adams/Dilbert -Original Message- From: Walker, Thomas [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 11:08 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow And using another backup solution won't result in many tape mounts as well? TSM might be more mounts than others, but you only have to do one restore. Remember, not using incremental forever means that you must resotre a machine at least two times. How about using backup sets if time is that much of an issue? If you have a couple hundred servers, I assume you have enough tape drives to make this feasible? Using, say 5 drives, to restore 100 clients is probably a pipe dream. Also, do you run multiple servers? You can easily pass the bus throughput of most machines when trying to restore this much data. I guess what I'm saying is that people argue that tsm mounts a lot of tapes and appears slow during DR restores, but in reality, the people that complain are usually trying to restore a lot of clients on a severely under-sized configuration. I think matching your DR hardware setup to your production setup is not a good idea. Most production setups are for speed in backing up. This usually means they are not optimized for restore speed. Also, prioritizing restores is
Re: Backing up Active Directory on Win2000
From the Backup/Archive Command line clinet (dsmc), enter q systemobject. It should show you the last backup date of all system objects. tsm q systemobject Size Backup DateMgmt Class A/I File ----- --- 7,750 05/17/2002 00:04:27DEFAULT A SYSTEM OBJECT\SERVER1\compdb 717,644 05/17/2002 00:04:28DEFAULT A SYSTEM OBJECT\SERVER1\EVENTLOG 140,726,199 05/17/2002 00:04:34DEFAULT A SYSTEM OBJECT\SERVER1\SYSFILES 21,533,875 05/17/2002 00:11:37DEFAULT A SYSTEM OBJECT\SERVER1\SYSVOL 94,404,688 05/17/2002 00:14:20DEFAULT A SYSTEM OBJECT\SERVER1\NTDS 4,318,790 05/17/2002 00:14:32DEFAULT A SYSTEM OBJECT\SERVER1\REGISTRY 20,883 05/17/2002 00:14:34DEFAULT A SYSTEM OBJECT\SERVER1\RSM -Original Message- From: Julie Phinney [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 2:57 PM To: [EMAIL PROTECTED] Subject: Re: Backing up Active Directory on Win2000 Thanks, Tim, What's a Q systemobject? That command doesn't seem to produce anything, do I have it wrong? Thanks, Julie Rushforth, Tim [EMAIL PROTECTED] To: [EMAIL PROTECTED] IPEG.MB.CA cc: Sent by: ADSM: Subject: Re: Backing up Active Directory on Win2000 Dist Stor Manager [EMAIL PROTECTED] DU 05/16/2002 05:48 PM Please respond to ADSM: Dist Stor Manager Incremental backup process all of the system ojbects on our Windows 2000 Domain Controllers. I've done full restores with many client versions including 4.2.1.20 and 4.12.12. The default is to include system objects with DOMAIN ALL-LOCAL. What is your domain statement? Have you done a q systemobject from the b/a command line? Tim Rushforth City of Winnipeg -Original Message- From: Julie Phinney [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 4:11 PM To: [EMAIL PROTECTED] Subject: Backing up Active Directory on Win2000 Hi all, I'm not familiar with Active Directory on Win2000 but I've been told by one of our Win2000 guys : There is a System Object selection list that includes the following items to backup using TSM: Active Directory, COM+ DB, Event Log, Registry, RSM, System Files, System Volume But it appears like only the following System Objects are currently being selected for backup: Event Log Registry RSM I'm wondering if by default, incremental backup does not back up all of the System Objects? Do I need to specify something in the DSM.OPT file or in a client optionset to get it to do all the system objects in Active Directory? Thanks, Julie Phinney
Re: Ordering license upgrades
Nikolai Sonin System Architect ESI Group 28381 Encina Drive Suite 100 Winters CA, 95694-9007 530-795-0200 ext. 235 Thomas Denier [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 05/17/2002 12:35 PM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Ordering license upgrades We have a TSM 4.2.1.9 server running under OS/390. We are about to order more client licenses. The last time we did this IBM and/or Tivoli required us to tell them how the new licenses would be divided among different platforms: how many for Windows NT, how many for AIX, and so on. The charge per client license is the same regardless of operating system. The 'register license' command does not provide any means for distinguishing between Windows NT licenses, AIX licenses, and so on. Why in the world do we need to provide platform information in order to get more client licenses? So that Tivoli can know what clients are being used the most in customer sites. This allows them to get the right mix of support people and what clients should be patched and tested first. It also helps Tivoli developers develop business cases for improving clients. The Novel client is not as popular as the NT client, and look where all the development dollars are going.
Re: Tuning TSM
Reading thru this thread, no one has mentioned that backup will be slower than archive -- for TWO significant reasons: 1. The standard progressive-incremental requires alot of work in comparing the attributes of all files in the affected file systems, especially for a LARGE number of files/directories (whereas archive has minimal database overhead -- it just moves data). 2. Writes to disk are NOT as fast as tape IF the data can be delivered to the tape device at streaming speed; this is especially true if using no-RAID or RAID-5 for disk pool striping (with parity)... RAID-0 might compete if multiple paths controllers are configured. The big advantage to disk pools is more concurrent backup/archive operations, then disk-migration can stream offload the data to tape. So, firstly, debug fundamentals using tar and archive commands (to eliminate db overhead comparing file system attributes to identify changed files/objects); once you are satisfied with the thruput for archive, allow 20-50% overhead for daily incremental. If your best incremental experience is not satisfactory, (but archive is okay) consider other options discussed in the performance-tuning papers -- such as, reducing the number of files per file system, use incrbydate during the week, increase horsepower on the client machine and/or TSM server (depending on where the incr. bottlenecks are). The SHARE archives do not yet have the Nashville proceedings posted; when they do show up, they are in the members-only area (I was just there, searching for other sessions). - Original Message - From: Ignacio Vidal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 17, 2002 6:30 AM Subject: Re: Tuning TSM Zlatko: OK: tcpwindowsize is in KBytes (actually my setting is 1280). I have the same question (why client is idling?). We have users working on that server from 9:00 until 22:00 (every day...), backup jobs start about 00:15/01:15 I've monitored the nodes in disk i/o operations and network transfers, in different moments of the day. About cpu load/memory usage/pagination: the values are all OK, for example: - cpu load (usr) has an average of 5~7 during all day - memory usage (have 7GB RAM) is not a problem (about 30~40% for computational the same for noncomp) - pagination: max use may be 10~12% (mostly of the day 0.5%, peaks during user's work time) Viewing your results (500GB in 3:10hs), and trying to compare: we're backing up 250GB starting 00:15 and ending 07:00... 250GB in 6:45hs (it's not good) Yesterday I set resource utilization = 10 too, and performance was the same (really a bit worst). I think there are multiple problems (and our provider -IBM- cannot help us): First of all: disk performance (IBM should tell us how to get the best from FastT500), we have from 15 to 25 MB/sec in the storage... Then: all TSM nodes in our installation have not the same file configuration. I explain a bit more this: we have nodes merging a lot of files (25) with an average size of 40KB each and a few files (1000) with an average size of 50MB (it's Oracle Financials: the database server keeps datafiles and files belonging to application and DB motor). We have 4 nodes such as just described, with a total of 35~40GB for each (average and growing...) Well, here was a brief description. I'm listening for new ideas. Thanks Ignacio -Mensaje original- De: Zlatko Krastev [mailto:[EMAIL PROTECTED]] Enviado el: viernes, 17 de mayo de 2002 5:29 Para: [EMAIL PROTECTED] Asunto: Re: Tuning TSM Just a point TCPWindowsize parameter is measured in kilobytes not bytes. And according to Administrator's reference it must be between 0 and 2048. If not in range on client complains with ANS1036S for invalid value. On server values out of range mean 0, i.e. OS default. However this are side remarks. The main question is why client is idling. Have you monitored the node during to disk and to tape operation? Is migration starting during backup? Are you using DIRMC. You wrote client compression - what is the processor usage (user)? What is the disk load - is the processor I/O wait high? Is the paging space used - check with svmon -P. You should get much better results. For example recently we've achieved 500 GB in 3h10m - fairly good. It was similar to your config - AIX nodeserver, client compression, disk pool, GB ether. Ether was driven 10-25 MB/s depending on achieved compression. The bottleneck was EMC Symmetrix the node was reading from but another company was dealing with it and we were unable to get more than 60-70 MB/s read. Resourceutilization was set to 10. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Re: Tuning TSM Zlatko: Here are the answers: Have you tested what is the performance of FAStT 500 disks? Those were mid-class disk
Re: Backing up Active Directory on Win2000
Julie, To add to Tim's comments. The TSM B/A client processes all system objects which are active on the machine; there are now a total of eleven of these system objects (added the WMI db support in TSM 5.1.0) of which only a subset will be valid on a given machine. This subset depends both on the flavor of Windows 2000 installed (e.g., Pro vs. Server vs. Adv. Server ...) and which Windows components are installed (e.g., Active Directory is available with the W2k server edition but only active if it is installed). You can expand the System Object container in the Windows B/A GUI to see which system objects are active. Also, you can issue the command SHOW SYSTEMOBJECT (not documented) and see which objects are active: statrc system object --- - OK COM+ Database n/a 4312Certificate Server Database OK Event Log ... OK WMI Database From this you can see that the COM+, Event Log and WMI Database are active but Cert. Server is not .. (I only showed partial output). As Tim mentions, the QUERY SYSTEMOBJECT shows you what is actually backed-up to the TSM server. Hope this helps, Jim Smith TSM Development ... From the Backup/Archive Command line clinet (dsmc), enter q systemobject. It should show you the last backup date of all system objects. tsm q systemobject Size Backup DateMgmt Class A/I File ----- --- 7,750 05/17/2002 00:04:27DEFAULT A SYSTEM OBJECT\SERVER1\compdb 717,644 05/17/2002 00:04:28DEFAULT A SYSTEM OBJECT\SERVER1\EVENTLOG 140,726,199 05/17/2002 00:04:34DEFAULT A SYSTEM OBJECT\SERVER1\SYSFILES 21,533,875 05/17/2002 00:11:37DEFAULT A SYSTEM OBJECT\SERVER1\SYSVOL 94,404,688 05/17/2002 00:14:20DEFAULT A SYSTEM OBJECT\SERVER1\NTDS 4,318,790 05/17/2002 00:14:32DEFAULT A SYSTEM OBJECT\SERVER1\REGISTRY 20,883 05/17/2002 00:14:34DEFAULT A SYSTEM OBJECT\SERVER1\RSM -Original Message- From: Julie Phinney [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 2:57 PM To: [EMAIL PROTECTED] Subject: Re: Backing up Active Directory on Win2000 Thanks, Tim, What's a Q systemobject? That command doesn't seem to produce anything, do I have it wrong? Thanks, Julie Rushforth, Tim [EMAIL PROTECTED] To: [EMAIL PROTECTED] IPEG.MB.CA cc: Sent by: ADSM: Subject: Re: Backing up Active Directory on Win2000 Dist Stor Manager [EMAIL PROTECTED] DU 05/16/2002 05:48 PM Please respond to ADSM: Dist Stor Manager Incremental backup process all of the system ojbects on our Windows 2000 Domain Controllers. I've done full restores with many client versions including 4.2.1.20 and 4.12.12. The default is to include system objects with DOMAIN ALL-LOCAL. What is your domain statement? Have you done a q systemobject from the b/a command line? Tim Rushforth City of Winnipeg -Original Message- From: Julie Phinney [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 4:11 PM To: [EMAIL PROTECTED] Subject: Backing up Active Directory on Win2000 Hi all, I'm not familiar with Active Directory on Win2000 but I've been told by one of our Win2000 guys : There is a System Object selection list that includes the following items to backup using TSM: Active Directory, COM+ DB, Event Log, Registry, RSM, System Files, System Volume But it appears like only the following System Objects are currently being selected for backup: Event Log Registry RSM I'm wondering if by default, incremental backup does not back up all of the System Objects? Do I need to specify something in the DSM.OPT file or in a client optionset to get it to do all the system objects in Active Directory? Thanks, Julie Phinney
Re: TSM FLASH: UNIX BACKUP-ARCHIVE CLIENT V4.2.2
Paul (or anyone), I'm not aware of the problem you ran into. Do you know if it was fixed in the 4.2.1.30 Windows client? Is there an APAR for this problem that I could look at? Thanks. At 04:31 PM 5/17/2002 -0400, you wrote: Jim, I would like to thank you for publishing this information. We got bit by the windows client at 4.2.1.20 and 4.2.1.26 failing half way through a backup because of a locked file and the backup looking successful. The result was we lost many backups for about 10 days without realizing it. The problem was fixed by the 4.2.2 Windows client. I recommend everyone go to that level if they are running 4.2.1.15 server (anything higher than 4.2.1.11). We think the problem was introduced by us going to that level of the server. It would be really nice if the action you took here for this problem had been taken for this backup integrity problem as well. It is really unacceptable to lose backups or have backups with integrity problems because of not having the information on a known problem. This forum is documented everywhere and used by many customers. It is a great way to get this kind of information out. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -Original Message- From: Jim Smith [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 3:57 PM To: [EMAIL PROTECTED] Subject: TSM FLASH: UNIX BACKUP-ARCHIVE CLIENT V4.2.2 Importance: High Problem Description: The TSM 4.2.2 UNIX backup-archive clients may produce error messages similar to the following when performing incremental backup of files with hard links: ANS1228E Sending of object 'filename' failed ANS4018E Error processing 'filename': file name too long where filename is the name of the file that failed to back up. It is important to note that file names experiencing this problem are NOT too long. Message ANE4018E (same text as ANS4018E above) may also be logged to the TSM server. This problem affects files that have hard links. For affected files, the problem occurs only during incremental backup. SELECTIVE backup of these files works correctly. For files that have hard links, both the link and the original file may be affected by this problem: If the original file does not have a backup version on the TSM server, then the original file will experience the problem. If the hard link does not have a backup version on the TSM server, then the hard link will experience the problem. Files with hard links where the file already has a backup version (regardless of whether the link has a backup version) are unaffected. Hard links where the link already has a backup version (regardless of whether the original file has a backup version) are unaffected. Files that have no hard links are unaffected. Client APAR IC33645 has been opened to address this problem. The version 4.2.2 UNIX clients have been removed from the FTP download site. They will soon be replaced with newer client code that fixes this problem. Circumvention: Use SELECTIVE backup to back up those files that are affected by this problem. They can be identified by reviewing the ANS1228E and ANS4018E messages in the dsmerror.log file. The backup-archive GUI may also be used to back up these files. From the GUI, be sure to select the Always backup option (located in the drop-down list to the left of the Help button). Alternatively, customers who were running an earlier 4.2.x version of the client can remove 4.2.2 and reinstall the earlier version. Customers who upgraded from version 4.1.x or below can not back off, and must use the circumvention described above. We plan on having a fix available soon, so this circumvention is viewed as being very short-term. Users Affected: All TSM 4.2.2 UNIX backup-archive clients. Recommendation: Apply fixing code when available. We anticipate that the fix will be delivered on or before the end of May 2002. This statement was prepared by TSM Backup-Archive client development and system test
Re: Reclamation is not happening - HELP!
Jack, As TSM ages backup and archive data, the files only get 'marked' for deletion. You must run an EXPIRE INVENTORY command to actually flip the switch from 'marked' for deletion to deleted. Then your storage pool reclamation should work. That is, unless I am missing something too!!! 8-) John G. Talafous IS Technical Principal The Timken CompanyGlobal Software Support P.O. Box 6927 Data Management 1835 Dueber Ave. S.W. Phone: (330)-471-3390 Canton, Ohio USA 44706-0927 Fax : (330)-471-4034 [EMAIL PROTECTED] http://www.timken.com -Original Message- From: Coats, Jack [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 1:50 PM To: [EMAIL PROTECTED] Subject: Reclamation is not happening - HELP! My tape use is going up, but nothing is being reclaimed from my copy pool. I must have done something wrong, but where do I go to look for whatever is wrong first? What am I missing? I can find nothing in the activity log, and even when I do a update stg copypool rec=5 and it should recover a lot, nothing happens. Sometimes the process starts up, but will sit for hours and nothing gets reclaimed. Running TSM 4.1.5 on NT, with 3583 library and LTO drives. It has been working, but stopped earlier this week. ... TIA ... Jack
Re: Ordering license upgrades
'cause there is no published rule how to convert points to processors. I am trying to find the answer since the announcement of new licensing scheme but still without success. Just ask them for NN processors or MM points. In both cases you have the right to use them on different platforms. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Ordering license upgrades We have a TSM 4.2.1.9 server running under OS/390. We are about to order more client licenses. The last time we did this IBM and/or Tivoli required us to tell them how the new licenses would be divided among different platforms: how many for Windows NT, how many for AIX, and so on. The charge per client license is the same regardless of operating system. The 'register license' command does not provide any means for distinguishing between Windows NT licenses, AIX licenses, and so on. Why in the world do we need to provide platform information in order to get more client licenses?
Re: Tuning TSM
Hi Don, I looked for incrbydate in the installation guide and reference manual for this option but haven't found it. Can I use this for Solaris clients? -Bern Ruelas Cadence Design Systems - Storage Sr. Systems Engineer -Original Message- From: Don France (TSMnews) [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 2:27 PM To: [EMAIL PROTECTED] Subject: Re: Tuning TSM Reading thru this thread, no one has mentioned that backup will be slower than archive -- for TWO significant reasons: 1. The standard progressive-incremental requires alot of work in comparing the attributes of all files in the affected file systems, especially for a LARGE number of files/directories (whereas archive has minimal database overhead -- it just moves data). 2. Writes to disk are NOT as fast as tape IF the data can be delivered to the tape device at streaming speed; this is especially true if using no-RAID or RAID-5 for disk pool striping (with parity)... RAID-0 might compete if multiple paths controllers are configured. The big advantage to disk pools is more concurrent backup/archive operations, then disk-migration can stream offload the data to tape. So, firstly, debug fundamentals using tar and archive commands (to eliminate db overhead comparing file system attributes to identify changed files/objects); once you are satisfied with the thruput for archive, allow 20-50% overhead for daily incremental. If your best incremental experience is not satisfactory, (but archive is okay) consider other options discussed in the performance-tuning papers -- such as, reducing the number of files per file system, use incrbydate during the week, increase horsepower on the client machine and/or TSM server (depending on where the incr. bottlenecks are). The SHARE archives do not yet have the Nashville proceedings posted; when they do show up, they are in the members-only area (I was just there, searching for other sessions). - Original Message - From: Ignacio Vidal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 17, 2002 6:30 AM Subject: Re: Tuning TSM Zlatko: OK: tcpwindowsize is in KBytes (actually my setting is 1280). I have the same question (why client is idling?). We have users working on that server from 9:00 until 22:00 (every day...), backup jobs start about 00:15/01:15 I've monitored the nodes in disk i/o operations and network transfers, in different moments of the day. About cpu load/memory usage/pagination: the values are all OK, for example: - cpu load (usr) has an average of 5~7 during all day - memory usage (have 7GB RAM) is not a problem (about 30~40% for computational the same for noncomp) - pagination: max use may be 10~12% (mostly of the day 0.5%, peaks during user's work time) Viewing your results (500GB in 3:10hs), and trying to compare: we're backing up 250GB starting 00:15 and ending 07:00... 250GB in 6:45hs (it's not good) Yesterday I set resource utilization = 10 too, and performance was the same (really a bit worst). I think there are multiple problems (and our provider -IBM- cannot help us): First of all: disk performance (IBM should tell us how to get the best from FastT500), we have from 15 to 25 MB/sec in the storage... Then: all TSM nodes in our installation have not the same file configuration. I explain a bit more this: we have nodes merging a lot of files (25) with an average size of 40KB each and a few files (1000) with an average size of 50MB (it's Oracle Financials: the database server keeps datafiles and files belonging to application and DB motor). We have 4 nodes such as just described, with a total of 35~40GB for each (average and growing...) Well, here was a brief description. I'm listening for new ideas. Thanks Ignacio -Mensaje original- De: Zlatko Krastev [mailto:[EMAIL PROTECTED]] Enviado el: viernes, 17 de mayo de 2002 5:29 Para: [EMAIL PROTECTED] Asunto: Re: Tuning TSM Just a point TCPWindowsize parameter is measured in kilobytes not bytes. And according to Administrator's reference it must be between 0 and 2048. If not in range on client complains with ANS1036S for invalid value. On server values out of range mean 0, i.e. OS default. However this are side remarks. The main question is why client is idling. Have you monitored the node during to disk and to tape operation? Is migration starting during backup? Are you using DIRMC. You wrote client compression - what is the processor usage (user)? What is the disk load - is the processor I/O wait high? Is the paging space used - check with svmon -P. You should get much better results. For example recently we've achieved 500 GB in 3h10m - fairly good. It was similar to your config - AIX nodeserver, client compression, disk pool, GB ether. Ether was driven 10-25 MB/s depending on achieved compression. The bottleneck was EMC Symmetrix the node was reading from but another company was dealing with it and we were unable to get more than 60-70 MB/s
Re: tdpoconf error ANU2534E
Hi, thanks for your help, I`ve tried doing the modifications you suggested me but with no luck, i keep getting the same messages in the tdpoerror: ANU2603E The option 9 in file tdpo.opt ANU2537E Error found while parsing options in TDP for Oracle options file ANU2534E Option file error I`m using: In /usr/tivoli/tsm/client/oracle/bin/tdpo.opt DSMI_ORC_CONFIG /usr/tivoli/tsm/client/oracle/bin/dsm.opt TDPO_NODE desareg_tdp TDPO_OWNER root In /usr/tivoli/tsm/client/oracle/bin/dsm.opt Servername TSM390 In /usr/tivoli/tsm/client/api/bin/dsm.sys servername TSM390 commm tcpip tcpport 1500 tcps131.1.20.68 Could you please point me in some direction? Thanks Luis From: Neil Rasmussen [EMAIL PROTECTED] Reply-To: ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: tdpoconf, error, ANU2534E Date: Fri, 17 May 2002 07:54:42 -0700 Luis, I apologize, that is a pretty useless message (and not very helpful). But regardless, I think I can help you out. First off, are you using the tdpo.opt in the installation directory or are you defining it in your own directory? To start, I would use default installation directory /usr/tivoli/tsm/client/oracle/bin with the following in my tdpo.opt, substituting for your environment: In your /usr/tivoli/tsm/client/oracle/bin/tdpo.opt: DSMI_ORC_CONFIG /usr/tivoli/tsm/client/oracle/bin/dsm.opt TDPO_NODE node TDPO_OWNER owner In your /usr/tivoli/tsm/client/oracle/bin/dsm.opt: Servername your dsm.sys stanza servername In your /usr/tivoli/tsm/client/api/bin/dsm.sys: servername match from dsm.opt commm tcpip tcpport your TSM Server port number tcpsyour TSM Server address You should be able to establish a connection with your server with these basic settings. Then you should run tdpoconf password. Hope this helps. -- Date:Fri, 17 May 2002 03:23:15 + From:Luis Tapia [EMAIL PROTECTED] Subject: tdpoconf, error, ANU2534E Hi List, I`ve been trying to install TDP for Oracle for AIX 2.2.1 in a AIX 5.1 box, but I can not make the utility TDPOCONF work, it seems that my tdpo.opt file is not right but I cant not find where the problem is, when I issue and tdpoconf showenv or try to set the password I get an ANU 2534E Option file error the file tdpoerror.log is not very helpful, can somebody send me a working tdpo.opt/dsm.opt/dsm.sys set so i can use them as example? thanks for your help. Luis Regards, Neil Rasmussen Software Development TDP for Oracle [EMAIL PROTECTED] _ Join the world s largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: Ordering license upgrades
And while we're on the subject of licenses and upgrades, I was informed by my reseller that Tivoli has withdrawn the TSM Enterprise Edition from marketing. All of the constituent parts are still available, but you can not purchase the bundle. Word is that it was too confusing to end users. I hope it didn't also have to do with the fact that our software quote went up by $70,000 when the change was made. -- Tom Thomas A. La Porte, DreamWorks SKG mailto:[EMAIL PROTECTED] On Sat, 18 May 2002, Zlatko Krastev wrote: 'cause there is no published rule how to convert points to processors. I am trying to find the answer since the announcement of new licensing scheme but still without success. Just ask them for NN processors or MM points. In both cases you have the right to use them on different platforms. Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Ordering license upgrades We have a TSM 4.2.1.9 server running under OS/390. We are about to order more client licenses. The last time we did this IBM and/or Tivoli required us to tell them how the new licenses would be divided among different platforms: how many for Windows NT, how many for AIX, and so on. The charge per client license is the same regardless of operating system. The 'register license' command does not provide any means for distinguishing between Windows NT licenses, AIX licenses, and so on. Why in the world do we need to provide platform information in order to get more client licenses?
Re: TSM FLASH: UNIX BACKUP-ARCHIVE CLIENT V4.2.2
That may be why we did not see it on all of our clients. It may turn out that 4.2.1.30 does not have the problem. However, this problem did not crop up until we put on 4.2.1.15 TSM server. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -Original Message- From: Paul Zarnowski [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 6:12 PM To: [EMAIL PROTECTED] Subject: Re: TSM FLASH: UNIX BACKUP-ARCHIVE CLIENT V4.2.2 Paul (or anyone), I'm not aware of the problem you ran into. Do you know if it was fixed in the 4.2.1.30 Windows client? Is there an APAR for this problem that I could look at? Thanks. At 04:31 PM 5/17/2002 -0400, you wrote: Jim, I would like to thank you for publishing this information. We got bit by the windows client at 4.2.1.20 and 4.2.1.26 failing half way through a backup because of a locked file and the backup looking successful. The result was we lost many backups for about 10 days without realizing it. The problem was fixed by the 4.2.2 Windows client. I recommend everyone go to that level if they are running 4.2.1.15 server (anything higher than 4.2.1.11). We think the problem was introduced by us going to that level of the server. It would be really nice if the action you took here for this problem had been taken for this backup integrity problem as well. It is really unacceptable to lose backups or have backups with integrity problems because of not having the information on a known problem. This forum is documented everywhere and used by many customers. It is a great way to get this kind of information out. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -Original Message- From: Jim Smith [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 3:57 PM To: [EMAIL PROTECTED] Subject: TSM FLASH: UNIX BACKUP-ARCHIVE CLIENT V4.2.2 Importance: High Problem Description: The TSM 4.2.2 UNIX backup-archive clients may produce error messages similar to the following when performing incremental backup of files with hard links: ANS1228E Sending of object 'filename' failed ANS4018E Error processing 'filename': file name too long where filename is the name of the file that failed to back up. It is important to note that file names experiencing this problem are NOT too long. Message ANE4018E (same text as ANS4018E above) may also be logged to the TSM server. This problem affects files that have hard links. For affected files, the problem occurs only during incremental backup. SELECTIVE backup of these files works correctly. For files that have hard links, both the link and the original file may be affected by this problem: If the original file does not have a backup version on the TSM server, then the original file will experience the problem. If the hard link does not have a backup version on the TSM server, then the hard link will experience the problem. Files with hard links where the file already has a backup version (regardless of whether the link has a backup version) are unaffected. Hard links where the link already has a backup version (regardless of whether the original file has a backup version) are unaffected. Files that have no hard links are unaffected. Client APAR IC33645 has been opened to address this problem. The version 4.2.2 UNIX clients have been removed from the FTP download site. They will soon be replaced with newer client code that fixes this problem. Circumvention: Use SELECTIVE backup to back up those files that are affected by this problem. They can be identified by reviewing the ANS1228E and ANS4018E messages in the dsmerror.log file. The backup-archive GUI may also be used to back up these files. From the GUI, be sure to select the Always backup option (located in the drop-down list to the left of the Help button). Alternatively, customers who were running an earlier 4.2.x version of the client can remove 4.2.2 and reinstall the earlier version. Customers who upgraded from version 4.1.x or below can not back off, and must use the circumvention described above. We plan on having a fix available soon, so this circumvention is viewed as being very short-term. Users Affected: All TSM 4.2.2 UNIX backup-archive clients. Recommendation: Apply fixing code when available. We anticipate that the fix will be delivered on or before the end of May 2002. This statement was prepared by TSM Backup-Archive client development and system test
