Backup options for cloud workloads
Note:
For a connected VM, a file system consistent snapshot is attempted. In case a connected VM is stopped later, then the application enters into an error state and a crash-consistent snapshot is taken instead of a file system consistent snapshot. You can refer to the Job monitor and see the logs if the snapshot taken was crash-consistent or file system consistent snapshot.
You can choose to enable regional snapshots for the Google cloud workloads while creating a protection plan.
If the regional snapshot option is enabled, the snapshot will be created in the same region in which the asset exists. Otherwise, the snapshot will be created in a multi-regional location.
You can choose to specify a snapshot destination peer resource group while creating a protection plan for Azure or Azure Stack Hub. While the previous functionality of defining a peer resource group by specifying a prefix still exists, you can now directly associate a snapshot to an existing peer resource group at the time of creating a protection plan.
If you have selected the cloud provider as Microsoft Azure or Azure Stack Hub while creating a protection plan, you can select Specify snapshot destination resource group to associate snapshots to a particular peer resource group within the same region in which the asset exists. Then select a configuration, subscription, and a resource group for a snapshot destination.
The snapshot is stored in one of the destination resource groups, in the following preference:
A destination resource group specified in the protection plan
A pre-fixed resource group specified in the plugin configuration (for Azure only)
A resource group in which the asset exists, if no destination or pre-fixed resource group is specified in NetBackup.
You can configure a protection plan to exclude some disks from the backup and snapshot which is applicable to all supported cloud vendors including GCP. This enables you to avoid redundant images of the disks that do not need to be backed up, and speed up the backups by reducing the volume of data to be processed.
If you are creating a protection plan for AWS, Azure, Azure Stack Hub, or GCP clouds, you can select Exclude selected disks from backups option and specify the disks that should not be included in the backup image. You can choose to exclude either all the non-boot disks, or the disks that have specific tags associated with them in the corresponding cloud provider account.
Note:
A protection plan that has the disk exclusion option enabled can be applied only to the cloud VM type assets and VM intelligent groups.
Then while restoring the VMs from the Recovery Points tab, refer to the Includes disks column to view the list of disks that are included or excluded in the backup image.
Refer to the information on creating a protection plan in the NetBackup Web UI Administrator's Guide for the complete procedure.
Notes:
For LVMs, if disks are excluded partially then the system might not boot up properly.
If there is a non-supported file system configured on a disk and user wants to exclude that disk from a snapshot. The snapshot continues to be a crash-consistent snapshot as the disk containing the non-supported file system is excluded.
To exclude the disk, have the flag attached to the data disk before taking a snapshot in the
/etc/fstabfile. This is required if the you reboot the instance without this volume attached (for example, after moving the volume to another instance), the mount option enables the instance to boot even if there are errors mounting the volume. For more information, refer to the following example entry in the/etc/fstabfile:For example,
Ensure that the assets are properly discovered after making any changes in their tags from the cloud provider. Once the policy run is scheduled for an asset, the disks are excluded as per the discovered data only. If you attach a tag while the snapshot is in progress, NetBackup does not consider that as a part of exclusion. Once discovery is complete, it will be considered for the next protection cycle.
In case of an OS with a non-English locale, if you opt for tag based exclusion in the protection plan and the disk tags contain non-English characters, even then, disk exclusion works as expected. But in some cases, a tag with non-English characters is not correctly captured in the job(try) logs and audit logs although there is no functionality impact as disk exclusion is considered correctly.