You can perform application-consistent snapshot backups of the following applications using Commvault agents running on Azure VMs. You can perform multiple snapshot and backup copy operations for different applications on the client at the same time.
-
DB2
-
Epic EHR
-
Oracle
-
SAP HANA
-
SAP Oracle
-
SQL Server
-
Sybase
Using Azure Premium SSD v2 and Ultra Disks
You can run application-consistent disk snapshots for Azure Premium SSD v2 and Ultra Disk types. When the system mounts snapshots of these disk types it does not wait for the Azure clone copy operation to finish. This allows you to run multiple backup copy operations simultaneously by avoiding the significant time delays associated with clone copies of these disk types.
By default, when a clone disk is created from the snapshot for backup copy or revert operations, the input/output operations per second (IOPS) and throughput performance settings of the source "snapped" disk are used for the performance settings of the created "cloned" disk. If you want to configure different custom values for the IOPS and throughput performance settings, configure the bAzureCloneDiskUseCustomPerfSettings setting to a value of true, then configure the desired performance settings for either the Azure Premium SSD v2 or Ultra Disk types, using the two settings for the disk type listed below:
- nAzureCloneDiskSSDV2Iops – Azure Premium SSD v2 IOPS
- nAzureCloneDiskSSDV2Throughput – Azure Premium SSD v2 throughput
- nAzureCloneDiskUltraIops – Azure Ultra Disk IOPS
- nAzureCloneDiskUltraThroughput – Azure Ultra Disk throughput
For instructions about adding a setting, see Adding a CommCell Setting.
Instant access snapshots for Azure Premium SSD v2 and Ultra Disks
You can use instant access snapshots to protect database and file system clients that run on Azure VMs with Azure Premium SSD v2 or Ultra Disk managed disks. Snapshots of these disk types are not instant access by default. Azure copies the source disk data to the snapshot in the background, and you must wait for that copy to finish before you can use the snapshot. An instant access snapshot can be used immediately for restore operations, while the background copy continues.
When an in-guest agent runs a snapshot backup, the agent creates an instant access snapshot through the Azure REST API. All downstream restore operations use this snapshot, so restores do not wait for a snapshot copy operation to complete. This reduces the time required to start a restore, which can help you meet aggressive recovery time objectives (RTOs).
Enabling instant access snapshots requires explicit configuration on the database or file system client. Snapshots remain in the instant access state for the specified duration.
Consider the following when you use instant access snapshots:
-
The instant access duration must be between 60 and 300 minutes, as defined by Microsoft.
-
After the duration expires, the snapshot leaves the instant access state. If the background data copy is still in progress at that time, you must wait for it to complete before you can use the snapshot.
-
Azure bills for the additional storage that an instant access snapshot uses during its active lifetime. Azure also charges a one-time fee for each disk restored from the snapshot.
-
Until the background data copy finishes, an instant access snapshot depends on the availability of its source disk and does not protect against disk failures.
-
Azure allows three in-progress snapshots per Ultra Disk or Premium SSD v2 disk. Instant access snapshots count toward this limit.
-
Snapshots of other managed disk types, such as Premium SSD, Standard SSD, and Standard HDD, are instant access by default and do not require this configuration.
For additional restrictions and billing details, see the Microsoft article Instantly access managed disk snapshots.
Use of Incremental Snapshots
By default, the snapshot engine leverages Microsoft's incremental snapshot type for the managed disks. Incremental snapshots are a cost-effective point-in-time backup of the managed disks, which store only the delta data from the last snapshot. If the incremental snapshot fails for any reason, the snapshot engine creates a regular full snapshot automatically. Microsoft's incremental snapshot solution has the following advantages:
-
Cost-effective solution to create snapshots that include only the differences from the previous snapshot.
-
Data aging and restore operations are the same as that for Commvault regular snapshots.
For more information on the restrictions and prerequisites for incremental snapshots, see Microsoft article Create an incremental snapshot for managed disks.
Using NVMe Controllers on Linux
You can use NVMe controllers for the source client on a Linux platform to run the IntelliSnap backups. To do this, you must install the nvme-cli package on your source VM.
Snapshot Operation Types
You can perform the following snapshot operations using the Microsoft Azure snapshot engine.
-
IntelliSnap backups are supported only for the Azure managed disks for the virtual machine.
-
IntelliSnap restore operations and revert operations
As part of a snapshot restore operation, temporary disks (snapshot clones) are created from point-in-time snapshots and attached to the VM. Data is transferred from the snapshot clones to the original database disks. The snapshot clones are detached and deleted after the data transfer completes.
As part of a snapshot revert operation, the existing database disks are detached from the VM and deleted from the resource groups. You can use the bAzureDeleteOriginalDiskOnRevert additional setting to control whether deletion of the existing database disks from the resource groups is skipped. The new disks are then created from the point-in-time snapshots and attached to the VM.
-
Offline backup copy operations with and without a proxy server
Backup copy operations with the source VM and the proxy VM on different subscription or resource group are supported. Make sure that the proxy VM has the contributor role at the Azure Resource Groups scope that manages the VM and the backup snapshots.
-
Replica copy of an Azure snapshot in a different Azure region
You can make a replica copy of an Azure snapshot in a region other than the source region. The replica copy is an application-consistent snapshot copy that is created in a different region for disaster recovery purposes. This copy reduces your risk of Azure region-level failures or outages and allows you to choose regions abiding by data sovereignty laws. You can use the replica copy to restore data to another client that is in the destination region of the replica copy.
This feature must be enabled at the plan level. A secondary snapshot copy must be configured with region mappings that use Azure as the vendor. For more information about configuring the secondary snapshot copy, see Adding a Snapshot Copy to a Plan.
Cross-region restores from a replica copy back to the source client or to a client in another region are not supported.
You can make replica copies for the following workloads:
- Oracle
- SAP HANA
- SAP on Oracle
-
Database copy restore operations with a bare-metal setup from one Azure VM to a new Azure VM
Cross-machine restores with the source and destination VM on different subscription or resource groups are supported.
Availability Zones
IntelliSnap operations are supported on Azure VMs with availability zones. Inter-zone data transfer rates are applied when you restore the snapshots to a different availability zone. For more information about the inter-zone data transfer rates, see Azure - Bandwidth Pricing Details documentation.