Skip to main content
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 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. 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.

    sysdamin_permissions.png

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

  • Phoenix only supports databases created on NTFS volumes. 
  • After 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 Phoenix agent to back up databases. Similarly, you cannot restore databases backed up using the Windows Server Phoenix 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 Phoenix, Phoenix does not back up such a virtual machine.
  • Phoenix deletes the manually created snapshots named PhoenixBackupSnap or PhoenixTempSnap when the Phoenix backup proxy performs the first backup of the virtual machine. 
  • 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.

Limitations 

  • Phoenix does not support backup of mirrored SQL server databases. Phoenix excludes such databases from backup. 
  • SQL Server aware backups are not available for availability groups at the moment. 
  • SQL Server aware backups are not available for failover clustered instances (FCIs) at the moment. 
  • 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 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.

Prerequisites for 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 the VMware 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.

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. (kb.vmware.com/kb/1037094).

  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.