This article contains the following sections:
- Defining Support Levels
- Certified Platforms
- Key considerations
- Limitations for SQL Servers
Ensure that you read through all the requirements mentioned in this doc before you set up Phoenix to backup your databases.
Defining support levels
Druva categorizes its platform support levels as following:
- 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.
Windows Server (64-bit)
(Standard and Enterprise editions)
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
- Phoenix agent interacts with Volume Shadow Copy Service to back up your data. To ensure successful backups from your servers, make sure that the Volume Shadow Copy Service is running.
- 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 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 Bulkadmin Required during transaction mark restore with numerous inline transactions when pushed through VDI connection. Dbcreator Required during point in time standby restore to create and access the .tmp file required during the process. Diskadmin Required during point in time standby restore to create and access the .tmp file required during the process. Processadmin Required during full and differential restores that are performed using SQL writer and log restore using VDI connection. Securityadmin Required to access database for restore from the Phoenix process, for point in time and standby restore. Serveradmin Required to access database for restore from the Phoenix process, for point in time and standby restore. Setupadmin Required for backup and restore operations. Sysadmin Required during restore to execute the TSQL query in parallel to VDI connection.
- 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 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.
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.
- Phoenix supports transaction log truncation. Transaction logs are truncated after Phoenix backs them up.
- Log backups are retained based on daily retention 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 databases fails 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 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 for SQL Servers
The following list provides information on scenarios when a backup or restore job can fail.
- If recovery model of database is changed from FULL to SIMPLE after last successful log backup, then the next log backup is skipped.
- If a third-party tool takes log backup after Phoenix application latest log backup, then log backup fails till next full/differential successful backup is triggered.
- If log backup was triggered and same database was replaced by a restore method by any application or a user, then the log backup fails till the next full backup job is complete.
- If, for any database provided, point-in-time 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 backup a maximum of 64 databases.
- 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, SQL Server backup may fail. The product is not exhaustively tested with all other backup solutions.
- If a third party VSS Provider is used then 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. Such as Read-only attribute, Restricted access, Ownership, and Broker-Enabled.
- Restore to SQL server Instance fails if a user tries to restore to a folder/directory having folder compress property enabled.
- Single user database should not be backed up if it is being used by any user, this may result into backup failure.
- Restore may fail if SQL instance contains any database/databases with state 'restoring'. Remove all databases having state 'restoring' from SQL instance to restore successfully.
- Restore cannot be performed for databases with same name across instances in single restore request.
- Point-in-time restore across time zones is not supported.
- Restore across SQL server versions is not supported, and may fail due to compatibility issues.
- If same DB name is selected for restore from multiple instances, the restore fails.
- If network is disabled during log backup or restore, then log backup/restore will fail. This is not a typical network disconnect scenario.
- Database standby restore from SQL 2012 to SQL 2014 fails with ‘database upgrade needed’.
- Database restore from SQL 2014 to SQL 2012 fails with VSS writer error.
Read Quick steps to set up Phoenix to back up databases to get started.