IBM Support

IT33240: DURING COPY BACKUP, WHEN MORE THAN ONE PVC IS PART OF AN SLA, ALL THE DATA IS COPIED TO THE SAME LOCATION ON THE VSNAP SERVER.

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • Given the copy backups share the same location, the restored
    data could be from any of the PVCs in the same SLA. After a copy
    restore, the data will not be what is expected.
    

Local fix

  • The problem occurs when more than one PVCs is assigned to an
    SLA.  Assigning a single PVC to a single SLA will prevent this
    problem. Increasing the snapshot retention period will ensure
    the data is available for recovery.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * All 10.1.6 Spectrum Protect Plus users of the Kubernetes     *
    * agent with an copy backup SLA where more than one PVC is     *
    * assigned to the SLA.                                         *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * If there is more than one PV in the SLA, then during the     *
    * copy backup operation, the data blocks from all PVs are      *
    * copied to the same location in the vSnap server storage. The *
    * result is undetectable corruption of the backup data. No     *
    * error is logged during backup. If a PV from the vSnap server *
    * is restored, the restore is successful but the restored PV   *
    * is corrupted.                                                *
    *                                                              *
    * The snapshots are not affected by this issue, and can be     *
    * used to restore the PVs.                                     *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Apply fixing level when available. This problem is currently *
    * projected to be fixed in level IBM Spectrum Protect Plus     *
    * levels 10.1.6 interim fix 1 and 10.1.7. Note that until the  *
    * fixing level is available, this information is subject to    *
    * change at the discretion of IBM.                             *
    ****************************************************************
    

Problem conclusion

  • The 10.1.6 interim fix1 will copy each PVC to a unique NFS mount
    location on the vSnap server.
    

Temporary fix

Comments

APAR Information

  • APAR number

    IT33240

  • Reported component name

    SP PLUS

  • Reported component ID

    5737SPLUS

  • Reported release

    A16

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2020-06-17

  • Closed date

    2020-06-18

  • Last modified date

    2020-06-18

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

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

Fix information

  • Fixed component name

    SP PLUS

  • Fixed component ID

    5737SPLUS

Applicable component levels

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSNQFQ","label":"IBM Spectrum Protect Plus"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"A16"}]

Document Information

Modified date:
19 June 2020