This topic contains the following sections:
- Defining support levels
- Certified platforms
- Key considerations
- Limitations of SQL Servers
Ensure that you read through all the requirements mentioned in this topic before you set up Phoenix to back up your databases.
Defining support levels
Druva categorizes its platform support levels as follows:
- Certified Platforms:
A certified platform is fully tested by Quality Assurance (QA) team. Druva certifies these environments and performs regular testing with every cloud release to ensure the functionality works as expected.
- Supported Platforms:
A supported platform is not tested by the Druva QA team with every cloud release, however, the functionality should work as expected. Druva will provide support for such platforms. Issues that require time and resources beyond commercial viability may not be addressed.
Druva certifies the following editions:
- Windows Server (64-bit) Standard and Windows Server (64-bit) Enterprise edition operating systems
- SQL Server Enterprise edition
Windows Server (64-bit)
SQL Server editions
Windows Server 2016 (x86-64)
Microsoft Windows Server 2012 R2
Microsoft Windows Server 2012
Microsoft Windows Server 2008 R2 SP 1
Microsoft Windows Server 2008 R2
Microsoft Windows Server 2008 SP 2
Microsoft Windows Server 2008
For more information on hardware requirements for Phoenix agent, see Hardware requirements.
Druva supports SQL Server Standard editions of the versions listed above.
- 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 MS-SQL servers 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 servers. 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 are running an agent with version 4.6.5 or earlier, set the SQLCMD system variable path to reflect the path to the SQLCMD utility directory. If this variable is not set correctly, backups and restores to and from your MS-SQL server will fail.
- 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.
- Phoenix supports backup of availability group databases in MS-SQL Server 2012 onward since Microsoft introduced availability group in SQL 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.
- 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.
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 only supports databases created on NTFS volumes.
- Phoenix supports file-stream database backup.
- Phoenix does not support backup of encrypted or 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 for single user database fail 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 successfully completed with errors.
- For MS-SQL 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.
Limitations of MS-SQL servers
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 for any database provided, point-in-time restore is not available (transaction log not backed up due to any reason), 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.
- Encrypted databases are not supported.
- Databases which get mirrored are not supported.
- 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. The product is not exhaustively tested with all other backup solutions.
- If a third-party VSS provider is used, the product may not work. It is recommended to use the default Microsoft provider.
- Database name with apostrophe and comma is not supported.
- 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 cannot be performed for databases with the same name across instances in single restore request.
- 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.
- 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.
- 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.
SQL FCI Key considerations and Limitations
The following list provides information on the key considerations and limitations pertaining to SQL FCI:
- 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.
Read Quick steps to set up Phoenix to back up databases to get started.