NetWorker 19.7 Snapshot Management Integration Guide

RecoverPoint snapshot retention

You can identify the lifecycle of a RecoverPoint SPIT only by the RecoverPoint Copy Policy that is configured by the bookmark. When the bookmark reaches the end of its Copy Policy retention period, the SPIT becomes invalid and a NetWorker recovery cannot use the SPIT.

Occasionally, NSM snapshot save sets that correspond to invalid bookmarks can be present in the NetWorker media database. This issue can occur when the daily cleanup process has not yet removed the save set references.

When you plan the management of RecoverPoint snapshot operations with NSM, consider the following potential issues:

• A high storage change rate can force a bookmark out of its Copy Policy retention period before a backup is completed. This issue can cause snapshot clones to fail.

  For example, RecoverPoint software can track database changes to a production LUN many times each second with an update to its journal volume for each change. When the journal volume reaches its capacity, RecoverPoint automatically discards the oldest journal updates, including bookmarks created for NSM. For a large NSM clone, the time that is needed to back up a SPIT can exceed the duration of the SPIT’s record in the journal. If RecoverPoint deleted the bookmark, the backup fails.

  A possible solution is to increase the amount of journal space in a consistency group.

• If the NSM snapshot policy retains a snapshot save set longer than the RecoverPoint Copy Policy retention period for its bookmark, the save set remains in the NetWorker media database although it is invalid.
• The restore operation can cause RecoverPoint to remove the oldest bookmarks due to Copy Policy retention periods. Restore from a snapshot or from conventional storage adds updates to the RecoverPoint data changes and can force older bookmarks out of the retention period.

  A possible solution is to increase the amount of journal space in a consistency group.