Retention policies
VolumeCare creates and manages snapshot based on retention policies. They are
defined in the configuration in sections with the [policy:<policy-name>]
template. For details about where and how to set the configuration options, see
Configuration options.
About
The policy name is defined in the section header.
The essence of each policy is defined by the policy mode, so the mode option
should be specified in each policy section. Depending on the policy mode, other
options should also be specified in the policy section to provide the policy
parameters. For details, see Retention policy modes.
The list of policies for a cluster (or a set of clusters) is immutable - new policies can be added, but existing ones must not be removed or modified. This is required, as otherwise the state of the already created snapshots will be undefined.
Policy resolution
Each entity (volume or virtual machine) should have a policy applied to it. Only one policy can be applied to an entity at a time. The policy for each entity is resolved, in order of precedence:
volumes, by adding a tag
vc-policy=<policy-name>to the volume;templates, via
[template:<template-name>]section in the configuration with thepolicy=<policy-name>option in it;the whole cluster, via the
[template:*]section. This section is mandatory.
Virtual Machines have the common policy of all their volumes. All volumes of a virtual machine must have the same retention policy, otherwise it is considered a misconfiguration and the virtual machine will be ignored by the service.
Note
[template:*] is mandatory, otherwise VolumeCare will refuse to start. As of version 1.19 its default value is policy=no.
Changing a policy
The policies are best explained as immutable objects, thus when a change is required, the old policy needs to be kept until the new policy is applied. This immutability is not enforced due to rare exceptions requiring actual changes in an existing policy, but is strongly encouraged.
Single-cluster
Policy changes are best performed by creating a new policy and leaving the snapshots in the old one to expire when this is possible. Any changes in the /etc/storpool/volumecare.conf require restarting the storpool_volumecare service (presently running in the first node in a cluster if configured).
Multiple clusters
Changing a remote policy requires the change to occur both in the local and the remote clusters, otherwise the policy goes out of sync. A monitoring alert for policies out of sync is in development and will alert for such issues once done.