Enterprise Workloads Editions: ✅ Business | ✅ Enterprise | ✅ Elite
Prerequisites for SQL Server application-aware backups
Backup proxy version must be 4.8.7-79132 or higher
Ensure that the latest version of VMware Tools is installed and is running on the Windows Server virtual machine that hosts the SQL Server on which you want us to run a SQL Server aware backup.
Ensure that the Windows Server virtual machine that hosts the Microsoft SQL Server is powered on and reachable from the backup proxy virtual machine. The Druva backup proxy should be able to establish a direct network connection to the virtual machine using IPv4.
Ports 3542 and 3545 specifically need to be reachable from the Proxy. Make sure you whitelist ports 3542 and 3545 on the Virtual Machine’s firewall or any Antivirus. The backup proxy uses VMware Tools to inject two executables and a few supporting files such as certificates into the guest OS of the virtual machine using port 3542. The SQL executable service PhoenixSQLGuestPlugin queries the Microsoft VSS APIs to back up and restore SQL Server databases. The guestossvc service interacts with the PhoenixSQLGuestPlugin service using the port 3545
Druva recommends that you use Microsoft’s native VSS provider. Druva interacts with Volume Shadow Copy Service (VSS) to back up your data. To ensure successful backups from your servers, make sure that the Volume Shadow Copy Service is not disabled and the SQL Writer Service on your SQL Server is running. Druva starts the SQL Writer Service if it's not running.
Make sure that the account assigned to your Server in the Druva Console for Application Aware has the 'Local Administrator' privileges on the Virtual Machine you are trying to Backup. During application-aware backup, the proxy must be able to create a file named vmbackup.conf in the directory C:\ProgramData\VMware\VMware Tools and add SqlServerWriter entry to it. But the Proxy will only be able to create the file vmbackup.conf in the directory C:\ProgramData\VMware\VMware Tools if the account assigned to your Server in the Druva Console for Application Aware has the 'Local Administrator' privileges on the Virtual Machine you are trying to Backup. To change the credentials used for application-aware backup in Druva, you can find the steps below:
https://docs.druva.com/Phoenix/030_C...VMware_serversEnsure that the disk space on the drive where your shadow copy storage is located is adequate for the cumulative size of your databases. To know how you can configure VSS to write shadow copies to a separate drive, see Set VSS to write shadow copies to a separate NTFS volume.
Ensure that you have enabled Windows authentication for your SQL Server. For more information, see Change Server Authentication Mode.
📝 Note
The Windows account configured must be a local administrator account or should be a part of the Administrators group. Appaware backup is not supported for non-administrator user accounts.
Permission | Description |
Administrator | Required for SQL Server backup and restores. |
Sysadmin | Required for SQL Server backup and restores. |
If you want to perform log backups for the databases, ensure that you set the databases to FULL RECOVERY mode. For more information about modifying recovery mode, see View or Change the Recovery Model of a Database.
Ensure that backups of databases don't have an apostrophe or a comma in their names. Druva excludes such databases from backup.
Key considerations for SQL Server application-aware backups
The following are some of the key considerations for SQL Server application-aware backups:
To support application-aware backups, the VSS storage for a volume must be allocated to the volume itself. If the VSS storage for a volume is mapped to another volume before taking an application-aware backup, Druva attempts to change it to the volume itself.
For example, if the shadow copy storage is configured as E: for volume C:, then Druva attempts to change it to volume C: itself.
Druva changes the VSS storage association only for those volumes where database files reside.
Druva allocates 10% of the volume size for the VSS storage. Once the storage association is changed successfully, it remains the same for further backups.
📝 Note
If Druva fails to change the VSS storage association, the application-aware backup will fail.
Druva agent may fail to change the VSS storage association if there:
are existing shadow copies of the volume stored on another volume. For example, if shadow copies for volume C: are stored on volume E:.
is not enough free space available on the volume.
Druva only supports databases created on NTFS volumes.
After Druva successfully backs up the transaction logs through a log backup job, the transaction logs are truncated.
Log backups are retained based on daily retention period defined in the backup policy. If a log backup falls out of daily retention period, it is deleted. Weekly, monthly, and yearly retention policies are not applicable for log backups.
Log backups fail for a single user database if it is the only database that is getting backed up. If a single-user database is not the only database, the log backup job is completed successfully with errors.
You cannot restore databases backed up under SQL Server aware VM backups to other SQL Servers that use the Windows Server Hybrid Workloads agent to back up databases. Similarly, you cannot restore databases backed up using the Windows Server Hybrid Workloads agent to the virtual machines with SQL Server aware backups enabled.
TL backups stop when the free space on volumes is less than 1 GB.
Other considerations for configuring VMware for backup
The following are some of the key considerations for configuring VMware for backup:
If you have suspended any virtual machine and configured it for backup in Druva, Druva does not back up such a virtual machine.
Druva deletes the manually created snapshots named PhoenixBackupSnap or PhoenixTempSnap when the Druva backup proxy performs the first backup of the virtual machine.
Druva supports vRDMs. However, it does not support raw disks, RDM physical mode disks (pRDM), independent disks, or virtual machines that are configured with bus-sharing.
Note that this behavior is aligned with the default behavior of VMware, whereby snapshots of raw disks, RDM physical mode disks, independent disks, or virtual machines configured with bus-sharing are not supported.VMware introduced support for NVMe controllers and NVMe disks from vCenter version 6.5 and hardware version 13. With version 6.0.3-178504 of the VMware Backup proxy you can backup and restore virtual machines with NVMe disks or controllers using the HotAdd transport mode. The backup of virtual machines with NVMe disks or controllers falls back to the NBDSSL mode if the VMware Backup proxy does not have an NVMe controller.
The following section explains the steps you need to perform if you want to protect virtual machines with NVMe disks or controllers.
For existing backup proxies at versions lower than 6.0.3-178504:
Upgrade the Backup proxy from Management Console.
By default, when the existing VMware backup proxies are upgraded to the latest agent version, the HotAdd transport mode backups are disabled. You must add the ENABLE_NVME_SUPPORT flag and set it toTruein Phoenix.cfg file to enable it, and perform the following:Shut down the VM.
Upgrade the VM's hardware version to 13 or higher.
Start the VM.
Optionally, if you do not have any NVMe disk-based VMs in your environment, set the ENABLE_NVME_SUPPORT flag in the Phoenix.cfg file to
False.
For VMware Backup proxy version 6.0.3-178504:
You can backup and restore virtual machines with NVMe disks or controllers. Restores from the new snapshots created after the agent upgrade are subject to some Limitations.
For restores of virtual machines with NVMe controllers or disks from older snapshots, ensure that the parameter ENABLE_NVME_CONVERSION = True is enabled in the Phoenix.cfg file on the VMware Backup proxy. The restores are subject to some Limitations.
For new Backup proxy deployments and additional Backup proxy deployments:
VMware backup proxies version 6.0.3-178504 or higher support backups and restores of virtual machines with NVMe disks or controllers using the HotAdd transport mode.
By default, additional proxies with version 6.0.3-178504 and above are deployed with 4 NVMe controllers/disks.
📝 Note
New backup proxy deployments via the first proxy deployer support the NVMe disks/controllers. However, when the proxy is deployed via the OVA template, you must perform manual steps.
If upgrade VM permission is disabled:
The additional proxy deployment will fail.
First proxy deployer will deploy the proxy but without the capability to perform backups using HotAdd transport mode for NVMe-disk based workloads.
MS SQL backups and VMware backups of the same virtual machine must start at different times to avoid backup errors. Ensure that the backups windows do not overlap.
Limitations
Druva does not support backup of mirrored SQL server databases. Druva excludes such databases from backup.
SQL Server aware backups are not available for availability groups at the moment.
SQL Server AppAware backups do not support SQL filestream databases.
SQL Server aware backups are not available for failover clustered instances (FCIs) at the moment.
SQL database restores from VMs with NVMe controllers or disk are not supported. Full VM restores having app-aware policy configured will restore such databases as part of VM restores.
If the backup proxy is unencrypted, and the virtual machine that is getting backed up through HotAdd is encrypted:
Transport mode is changed to NBDSSL, and the virtual machine is backed up successfully
When you restore the virtual machine, it is restored as an unencrypted virtual machine.
You cannot use all four DNS server addresses if:
You have enabled both network interface cards in the backup proxy
Both cards are configured to use different networks
Both cards use two domain naming systems each
Due to Druva backup proxy limitations, when you add DNS server addresses, three out of four DNS addresses are used based on the sequence of network interface cards you configure.
System databases are not protected as part of VMware application-aware MS SQL backups. Use the MS SQL Server agent to protect MS SQL system databases.
Prerequisites for configuring virtual machines for Instant Restore
Make sure you have deployed and configured CloudCache for local storage.
VM proxy, ESXI host and Cloud Cache should be able to ping and resolve to each other bi-directionally
Ports required to be opened on Cloud Cache are:
443 : For Backups
111 : Port mapper
2049 : For NFS service, to create a temporary NFS datastore on the ESXI host.
49152 : Instant restore service
49153 : Instant restore servicePorts required to be opened on ESXI host are:
111 : Port mapper
2049 : For NFS service, to create a temporary NFS datastore on the ESXI host.
49152 : Instant restore service
Make sure that the virtual machine you want to restore instantly is mapped to the Linux CloudCache version 4.1 and later for backup.
Make sure that you have enabled instant restore for the virtual machine.
Make sure that you have at least one instant restore supported proxy (version 5.0.5.x or later) that is in a connected state in the proxy pool.
Add permissions to backup proxy to create a datastore, or to migrate a Hot or Cold VM. For more information, see Required vCenter or ESXi user permissions for backup, restore, and OVA deployment.
Instant restore and migrate to production jobs support staging datastores. A staging datastore is a datastore on an ESXi host that stores all changes to the instantly restored virtual machine.
Migrate to production job for a VM cannot reuse the staging datastore used for the instant restore job of that VM. If you want to migrate a virtual machine to production, ensure you have another datastore on the same or different ESXi host, depending on whether you are migrating to the same or alternate host.
Key considerations for Instant Restore of virtual machines
If you switch to a Windows CloudCache after enabling Instant Restore, the Instant Restore is disabled for the selected VMs.
Instant restore of virtual machines is supported from Hot restore points only.
If you dissociate a VM from CloudCache, all the subsequent backups of the VM will be stored directly on the Druva Ccloud, and instant restoration of the VM is not possible.
Deleting an instantly restored VM dissipates it from CloudCache and cannot be recovered later.
For better performance, we recommend that you migrate the instantly restored VMs within a week.
We recommend that you do not use an old restore point (RP) as compaction kicks in if the RPs fall out of the retention period.
We recommend that you do not restart Linux CloudCache during instant restore or migration as that causes failure of the respective jobs.
Prerequisites for HotAdd transport
For HotAdd transport mode to work correctly following are the pre-requisites:
The datastore on which the backup proxy is created must be formatted with the right block size to be able to mount the largest virtual disk of the hot added virtual machines. The block size limitations vary across VMFS, VMFS-2, VMFS-3 and VMFS-5 for a given virtual disk size. For details on the block size requirements, please refer to the VMware kbarticle.
The proxy being used to backup the virtual machine must be a Virtual Machine on a host that is able to access data store, where the source virtual machine's disk are stored.
In versions 5.1 and older of vSphere, the maximum supported VMDK size is 1.98 TB
The disks that are to be HotAdd must be SCSI. IDE drives are not compatible with HotAdd.
The datastore of the source virtual machine and the datastore of the backup proxy should be of the same blocksize.
To back up virtual machines with NVMe disks or NVMe controllers using the HotAdd transport mode, ensure that you've performed a new deployment of VMware Backup proxy version 6.0.3-178504. If you're using an older Backup proxy, ensure that you manually perform the steps explained under Existing backup proxies at versions lower than 6.0.0 -147290.
If any of the above conditions are not met then the backup will fail over to NBD/NBDSSL.
Limitations with HotAdd
HotAdd may fail if any disk was created with a newer hardware version than the virtual machine being backed up.
For example, if a disk was moved from a hardware version 8 virtual machine to a hardware version 7 virtual machine. To resolve, upgrade the hardware version of the virtual machine.
A single SCSI controller can have a maximum of 15 disks attached. To run multiple concurrent jobs with more than 15 disks, you need to add more SCSI controllers to your backup proxy that is responsible for hot adding the disks. (KB article).
HotAdd may fail if you are trying to back up the virtual machine through the host added as a standalone server, but actually being managed by vCenter.
Hot Add may fail if the virtual machine you are trying to back up and the backup proxy are in different clusters.
The backups will fail if you have set HotAdd as a transport mode in the Phoenix.cfg file for the VMs having NVMe disks and the proxies are not upgraded.