Skip to main content

How can we help you?

Druva Documentation

Prerequisites for configuring virtual machines for backup

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite


Before you begin, ensure that you have reviewed the Support Matrix

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 Phoenix backup proxy should be able to establish a direct network connection to the virtual machine using IPv4.

  • Druva recommends that you use Microsoft’s native VSS provider. Druva Phoenix 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.

  • Ensure 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.   Ensure that the SQL Server is running with the Local System account.  For more information on how to manage the credentials of a VM, see Configure virtual machines for backup.


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 Phoenix 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:

  • Druva Phoenix only supports databases created on NTFS volumes. 
  • After Druva Phoenix 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 Phoenix, Druva Phoenix does not back up such a virtual machine.
  • Druva Phoenix deletes the manually created snapshots named PhoenixBackupSnap or PhoenixTempSnap when the Druva Phoenix backup proxy performs the first backup of the virtual machine. 
  • Druva Phoenix 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: 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 table explains the steps you need to perform if you want to protect virtual machines with NVMe disks or controllers.

    Backup proxy versions To protect VMs with NVMe disks or controllers

    Existing backup proxies at versions lower than 6.0.3-178504

    Upgrade the Backup proxy from Phoenix console.

    Note: 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 to True in Phoenix.cfg file to enable it, and perform the following:

    1. Shut down the VM.
    2. Upgrade the VM's hardware version to 13 or higher.
    3. Start the VM.

    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.

    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. 

    Note: If upgrade VM permission is disabled:

    1. The additional proxy deployment will fail.
    2. First proxy deployer will deploy the proxy but without the capability to perform backups using HotAdd transport mode for NVMe-disk based workloads.

Note: 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.  


  • Druva Phoenix does not support backup of mirrored SQL server databases. Druva Phoenix 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 Phoenix 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 Druva Phoenix 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.

  • Make sure that the virtual machine that you want to restore instantly is mapped to the Linux CloudCache version 4.0.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:

  1. 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 theVMware kb article.

  2. 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.

  3. In versions 5.1 and older of vSphere, the maximum supported VMDK size is 1.98 TB

  4. The disks that are to be HotAdd must be SCSI. IDE drives are not compatible with HotAdd.

  5. The datastore of the source virtual machine and the datastore of the backup proxy should be of the same blocksize.

  6. 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.

Note: If any of the above conditions are not met then the backup will fail over to NBD/NBDSSL.

  Limitations with HotAdd

  1. HotAdd may fail if any disk was created with a newer hardware version than the virtual machine being backed up.

  2. 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.

  3. 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. (

  4. 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.

  5. Hot Add may fail if the virtual machine you are trying to back up and the backup proxy are in different clusters.

  6. 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.