Potential data integrity issue for deduplicated data that is replicated to a deduplication-enabled storage pool on a target server

Flash (Alert)


Abstract

Deduplicated data that is replicated to a deduplication-enabled storage pool might be incorrectly stored on the target system. The data might be stored incorrectly such that under rare conditions it could become inaccessible on the Target system.

Content

PROBLEM SUMMARY:

As documented in APAR IC82350, data might be stored incorrectly during the replication process and possibly become inaccessible under the following conditions:

· The target server that is used in the replication process is at Version 6.3.0.000
· The replication process deduplicated the data while storing it to the target server.
· The storage pool that was previously enabled for deduplication, and contains deduplicated
data stored via the replication process, has the deduplication feature turned off. The
deduplicated data is then moved out of the storage pool with the deduplication feature
disabled.

Affected data types: Data that is deduplicated during the replication process.

WHO IS AFFECTED:

All users of Tivoli Storage Manager server V6.3.0.000 who have turned off the deduplication feature for a storage pool that had previously stored data that was deduplicated during a replication process. It also requires that the data was subsequently moved from the storage pool to another primary storage pool.

RECOMMENDATION:

Before replicating deduplicated data, apply the Tivoli Storage Manager server fixing level 6.3.1.000 or higher, which contains the fix for APAR IC82350.

If data has already been replicated and deduplicated on the target server, ensure that the deduplication feature is not turned off if that data is to be moved from that storage pool. The following command can be issued to prevent the server from deduplicating data but keeps the feature enabled:

UPDATE STGPOOL <Stgpool Name> DEDUPLICATE=YES IDENTIFYPROCESS=0

If data has already been moved from the storage pool after the deduplication feature was turned off, the data might be stored incorrectly. To determine if this is the case, an audit volume should be performed against all storage pool volumes. The audit volume process will indicate whether or not any damaged files were found. If files are found to be damaged they will need to be restored from a copy storage pool, if available, or deleted and replicated again from the source server.

As a best practice, it is always recommended that the deduplication feature be disabled by issuing the command above. If client-side deduplication is being used on the server, the node(s) can be updated to prevent deduplication from occurring by using the following command:

UPDATE NODE <Node Name> DEDUP=SERVERONLY

PROBLEM RESOLUTION:

As documented in APAR IC82350, after applying 6.3.1.00 fixing level or higher, the server will correctly replicate node data with deduplication enabled on the target server.


CIRCUMVENTION:
Do not disable storage pool deduplication if deduplicated files exist in the target replication storage pool. To prevent further deduplication of incoming data, update the number of identification processes for the given storage pool to 0:

UPDATE STGPOOL <Stgpool Name> DEDUPLICATE=YES IDENTIFYPROCESS=0

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Tivoli Storage Manager
Server

Software version:

6.3

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows

Software edition:

Enterprise

Reference #:

1591591

Modified date:

2013-07-29

Translate my page

Machine Translation

Content navigation