Search <book_title>...

Veritas CloudPoint Administrator's Guide

Last Published: 2020-06-04

Product(s): CloudPoint (2.2.2)

Platform: Linux

How a CloudPoint protection policy works

After you create a CloudPoint protection policy with the desired parameters, you have to assign the policy to one or more assets. CloudPoint then triggers the policy runs as per the defined policy schedule. During each policy cycle, CloudPoint scans the assigned assets and performs the following actions:

Creates snapshots of the assets to which the policy is assigned
Replicates the snapshots if the replication option is enabled
Deletes the asset snapshots, beginning with the oldest snapshot copy first, if the policy-triggered snapshot count is more than the defined retention value

During a policy run, when CloudPoint takes asset snapshots, it holds them together in a virtual object called as a snapshot group. A snapshot group represents a unique set of snapshots taken at a particular point in time, where each snapshot belongs to a particular asset that is included in the policy. A snapshot group contains only one snapshot per asset, it never includes two snapshots that belong to the same asset. CloudPoint creates a new and unique snapshot group in each policy run.

CloudPoint uses a snapshot group as the unit of reference for running policy-driven snapshot deletion operations. If the snapshot count exceeds the retention value defined in a policy, CloudPoint deletes the oldest policy-triggered snapshot copy during the policy run. CloudPoint uses the age (time when a snapshot was taken) and number (snapshot group count) of the snapshot group to determine which snapshots are to be deleted. CloudPoint does not use the age or the number of the individual asset snapshots within a group.

For example, consider a policy P1 that is assigned to assets A1, A2, and A3 and is scheduled to run on the Monday, Tuesday, and Wednesday of a week. The retention count is set to 1, which means CloudPoint should maintain only one copy of the snapshots at any given time.

Table: CloudPoint policy behavior example

Policy name	Policy schedule	Retention value	Assigned to assets
P1	Run once a day on Mondays, Tuesdays, and Wednesdays	1	A1, A2, A3

Now let us look at the CloudPoint policy behavior, depending on different scenarios:

During the first policy run on a Monday, CloudPoint creates three snapshots, A1-Snap-Mon, A2-Snap-Mon, A3-Snap-Mon, and puts them in a snapshot group called G1. The three snapshots represent one for each asset that is included in the policy.
In the Tuesday policy run, consider a case where the snapshot creation for asset A3 fails. CloudPoint creates two snapshots, A1-Snap-Tue and A2-Snap-Tues, and puts them in a new snapshot group called G2.
With G1 and the newly created snapshot group G2, the snapshot group count exceeds the policy retention value of 1. CloudPoint immediately triggers a snapshot delete operation and deletes all the snapshots included in group G1, as G1 is the older of the two snapshot groups.
As G1 is deleted, there is only one snapshot group (G2) that remains at the end of the Tuesday policy run. G2 includes only two snapshots, one each for assets A1 and A2. Asset A3 does not have any snapshot as snapshot creation had failed in the Tuesday policy run and CloudPoint has already deleted snapshot group G1 that included an older snapshot of asset A3.
Now consider a case where asset A2 is removed from the policy. Policy P1 is no longer associated with the asset A2. In the Wednesday policy run, CloudPoint creates two snapshots A1-Snap-Wed and A3-Snap-Wed and puts them in snapshot group G3. Snapshot for asset A2 is not created as A2 is no longer included in the policy.
With G2 and the newly created snapshot group G3, the snapshot count exceeds the policy retention value. CloudPoint triggers a snapshot delete operation once again. G2 is the older between G2 and G3, so CloudPoint deletes the snapshots in group G2.
As G2 is deleted, there is only one snapshot group (G3) that remains at the end of the Wednesday policy run. G3 includes two snapshots, one each for asset A1 and asset A3. Asset A2 does not have any snapshots.

Note the following:

CloudPoint does not consider the individual asset snapshot count when performing the delete operation. Also, if the snapshot creation fails in a subsequent policy run, CloudPoint does not retain the asset snapshot that was created during the earlier policy cycle.
In this case, asset A3 had only one snapshot in group G1, as the snapshot operation had failed in the Tuesday policy run. But with creation of G2, the snapshot group count exceeded the policy retention value and G1 was deleted. As a result, asset A3 does not have any snapshots remaining at the end of the Tuesday policy run, even if the policy retention value is 1.
CloudPoint does not retain policy-created snapshots if an asset is removed from a policy. CloudPoint does not consider that an asset is no longer associated with the policy and proceeds with delete operation. An asset snapshot is deleted even if the policy is no longer associated with the asset.
In this case, during the Wednesday policy run, CloudPoint does not create a new snapshot for asset A2 as it was excluded from the policy. However, with the creation of G3, the snapshot group count exceeded the policy retention value and G2 was deleted. G2 included a snapshot of asset A2, and even though A2 is no longer associated with the policy, deletion of G2 resulted in the deletion of the snapshot that belonged to A2.