Table of ContentsLibraryView in Frames

Local backup protection using dataset and SnapVault integration

SnapManager uses datasets to create remote backup copies of local data residing in the primary Storage Group. You must schedule your backup operations such that their transfer to SnapVault secondary storage does not get affected.

Ensure that you meet the following conditions before SnapManager starts creating remote backup copies:
  1. A dataset exists.
  2. The Archive local backup using SnapVault option is enabled.
  3. The dataset protection status is Protected and conformance status as Conformant.

    If the configuration contains non-Exchange LUNs, the qtrees containing the non-Exchange database are not updated during archiving. This changes the dataset protection status to Lag Warning or Lag Error.

For more information, see the relevant Protection Manager documentation.

Scheduling backup operations according to SnapVault transfers

You must schedule your backup operations so that they cannot be deleted before their SnapVault transfer to the secondary storage is complete.

You configure a backup operation so that only two backup copies can be retained on the primary storage. You schedule the backup operations at 12 PM, 1 PM, 2 PM, and 3 PM. The backup operations take three hours before their SnapVault transfer to the secondary storage is complete. When the 3 PM backup operation is running, the 12 PM backup operation is still transferring. Hence SnapManager deletes the 1 PM backup, and the Protection Manager job fails as it fails to find the deleted 1 PM backup to transfer. You can avoid this by using number of days for local backup retention instead of using number of backup copies for local backup retention.