Re: verify management class
I believe it should look for new domain default management class Besides , you should also consider increasing backup retention associated to policy domain. If any object bound to specific management class and if it doesn't found the same management class in your new domain then it will consider policy domain backup retention grace period. So it would also protect your data https://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?topic=%2Fcom.ibm.itsmaixn.doc%2Fanragd55434.htm By Sarav +65-82284384 On 22 Oct 2014, at 2:56 am, Hanover, Cameron chano...@umich.edu wrote: While I search for answers elsewhere, maybe someone already has an answer floating around in their head. TSM server 6.3. I have a user that has about 2 weeks worth of TDP/SQL backups. They have turned off backups on the node. They have a 60 day retention policy currently. They want to retain all two weeks of backups for 365 days, including the inactive ones. My thought was this: Create a new domain with a new default management class that has a 365 day retention. Update the node to that domain, and all of its backups would be assigned the default retention policy of the new domain. I was hoping that I could query the backups table to verify that this was the case, but it doesn't appear to be that simple. select hl_name,ll_name,class_name,state from backups where node_name='BF-SPDB01_SQL' HL_NAME: \WSS_Content_uhr\ LL_NAME: full CLASS_NAME: DEFAULT STATE: ACTIVE_VERSION When expiration runs, will it consider the default retention policy of the domain when the backup was performed, or will it look at the new domain? My backup idea is to update the STANDARD management class on another server instance to 365 days retention and export the node over there. -- Cameron Hanover chano...@umich.edu A parade of thugs and fashion critics could pass through your living room without you noticing, provided you were distracted by a sufficiently shiny piece of tinfoil. --Lore Sjöberg
TSM for VE 7.1.1 upgrade question
I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
Re: TSM client availability for Max OS X 10.10 (Yosemite)
Hi Ruth, We are very interested as well, and asked our business partner this same question. This is what I got back from them: [IBM's] goal is to support new versions of OS within 90 days. I'm hoping that they will announce something in the next couple of weeks, but I'm also not holding my breath. ..Paul At 04:17 PM 10/21/2014, Mitchell, Ruth Slovik wrote: Hi all, Does anyone know when a TSM client will be available/approved for Mac OS X 10.10 Yosemite? Many thanks. Ruth Mitchell U of I, Urbana, IL -- Paul ZarnowskiPh: 607-255-4757 Assistant Director of Storage ServicesFx: 607-255-8521 IT at Cornell / InfrastructureEm: p...@cornell.edu 719 Rhodes Hall, Ithaca, NY 14853-3801
Re: TSM for VE 7.1.1 upgrade question
One more thing I just noticed. The selection was greyed out because I had not yet selected a server to back up. Once you select a server, the pull down becomes active and you get 4 choices on the 7.1.0 setups with the default being Incremental Forever - Incremental but the updated client only has the one choice Periodic Full - Full. On Wed, Oct 22, 2014 at 10:11 AM, Tom Alverson tom.alver...@gmail.com wrote: I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
Re: TSM for VE 7.1.1 upgrade question
Are you sure you included the VM feature when you upgraded the B/A client? FYI, if you do the VME upgrade to 7.1.1.0 first, it will automatically upgrade the B/A client as well. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Alverson Sent: Wednesday, October 22, 2014 10:11 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM for VE 7.1.1 upgrade question I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
Which volumes for a VM?
I have my VME storage pool setup to collocate by filespace so (mostly) each VM has its own set of backup volumes. For my upcoming DR test we will be restoring one or two VMs. I desperately need a way to determine which set of volumes are being used by any given VM. Any help out there? David
Re: TSM for VE 7.1.1 upgrade question
Did you upgrade VE to 7.1.1 first? -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Alverson Sent: Wednesday, October 22, 2014 10:11 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM for VE 7.1.1 upgrade question I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
Re: Which volumes for a VM?
Hallo David, may be this helps as a starter: select distinct volume_name - from volumeusage - where node_name='CLIENT' - and stgpool_name='POOL' - and filespace_name='\\tsmxxx\c$' rgds Michael.Malitz @tsmpoweradmin.com David Ehresman david.ehres...@louisville.edu hat am 22. Oktober 2014 um 16:30 geschrieben: I have my VME storage pool setup to collocate by filespace so (mostly) each VM has its own set of backup volumes. For my upcoming DR test we will be restoring one or two VMs. I desperately need a way to determine which set of volumes are being used by any given VM. Any help out there? David
Re: Which volumes for a VM?
David, Here's one way to do it. __ tsm: q fi data center node name \VMFULL-vm-name # query filespace output displays FSID of the filespace for the vm in question __ tsm: select volume_name from volumeusage where filespace_id ='FSID' Hope this works for you, Keith
Re: Which volumes for a VM?
Thanks. I expected queries against the volumeusage table to run forever, but this actually ran quite quickly. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Arbogast, Warren K Sent: Wednesday, October 22, 2014 10:42 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Which volumes for a VM? David, Here's one way to do it. __ tsm: q fi data center node name \VMFULL-vm-name # query filespace output displays FSID of the filespace for the vm in question __ tsm: select volume_name from volumeusage where filespace_id ='FSID' Hope this works for you, Keith
tsm server failes to start in foreground!!
TSM service fails to start, tried running in foreground. Any ideas!! C:\Program Files\Tivoli\TSM\serverdsmserv -k server1 ANR7800I DSMSERV generated at 16:13:56 on Oct 19 2012. Tivoli Storage Manager for Windows Version 6, Release 3, Level 3.000 Licensed Materials - Property of IBM (C) Copyright IBM Corporation 1990, 2011. All rights reserved. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corporation. ANR0900I Processing options file c:\program files\tivoli\tsm\server1\dsmserv.opt. ANR4726I The ICC support module has been loaded. ANR0990I Server restart-recovery in progress. ANR0151W Database manager fails to start. For more information about the failure, issue the db2start command. ANRD_2785511358 RdbStartInstance(rdbinst.c:1310) Thread0: Add codes to msg DB_DATABASE_S- TART_FAILED sqlCode -1397. ANRD Thread0 issued message from: ANRD Thread0 07FEEAA09839 OutDiagToCons()+159 ANRD Thread0 07FEEAA033BC outDiagfExt()+fc ANRD Thread0 07FEEA7D72FB RdbStartInstance()+41b ANRD Thread0 07FEEA73B522 dbiInit()+152 ANRD Thread0 07FEEA20D35D AdmServerMonitorThread()+73d ANRD Thread0 07FEEA20EAAB admStartServer()+cb ANRD Thread0 07FEEA1F3474 adsmMain()+e84 ANRD Thread0 00013FE0111B main()+9b dsmserv.c:241 ANRD Thread0 00013FE028DA __tmainCRTStartup()+11a crtexe.c:555 ANRD Thread0 76CD652D BaseThreadInitThunk()+d ANRD Thread0 76E0C521 RtlUserThreadStart()+21 ANR0172I rdbdb.c(1650): Error encountered performing action InstanceStop. ANR0162W Supplemental database diagnostic information: -1032:SQLSTATE 57019: The statement was not successful, because of a problem with a resource. :-1032 (SQL1032N No start database manager command was issued. SQLSTATE=57019 Tim Brown
Re: tsm server failes to start in foreground!!
Login as TSM/DB2 instance owner to run db2start: [see 4th message line from failure below] ANR0151W Database manager fails to start. For more information about the failure, issue the db2start command. jim.o...@yale.edu (w#203.432.6693, c#203.494.9201, h#203.387.3030) On 10/22/2014 11:00 AM, Tim Brown wrote: TSM service fails to start, tried running in foreground. Any ideas!! C:\Program Files\Tivoli\TSM\serverdsmserv -k server1 ANR7800I DSMSERV generated at 16:13:56 on Oct 19 2012. Tivoli Storage Manager for Windows Version 6, Release 3, Level 3.000 Licensed Materials - Property of IBM (C) Copyright IBM Corporation 1990, 2011. All rights reserved. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corporation. ANR0900I Processing options file c:\program files\tivoli\tsm\server1\dsmserv.opt. ANR4726I The ICC support module has been loaded. ANR0990I Server restart-recovery in progress. ANR0151W Database manager fails to start. For more information about the failure, issue the db2start command. ANRD_2785511358 RdbStartInstance(rdbinst.c:1310) Thread0: Add codes to msg DB_DATABASE_S- TART_FAILED sqlCode -1397. ANRD Thread0 issued message from: ANRD Thread0 07FEEAA09839 OutDiagToCons()+159 ANRD Thread0 07FEEAA033BC outDiagfExt()+fc ANRD Thread0 07FEEA7D72FB RdbStartInstance()+41b ANRD Thread0 07FEEA73B522 dbiInit()+152 ANRD Thread0 07FEEA20D35D AdmServerMonitorThread()+73d ANRD Thread0 07FEEA20EAAB admStartServer()+cb ANRD Thread0 07FEEA1F3474 adsmMain()+e84 ANRD Thread0 00013FE0111B main()+9b dsmserv.c:241 ANRD Thread0 00013FE028DA __tmainCRTStartup()+11a crtexe.c:555 ANRD Thread0 76CD652D BaseThreadInitThunk()+d ANRD Thread0 76E0C521 RtlUserThreadStart()+21 ANR0172I rdbdb.c(1650): Error encountered performing action InstanceStop. ANR0162W Supplemental database diagnostic information: -1032:SQLSTATE 57019: The statement was not successful, because of a problem with a resource. :-1032 (SQL1032N No start database manager command was issued. SQLSTATE=57019 Tim Brown
Deduplication anomalies
I am trying to determine the causes of two anomalies in the behavior of a deduplicated storage pool in our TSM test environment. The test environment uses TSM 6.2.5.0 server code running under zSeries Linux. The environment has been using only server side deduplication since early September. Some tests before that time used client side deduplication. The first anomaly has to do with reclamation of the deduplicated storage pool. For the last several days 'reclaim stgpool' commands have ended immediately with the message: ANR2111W RECLAIM STGPOOL: There is no data to process for LDH. This was surprising, given the amount of duplicated date reported by 'identify duplicates' processes. Yesterday I discovered that the storage pool had several volumes that were eligible for reclamation with the threshold that had been specified in the 'reclaim stgpool' commands. There had been a successful storage pool backup after the then most recent client backup sessions. I was able to perform 'move data' commands for each of the eligible volumes. The second anomaly has to do with filling volumes. The deduplicated storage pool has 187 filling volumes with a reported occupancy of 0.0. Most of these also have the percentage of reclaimable space also reported as 0.0, and all have the percentage of reclaimable space below 20. Most of the last write dates are concentrated in three afternoons. I maintain a document in which I log changes in the test environment and observations of the behavior of the environment. This document does not show any change in the environment or any observed anomalies on the days when most of the low occupancy volumes were last written. The test environment has two collocation groups. I have verified that the deduplicated storage pool is configured for collocation by group and that every node is in one of the collocation groups. All of the volumes in the storage pool have an access setting of 'READWRITE'. I have tried performing 'move data' commands for a few of the low occupancy volumes. The test environment consistently allocated a new scratch volume for output rather than adding the contents of the input volume to one of the few filling volumes with substantial amounts of data or to one of the many other low occupancy volumes. Web searches for the ANR2111W message turned up nothing except reminders that a storage pool backup is needed before reclamation. Web searches for various groups of keywords related to the second anomaly have turned up nothing recognizably relevant. Thomas Denier Thomas Jefferson University Hospital The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters.
TSM 7.1 usage of volumes for dedupe
We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the volumes in the storage pool. Since we never ran v6, I don't know if this is normal or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch volumes as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status --- -- - - /data0/0B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/0C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM 7.1 usage of volumes for dedupe
Hi Martha, have you run query content on some of the volumes to see, if they are really empty? Michael On Wed, Oct 22, 2014 at 5:47 PM, Martha M McConaghy martha.mccona...@marist.edu wrote: We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the volumes in the storage pool. Since we never ran v6, I don't know if this is normal or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch volumes as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status --- -- - - /data0/0B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/0C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM 7.1 usage of volumes for dedupe
Hi Martha! Has the storage pool been backed up to a copy pool? If the DEDUPREQUIRESBACKUP option is set to YES (default), reclaim can't happen until the BACKUP STGPOOL is done. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael Roesch Sent: Wednesday, October 22, 2014 12:08 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe Hi Martha, have you run query content on some of the volumes to see, if they are really empty? Michael On Wed, Oct 22, 2014 at 5:47 PM, Martha M McConaghy martha.mccona...@marist.edu wrote: We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the volumes in the storage pool. Since we never ran v6, I don't know if this is normal or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch volumes as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status --- -- - - /data0/0B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/0C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM 7.1 usage of volumes for dedupe
Yup, they are really empty. /data0/0D57.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full tsm: TSMPRIMESERVERq content /data0/0D57.BFS Session established with server TSMPRIMESERVER: Linux/x86_64 Server Version 7, Release 1, Level 1.0 Server date/time: 10/22/2014 12:54:58 Last access: 10/22/2014 11:36:27 ANR2034E QUERY CONTENT: No match found using this criteria. ANS8001I Return code 11. Martha On 10/22/2014 12:08 PM, Michael Roesch wrote: Hi Martha, have you run query content on some of the volumes to see, if they are really empty? Michael On Wed, Oct 22, 2014 at 5:47 PM, Martha M McConaghy martha.mccona...@marist.edu wrote: We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the volumes in the storage pool. Since we never ran v6, I don't know if this is normal or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch volumes as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status --- -- - - /data0/0B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/0C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601 -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM 7.1 usage of volumes for dedupe
Yeah, I do it regularly, at least once a week. We also have a replication server, but I like the security of having them on tape too. I usually run the reclamation after the backup is done. Martha On 10/22/2014 12:29 PM, Prather, Wanda wrote: Hi Martha! Has the storage pool been backed up to a copy pool? If the DEDUPREQUIRESBACKUP option is set to YES (default), reclaim can't happen until the BACKUP STGPOOL is done. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael Roesch Sent: Wednesday, October 22, 2014 12:08 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe Hi Martha, have you run query content on some of the volumes to see, if they are really empty? Michael On Wed, Oct 22, 2014 at 5:47 PM, Martha M McConaghy martha.mccona...@marist.edu wrote: We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the volumes in the storage pool. Since we never ran v6, I don't know if this is normal or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch volumes as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status --- -- - - /data0/0B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/0C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601 -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM client availability for Max OS X 10.10 (Yosemite)
Hi Ruth and Paul, The test teams just completed testing and the support announcement was just added to the requirements technote: The overall page: http://www-01.ibm.com/support/docview.wss?uid=swg21243309 The specific page for the Apple Macintosh Client Requirements: http://www-01.ibm.com/support/docview.wss?rs=663context=SSGSG7q1=client+requirements+macintoshuid=swg21053584loc=en_UScs=utf-8lang=en Note: Mac OS X 10.10 support is with a 7.1.1 or higher client. Thank you, Del ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 10/21/2014 04:17:34 PM: From: Mitchell, Ruth Slovik rmi...@illinois.edu To: ADSM-L@VM.MARIST.EDU Date: 10/21/2014 04:19 PM Subject: TSM client availability for Max OS X 10.10 (Yosemite) Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Hi all, Does anyone know when a TSM client will be available/approved for Mac OS X 10.10 Yosemite? Many thanks. Ruth Mitchell U of I, Urbana, IL
Re: TSM 7.1 usage of volumes for dedupe
hi Martha, See if this can apply : www-01.ibm.com/support/docview.wss?uid=swg21685554 Note that I had a situation where Q CONT returned that the volume was empty but it wasn't in reality since it was impossible to delete it (without discrading data). A select statement against the contents showed some files. Unforunately, I don't know how this story finished... -- Best regards / Cordialement / مع تحياتي Erwann SIMON - Mail original - De: Martha M McConaghy martha.mccona...@marist.edu À: ADSM-L@VM.MARIST.EDU Envoyé: Mercredi 22 Octobre 2014 17:47:14 Objet: [ADSM-L] TSM 7.1 usage of volumes for dedupe We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the volumes in the storage pool. Since we never ran v6, I don't know if this is normal or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch volumes as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status --- -- - - /data0/0B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/0C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM client availability for Max OS X 10.10 (Yosemite)
Thanks Del! At 01:49 PM 10/22/2014, Del Hoobler wrote: Hi Ruth and Paul, The test teams just completed testing and the support announcement was just added to the requirements technote: The overall page: http://www-01.ibm.com/support/docview.wss?uid=swg21243309 The specific page for the Apple Macintosh Client Requirements: http://www-01.ibm.com/support/docview.wss?rs=663context=SSGSG7q1=client+requirements+macintoshuid=swg21053584loc=en_UScs=utf-8lang=en Note: Mac OS X 10.10 support is with a 7.1.1 or higher client. Thank you, Del ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 10/21/2014 04:17:34 PM: From: Mitchell, Ruth Slovik rmi...@illinois.edu To: ADSM-L@VM.MARIST.EDU Date: 10/21/2014 04:19 PM Subject: TSM client availability for Max OS X 10.10 (Yosemite) Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Hi all, Does anyone know when a TSM client will be available/approved for Mac OS X 10.10 Yosemite? Many thanks. Ruth Mitchell U of I, Urbana, IL -- Paul ZarnowskiPh: 607-255-4757 Assistant Director of Storage ServicesFx: 607-255-8521 IT at Cornell / InfrastructureEm: p...@cornell.edu 719 Rhodes Hall, Ithaca, NY 14853-3801
Re: TSM 7.1 usage of volumes for dedupe
Martha, !!Maybe your volumes are *not* really empty: retry with... Query CONtent [volname] FOLLOWLinks=Yes[especially for deduplicated content] See Help Query CONtent for details ... including default: FOLLOWLinks=No jim.o...@yale.edu (w#203.432.6693, c#203.494.9201, h#203.387.3030) On 10/22/2014 1:05 PM, Martha M McConaghy wrote: Yup, they are really empty. /data0/0D57.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full tsm: TSMPRIMESERVERq content /data0/0D57.BFS Session established with server TSMPRIMESERVER: Linux/x86_64 Server Version 7, Release 1, Level 1.0 Server date/time: 10/22/2014 12:54:58 Last access: 10/22/2014 11:36:27 ANR2034E QUERY CONTENT: No match found using this criteria. ANS8001I Return code 11. Martha On 10/22/2014 12:08 PM, Michael Roesch wrote: Hi Martha, have you run query content on some of the volumes to see, if they are really empty? Michael On Wed, Oct 22, 2014 at 5:47 PM, Martha M McConaghy martha.mccona...@marist.edu wrote: We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the volumes in the storage pool. Since we never ran v6, I don't know if this is normal or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch volumes as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status --- -- - - /data0/0B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/0C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601 -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM VE Question
Hi David, The versioning is on the virtual machine and not the disks; so the vm backups that have disk #2 included will last as long as the parent vm in terms of policy. Each incremental backup creates a new version of the vm backup and will thus expire the current active version; so if you have a daily schedule set-up for incr. forever backups, the backups in question will age out naturally. Del ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 10/16/2014 03:50:10 PM: From: David Ehresman david.ehres...@louisville.edu To: ADSM-L@VM.MARIST.EDU Date: 10/16/2014 03:50 PM Subject: TSM VE Question Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU I am backing up a VM which has two hard disks use TSMVE incremental forever. If I switch to only backing up the first hard disk, will backups for the 2nd hard disk expire? Or will they hang around forever? TSMVE 7.1.1.0. David
Re: TSM for VE 7.1.1 upgrade question
I did not know that about the VME update. I planned to update the BACLIENT first and make sure the nightly backup ran ok before updating the TSM for VE part. Tom On Wed, Oct 22, 2014 at 10:26 AM, David Ehresman david.ehres...@louisville.edu wrote: Are you sure you included the VM feature when you upgraded the B/A client? FYI, if you do the VME upgrade to 7.1.1.0 first, it will automatically upgrade the B/A client as well. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Alverson Sent: Wednesday, October 22, 2014 10:11 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM for VE 7.1.1 upgrade question I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
Re: TSM for VE 7.1.1 upgrade question
No, I planned to to that tomorrow if this update did not break anything. On Wed, Oct 22, 2014 at 10:32 AM, Prather, Wanda wanda.prat...@icfi.com wrote: Did you upgrade VE to 7.1.1 first? -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Alverson Sent: Wednesday, October 22, 2014 10:11 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM for VE 7.1.1 upgrade question I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
Re: TSM for VE 7.1.1 upgrade question
I think I might go ahead and try the TSM for VE 7.1.1 update now as I have my doubts as to whether tonight's scheduled backup will work how it is now. On Wed, Oct 22, 2014 at 10:26 AM, David Ehresman david.ehres...@louisville.edu wrote: Are you sure you included the VM feature when you upgraded the B/A client? FYI, if you do the VME upgrade to 7.1.1.0 first, it will automatically upgrade the B/A client as well. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Alverson Sent: Wednesday, October 22, 2014 10:11 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM for VE 7.1.1 upgrade question I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
Re: TSM 7.1 usage of volumes for dedupe
Nice try, but no luck: tsm: TSMPRIMESERVERq content /data0/0D57.BFS followlinks=yes Session established with server TSMPRIMESERVER: Linux/x86_64 Server Version 7, Release 1, Level 1.0 Server date/time: 10/22/2014 14:10:44 Last access: 10/22/2014 12:54:58 ANR2034E QUERY CONTENT: No match found using this criteria. ANS8001I Return code 11. Martha On 10/22/2014 2:01 PM, James R Owen wrote: Martha, !!Maybe your volumes are *not* really empty: retry with... Query CONtent [volname] FOLLOWLinks=Yes[especially for deduplicated content] See Help Query CONtent for details ... including default: FOLLOWLinks=No jim.o...@yale.edu (w#203.432.6693, c#203.494.9201, h#203.387.3030) On 10/22/2014 1:05 PM, Martha M McConaghy wrote: Yup, they are really empty. /data0/0D57.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full tsm: TSMPRIMESERVERq content /data0/0D57.BFS Session established with server TSMPRIMESERVER: Linux/x86_64 Server Version 7, Release 1, Level 1.0 Server date/time: 10/22/2014 12:54:58 Last access: 10/22/2014 11:36:27 ANR2034E QUERY CONTENT: No match found using this criteria. ANS8001I Return code 11. Martha On 10/22/2014 12:08 PM, Michael Roesch wrote: Hi Martha, have you run query content on some of the volumes to see, if they are really empty? Michael On Wed, Oct 22, 2014 at 5:47 PM, Martha M McConaghy martha.mccona...@marist.edu wrote: We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the volumes in the storage pool. Since we never ran v6, I don't know if this is normal or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch volumes as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status --- -- - - /data0/0B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/0C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601 -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601 -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM 7.1 usage of volumes for dedupe
Interesting. Seems very similar, except the status of these volumes is FULL, not EMPTY. However, the %reclaimable space is 0.0. I think this is a bug. I would expect the volume to leave the pool once it is reclaimed. It would be OK with me if it did not. However, since the status is FULL, it will never be reused. That seems wrong. If it is going to remain attached to the dedupepool, the status should convert to EMPTY so the file can be reused. Or, go away altogether so the space can be reclaimed and reused. In looking at the filesystem on the Linux side (sorry I didn't mention this is running on RHEL), the file exists on /data0, but with no size: [urmm@tsmserver data0]$ ls -l *d57* -rw--- 1 tsminst1 tsmsrvrs 0 Oct 10 20:22 0d57.bfs /data0 is 100% utilized, so this file can never grow. Seems like it should get cleaned up rather than continue to exist. Martha On 10/22/2014 1:58 PM, Erwann SIMON wrote: hi Martha, See if this can apply : www-01.ibm.com/support/docview.wss?uid=swg21685554 Note that I had a situation where Q CONT returned that the volume was empty but it wasn't in reality since it was impossible to delete it (without discrading data). A select statement against the contents showed some files. Unforunately, I don't know how this story finished... -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM 7.1 usage of volumes for dedupe
Martha, I guess your FS is quite large. You can obtain some free space by reducing the percentage of reserved blocks. Default is 5%, you can safely decrease this value to 2%, see m option of the tune2fs command. -- Best regards / Cordialement / مع تحياتي Erwann SIMON - Mail original - De: Martha M McConaghy martha.mccona...@marist.edu À: ADSM-L@VM.MARIST.EDU Envoyé: Mercredi 22 Octobre 2014 20:22:31 Objet: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe Interesting. Seems very similar, except the status of these volumes is FULL, not EMPTY. However, the %reclaimable space is 0.0. I think this is a bug. I would expect the volume to leave the pool once it is reclaimed. It would be OK with me if it did not. However, since the status is FULL, it will never be reused. That seems wrong. If it is going to remain attached to the dedupepool, the status should convert to EMPTY so the file can be reused. Or, go away altogether so the space can be reclaimed and reused. In looking at the filesystem on the Linux side (sorry I didn't mention this is running on RHEL), the file exists on /data0, but with no size: [urmm@tsmserver data0]$ ls -l *d57* -rw--- 1 tsminst1 tsmsrvrs 0 Oct 10 20:22 0d57.bfs /data0 is 100% utilized, so this file can never grow. Seems like it should get cleaned up rather than continue to exist. Martha On 10/22/2014 1:58 PM, Erwann SIMON wrote: hi Martha, See if this can apply : www-01.ibm.com/support/docview.wss?uid=swg21685554 Note that I had a situation where Q CONT returned that the volume was empty but it wasn't in reality since it was impossible to delete it (without discrading data). A select statement against the contents showed some files. Unforunately, I don't know how this story finished... -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM 7.1 usage of volumes for dedupe
Hi Martha, I see this situation occur when a filesystem gets almost completely full. Do 'q dirsp dev-class-name' to check for nearly full filesystems. The server doesn't fence off a filesystem like this, instead it keeps hammering on it, allocating new volumes. When it tries to write to a volume and gets an immediate out-of-space error, it marks the volume full so it won't try to use it again. I run this sql to find such volumes and delete them - select 'del v '||cast(volume_name as char(40)), cast(stgpool_name as char(30)), last_write_date - from volumes where upper(status) = 'FULL' and pct_utilized = 0 and pct_reclaim = 0 order by 2, 3 You should remove such filesystems from the devclass directory list until reclaim has emptied them a little bit. Hope his helps, Bill Colwell Draper Lab -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Martha M McConaghy Sent: Wednesday, October 22, 2014 2:23 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: TSM 7.1 usage of volumes for dedupe Interesting. Seems very similar, except the status of these volumes is FULL, not EMPTY. However, the %reclaimable space is 0.0. I think this is a bug. I would expect the volume to leave the pool once it is reclaimed. It would be OK with me if it did not. However, since the status is FULL, it will never be reused. That seems wrong. If it is going to remain attached to the dedupepool, the status should convert to EMPTY so the file can be reused. Or, go away altogether so the space can be reclaimed and reused. In looking at the filesystem on the Linux side (sorry I didn't mention this is running on RHEL), the file exists on /data0, but with no size: [urmm@tsmserver data0]$ ls -l *d57* -rw--- 1 tsminst1 tsmsrvrs 0 Oct 10 20:22 0d57.bfs /data0 is 100% utilized, so this file can never grow. Seems like it should get cleaned up rather than continue to exist. Martha On 10/22/2014 1:58 PM, Erwann SIMON wrote: hi Martha, See if this can apply : www-01.ibm.com/support/docview.wss?uid=swg21685554 Note that I had a situation where Q CONT returned that the volume was empty but it wasn't in reality since it was impossible to delete it (without discrading data). A select statement against the contents showed some files. Unforunately, I don't know how this story finished... -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601 Notice: This email and any attachments may contain proprietary (Draper non-public) and/or export-controlled information of Draper Laboratory. If you are not the intended recipient of this email, please immediately notify the sender by replying to this email and immediately destroy all copies of this email.
Re: TSM 7.1 usage of volumes for dedupe
What's your colocation set too for that stgpool? On 22 Oct 2014 16:50, Martha M McConaghy martha.mccona...@marist.edu wrote: We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the volumes in the storage pool. Since we never ran v6, I don't know if this is normal or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch volumes as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status --- -- - - /data0/0B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/0C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM 7.1 usage of volumes for dedupe
Don't believe that. I have seen it before - if you can do a MOVE DATA, it isn't really empty. I think it has to do with dedup. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Martha M McConaghy Sent: Wednesday, October 22, 2014 1:06 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe Yup, they are really empty. /data0/0D57.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full tsm: TSMPRIMESERVERq content /data0/0D57.BFS Session established with server TSMPRIMESERVER: Linux/x86_64 Server Version 7, Release 1, Level 1.0 Server date/time: 10/22/2014 12:54:58 Last access: 10/22/2014 11:36:27 ANR2034E QUERY CONTENT: No match found using this criteria. ANS8001I Return code 11. Martha On 10/22/2014 12:08 PM, Michael Roesch wrote: Hi Martha, have you run query content on some of the volumes to see, if they are really empty? Michael On Wed, Oct 22, 2014 at 5:47 PM, Martha M McConaghy martha.mccona...@marist.edu wrote: We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the volumes in the storage pool. Since we never ran v6, I don't know if this is normal or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch volumes as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status --- -- - - /data0/0B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/0C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601 -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM 7.1 usage of volumes for dedupe
Try show dedupdeleteinfo - if there are chunks queued or threads actively working on deleting chunks, the volumes will remain. Regards, Joerg Pohlmann -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: October 22, 2014 11:50 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe Don't believe that. I have seen it before - if you can do a MOVE DATA, it isn't really empty. I think it has to do with dedup. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Martha M McConaghy Sent: Wednesday, October 22, 2014 1:06 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe Yup, they are really empty. /data0/0D57.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full tsm: TSMPRIMESERVERq content /data0/0D57.BFS Session established with server TSMPRIMESERVER: Linux/x86_64 Server Version 7, Release 1, Level 1.0 Server date/time: 10/22/2014 12:54:58 Last access: 10/22/2014 11:36:27 ANR2034E QUERY CONTENT: No match found using this criteria. ANS8001I Return code 11. Martha On 10/22/2014 12:08 PM, Michael Roesch wrote: Hi Martha, have you run query content on some of the volumes to see, if they are really empty? Michael On Wed, Oct 22, 2014 at 5:47 PM, Martha M McConaghy martha.mccona...@marist.edu wrote: We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the volumes in the storage pool. Since we never ran v6, I don't know if this is normal or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch volumes as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status --- -- - - /data0/0B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/0C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/0CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601 -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
Re: TSM for VE 7.1.1 upgrade question
OK I ran the TSM for VE install and now everything is at 7.1.1 level. I still have the same issue with the only option being Periodic Full - Full for the backup type in the GUI. I started a backup of a random VM and instead of failing right away it looks like it is backing up something. Does upgrading to 7.1.1 force all backups to do a fresh initial full backup?? On Wed, Oct 22, 2014 at 2:11 PM, Tom Alverson tom.alver...@gmail.com wrote: I think I might go ahead and try the TSM for VE 7.1.1 update now as I have my doubts as to whether tonight's scheduled backup will work how it is now. On Wed, Oct 22, 2014 at 10:26 AM, David Ehresman david.ehres...@louisville.edu wrote: Are you sure you included the VM feature when you upgraded the B/A client? FYI, if you do the VME upgrade to 7.1.1.0 first, it will automatically upgrade the B/A client as well. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Alverson Sent: Wednesday, October 22, 2014 10:11 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM for VE 7.1.1 upgrade question I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
Re: TSM for VE 7.1.1 upgrade question
Tom, This is a known issue and we are working on it. See APAR IT04554. The local fix suggests: 1 - Run custom install of the 7.1.1.0 TSM for Virtual Environments install suite from PPA, Choose to only install the TSM for Virtual Environments enablement file. As an alternative, you can uninstall the product completely and then install 7.1.1. Let me know if this resolves the issue. Alexei Kojenov TSM Client Development ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 10/22/2014 12:20:11 PM: From: Tom Alverson tom.alver...@gmail.com To: ADSM-L@VM.MARIST.EDU Date: 10/22/2014 12:21 PM Subject: Re: [ADSM-L] TSM for VE 7.1.1 upgrade question Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU OK I ran the TSM for VE install and now everything is at 7.1.1 level. I still have the same issue with the only option being Periodic Full - Full for the backup type in the GUI. I started a backup of a random VM and instead of failing right away it looks like it is backing up something. Does upgrading to 7.1.1 force all backups to do a fresh initial full backup?? On Wed, Oct 22, 2014 at 2:11 PM, Tom Alverson tom.alver...@gmail.com wrote: I think I might go ahead and try the TSM for VE 7.1.1 update now as I have my doubts as to whether tonight's scheduled backup will work how it is now. On Wed, Oct 22, 2014 at 10:26 AM, David Ehresman david.ehres...@louisville.edu wrote: Are you sure you included the VM feature when you upgraded the B/A client? FYI, if you do the VME upgrade to 7.1.1.0 first, it will automatically upgrade the B/A client as well. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Alverson Sent: Wednesday, October 22, 2014 10:11 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM for VE 7.1.1 upgrade question I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
Re: TSM for VE 7.1.1 upgrade question
Are you saying the download I got from the open FTP site will not work? I was able to trigger a command line backup if I included the -mode=IFINCR option, but the first time I tried it I got the license error. I found the old license from the initial install and copied it to the BACLIENT directory and was able to do a manual command line backup. If I have to log into some PPA site to download a good installer I will need to find one of my co-workers who has done this before to help me out as I have not used that myself. On Wed, Oct 22, 2014 at 5:38 PM, Alexei Kojenov kojen...@us.ibm.com wrote: Tom, This is a known issue and we are working on it. See APAR IT04554. The local fix suggests: 1 - Run custom install of the 7.1.1.0 TSM for Virtual Environments install suite from PPA, Choose to only install the TSM for Virtual Environments enablement file. As an alternative, you can uninstall the product completely and then install 7.1.1. Let me know if this resolves the issue. Alexei Kojenov TSM Client Development ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 10/22/2014 12:20:11 PM: From: Tom Alverson tom.alver...@gmail.com To: ADSM-L@VM.MARIST.EDU Date: 10/22/2014 12:21 PM Subject: Re: [ADSM-L] TSM for VE 7.1.1 upgrade question Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU OK I ran the TSM for VE install and now everything is at 7.1.1 level. I still have the same issue with the only option being Periodic Full - Full for the backup type in the GUI. I started a backup of a random VM and instead of failing right away it looks like it is backing up something. Does upgrading to 7.1.1 force all backups to do a fresh initial full backup?? On Wed, Oct 22, 2014 at 2:11 PM, Tom Alverson tom.alver...@gmail.com wrote: I think I might go ahead and try the TSM for VE 7.1.1 update now as I have my doubts as to whether tonight's scheduled backup will work how it is now. On Wed, Oct 22, 2014 at 10:26 AM, David Ehresman david.ehres...@louisville.edu wrote: Are you sure you included the VM feature when you upgraded the B/A client? FYI, if you do the VME upgrade to 7.1.1.0 first, it will automatically upgrade the B/A client as well. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Alverson Sent: Wednesday, October 22, 2014 10:11 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM for VE 7.1.1 upgrade question I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
Re: TSM for VE 7.1.1 upgrade question
That APAR only talks about the license file problem. My problem is the GUI is stuck in the Periodic Full - Full mode with no other options in the pull down menu. Will the fix described in the APAR address this issue? On Wed, Oct 22, 2014 at 5:38 PM, Alexei Kojenov kojen...@us.ibm.com wrote: Tom, This is a known issue and we are working on it. See APAR IT04554. The local fix suggests: 1 - Run custom install of the 7.1.1.0 TSM for Virtual Environments install suite from PPA, Choose to only install the TSM for Virtual Environments enablement file. As an alternative, you can uninstall the product completely and then install 7.1.1. Let me know if this resolves the issue. Alexei Kojenov TSM Client Development ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 10/22/2014 12:20:11 PM: From: Tom Alverson tom.alver...@gmail.com To: ADSM-L@VM.MARIST.EDU Date: 10/22/2014 12:21 PM Subject: Re: [ADSM-L] TSM for VE 7.1.1 upgrade question Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU OK I ran the TSM for VE install and now everything is at 7.1.1 level. I still have the same issue with the only option being Periodic Full - Full for the backup type in the GUI. I started a backup of a random VM and instead of failing right away it looks like it is backing up something. Does upgrading to 7.1.1 force all backups to do a fresh initial full backup?? On Wed, Oct 22, 2014 at 2:11 PM, Tom Alverson tom.alver...@gmail.com wrote: I think I might go ahead and try the TSM for VE 7.1.1 update now as I have my doubts as to whether tonight's scheduled backup will work how it is now. On Wed, Oct 22, 2014 at 10:26 AM, David Ehresman david.ehres...@louisville.edu wrote: Are you sure you included the VM feature when you upgraded the B/A client? FYI, if you do the VME upgrade to 7.1.1.0 first, it will automatically upgrade the B/A client as well. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Alverson Sent: Wednesday, October 22, 2014 10:11 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM for VE 7.1.1 upgrade question I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
Re: TSM for VE 7.1.1 upgrade question
OK now that I have put a copy of the LIC file into the BACLIENT directory it looks like the GUI is working now (it gives me the incremental forever option). I guess maybe this is a feature it will only show you if it sees the license file? I have one of my co-workers downloading from the PPA now but that will take a while. Thanks everyone for the help. Tom On Wed, Oct 22, 2014 at 6:31 PM, Tom Alverson tom.alver...@gmail.com wrote: That APAR only talks about the license file problem. My problem is the GUI is stuck in the Periodic Full - Full mode with no other options in the pull down menu. Will the fix described in the APAR address this issue? On Wed, Oct 22, 2014 at 5:38 PM, Alexei Kojenov kojen...@us.ibm.com wrote: Tom, This is a known issue and we are working on it. See APAR IT04554. The local fix suggests: 1 - Run custom install of the 7.1.1.0 TSM for Virtual Environments install suite from PPA, Choose to only install the TSM for Virtual Environments enablement file. As an alternative, you can uninstall the product completely and then install 7.1.1. Let me know if this resolves the issue. Alexei Kojenov TSM Client Development ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 10/22/2014 12:20:11 PM: From: Tom Alverson tom.alver...@gmail.com To: ADSM-L@VM.MARIST.EDU Date: 10/22/2014 12:21 PM Subject: Re: [ADSM-L] TSM for VE 7.1.1 upgrade question Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU OK I ran the TSM for VE install and now everything is at 7.1.1 level. I still have the same issue with the only option being Periodic Full - Full for the backup type in the GUI. I started a backup of a random VM and instead of failing right away it looks like it is backing up something. Does upgrading to 7.1.1 force all backups to do a fresh initial full backup?? On Wed, Oct 22, 2014 at 2:11 PM, Tom Alverson tom.alver...@gmail.com wrote: I think I might go ahead and try the TSM for VE 7.1.1 update now as I have my doubts as to whether tonight's scheduled backup will work how it is now. On Wed, Oct 22, 2014 at 10:26 AM, David Ehresman david.ehres...@louisville.edu wrote: Are you sure you included the VM feature when you upgraded the B/A client? FYI, if you do the VME upgrade to 7.1.1.0 first, it will automatically upgrade the B/A client as well. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Alverson Sent: Wednesday, October 22, 2014 10:11 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM for VE 7.1.1 upgrade question I have a number of data movers set up with Baclient 7.1.0 and TSM for VE 7.1.0 that are working OK but I wanted to update them to 7.1.1. The main reason is the many failures I get when it does not back up VM Templates (backup of templates is disabled but 7.1.0 still counts these as failures). The issue I ran into is that I update just the Baclient (so far) to 7.1.1 and ran the GUI to do a test backup. Now that data mover only offers Periodic Full - Full as the backup type (not greyed out but no other choice). On the other servers the choice is greyed out and set to Incremental Forever - Incremental. When I try a test backup with the Periodic Full - Full setting on the upgraded server it fails with the error: ANS9395E The filespace has been migrated to the incremental forever model Is this caused by the update of Baclient to 7.1.1 or is there some other configuration error? Tom
