Deduplicated data that is imported into a non-deduplicated storage pool might be incorrectly stored on the target system. Under certain rare conditions, the data might become inaccessible on the target system. The data on the source system will not be affected and will be accessible.
Tivoli Storage Manager Version 6.2 servers have the capability to deduplicate data that is stored by export/import processes. The requirement for doing so is that the data must have been deduplicated on the source system, and the storage pool(s) that receive the data on the target system must be enabled for deduplication.
As documented in APAR IC80755, a problem can occur if deduplicated data is exported and imported to a non-deduplicated storage pool on the target server. The imported data might be incorrectly stored in the non-deduplicated storage pool during the import process.
If this occurs, any files that have been stored incorrrectly on the target system might not be recoverable. Most server data movement operations will expose this error condition resulting in the following error messages:
ANR9999D BfGetBitfileExtents(bfaggrut.c:XXXX) Thread<XX>: BFBE Entry not found for object XXXXXXX (SESSION: XXX)
ANR9999D bfRtrv(bfrtrv.c:XXXX) Thread<XX>: Error 87 obtaining deduplication information for object XXXXXXX in super bitfile XXXXXX in pool XXXXXX (SESSION: XXX)
For this error to occur, all of the following conditions must be true:
* The IMPORT NODE/EXPORT NODE command was used on server levels 6.2.0.000 -
* The IMPORT NODE command attempts to import deduplicated data to a non-deduplicated
storage pool on the target server.
* The referencing records for the imported data in the non-deduplicated storage pool are lost.
As a result of the above factors, this is a situation that rarely occurs.
WHO IS AFFECTED:
Users of Tivoli Storage Manager server versions 6.2.0.000 - 18.104.22.168 who have imported data from deduplicated storage pools to non-deduplicated storage pools.
This problem does not occur when the IMPORT NODE command is issued on server fixing levels 6.1.x.x and 6.3.x.x.
This problem does not occur when the IMPORT NODE command is issued on server fixing levels earlier than 6.2.0.000 or on 22.214.171.124 and later.
This problem does not affect the IMPORT NODE command when deduplicated data is imported to a deduplication-enabled storage pool on the target system. It also does not affect data that has not been deduplicated on the source system.
Before issuing an IMPORT NODE command to copy deduplicated data to a non-deduplicated target storage pool, apply the Tivoli Storage Manager server fixing level 6.2.4.000 or higher, which contains the fix for APAR IC80755.
If you previously issued the IMPORT NODE command, prior to applying the fixing level, the following operations can be performed to determine if any of the imported data has been affected:
· If the imported data has been backed up to a copy storage pool, run the validate extents utility as shown below:
VALIDATE EXTENTS <primary storage pool> <copy storage pool> action=fixextents
· If the imported data has not been backed up to a copy storage pool, the data in the storage pool can be moved/copied with any of the following server operations to detect data that has been incorrectly stored:
All of the operations above will flag any data found to be incorrectly stored as damaged. The damaged data can then be deleted and either re-imported from source server or backed up from originating client machine.
When the 6.2.4.000 or higher fixing level is applied, the Tivoli Storage Manager server will properly store all data during the import process.
Do not import deduplicated data to a non-deduplicated storage pool until you have installed fixing level 6.2.4.000 or higher.