Skip to main content
Druva Documentation

System requirements

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

Software requirements for MS SQL servers

Druva supports the following editions:

  • Windows Server (64-bit) Standard and Windows Server (64-bit) Enterprise edition operating systems
  • SQL Server Enterprise edition
  • SQL Server Standard editions of the versions listed below running on certified Windows Servers. 
  • Backup and restore of databases encrypted with Transparent Data Encryption (TDE).

Windows Server (64-bit)

SQL Server Editions

Windows Server 2016 SQL Server 2017

Windows Server 2016

  • SQL Server 2016 SP1 
  • SQL Server 2014

Microsoft Windows Server 2012 R2

  • SQL Server 2016 SP1
  • SQL Server 2014
  • SQL Server 2012 Service Pack (SP) 2
  • SQL Server 2008 Service Pack (SP) 4
  • SQL Server 2008 R2 SP 3

Microsoft Windows Server 2012

  • SQL Server 2016 SP1
  • SQL Server 2012 SP 2
  • SQL Server 2008 R2 SP 3
  • SQL Server 2008

Microsoft Windows Server 2008 R2 SP 1

  • SQL Server 2012 SP 2
  • SQL Server 2008

Microsoft Windows Server 2008 R2

  • SQL Server 2008 R2 SP 3
  • SQL Server 2008

Microsoft Windows Server 2008 SP 2

  • SQL Server 2012 SP 2
  • SQL Server 2008 R2 SP 3
  • SQL Server 2008

Microsoft Windows Server 2008

  • SQL Server 2008 SP 4
  • SQL Server 2008

Hardware requirements

For more information on hardware requirements for Phoenix agent, see Hardware requirements


  • Phoenix agent 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 the Microsoft’s native VSS provider. If you are using a third-party VSS provider, you must configure Phoenix agents to recognize this provider. 
  • Ensure that the SQL Writer Service on your SQL Server is 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 Local System account has permissions listed in the following table:
    Permission Description
    Sysadmin Required for SQL Server backup and restores. 
  • If you want to perform log backups for the database, ensure that you set the databases to FULL RECOVERY mode. For more information about modifying recovery mode, refer to View or Change the Recovery Model of a Database.  
  • If you want the Phoenix agent to run under a domain user account:
    • Ensure that the domain user is added under the local administrative group of the SQL Server
    • Ensure that Phoenix agent and SQL Server VSS writer service log on using the same domain user account. (By default both services log on using the local system account.)
    • Ensure that Sysadmin right is assigned to the domain user in the SQL server.

Prerequisites and considerations for SQL Server Availability Groups

  • Phoenix supports backup of availability group databases in MS-SQL Server 2012 onward since Microsoft introduced availability group in SQL Server 2012.
  • Ensure that you install Phoenix agent on all primary and secondary nodes in the availability group.
  • Ensure that you enable the Readable secondary option for the secondary nodes for successful backups from that node.
  • Ensure that all the nodes in an availability group must have the same Phoenix agent version installed on them.
  • Restore of availability group databases is not cluster-aware (not part of the existing AG). To add a restored database to an AG, see Availability Group - Add a Database.

Key considerations

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 supports file-stream database backup. 
  • Phoenix does not support backup of mirrored SQL server databases. Ensure that you exclude such databases from backups.  
  • Phoenix does not support backups of databases having an apostrophe or a comma in their names. Ensure that you exclude such databases from backups.  
  • 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. 
  • For the Phoenix agent version 4.6.5 or earlier, backups of MDF, NDF, and LDF files that reside at the root of a drive are not supported. For example, if your MDF files reside in D:\, a backup of these files will fail. That is why you must ensure that the MDF, NDF, and LDF files reside in a subfolder under a drive, for example, D:\ThisFolder.  
  • 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. 


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

  • 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 until the next full/differential successful backup is triggered.
  • If log backup was triggered and the same database was replaced by a restore method by any application or a user, then the log backup fails until the next full backup job is complete.
  • 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.
  • The agent is tested to back up a maximum of 64 databases. However, Microsoft recommends creating a snapshot backup of lesser than 35 databases at a time. Refer to the Microsoft article. To back up more databases on a 64-bit SQL server, increase the Max Worker Threads configuration. 
  • Other VSS-based backup software may cause agent’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 260 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.
  • Restore to MS-SQL server instance fails if you try to restore to a folder/directory having folder compress property 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.
  • Restore fails if multiple backed up instances contain databases with a common name. For example, on a Windows Server, there are two SQL Server instances: SQLINSTANCE1 and SQLINSTANCE2 and both instances contain a database called OrgDB. When you restore the two instances, the restore fails since both the instances have a database called OrgDB. 
  • Point-in-time restore across time zones is not supported.
  • Restore across MS-SQL server versions is not supported, and may fail due to compatibility issues.
  • If the same database name is selected for restore from multiple instances, the restore fails.
  • If the network is disabled during log backup or restore, the log backup/restore will fail. This is not a typical network disconnect scenario.
  • Database standby restore from MS-SQL 2012 to MS-SQL 2014 fails with ‘database upgrade needed’.
  • Database restore from MS-SQL 2014 to MS-SQL 2012 fails with VSS writer error.
  • Phoenix does not support restore of databases from availability group backup sets to Phoenix agents older than version 4.7.1.
  • While restoring databases to an AG, the restore fails if the Phoenix service is running with the local system account. Ensure that you run the Phoenix service with the domain user account that was used while setting up the AG.
  • 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
  • Creating a backup set with databases from 2 different instances is not supported. For example, db1 is a database under instance 1, and db2 is a database under instance 2. You cannot attach db1 and db2 to the same backup set. 

SQL FCI Key considerations and Limitations

The following list provides information on the key considerations and limitations pertaining to SQL FCI:

Key considerations

  • Phoenix client service and SQL FCI service must be running on the same node in the cluster.
  • In case of restores to FCIs, the restore location must be on the shared storage assigned to the FCI.
  • Phoenix agent needs to be installed on all cluster nodes of FCI. However, the upgrade to the Phoenix agent upgrades all the Phoenix agents on all nodes.


  • Availability group backup on FCI is not supported.
  • Phoenix does not support backup of FCI and stand-alone instances both on the same host.
  • When failover happens, the FQDN displayed on the Phoenix Management Console also changes.
  • If there are two FCIs with alternate primary and secondary server configurations, only one of them can be configured in Phoenix for backup.

Next steps

Read Quick steps to set up Phoenix to back up databases to get started.