IT12078: VSS SNAPSHOT NAME INCORRECTLY STORED AS FILESPACE IN CLIENT REPL DB. MAY CAUSE ANS2120W OR NO FAILOVER CONSISTENCY CHECK

IBM Spectrum Protect client 7.1.4.x interim fix downloads

APAR status

• Closed as program error.

Error description

• With the introduction of client failover to a replicated server,
  consistency checking was added to compare the last
  backup/archive/migration time from the server with a last
  backup/archive/migration time now stored in the client side
  database (tsmnrtable.DB). One of the fields included in each of
  these client database entries is the filespace name. Currently
  the Tivoli Storage Manager/Spectrum Protect client will
  incorrectly store the VSS snapshot name as the filespace name in
   the client database  if the option SNAPSHOTPROVIDERFS VSS is
  being used. This will create one of two problems depending up
  whether or not a prior backup/archive was performed without the
  SNAPSHOTPROVIDERFS VSS option in place.
  
  Problem 1
  If a backup/archive of the client filespace in question was
  performed without the SNAPSHOTPROVIDERFS VSS option then the
  client database would have a valid entry for the filespace with
  that date and time. On subsequent backup/archives with the
  SNAPSHOTPROVIDERFS VSS option in place, this older date and time
  would not match with the value returned from the server. This
  results in the following messages during backup and restore
  operations:
  
  09/30/2015 19:02:32 ANS2120W The last store operation date
  reported by the server REPLSERVERNAME of 09/29/2015 23:54:24 UTC
  does not match the last store operation date of 06/29/2015
  23:12:44 UTC stored by the client.
  09/30/2015 19:17:52 ANS2120W The last store operation date
  reported by the server REPLSERVERNAME of 09/29/2015 23:54:24 UTC
  does not match the last store operation date of 06/29/2015
  23:12:44 UTC stored by the client.
  
  A client service trace of a new backup and subsequent restore
  from a windows client processing an object on the D: drive shows
  the following:
  
  The entry put into database at backup:
  -------------------------------------------
     Key ServerName   : TSMSRV1
     Key NodeName     : NODE1
     Key Data Type    : 65536
     Key File Space   :
  \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy26
     Sequence         : 25
     Last Update Time : 10/02/2015 18:39:42
  -------------------------------------------
  (Note the filespace value is a VSS snapshot name)
  
  The entry found on restore:
  -------------------------------------------
     Key ServerName   : TSMSRV1
     Key NodeName     : NODE1
     Key Data Type    : 65536
     Key File Space   : \\ac2\d$
     Sequence         : 0
     Last Update Time : 06/29/2015 23:12:44
  -------------------------------------------
  (NOTE: the filespace value is now accurate)
  
  Comparison seen in trace that is triggering the ANS2120W:
    serverStoreDate : 10/02/2015 18:39:42
    localStoreDate  : 06/29/2015 23:12:44
  
  NOTE: the date and time stamp here is in UTC so that client and
  server times can be validly compared without concern for whether
  or not they are in the same timezone.
  
  Problem 2
  If backup/archives have always been run with SNAPSHOTPROVIDERFS
  VSS then all the entries in the client database will have the
  incorrect filespace values. When the client looks for an entry
  in this database a match will not be found because it is looking
  for a record with the valid filespace name. With no record found
  the client does not think a backup of this filespace has ever
  occurred so it will not check for a filespace date and time on
  the server. This means that if the date and time of the
  filespace on the server is not current no notification/warning
  will be issued and the user will not be aware if there is an
  actual difference between the client and server.
  
  A client service trace of a backup for this case shows the
  record not found and the ?not backed up? indication for the
  filespace (when the user knows and can vadidate via a schedule
  log or query filespace through an Admin client that the
  filespace has been backed up):
  
  10/21/2015 09:51:55.791 [004756] [3484] :
  ..\..\common\ba\nrtable.cpp(1475):
  NodeReplicationTableTable::getLastStoreDate searching for
  serverName "TORINO" nodeName "TORINO" fileSpace "\\torino\c$"
  with data type 65536 (Backup data)
  10/21/2015 09:51:55.791 [004756] [3484] :
  ..\..\common\ba\nrtable.cpp( 618):
  NodeReplicationTable::getRecord sKey
  'TORINO:TORINO:65536:\\torino\c$'
  10/21/2015 09:51:55.791 [004756] [3484] :
  ..\..\common\ba\nrtable.cpp( 640):
  NodeReplicationTable::getRecord cache entry for
  'TORINO:TORINO:65536:\\torino\c$' not found .
  10/21/2015 09:51:55.791 [004756] [3484] :
  ..\..\common\ba\nrtable.cpp( 653):
  NodeReplicationTable::getRecord returning 104
  10/21/2015 09:51:55.791 [004756] [3484] :
  ..\..\common\ba\nrtable.cpp( 532): NodeReplicationTable::Close()
  Record bHaveFileLock true bCacheDbOpen true
  10/21/2015 09:51:55.791 [004756] [3484] :
  ..\..\common\ba\nrtable.cpp( 542): NodeReplicationTable::Close()
  closing database file
  10/21/2015 09:51:55.791 [004756] [3484] :
  ..\..\common\ba\nrtable.cpp(1492):
  NodeReplicationTableTable::getLastStoreDate couldn't find
  nrtable record rc 0
  10/21/2015 09:51:55.791 [004756] [3484] :
  ..\..\common\fs\filespac.cpp(3379): cuCompareFSQryRespTimes file
  space >\\torino\c$< not backed up
  
  Tivoli Storage Manager Versions Affected:
  TSM Backup-Archive client version 7.1.x; Windows Platform
  
  Initial Impact:
  Moderate
  
  Additional Keywords:
  ANS2120W, client replication, replication, node replication,
  tsm, failover, backup, restore, last store operation date
  

Local fix

• User can delete the tsmnrtable.DB file located in the
  "..\TSM\baclient" directory to resolve the ANS2120W messages.
  This should only be performed if the user is absolutely certain
  the entries are incorrect. Testing a restore of the object(s) is
   advised prior to deleting the tsmnrtable.DB file.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * Tivoli Storage Manager Client versions 7.1.1, 7.1.2, 7.1.3   *
  * and 7.1.4 running on all Microsoft Windows platforms.        *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * See ERROR DESCRIPTION                                        *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * This issue is projected to be fixed in the Tivoli Storage    *
  * Manager Client on Windows in level 7.1.6                     *
  * Note 1: This is subject to change at the discretion of IBM.  *
  ****************************************************************
  

Problem conclusion

• Correct filespace name is saved in node replication table.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Modules/Macros

• dsmagent dsm
  

Fix information

• Fixed component name

  TSM CLIENT

• Fixed component ID

  5698ISMCL

Applicable component levels

• R71W PSY

     UP