Data aging and retention is controlled by the storage policy that is associated with a subclient.
Individual VMs inherit data aging and retention settings from the subclient. You cannot associate child VMs with different storage policies.
With 11.20 and more recent releases, you can access backup data for each individual VM, even if the VM Admin job for the subclient is not available, but VM Admin jobs are not marked as aged until all associated individual VM jobs are marked as aged.
To enable or disable data aging for a VM-centric virtualization client, configure the Enable data aging setting on the Activity Control tab in the Client Computer Properties dialog box for the virtualization client. When you disable data aging for a virtualization client, data aging is disabled for all VMs that are included under the virtualization client. Also, when you enable data aging for a virtualization client, data aging is enabled for all VMs. However, you can configure Enable data aging setting to disable data aging for an individual VM. For more information, see Disable Data Aging on a Client.
Considerations
Note the following considerations for data aging and retention for virtualization:
For V2 indexing, if an inactive VM is in only one backupset, it will be aged from the backupset based on the number of days. If an inactive VM is in multiple backupsets, it will not be deleted, even if one of the backupsets is deconfigured.
-
To receive notification when virtual machines are decommissioned, you can configure an alert using the Virtual Machine has been decommissioned rule.
-
If you remove a VM from all subclients, the VM is automatically deconfigured, and the backup data for the VM is marked for data aging.
If you delete a VM from the hypervisor, but the VM is explicitly added to subclient content (rather than being selected by an automatic discovery rule), and backups are running on the subclient, the VM is not automatically deconfigured. As a result, a backup job for the VM fails, and the parent job for the subclient is marked as completed with errors. Before the VM can be marked as deconfigured, you must remove it from the subclient.
For Indexing V1 VMs, if you delete the VM from the vCenter, the next backup or discovery operation identifies and marks the VM as deleted in the CommServe database. Then, the VM client remains in the Commvault software as long as it still contains valid jobs. 30 days after the jobs are aged, the VM client is removed.
-
Data retention rules that are defined in the associated storage policy supersede any rule that is specified for deleting a VM (in the NumberOfDaysToKeepUnProtectedVMs additional setting).
The NumberOfDaysToKeepUnProtectedVMs additional setting refers to how long the VM remains active in the database after all of its backups are aged. By default, the setting is 30 days. (For more information, see Deleted or Deconfigured Clients.)
Examples:
-
If the data retention rules for a VM's storage policy specify retaining data for 1 year and the NumberOfDaysToKeepUnProtectedVMs additional setting is set to 30 days, even if the VM is inadvertently deleted from the vCenter, the data for that VM is still retained for 1 year (in the content store).
-
If the data retention rules for a VM's storage policy specify retaining data for 15 days (2 cycles), and the NumberOfDaysToKeepUnProtectedVMs additional setting is set to 30 days, regardless of whether the VM is deleted from the vCenter, the data is only retained according to the rules defined in the associated storage policy, in this case, 15 days. Then the VM is deleted from the content store.
Note
This is true if the VM is still present on the vCenter, but removed from the VM groups by adding a filter from the backup set level, or if the VM is retired and removed from the VM groups. The data is only retained according to the rules defined in the associated storage policy, in this case, 15 days. Then the VM is deleted from the content store.
-