AW: inventory expiration time
4CPU, Windows2003, 4GB Ram, CX700 Disks Raid5 (shared, 10k), TSM 5.3.2 During the same time there is expiration from an other smaller instance on the same machine that lasts about an hour. Regards Stefan Holzwarth DB Speed Expiration ACTIVITY Date Examined Objects Examined Up/Hr EXPIRATION 2006-06-27 2430008 925200 EXPIRATION 2006-06-28 2404404 1083600 EXPIRATION 2006-06-29 2453121 993600 EXPIRATION 2006-06-30 2535449 928800 EXPIRATION 2006-07-01 2600885 835200 EXPIRATION 2006-07-02 2751620 1004400 EXPIRATION 2006-07-03 2913433 99 EXPIRATION 2006-07-04 2560030 946800 EXPIRATION 2006-07-05 2568634 1098000 EXPIRATION 2006-07-06 2619294 1198800 EXPIRATION 2006-07-07 2835640 1044000 EXPIRATION 2006-07-08 2922019 932400 EXPIRATION 2006-07-09 3152030 1177200 EXPIRATION 2006-07-10 3307528 1004400 EXPIRATION 2006-07-11 2942075 1036800 EXPIRATION 2006-07-12 2947009 1134000 EXPIRATION 2006-07-13 3077056 914400 EXPIRATION 2006-07-14 3003355 878400 EXPIRATION 2006-07-15 2888349 972000 EXPIRATION 2006-07-16 3059609 1245600 EXPIRATION 2006-07-17 3226511 117 EXPIRATION 2006-07-18 2994471 968400 EXPIRATION 2006-07-18 2653356 2469600 EXPIRATION 2006-07-19 2937517 1011600 EXPIRATION 2006-07-20 2874305 1137600 EXPIRATION 2006-07-20 2585014 2818800 EXPIRATION 2006-07-21 3125122 882000 EXPIRATION 2006-07-22 3130365 828000 EXPIRATION 2006-07-23 3262415 1245600 EXPIRATION 2006-07-24 3308901 1245600 EXPIRATION 2006-07-25 3038719 1227600 EXPIRATION 2006-07-26 2990903 943200 EXPIRATION 2006-07-27 2971022 1296000 > -Ursprüngliche Nachricht- > Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im > Auftrag von Dirk Kastens > Gesendet: Freitag, 28. Juli 2006 08:30 > An: ADSM-L@VM.MARIST.EDU > Betreff: Re: inventory expiration time > > Richard Hammersley schrieb: > > The machine is a new dual processor P520 with 4 gig of > memory attached > > to an EMC cx300 san. > > We also have a p520, but with 12 GB of memory. We're running TSM 5.3.3 > on AIX 5.3. > Our inventory expiration runs once a week and takes more than > 6 hours to > complete: > > ANR0812I Inventory file expiration process 4218 completed: examined > 7907625 objects, deleting 1416779 backup objects, 191 archive > objects, 0 > DB backup volumes, and 0 recovery plan files. 0 errors were > encountered. > > -- > Regards, > > Dirk Kastens > Universitaet Osnabrueck, Rechenzentrum (Computer Center) > Albrechtstr. 28, 49069 Osnabrueck, Germany > Tel.: +49-541-969-2347, FAX: -2470 >
Re: inventory expiration time
Richard Hammersley schrieb: The machine is a new dual processor P520 with 4 gig of memory attached to an EMC cx300 san. We also have a p520, but with 12 GB of memory. We're running TSM 5.3.3 on AIX 5.3. Our inventory expiration runs once a week and takes more than 6 hours to complete: ANR0812I Inventory file expiration process 4218 completed: examined 7907625 objects, deleting 1416779 backup objects, 191 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. -- Regards, Dirk Kastens Universitaet Osnabrueck, Rechenzentrum (Computer Center) Albrechtstr. 28, 49069 Osnabrueck, Germany Tel.: +49-541-969-2347, FAX: -2470
Strange filesize after export/import
Hi, we are just testing the migration of a TSM 5.1.9.5 (AIX 4.3) to a TSM 5.2.7.2 (AIX 5.2). So far everything seems OK, policies and data were exported and imported just fine, but I noticed a discrepancy in the file sizes shown in a select from contents for ALL files (data are from a ContenManager)! This is an example: On the old TSM tsm: ECKWAND>select * from contents where file_name='/MC_ARCHIV_PO4_1/ MC_ARCHIV_PO4_1AKKDBJHB.DMD' VOLUME_NAME: /tivoli1/stgpool/archiv_po4_1_file01 NODE_NAME: ARCHIV_PO TYPE: Bkup FILESPACE_NAME: /OBJRZ/FRN/ADSM/192.168.126.134/MC_ARCHIV_PO4_1 FILE_NAME: /MC_ARCHIV_PO4_1/ MC_ARCHIV_PO4_1AKKDBJHB.DMD AGGREGATED: No FILE_SIZE: 56210 SEGMENT: CACHED: No FILESPACE_ID: 6 FILESPACE_HEXNAME: FILE_HEXNAME: After the import on the new TSM: tsm: TEST-KANDEL>select * from contents where file_name='/MC_ARCHIV_PO4_1/ MC_ARCHIV_PO4_1AKKDBJHB.DMD' VOLUME_NAME: /usr/local/tsm/server2/data/apo4_01 NODE_NAME: ARCHIV_PO TYPE: Bkup FILESPACE_NAME: /OBJRZ/FRN/ADSM/192.168.126.134/MC_ARCHIV_PO4_1 FILE_NAME: /MC_ARCHIV_PO4_1/ MC_ARCHIV_PO4_1AKKDBJHB.DMD AGGREGATED: 124/256 FILE_SIZE: 11195180 SEGMENT: CACHED: No FILESPACE_ID: 1 FILESPACE_HEXNAME: FILE_HEXNAME: Note the difference in FILE_SIZE: 56210 vs. 11195180! This seems strange! And what does the difference in the field AGGREGATED mean (No vs. 124/256)? Interestingly enough, I can restore the object from the new TSM and inspect it in a viewer (it's a TIFF) just fine. The dsmc query shows it as: tsm> query backup "/OBJRZ/FRN/ADSM/192.168.126.134/MC_ARCHIV_PO4_1//MC_ARCHIV_PO4_1/MC_ARCHIV_PO4_1AKKDBJHB.DMD" Size Backup DateMgmt Class A/I File ----- --- API 55,858 B 03/25/01 00:11:12MC_ARCHIV_ A /OBJRZ/FRN/ADSM/192.168.126.134/MC_ARCHIV_PO4_1/MC_ARCHIV_PO4_1/MC_ARCHIV_PO4_1AKKDBJHB.DMD Another thing is puzzeling me: the blank in the filename in the "select", which is not appearing in the "query backup" result. Any hints? TIA Andreas
Re: inventory expiration time
>> On Thu, 27 Jul 2006 16:13:41 -0400, Richard Hammersley <[EMAIL PROTECTED]> >> said: > The machine is a new dual processor P520 with 4 gig of memory > attached to an EMC cx300 san. What's the underlying disk in the cx300? - Allen S. Rout
Re: CAN RESTORE ACTIVITY BE TRACED?
>> On Thu, 27 Jul 2006 15:06:37 -0500, Laura Mastandrea <[EMAIL PROTECTED]> >> said: > Thank you, I need clarification on what you mean by badly fragmented > data on tape. We are restoring full drives, so do you mean that a > file is on one tape and the next file is on another? Does > reclamation try to any kind of node consolidation? Reclamation does not have anything to do with node consolidation. If your data is in a storagepool which is not "collocated", you're going to have every machine's data, to a good approximation, spread across every tape. If this is a question in your mind, you should probably read the concepts guide which has been frequently referred to on this list recently. How many tapes were mounted to satisfy your restore? > I'm going to try the move nodedata. Count tape mounts for that process, that'll help you determine what's going on. - Allen S. Rout
Re: inventory expiration time
The machine is a new dual processor P520 with 4 gig of memory attached to an EMC cx300 san. David Longo wrote: I think that is kind of long. You didn't say what pSeries and how much RAM or what disk TSM DB is on. I have old pSeries. IBM p660-6H1, with 4x 750 MHz Procs and 4GB RAM. TSM DB is 120 GB, 67% utilized. DB is onm FAASTT 600 Turbo on RAID 5 across 73GB 15K drives. Expiration takes 4-6 hours with some other activities going on like you, but not a huge amount. Typically examine 8million + objects and delete about 800K, some days more, some less. Oh, and I have TSM server 5.2.6.0 on AIX 5.2. Deletes are what takes the longest time on expiration and you don't have that many. What do you show for "q db f=d" for "Cache Hit Pct". If your not at 99% or close, that is most likely your problem. Need to increase your Buffer Pool size, if that's the case. 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.5509 [EMAIL PROTECTED] Richard Hammersley <[EMAIL PROTECTED]> 07/27/06 3:22 PM >>> I am wondering if my inventory expiration elapsed times are typical. Examining just under 8,000,000 objects and deleting between 139k and 200k objects taking between 7.5 and 8.75 hours. Running on AIX 5.3 on a new P-series machine. TSM 5.3.4. Also, running some storage pool backups for the first 4 hours but that is all. See below. Date/TimeMessage -- 07/20/06 13:24:26 ANR0812I Inventory file expiration process 289 completed: examined 7858857 objects, deleting 138913 backup objects, 7:24 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 13355, PROCESS: 289) 07/21/06 14:40:23 ANR0812I Inventory file expiration process 309 completed: examined 7872837 objects, deleting 128256 backup objects, 8:40 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 14158, PROCESS: 309) 07/22/06 13:38:03 ANR0812I Inventory file expiration process 331 completed: examined 7911819 objects, deleting 157925 backup objects, 7:38 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 14809, PROCESS: 331) 07/23/06 14:09:38 ANR0812I Inventory file expiration process 352 completed: examined 7908552 objects, deleting 159163 backup objects, 8:09 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 15480, PROCESS: 352) 07/24/06 13:40:14 ANR0812I Inventory file expiration process 369 completed: examined 7886486 objects, deleting 152935 backup objects, 7:40 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 16156, PROCESS: 369) 07/25/06 14:02:38 ANR0812I Inventory file expiration process 392 completed: examined 7837552 objects, deleting 163399 backup objects, 8:02 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 17165, PROCESS: 392) 07/26/06 13:27:24 ANR0812I Inventory file expiration process 413 completed: examined 7790356 objects, deleting 159788 backup objects, 7:27 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 17634, PROCESS: 413) 07/27/06 14:42:01 ANR0812I Inventory file expiration process 435 completed: examined 7830543 objects, deleting 204427 backup objects, 8:42 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 18914, tsm: TSMSERV1>q db Available Assigned Maximum Maximum Page Total Used PctMax. Space Capacity Extension Reduction Size Usable PagesUtil Pct (MB) (MB)(MB)(MB) (bytes) Pages Util - - - --- - - - - 58,344 47,356 10,988 22,108 4,096 12,123,136 6,357,30952.4
Re: CAN RESTORE ACTIVITY BE TRACED?
Thank you, I need clarification on what you mean by badly fragmented data on tape. We are restoring full drives, so do you mean that a file is on one tape and the next file is on another? Does reclamation try to any kind of node consolidation? I'm going to try the move nodedata. Thank you. Laura Mastandrea To ADSM-L@VM.MARIST.EDU cc From Sent by "Allen S. Rout" <[EMAIL PROTECTED]> on 07/27/2006 02:25 PM "ADSM: Dist Stor Manager" Subject Re: [ADSM-L] CAN RESTORE ACTIVITY BE TRACED? Please respond to "ADSM: Dist Stor Manager" >> On Thu, 27 Jul 2006 10:37:46 -0500, Laura Mastandrea <[EMAIL PROTECTED]> said: > Is there a trace I can run on this a restore to see what is taking so long? > Is there a SQL Select that would give me where the time was spent for this > restore or is my only source the activity log? [ Oh yeah, you could also... ] If you MOVE NODEDATA for the affected filesystem onto disk, you can do several things: rule out badly fragmented data on the tapes (if it takes hours to move data from LT0 to local disk, then you have very very poor fragmentation characteristics) and then you can do the restore off the disk, which should rule out backhitch problems. Once those two sources are cut out, it'll probably be really clear if the network is in the way. - Allen S. Rout DISCLAIMER: This communication, along with any documents, files or attachments, is intended only for the use of the addressee and may contain legally privileged and confidential information. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of any information contained in or attached to this communication is strictly prohibited. If you have received this message in error, please notify the sender immediately and destroy the original communication and its attachments without reading, printing or saving in any manner. This communication does not form any contractual obligation on behalf of the sender or, the sender's employer, or the employer's parent company, affiliates or subsidiaries.
Re: inventory expiration time
I think that is kind of long. You didn't say what pSeries and how much RAM or what disk TSM DB is on. I have old pSeries. IBM p660-6H1, with 4x 750 MHz Procs and 4GB RAM. TSM DB is 120 GB, 67% utilized. DB is onm FAASTT 600 Turbo on RAID 5 across 73GB 15K drives. Expiration takes 4-6 hours with some other activities going on like you, but not a huge amount. Typically examine 8million + objects and delete about 800K, some days more, some less. Oh, and I have TSM server 5.2.6.0 on AIX 5.2. Deletes are what takes the longest time on expiration and you don't have that many. What do you show for "q db f=d" for "Cache Hit Pct". If your not at 99% or close, that is most likely your problem. Need to increase your Buffer Pool size, if that's the case. 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.5509 [EMAIL PROTECTED] >>> Richard Hammersley <[EMAIL PROTECTED]> 07/27/06 3:22 PM >>> I am wondering if my inventory expiration elapsed times are typical. Examining just under 8,000,000 objects and deleting between 139k and 200k objects taking between 7.5 and 8.75 hours. Running on AIX 5.3 on a new P-series machine. TSM 5.3.4. Also, running some storage pool backups for the first 4 hours but that is all. See below. Date/TimeMessage -- 07/20/06 13:24:26 ANR0812I Inventory file expiration process 289 completed: examined 7858857 objects, deleting 138913 backup objects, 7:24 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 13355, PROCESS: 289) 07/21/06 14:40:23 ANR0812I Inventory file expiration process 309 completed: examined 7872837 objects, deleting 128256 backup objects, 8:40 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 14158, PROCESS: 309) 07/22/06 13:38:03 ANR0812I Inventory file expiration process 331 completed: examined 7911819 objects, deleting 157925 backup objects, 7:38 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 14809, PROCESS: 331) 07/23/06 14:09:38 ANR0812I Inventory file expiration process 352 completed: examined 7908552 objects, deleting 159163 backup objects, 8:09 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 15480, PROCESS: 352) 07/24/06 13:40:14 ANR0812I Inventory file expiration process 369 completed: examined 7886486 objects, deleting 152935 backup objects, 7:40 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 16156, PROCESS: 369) 07/25/06 14:02:38 ANR0812I Inventory file expiration process 392 completed: examined 7837552 objects, deleting 163399 backup objects, 8:02 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 17165, PROCESS: 392) 07/26/06 13:27:24 ANR0812I Inventory file expiration process 413 completed: examined 7790356 objects, deleting 159788 backup objects, 7:27 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 17634, PROCESS: 413) 07/27/06 14:42:01 ANR0812I Inventory file expiration process 435 completed: examined 7830543 objects, deleting 204427 backup objects, 8:42 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 18914, tsm: TSMSERV1>q db Available Assigned Maximum Maximum Page Total Used PctMax. Space Capacity Extension Reduction Size Usable PagesUtil Pct (MB) (MB)(MB)(MB) (bytes) Pages Util - - - --- - - - - 58,344 47,356 10,988 22,108 4,096 12,123,136 6,357,30952.453.4 ## This message is for the named person's use
Re: CAN RESTORE ACTIVITY BE TRACED?
>> On Thu, 27 Jul 2006 10:37:46 -0500, Laura Mastandrea <[EMAIL PROTECTED]> >> said: > Is there a trace I can run on this a restore to see what is taking so long? > Is there a SQL Select that would give me where the time was spent for this > restore or is my only source the activity log? [ Oh yeah, you could also... ] If you MOVE NODEDATA for the affected filesystem onto disk, you can do several things: rule out badly fragmented data on the tapes (if it takes hours to move data from LT0 to local disk, then you have very very poor fragmentation characteristics) and then you can do the restore off the disk, which should rule out backhitch problems. Once those two sources are cut out, it'll probably be really clear if the network is in the way. - Allen S. Rout
Re: CAN RESTORE ACTIVITY BE TRACED?
>> On Thu, 27 Jul 2006 10:37:46 -0500, Laura Mastandrea <[EMAIL PROTECTED]> >> said: > Running TSM 5.2.4 on AIX 5.3 and restoring a Windows 2000 Advanced > server client. The filespace is on tape in a non-colocated storage > pool. The tape library is a 3584 with LTO3 drives. It takes about > 3 hours to restore 7 GB of compressed data. > I can monitor by doing q se f=d, but for three hours I can't do > this. The server at the time was not busy with other tape activity > that I could see. > Is there a trace I can run on this a restore to see what is taking > so long? Is there a SQL Select that would give me where the time > was spent for this restore or is my only source the activity log? What did the network throughput at the end of the restore look like? Are you certain that everything was properly configured? The single most common problem I've encountered with throughput is the "New box, duplex mismatch, slow network" problem. On the AIX side, you can use nmon to watch what the network is doing, and from that you could see wether the flow was steady or spiky. I have no idea how one monitors a windows box. Unless you've got some serious disk under your windows box, the LTO streaming speed is going to blow the doors off everything in the critical path between tape and client disk. This will mean that you'll do a lot of backhitching, which I understand LTO is not so good at. If you see spiky network on the server side, then that's a decent bet. - Allen S. Rout
inventory expiration time
I am wondering if my inventory expiration elapsed times are typical. Examining just under 8,000,000 objects and deleting between 139k and 200k objects taking between 7.5 and 8.75 hours. Running on AIX 5.3 on a new P-series machine. TSM 5.3.4. Also, running some storage pool backups for the first 4 hours but that is all. See below. Date/TimeMessage -- 07/20/06 13:24:26 ANR0812I Inventory file expiration process 289 completed: examined 7858857 objects, deleting 138913 backup objects, 7:24 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 13355, PROCESS: 289) 07/21/06 14:40:23 ANR0812I Inventory file expiration process 309 completed: examined 7872837 objects, deleting 128256 backup objects, 8:40 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 14158, PROCESS: 309) 07/22/06 13:38:03 ANR0812I Inventory file expiration process 331 completed: examined 7911819 objects, deleting 157925 backup objects, 7:38 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 14809, PROCESS: 331) 07/23/06 14:09:38 ANR0812I Inventory file expiration process 352 completed: examined 7908552 objects, deleting 159163 backup objects, 8:09 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 15480, PROCESS: 352) 07/24/06 13:40:14 ANR0812I Inventory file expiration process 369 completed: examined 7886486 objects, deleting 152935 backup objects, 7:40 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 16156, PROCESS: 369) 07/25/06 14:02:38 ANR0812I Inventory file expiration process 392 completed: examined 7837552 objects, deleting 163399 backup objects, 8:02 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 17165, PROCESS: 392) 07/26/06 13:27:24 ANR0812I Inventory file expiration process 413 completed: examined 7790356 objects, deleting 159788 backup objects, 7:27 hrs0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 17634, PROCESS: 413) 07/27/06 14:42:01 ANR0812I Inventory file expiration process 435 completed: examined 7830543 objects, deleting 204427 backup objects, 8:42 hrs 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 18914, tsm: TSMSERV1>q db Available Assigned Maximum Maximum Page TotalUsed PctMax. Space Capacity Extension Reduction Size Usable Pages Util Pct (MB) (MB)(MB)(MB) (bytes) Pages Util - - - --- - - - - 58,344 47,356 10,988 22,108 4,096 12,123,136 6,357,309 52.453.4
CAN RESTORE ACTIVITY BE TRACED?
Running TSM 5.2.4 on AIX 5.3 and restoring a Windows 2000 Advanced server client. The filespace is on tape in a non-colocated storage pool. The tape library is a 3584 with LTO3 drives. It takes about 3 hours to restore 7 GB of compressed data. I can monitor by doing q se f=d, but for three hours I can't do this. The server at the time was not busy with other tape activity that I could see. Is there a trace I can run on this a restore to see what is taking so long? Is there a SQL Select that would give me where the time was spent for this restore or is my only source the activity log? Thank you for your assistance. Laura Mastandrea DISCLAIMER: This communication, along with any documents, files or attachments, is intended only for the use of the addressee and may contain legally privileged and confidential information. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of any information contained in or attached to this communication is strictly prohibited. If you have received this message in error, please notify the sender immediately and destroy the original communication and its attachments without reading, printing or saving in any manner. This communication does not form any contractual obligation on behalf of the sender or, the sender's employer, or the employer's parent company, affiliates or subsidiaries.
Re: Using tsm-encryption and want to change the hostname at the Client
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
