Re: Using tsm-encryption and want to change the hostname at the Client
Alexei, thanks a lot for your detailled explanation ! It's clearer to me now :-) ... just only two more questions ? What about the windows-Clients - do I then (when changing the windows system-name) also have to manually remove the equivalent 'TSM.PWD' entry in the registry or elsewhere ? if so: Is that something to be done with the windows registry-editor or is there a tsm-windows-client function that can do for me the renaming/refresh of the locally stored tsm-pwds on windows so I can reenter the (same) encryption key passord once again ? About the 'using some garbage encryption key' : Isn't that something where the tsm-client really should say 'NO' stop backup and generate an error message ? ... preventing the user to have something unrecoverable - is there an existing apar ? Best regards Rainer Alexei Kojenov schrieb: Rainer, Your data is always encrypted with the key generated from the password that you enter, regardless of the hostname. The hostname is only used to store the password locally. For example, 1) Let's say the hostname is 'mercury' 2) You run your first backup and are prompted for encryption key password. Let's say you enter 'secret' 3) The string 'secret' is encrypted with 'mercury' and is stored in TSM.PWD 4) The data are encrypted with 'secret'. 5) On the next backup, the stored password is retrieved from TSM.PWD and decrypted with 'mercury', and 'secret' is used for data backup. 6) Let's say you change the hostname to 'venus' and delete/rename existing TSM.PWD 7) TSM prompts you for encryption key password and you enter 'secret' again. 8) 'secret' is encrypted with 'venus' and is stored in TSM.PWD (note, TSM.PWD will binary differ from the one from step 3, because the key, which is dependent on hostname, is different) 9) The data are encrypted with 'secret' (the same as in step 4, regardless of hostname). 10) On the next backup, stored password is decrypted with 'venus', and the same password 'secret' is used for backup. So you shouldn't worry about validity of your old backups as long as you use the same encryption password and you deleted/renamed TSM.PWD when changing the hostname. The problems come when someone changes the hostname bud does not delete TSM.PWD. In the example above, a backup following the hostname change will try to decrypt stored password with 'venus' and will get an incorrect result (because 'secret' was originally encrypted with 'mercury'!), so the new backups will be using some garbage encryption key, and it would be really hard to restore the new data correctly if TSM.PWD is lost or if the restore happens on a different machine. Alexei "ADSM: Dist Stor Manager" wrote on 07/27/2006 06:31:17 AM: Hi Alexei, thanks for your hint - now i come with a new question concerning the 'restore' : Because nothing changes other than the 'hostname' of that linux system ... ... what about the data that has been backed up prior to the time I rename the hostname and reenter the 'encryption key password' ? Because I stay with 'encryptkey save' what happens when (some time) I may do a full restore of the '/home/' -Filespace ? Because this Filespace '/home/' has data backed up that is encrypted with both encryption-key-usage of the old and the new 'hostname' ( but always the same 'tsm-Nodename' ) ... will I am able to restore(and decrypt) all of it ? ... i fear to go into problems - Or do I have to start backup again from 'zero' - for example : by renaming the filespace on the server at the time changing the hostname ? Thanks again for any hints ! -- that is something really confusing to me :-| Rainer Alexei Kojenov schrieb: Rainer, You need to make TSM client prompt you for encryption key password on the next backup after you changed the hostname. The only way to do this is to rename/remove the existing TSM.PWD file (this is the file where TSM client stores its passwords). You should rename this file rather than delete it, in case you have problems and want to revert. Alexei --- Dear TSmers, we have tsmserver 5.3.3.2 /solaris and tsm-Client 5.3.4.0 /linux. On the Client we use tsm-encryption : The 'nodename' Option is set in the dsm.sys and also the 'encryptkey save' OPtion is set and 'encryptiontype AES128' is also set. The inclexc-File contains a line like 'include.encrypt *' So far anything runs fine :-) Problem: Next week we have to change the 'hostname' of that linux-server. The Question now is : - if any - what steps are to be done at the tsm-Client ? ... and even at the tsm-server ? The (tsm)nodename won't be changed. Do I need the TSM-Client in a manual way give once again the encryption-key password to let the encryption-key be generated ? Or is there nothing to be done at the Client ? I have looked throgh the lists and docs and havent't found any 'procedures' for that scenario - just pointers to dependancies on the system's hostname. Thanks in advance for any hints , recipe or
Re: Using tsm-encryption and want to change the hostname at the Client
Rainer, Your data is always encrypted with the key generated from the password that you enter, regardless of the hostname. The hostname is only used to store the password locally. For example, 1) Let's say the hostname is 'mercury' 2) You run your first backup and are prompted for encryption key password. Let's say you enter 'secret' 3) The string 'secret' is encrypted with 'mercury' and is stored in TSM.PWD 4) The data are encrypted with 'secret'. 5) On the next backup, the stored password is retrieved from TSM.PWD and decrypted with 'mercury', and 'secret' is used for data backup. 6) Let's say you change the hostname to 'venus' and delete/rename existing TSM.PWD 7) TSM prompts you for encryption key password and you enter 'secret' again. 8) 'secret' is encrypted with 'venus' and is stored in TSM.PWD (note, TSM.PWD will binary differ from the one from step 3, because the key, which is dependent on hostname, is different) 9) The data are encrypted with 'secret' (the same as in step 4, regardless of hostname). 10) On the next backup, stored password is decrypted with 'venus', and the same password 'secret' is used for backup. So you shouldn't worry about validity of your old backups as long as you use the same encryption password and you deleted/renamed TSM.PWD when changing the hostname. The problems come when someone changes the hostname bud does not delete TSM.PWD. In the example above, a backup following the hostname change will try to decrypt stored password with 'venus' and will get an incorrect result (because 'secret' was originally encrypted with 'mercury'!), so the new backups will be using some garbage encryption key, and it would be really hard to restore the new data correctly if TSM.PWD is lost or if the restore happens on a different machine. Alexei "ADSM: Dist Stor Manager" wrote on 07/27/2006 06:31:17 AM: > Hi Alexei, > > thanks for your hint - now i come with a new question concerning the > 'restore' : > Because nothing changes other than the 'hostname' of that linux system ... > ... what about the data that has been backed up prior to the time > I rename the hostname and reenter the 'encryption key password' ? > > Because I stay with 'encryptkey save' what happens when (some time) > I may do a full restore of the '/home/' -Filespace ? > > Because this Filespace '/home/' has data backed up that is encrypted > with both encryption-key-usage of the old and the new 'hostname' > ( but always the same 'tsm-Nodename' ) > ... will I am able to restore(and decrypt) all of it ? > > ... i fear to go into problems - Or do I have to start backup again > from 'zero' - for example : > by renaming the filespace on the server > at the time changing the hostname ? > > Thanks again for any hints ! > -- that is something really confusing to me :-| > > Rainer > > > > Alexei Kojenov schrieb: > > > Rainer, > > > > You need to make TSM client prompt you for encryption key password on the > > next backup after you changed the hostname. The only way to do this is to > > rename/remove the existing TSM.PWD file (this is the file where TSM client > > stores its passwords). You should rename this file rather than delete it, > > in case you have problems and want to revert. > > > > Alexei > > > > --- > > > > Dear TSmers, > > > > we have tsmserver 5.3.3.2 /solaris and tsm-Client 5.3.4.0 /linux. > > > > On the Client we use tsm-encryption : > > The 'nodename' Option is set in the dsm.sys and also the > > 'encryptkey save' OPtion is set and 'encryptiontype AES128' is also set. > > The inclexc-File contains a line like 'include.encrypt *' > > So far anything runs fine :-) > > > > Problem: Next week we have to change the 'hostname' of that linux-server. > > The Question now is : - if any - what steps are to be done at the > > tsm-Client ? > > ... and even at the tsm-server ? > > The (tsm)nodename won't be changed. > > Do I need the TSM-Client in a manual way give once again the > > encryption-key password to let the encryption-key be generated ? > > Or is there nothing to be done at the Client ? > > > > I have looked throgh the lists and docs and havent't found any > > 'procedures' for that scenario - just pointers to dependancies on the > > system's hostname. > > > > Thanks in advance for any hints , recipe or links ... ! > > Rainer > > > > > > -- > > > > Rainer Wolf eMail: [EMAIL PROTECTED] > > kiz - Abt. Infrastruktur Tel/Fax: ++49 731 50-22482/22471 > > Universitaet Ulm wwweb: http://kiz.uni-ulm.de > > > > > > -- > > Rainer Wolf eMail: [EMAIL PROTECTED] > kiz - Abt. Infrastruktur Tel/Fax: ++49 731 50-22482/22471 > Universitaet Ulm wwweb:http://kiz.uni-ulm.de
Re: ACSLS ejects not working... help!
This could be just normal process. Sometimes when all TSM drives are all in use or mounted, move media command will fail. Even you tell not to check label, when label is not readable, it will still need to mount the tape into the drive for processing. Thanks, Sung Y. Lee "ADSM: Dist Stor Manager" wrote on 07/31/2006 11:27:14 AM: > Hello everyone, > > I have TSM 5.2.7.1 on AIX 5.3 and I also have an STK SL8500 with IBM LTO2 > tapes/drives. I'm just doing a move media and trying to eject all of our > NAS NDMP backup tapes. As you can see it is failing. My main question > is: Is this a TSM server issue or a library issue? I have been doing this > for over 2 years now and have not had any issues ejecting the tapes, but > for the past 2 ejects the tapes ARE ejecting from the library, but within > TSM it is stating that it there is a timeout issue and it doesn't update > the tapes as mountablenotinlib. Any ideas/suggestions would be > appreciated! Thanks! > > Date/Time Message > > -- > 07/31/06 10:15:19 ANR2017I Administrator OPERATIONS issued command: > MOVE >MEDIA * stg=tape_ndmp_offsite > wherestate=mountableinlib >wherestatus=ful,fil rem=b checkl=n ovflo="Vital >Records,Inc." (SESSION: 308754) > 07/31/06 10:15:19 ANR0984I Process 8407 for MOVE MEDIA started in the > >BACKGROUND at 10:15:19. (SESSION: 308754, PROCESS: > 8407) > 07/31/06 10:15:19 ANR0609I MOVE MEDIA started as process 8407. > (SESSION: >308754, PROCESS: 8407) > 07/31/06 10:15:19 ANR0610I MOVE MEDIA started by OPERATIONS as process > 8407. >(SESSION: 308754, PROCESS: 8407) > 07/31/06 10:15:19 ANR2017I Administrator OPERATIONS issued command: > MOVE >MEDIA * stg=tape_ndmp_offsite > wherestate=mountableinlib >wherestatus=ful,fil rem=b checkl=n ovflo="Vital >Records,Inc." (SESSION: 308755) > 07/31/06 10:15:19 ANR0984I Process 8408 for MOVE MEDIA started in the > >BACKGROUND at 10:15:19. (SESSION: 308755, PROCESS: > 8408) > 07/31/06 10:15:19 ANR0609I MOVE MEDIA started as process 8408. > (SESSION: >308755, PROCESS: 8408) > 07/31/06 10:15:19 ANR0610I MOVE MEDIA started by OPERATIONS as process > 8408. >(SESSION: 308755, PROCESS: 8408) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00173 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00178 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00185 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00186 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00189 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00191 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00194 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00246 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00247 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00466 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00633 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00637 >in library NASLIB starting. (SESSION: 308754, > PROCESS: >8407) > 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume > N00
Re: 3592 tape read performance
There *is* a way to get TSM to stop data movement mid-file. It's ugly. And I've had to use it in similar circumstances. Halt the TSM server. I still don't understand *why* we can't get a cancel process with force option. Tom Kauffman NIBCO, Inc -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Denier Sent: Monday, July 31, 2006 3:09 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: 3592 tape read performance -"Survoy, Bernard J" <[EMAIL PROTECTED]> wrote: - >Sounds like you have an issue on some volumes with the VCR (volume >control region). This structure is used (among other things) to >support high speed search operations. If the VCR is invalid or >damaged, the drive will go into a low speed (essentially sequential >scan) until you get to the data location you want (takes forever, >if you look at the drive, it looks like it is reading tape). I know >on Sun/STK enterprise class drives, we have a similar structure >called the MIR (media information record); this structure is >rebuilt during the sequential scan up to the point where you >successfully locate the data. A subsequent access beyond this >point is will rebuild the structure from that point forward. Just how slow is the linear scan? I am in the process of executing a 'move data' for a problem volume. The process moved 22 gigabytes in the first hour or so, and has ostensibly spent almost 5 hours working on a single 4.7 gigabyte file. How long should I wait for this one file before I conclude that I have a problem other than lost VCR information? What do I do if I decide at some point that the 'move data' is a lost cause, and want to try 'restore volume' instead? The 'cancel process' command is cleverly designed to be useless in this sort of situation; the process will not end until it finishes the current file. Is there a way to get TSM to stop a data movement process inmid-file? CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message.
Re: 3592 tape read performance
-"Survoy, Bernard J" <[EMAIL PROTECTED]> wrote: - >Sounds like you have an issue on some volumes with the VCR (volume >control region). This structure is used (among other things) to >support high speed search operations. If the VCR is invalid or >damaged, the drive will go into a low speed (essentially sequential >scan) until you get to the data location you want (takes forever, >if you look at the drive, it looks like it is reading tape). I know >on Sun/STK enterprise class drives, we have a similar structure >called the MIR (media information record); this structure is >rebuilt during the sequential scan up to the point where you >successfully locate the data. A subsequent access beyond this >point is will rebuild the structure from that point forward. Just how slow is the linear scan? I am in the process of executing a 'move data' for a problem volume. The process moved 22 gigabytes in the first hour or so, and has ostensibly spent almost 5 hours working on a single 4.7 gigabyte file. How long should I wait for this one file before I conclude that I have a problem other than lost VCR information? What do I do if I decide at some point that the 'move data' is a lost cause, and want to try 'restore volume' instead? The 'cancel process' command is cleverly designed to be useless in this sort of situation; the process will not end until it finishes the current file. Is there a way to get TSM to stop a data movement process inmid-file?
Re: audito data missing
Look up the reference info for the QUERY AUDITOCCUPANCY command, either in the Admin Reference or by running "HELP QUERY AUDITOCCUPANCY" from the admin CLI. Therein lies your answer. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] IBM Tivoli Storage Manager support web page: http://www-306.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. "ADSM: Dist Stor Manager" wrote on 07/31/2006 10:43:08 AM: > A customer ran a backup from the command line of the files in one > directory on a Windows 2003 node on Friday. When he runs q backup > "C:\\*" TSM returns a list of file descriptions and > sizes. About 10 Gb in all, mostly .iso files. Today, when I run 'q > audito *' from the TSM server, the node is listed, but 'Backup > Storage Used' is 0 mb. > > Is there something wrong here, or does the data in 'audito' get > refreshed on a cycle that hasn't expired yet? > > We run TSM 5.3.0.2 on AIX 5.2. The Windows 2003 node is running TSM > client 5.3.3. > > Thank you, > Keith Arbogast > Indiana University
Re: Configuring new 3592-E05 drives
Yep. Used tapeutil to get their serial # and such. "Barnes, Kenny" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 07/31/2006 01:41 PM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Configuring new 3592-E05 drives Can you talk to the drives using the IBMtape utilities from the OS? i.e. You should be open the drive as a device and read the SN of the drive. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan Forray/AC/VCU Sent: Monday, July 31, 2006 1:36 PM To: ADSM-L@VM.MARIST.EDU Subject: Configuring new 3592-E05 drives We finally got our 3592-E05 drives installed and attached to the SAN in our 3494 library. Now I am trying to figure out how to get them to work ! Is there something special about configuring TSM to use them ? The server is 5.3.2.3 on AIX. I did the cfgmgr and the smitty devices to define them to TSM... I bounced the TSM server.. Defined the DEVICE CLASS 3592. Defined the paths.. Defined the storage pool Did a: LABEL libv 3494ATL 085000 checkin=scr devtype=3592 and got the error: 7/31/2006 1:33:55 PM ANR8847E No 3592-type drives are currently available in library 3494ATL. Also, looking through the Admin Ref/Guide, there is constant talk about 3592 WORM drives ? What am I missing ? -- Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. --
Re: Configuring new 3592-E05 drives
I figured it out. Found an old document that says for "mixed media" in a 3494, you have to define the library, multiple times pointing to the same library. In this case, we have already been using 3590K tapes. So I defined a second library and all seems to be working.. Thanks for all the suggestions. "Nast, Jeff P." <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 07/31/2006 01:42 PM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Configuring new 3592-E05 drives Make sure that you have the "Mount Limit" set correctly in your 3592 device class... 3592-E05 is not a WORM drive... -Jeff -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Zoltan Forray/AC/VCU Sent: Monday, July 31, 2006 12:36 PM To: ADSM-L@VM.MARIST.EDU Subject: Configuring new 3592-E05 drives We finally got our 3592-E05 drives installed and attached to the SAN in our 3494 library. Now I am trying to figure out how to get them to work ! Is there something special about configuring TSM to use them ? The server is 5.3.2.3 on AIX. I did the cfgmgr and the smitty devices to define them to TSM... I bounced the TSM server.. Defined the DEVICE CLASS 3592. Defined the paths.. Defined the storage pool Did a: LABEL libv 3494ATL 085000 checkin=scr devtype=3592 and got the error: 7/31/2006 1:33:55 PM ANR8847E No 3592-type drives are currently available in library 3494ATL. Also, looking through the Admin Ref/Guide, there is constant talk about 3592 WORM drives ? What am I missing ? This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. As required by federal and state laws, you need to hold this information as privileged and confidential. If you have received this communication in error, please notify the sender and destroy all copies of this communication and any attachments.
Re: audito data missing
Try running an audit license again and see if the data appears. If I remember correctly, the amount of data that is reported in the q audito command, directly ties in with the audit license command. Meaning, the TSM server has to audit all its client information before it will report to the q audito (Good reason to run audit license each day). Thanks, Sean English Keith Arbogast <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 07/31/2006 01:43 PM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject [ADSM-L] audito data missing A customer ran a backup from the command line of the files in one directory on a Windows 2003 node on Friday. When he runs q backup "C:\\*" TSM returns a list of file descriptions and sizes. About 10 Gb in all, mostly .iso files. Today, when I run 'q audito *' from the TSM server, the node is listed, but 'Backup Storage Used' is 0 mb. Is there something wrong here, or does the data in 'audito' get refreshed on a cycle that hasn't expired yet? We run TSM 5.3.0.2 on AIX 5.2. The Windows 2003 node is running TSM client 5.3.3. Thank you, Keith Arbogast Indiana University ForwardSourceID:NT81DA
audito data missing
A customer ran a backup from the command line of the files in one directory on a Windows 2003 node on Friday. When he runs q backup "C:\\*" TSM returns a list of file descriptions and sizes. About 10 Gb in all, mostly .iso files. Today, when I run 'q audito *' from the TSM server, the node is listed, but 'Backup Storage Used' is 0 mb. Is there something wrong here, or does the data in 'audito' get refreshed on a cycle that hasn't expired yet? We run TSM 5.3.0.2 on AIX 5.2. The Windows 2003 node is running TSM client 5.3.3. Thank you, Keith Arbogast Indiana University
Re: Configuring new 3592-E05 drives
Yes. Just installed them last week. Yes, I did reboot the server(s). "LeBlanc, Patricia" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 07/31/2006 01:39 PM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Configuring new 3592-E05 drives Are you using the most up to date drivers? Atape and atldd?? -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan Forray/AC/VCU Sent: Monday, July 31, 2006 1:36 PM To: ADSM-L@VM.MARIST.EDU Subject: Configuring new 3592-E05 drives We finally got our 3592-E05 drives installed and attached to the SAN in our 3494 library. Now I am trying to figure out how to get them to work ! Is there something special about configuring TSM to use them ? The server is 5.3.2.3 on AIX. I did the cfgmgr and the smitty devices to define them to TSM... I bounced the TSM server.. Defined the DEVICE CLASS 3592. Defined the paths.. Defined the storage pool Did a: LABEL libv 3494ATL 085000 checkin=scr devtype=3592 and got the error: 7/31/2006 1:33:55 PM ANR8847E No 3592-type drives are currently available in library 3494ATL. Also, looking through the Admin Ref/Guide, there is constant talk about 3592 WORM drives ? What am I missing ?
Re: Configuring new 3592-E05 drives
Make sure that you have the "Mount Limit" set correctly in your 3592 device class... 3592-E05 is not a WORM drive... -Jeff -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Zoltan Forray/AC/VCU Sent: Monday, July 31, 2006 12:36 PM To: ADSM-L@VM.MARIST.EDU Subject: Configuring new 3592-E05 drives We finally got our 3592-E05 drives installed and attached to the SAN in our 3494 library. Now I am trying to figure out how to get them to work ! Is there something special about configuring TSM to use them ? The server is 5.3.2.3 on AIX. I did the cfgmgr and the smitty devices to define them to TSM... I bounced the TSM server.. Defined the DEVICE CLASS 3592. Defined the paths.. Defined the storage pool Did a: LABEL libv 3494ATL 085000 checkin=scr devtype=3592 and got the error: 7/31/2006 1:33:55 PM ANR8847E No 3592-type drives are currently available in library 3494ATL. Also, looking through the Admin Ref/Guide, there is constant talk about 3592 WORM drives ? What am I missing ? This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. As required by federal and state laws, you need to hold this information as privileged and confidential. If you have received this communication in error, please notify the sender and destroy all copies of this communication and any attachments.
Re: Configuring new 3592-E05 drives
Can you talk to the drives using the IBMtape utilities from the OS? i.e. You should be open the drive as a device and read the SN of the drive. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan Forray/AC/VCU Sent: Monday, July 31, 2006 1:36 PM To: ADSM-L@VM.MARIST.EDU Subject: Configuring new 3592-E05 drives We finally got our 3592-E05 drives installed and attached to the SAN in our 3494 library. Now I am trying to figure out how to get them to work ! Is there something special about configuring TSM to use them ? The server is 5.3.2.3 on AIX. I did the cfgmgr and the smitty devices to define them to TSM... I bounced the TSM server.. Defined the DEVICE CLASS 3592. Defined the paths.. Defined the storage pool Did a: LABEL libv 3494ATL 085000 checkin=scr devtype=3592 and got the error: 7/31/2006 1:33:55 PM ANR8847E No 3592-type drives are currently available in library 3494ATL. Also, looking through the Admin Ref/Guide, there is constant talk about 3592 WORM drives ? What am I missing ? -- Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. --
Re: Configuring new 3592-E05 drives
Are you using the most up to date drivers? Atape and atldd?? -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan Forray/AC/VCU Sent: Monday, July 31, 2006 1:36 PM To: ADSM-L@VM.MARIST.EDU Subject: Configuring new 3592-E05 drives We finally got our 3592-E05 drives installed and attached to the SAN in our 3494 library. Now I am trying to figure out how to get them to work ! Is there something special about configuring TSM to use them ? The server is 5.3.2.3 on AIX. I did the cfgmgr and the smitty devices to define them to TSM... I bounced the TSM server.. Defined the DEVICE CLASS 3592. Defined the paths.. Defined the storage pool Did a: LABEL libv 3494ATL 085000 checkin=scr devtype=3592 and got the error: 7/31/2006 1:33:55 PM ANR8847E No 3592-type drives are currently available in library 3494ATL. Also, looking through the Admin Ref/Guide, there is constant talk about 3592 WORM drives ? What am I missing ?
Configuring new 3592-E05 drives
We finally got our 3592-E05 drives installed and attached to the SAN in our 3494 library. Now I am trying to figure out how to get them to work ! Is there something special about configuring TSM to use them ? The server is 5.3.2.3 on AIX. I did the cfgmgr and the smitty devices to define them to TSM... I bounced the TSM server.. Defined the DEVICE CLASS 3592. Defined the paths.. Defined the storage pool Did a: LABEL libv 3494ATL 085000 checkin=scr devtype=3592 and got the error: 7/31/2006 1:33:55 PM ANR8847E No 3592-type drives are currently available in library 3494ATL. Also, looking through the Admin Ref/Guide, there is constant talk about 3592 WORM drives ? What am I missing ?
Re: Reclamation processing behavior
Thanks, I figured that it was normal, I was just curious as to why. It didn't make sense that it was the VTL, Since Tivoli sees it as a tape library. I should have guessed, since the only difference in the new storagpools is that now I have a next storage pool. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Johnson, Milton Sent: Monday, July 31, 2006 9:37 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Reclamation processing behavior This is normal behavior when reclaiming a storage pool that has a NEXT STGPOOL defined. I became aware to it when I upgraded to 5.3, I also have a VTL. However, being a VTL has nothing to do with it, it's having a NEXT STGPOOL defined that elicits this behavior. If you use the reclaim stg command then there is no delay. I found an IBM bulletin on the subject which is how I found that IBM considers normal behavior, that was 6 months ago so don't ask me to find it again. Hope that this helps, H. Milton Johnson -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thorneycroft, Doug Sent: Tuesday, July 25, 2006 5:09 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Reclamation processing behavior They should both appear as ATL's to Tivoli. The real tape is a Qualstar, with AIT Drives and Media, and the VTL appears as a Quantum, With DLT Drives and media. And Both are defined as primary sequential storage pools. I would expect the behavior to be the same. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Prather, Wanda Sent: Tuesday, July 25, 2006 2:59 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Reclamation processing behavior >>This really isn't a problem, but I was just curious if anyone knows >>why Tivol treats the two types of storage pools differently. >From TSM's point of view, why do you think they are 2 different "types" of storage pools? Aren't they both sequential tape devices, from the TSm server's point of view? Wanda Doug Thorneycroft > Systems Analyst > County Sanitation Districts of Los Angeles County > 1955 Workman Mill Road > Whittier, CA 90601 > Tel: (562)699-7411, Ext. 1058 > Fax:(562)695-6756 > www.lacsd.org > > >
Re: Reclamation processing behavior
This is normal behavior when reclaiming a storage pool that has a NEXT STGPOOL defined. I became aware to it when I upgraded to 5.3, I also have a VTL. However, being a VTL has nothing to do with it, it's having a NEXT STGPOOL defined that elicits this behavior. If you use the reclaim stg command then there is no delay. I found an IBM bulletin on the subject which is how I found that IBM considers normal behavior, that was 6 months ago so don't ask me to find it again. Hope that this helps, H. Milton Johnson -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thorneycroft, Doug Sent: Tuesday, July 25, 2006 5:09 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Reclamation processing behavior They should both appear as ATL's to Tivoli. The real tape is a Qualstar, with AIT Drives and Media, and the VTL appears as a Quantum, With DLT Drives and media. And Both are defined as primary sequential storage pools. I would expect the behavior to be the same. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Prather, Wanda Sent: Tuesday, July 25, 2006 2:59 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Reclamation processing behavior >>This really isn't a problem, but I was just curious if anyone knows >>why Tivol treats the two types of storage pools differently. >From TSM's point of view, why do you think they are 2 different "types" of storage pools? Aren't they both sequential tape devices, from the TSm server's point of view? Wanda Doug Thorneycroft > Systems Analyst > County Sanitation Districts of Los Angeles County > 1955 Workman Mill Road > Whittier, CA 90601 > Tel: (562)699-7411, Ext. 1058 > Fax:(562)695-6756 > www.lacsd.org > > >
Fw: audito report: real or compressed?
Keith, It's the total of data as the data was sent by the client. If the client compressed the data, then it's the compressed size, otherwise, it's the full/uncompressed size, regardless of where it resides in the TSM Server storagepools. Nick Cassimatis - Forwarded by Nicholas Cassimatis/Raleigh/IBM on 07/31/2006 12:28 PM - "ADSM: Dist Stor Manager" wrote on 07/31/2006 11:32:01 AM: > Does the auditoccupancy report show megabytes used after files have > been compressed on being migrated to tape or before? In other words, > the total of primary backup media used, or the total of the original > files on the node? Or, is it the sum of uncompressed storage on disk > pools and compressed storage on tape pools? We run TSM 5.3.0.2 on > AIX 5.2, and have a 3494 tape library with 3590 E1A drives. File > compression is done by the tape drives. > > Thank you, > Keith Arbogast > Indiana University
audito report: real or compressed?
Does the auditoccupancy report show megabytes used after files have been compressed on being migrated to tape or before? In other words, the total of primary backup media used, or the total of the original files on the node? Or, is it the sum of uncompressed storage on disk pools and compressed storage on tape pools? We run TSM 5.3.0.2 on AIX 5.2, and have a 3494 tape library with 3590 E1A drives. File compression is done by the tape drives. Thank you, Keith Arbogast Indiana University
ACSLS ejects not working... help!
Hello everyone, I have TSM 5.2.7.1 on AIX 5.3 and I also have an STK SL8500 with IBM LTO2 tapes/drives. I'm just doing a move media and trying to eject all of our NAS NDMP backup tapes. As you can see it is failing. My main question is: Is this a TSM server issue or a library issue? I have been doing this for over 2 years now and have not had any issues ejecting the tapes, but for the past 2 ejects the tapes ARE ejecting from the library, but within TSM it is stating that it there is a timeout issue and it doesn't update the tapes as mountablenotinlib. Any ideas/suggestions would be appreciated! Thanks! Date/Time Message -- 07/31/06 10:15:19 ANR2017I Administrator OPERATIONS issued command: MOVE MEDIA * stg=tape_ndmp_offsite wherestate=mountableinlib wherestatus=ful,fil rem=b checkl=n ovflo="Vital Records,Inc." (SESSION: 308754) 07/31/06 10:15:19 ANR0984I Process 8407 for MOVE MEDIA started in the BACKGROUND at 10:15:19. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:19 ANR0609I MOVE MEDIA started as process 8407. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:19 ANR0610I MOVE MEDIA started by OPERATIONS as process 8407. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:19 ANR2017I Administrator OPERATIONS issued command: MOVE MEDIA * stg=tape_ndmp_offsite wherestate=mountableinlib wherestatus=ful,fil rem=b checkl=n ovflo="Vital Records,Inc." (SESSION: 308755) 07/31/06 10:15:19 ANR0984I Process 8408 for MOVE MEDIA started in the BACKGROUND at 10:15:19. (SESSION: 308755, PROCESS: 8408) 07/31/06 10:15:19 ANR0609I MOVE MEDIA started as process 8408. (SESSION: 308755, PROCESS: 8408) 07/31/06 10:15:19 ANR0610I MOVE MEDIA started by OPERATIONS as process 8408. (SESSION: 308755, PROCESS: 8408) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00173 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00178 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00185 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00186 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00189 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00191 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00194 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00246 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00247 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00466 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00633 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00637 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00695 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00710 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for volume N00714 in library NASLIB starting. (SESSION: 308754, PROCESS: 8407) 07/31/06 10:15:33 ANR6696I MOVE MEDIA: CHECKOUT LIBVOLUME for vol
Re: TSM Blocks Device Files in HP-UX after using it...
Hi Bernaldo,
We also run TSM on HP-UX. I don't recall ever seeing that exact message,
but my guess is you either have a hardware problem with those two devices
(or something along the path to those devices... are they on the same FC
adapter or SCSI bus?),
-- OR --
HP-UX has renumbered the device files. I have had that happen, and I'm not
sure why... To be sure, you should do an 'ioscan -fnC tape' and compare it
to the files in /dev/rmt ('ls -l /dev/rmt'). If the devices have been
givien new instance numbers, I have found that the easiest, surest fix is
to delete the drives and paths from TSM and redefine them. You should also
remove any old unused special files from /dev/rmt by doing 'rmsf -a
/dev/rmt/23m' (for example). That command will remove the definition from
the kernel and all of the special files that were associated with that
device... 23m, 23mn, 23mb, 23mnb.
HTH
Regards,
Robin Sharpe
Berlex Labs
"Bernaldo de
Quiros, Iban 1"
ADSM-L@VM.MARIST.EDU
Sent by: "ADSM:cc
Dist Stor
Manager" Subject
<[EMAIL PROTECTED] TSM Blocks Device Files in HP-UX
.EDU> after using it...
07/31/2006 05:27
AM
Please respond to
"ADSM: Dist Stor
Manager"
<[EMAIL PROTECTED]
.EDU>
Hi Everyone !!
Did anyone got this error on TSM ¿? any information or GOTCHA's ¿?
07/28/06 12:54:47 ANRD mmsext.c(1360): ThreadId<70> Unable to
obtain
model type for '/dev/rmt/25m', rc = 30 Callchain
follows:
00d18e6f outDiagf+0x25f <-
00e7005b
ExtMountVolume+0xe53 <- 0088fbff
MmsMountVolume+0x3ff <- 00e0a0c7
PvrGtsOpen+0x9a7
<- 00e5fa07 TapiOpen+0x247 <-
0083ce1f
AgentThread+0x7d7 <- 0012edb3
StartThread+0x17b
<- 0006b47b *UNKNOWN* <- (SESSION: 506)
07/28/06 15:58:00 ANRD mmsext.c(1360): ThreadId<60> Unable to
obtain
model type for '/dev/rmt/23m', rc = 30 Callchain
follows:
00d18e6f outDiagf+0x25f <-
00e7005b
ExtMountVolume+0xe53 <- 0088fbff
MmsMountVolume+0x3ff <- 00e0a0c7
PvrGtsOpen+0x9a7
<- 00e5fa07 TapiOpen+0x247 <-
0083ce1f
AgentThread+0x7d7 <- 0012edb3
StartThread+0x17b
<- 0006b47b *UNKNOWN* <- (SESSION: 31)
After appearing this issues on actlog, TSM do not release the device file,
so device file remains busy. The only solution that I find at the moment is
to halt the TSM server to release device files.
When I re-start the TSM it could access the device files normally until
this issue occurs another time...
OS VERSION HP-UX 11.00
TSM 5.2.6.3
Using HP-UX Generic Driver to access tapes (stape).
Working with GRESHAM EDT 7.4.0.5.
Any help will be appreciated.
Thanks in Advance,
Regards,
Ibán Bernaldo de Quirós Márquez
Technical Specialist
cell: + 34 659 01 91 12
Sun Microsystems Iberia
TSM && OnDemand Content Manager
Hi all !! Did anyone has a TSM && OnDemand Content Manager implementation guide ¿? Or could someone explain me the main configuration to make OnDemand work with TSM ¿? Thanks In Advance, Regards, Ibán.
TSM Blocks Device Files in HP-UX after using it...
Hi Everyone !! Did anyone got this error on TSM ¿? any information or GOTCHA's ¿? 07/28/06 12:54:47 ANRD mmsext.c(1360): ThreadId<70> Unable to obtain model type for '/dev/rmt/25m', rc = 30 Callchain follows: 00d18e6f outDiagf+0x25f <- 00e7005b ExtMountVolume+0xe53 <- 0088fbff MmsMountVolume+0x3ff <- 00e0a0c7 PvrGtsOpen+0x9a7 <- 00e5fa07 TapiOpen+0x247 <- 0083ce1f AgentThread+0x7d7 <- 0012edb3 StartThread+0x17b <- 0006b47b *UNKNOWN* <- (SESSION: 506) 07/28/06 15:58:00 ANRD mmsext.c(1360): ThreadId<60> Unable to obtain model type for '/dev/rmt/23m', rc = 30 Callchain follows: 00d18e6f outDiagf+0x25f <- 00e7005b ExtMountVolume+0xe53 <- 0088fbff MmsMountVolume+0x3ff <- 00e0a0c7 PvrGtsOpen+0x9a7 <- 00e5fa07 TapiOpen+0x247 <- 0083ce1f AgentThread+0x7d7 <- 0012edb3 StartThread+0x17b <- 0006b47b *UNKNOWN* <- (SESSION: 31) After appearing this issues on actlog, TSM do not release the device file, so device file remains busy. The only solution that I find at the moment is to halt the TSM server to release device files. When I re-start the TSM it could access the device files normally until this issue occurs another time... OS VERSION HP-UX 11.00 TSM 5.2.6.3 Using HP-UX Generic Driver to access tapes (stape). Working with GRESHAM EDT 7.4.0.5. Any help will be appreciated. Thanks in Advance, Regards, Ibán Bernaldo de Quirós Márquez Technical Specialist cell: + 34 659 01 91 12 Sun Microsystems Iberia
Re: 3592 tape read performance
Hi Thomas, 3592-J1a, tsmserver 5.3.3.2 on Solaris10 we have the same thing happened - also removed 2 or 3 tapes from the library. It was really annoying because a tape may happen to be reading 24 hours constantly reading but with some kBytes per second. In our case it seems to be possibly both our old firmware in the tape-drives and also the tapes ( here: ibm labeled - not the fujii ). The tape support technician who checked the drives described 2 possibilities that may happenen at the tapes: one thing is that the builtin brakes on the tapes may seldomly have a malfunction leading to heavy positioning tasks of the drive. The other thing is that the tape-material is slightly stuck - that may happen with brandnew tapes and that might disappear once using the tape at the whole length. The firmware -update here has been a little bit complicated, because first the drives seems to be gone. After reset of the drives also the server-system had to be restarted. Also you should check the latest tape-driver (IBMTape) . Because now anything seems to be fine we may test again the ploblem-tapes if they now work better . Using the latest tape-drive and solaris-os Version it is very fine for me that the unix 'iostat' - utility now is friendly showing the current statistics of the tape-drives too ... not only of the disks as before our update. I currently localized one drive running a migration process and constantly running with nearly 100 % busy and a write speed roughly around 5 MB/s over the time. Moving that process to another drive ( same data , same destination tape-volume ) it shows to run normal and being 10 times faster. No errors at all - Just called the service ... so you may also take a look at iostat ( eg 'iostat -x 5' ) if you also can see the drives there. for example that is really no 'problem-output' :-) : extended device statistics device r/sw/s kr/s kw/s wait actv svc_t %w %b IBMtape6 0.0 348.30.0 89166.2 0.0 0.61.7 0 58 Greetings Rainer Thomas Denier schrieb: We are seeing increasingly frequent problems reading data from 3592 tapes. TSM sometimes spends as much as a couple of hours reading a single file with a size of a few hundred megabyes. In some cases, TSM reports a hardware or media error at the end of that time. In other cases TSM eventually reads the file successfully. In the latter case there are, as far as we can tell, no error indications at all: no TSM messages, nothing logged by the OS, and no indicators on the front panel of the tape drive. In some case the same tape volume suffers this type of problem repeatedly. The problems seem to spread roughly evenly over our whole population of 3592 drives. We have just removed one 3592 volume from service because of recurrent read problems, and are about to remove a second volume from service. We only have about 120 3592 volumes, and losing two of them within a week is disturbing, to put it mildly. The possiblity that the volumes with non-recurring (so far) problems will eventually need replacement is even more disturbing. Our TSM server is at 5.2.6.0, running under mainframe Linux. The 3592 tapes drives are all the J1A model. Does anyone have any suggestions for getting to the bottom of this? -- Rainer Wolf eMail: [EMAIL PROTECTED] kiz - Abt. Infrastruktur Tel/Fax: ++49 731 50-22482/22471 Universitaet Ulm wwweb:http://kiz.uni-ulm.de
