Skip to main content
Druva Documentation

System requirements for agentless application-aware backups on VMware virtual machines

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

Phoenix can back up and restore data that certain applications running inside the virtual machine generate in an application-consistent manner. For example, Phoenix can back up Microsoft SQL Server databases. The following sections describe the system requirements for the Phoenix backup proxy to back up the data that applications running inside the VM generate.  These requirements must be satisfied in addition to the VMware system requirements.

System requirements for the backup proxy to back up and restore Microsoft SQL Server databases inside a VM

Following sections describe the prerequisites and considerations for SQL Server aware backups.

Prerequisites for SQL Server aware backups

  • 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.
  • Port 3542 should be open for connections on the Windows Server virtual machine that hosts the SQL Server.
  • Port 3545 should be available for use on the Windows Server virtual machine that hosts the SQL Server. 
  • Ensure that the Windows VM is powered on.
  • Ensure that the Windows Server virtual machine that hosts the Microsoft SQL Server is 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.
  • 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. 
  • Druva recommends that you use Microsoft’s native VSS provider.
  • Ensure that the SQL Writer Service on your SQL Server is running. We start 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 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. 
  • Ensure that the credentials assigned to this VM have the sysadmin role and write permission in C:\ProgramData\ directory. 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.  

Key considerations for SQL Server aware backups

The following list provides information on MS-SQL and Windows features that Phoenix supports and uses to backup and restore databases.

  • Phoenix supports backup of MDF, NDF, and LDF files. 
  • Phoenix does not use any particular option from the NORECOVER, NO_TRUNCATE, and CONTINUE_AFTER_ERROR backup options. It uses the default set of SQL Server options.
  • Phoenix only supports databases created on NTFS volumes. 
  • Phoenix does not support backup of mirrored SQL server databases. Phoenix excludes such databases from backup.  
  • Phoenix does not support backups of databases having an apostrophe or a comma in their names. Phoenix excludes such databases from backup.  
  • 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. 
  • Phoenix can backup and restore databases encrypted using a private key. However, ensure that the certificate and key used to encrypt the backed up database must be present on the SQL server to which the database is restored. For more information, see Move a TDE protected database to another SQL Server on the Microsoft documentation portal. 
  • 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. 
  • 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.
  • SQL Server aware backups are not supported for databases on system drives.
  • Phoenix performs an instance-level backup of databases. The ability to choose databases for backup is not available at the moment. 
  • TL backups stop when the free space on volumes is less than 1 GB.
  • Backup proxy version must be 4.8.7-79132 or higher 

Limitations of SQL Server aware backups

The following list provides information on scenarios when a backup or restore job can fail.

  • Availability Groups are not supported at the moment. 
  • If the recovery model of the database is changed from FULL to SIMPLE after last successful log backup, the next log backup is skipped.
  • If a third-party tool takes log backup after Phoenix application latest log backup, the log backup fails and Phoenix triggers a full backup. 
  • If log backup was triggered and the same database was replaced by a restore method by any application or a user, the log backup fails. Phoenix triggers a full backup in that case. 
  • If a point-in-time restore is not available (transaction log not backed up due to any reason) for any database provided, then the database is restored to the nearest available restore point.
  • Other VSS-based backup software may cause  Phoenix's VSS snapshot mechanism to fail.
  • It is possible that due to third-party backup solutions, MS-SQL server backup may fail. Phoenix is not exhaustively tested with all other backup solutions.
  • Phoenix may not work if a third-party VSS provider is used. We recommended the use of the default Microsoft provider.
  • Due to Windows limitations, a restore job can fail if restore path exceeds 256 characters. 
  • Single-user database log backups are skipped.
  • Not all database attributes are restored. For example, Read-only attribute, Restricted access, Ownership, and Broker-Enabled.
  • A single-user database should not be backed up if it is being used by any user, this may result in backup failure.
  • Restore may fail if MS-SQL instance contains any database/databases with the state 'restoring'. Remove all databases having the state 'restoring' from MS-SQL instance to restore successfully.
  • If the network is disabled during log backup or restore, the log backup/restore will fail. This is not a typical network disconnect scenario.
  • Point-in-time restore using the latest timestamp fails if: 
    • The secondary database file (*.ndf) is deleted
    • A log or full backup is taken after it

If you observe the below errors in your Windows event logs, contact Druva Support:

Event ID: 57 NTFS Warning
The system failed to flush data to the transaction log. Corruption may occur.

Event ID: 137 NTFS Error
The default transaction resource manager on volume \\?\Volume{806289e8-6088-11e0-a168-005056ae003d} encountered a non-retryable error and could not start. The data contains the error code.

Event ID: 140 NTFS Warning
The system failed to flush data to the transaction log. Corruption may occur in VolumeId:<> DeviceName: \Device\HarddiskVolume<>.(A device which does not exist was specified.).

Few databases might not be recoverable since the VSS service failed to keep the SQL VSS snapshot persistent on the source VM.  Druva is working closely with VMware support to address the above problem.

Ports and communication protocols for Phoenix

Phoenix communicates with your virtual infrastructure to backup and restore virtual machine data. This communication happens via ports and communication protocols that are secure for communication and transition of data.

Phoenix uses a combination of Transport Layer Security (TLS) and Secure Socket Layer (SSL) protocols for establishing a connection and initiating communication between Phoenix components and your virtual infrastructure components such as vCenter Server, ESXi hosts, and virtual machines.

The following diagram depicts the ports and communication protocols that are used by Phoenix for secure connection and communication during the backup and restore operations.

port_communication_protocols_vmware_with_SQL.png

The following table describes the port and communication protocols used for communication between Phoenix and various VMware components.

Port

Communication Protocol

Description

443

HTTPS+SSL

Phoenix uses Port 443 to establish a secure connection and communication between the following:

  • Backup Proxy to Phoenix Cloud
  • Backup Proxy to Phoenix CloudCache
  • Backup Proxy to vCenter Server
  • Backup Proxy to ESXi host
    Note: Backup proxy establishes connection with ESXi host over Port 443 only if it registered with Phoenix as Standalone ESXi. If the ESXi host is registered with Phoenix through vCenter Server, backup proxy communicates with the ESXi host over Port 902.

902

TCP/UDP

Phoenix uses port 902 to establish a connection between the backup proxy and ESXi host registered with Phoenix through vCenter Server.

3542 HTTPS+SSL For application-aware backups, 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. When the executables run, they start guest OS processes called guestossvc and PhoenixSQLGuestPlugin. The backup proxy uses the opened port 3542 on the guest OS so that it can communicate with guestossvc to run SQL Server backups. Ensure that this port is open on the guest OS.

The backup proxy also uses this port to restore databases to the virtual machine.
3545 HTTPS+SSL For application-aware backups, 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 this port. The PhoenixSQLGuestPlugin service cannot directly communicate with the backup proxy. 

3389/22

 

TCP/UDP

During the backup cycle, the backup proxy sends network packets to Windows virtual machines (where VMware tools are installed) on port 3389 to identify if the RDP port is open or not. For Linux virtual machines, the port is 22, which is used for SSH.

This is used for Phoenix DRaaS or DR restores.

123 UDP Backup proxy accesses NTP server on Port 123 (UDP) for time synchronization.

443

HTTPS+SSL

Phoenix uses SSL for a secure connection that happens between the following:

  • Backup proxy and vCenter Server
  • Backup proxy and ESXi hosts

443

HTTPS+TLS

Phoenix uses TLS for a secure connection that happens between the following:

  • Backup proxy and Phoenix Cloud
  • Backup proxy and Phoenix CloudCache
  • Phoenix CloudCache and Phoenix Cloud