📝 Note
Hybrid Workloads supports only the English language for the user account. To verify the current language setting, run the DBCC USEROPTIONS command and check the language value. If it is not set to English, please change the language to English before proceeding.
The Hybrid Workloads agent interacts with Volume Shadow Copy Service (VSS) to perform full backups. Ensure that the Volume Shadow Copy Service is not disabled.
The Hybrid Workloads agent uses Microsoft SQL Server Virtual Device Interface (VDI) for differential and transaction log backups.
The account used for SQL backups and restores must also have the CREATE DATABASE permission for successful restores from recovery points. If the account used for SQL backups and restores does not have the CREATE DATABASE permission, the restores may fail with the SQL7 error. For more information, see GRANT Database Permissions.
📝 Note
As with any other third-party backup software, Druva interfaces with Microsoft Virtual Device Interface (VDI) to perform differential and transaction log, backups and restores. The SysAdmin role is mandatory for VDI backups and restores. If the user account used for SQL VDI differential backups does not have the sysadmin role, the backups will fail in the initial stages. If differential and transaction log backups and restores are not required, sysadmin permissions are not required. For more information, seeSQL Server VDI backup and restore operations require Sysadmin privileges.
Druva recommends that you use the Microsoft’s native VSS provider. If you are using a third-party VSS provider, you must configure Hybrid Workloads 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 these permissions:
Sysadmin: Required for SQL server backup and restores.
📝 Note
As with any other third-party backup software, Druva interfaces with Microsoft Virtual Device Interface (VDI) to back up and restore SQL Database Transaction Logs. To use VDI, SysAdmin role is mandatory. If transaction log backups and restores are not required, sysadmin permissions are not required.
For more information, see Backup (Transact-SQL), and Restore Statements (Transact - SQL).
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.
Druva supports backup of availability group databases in MS-SQL server 2012 onward since Microsoft introduced availability group in SQL 2012.
Ensure that you install Hybrid Workloads 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 Hybrid Workloads agent version installed on them.
If you want the Hybrid Workloads 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 Hybrid Workloads 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.
Key considerations
The following list provides information on MS-SQL and Windows features that Druva supports and uses to backup and restore databases.
Druva supports backup of MDF, NDF, and LDF files.
Druva only supports databases created on NTFS volumes.
Druva supports file-stream database backup.
Druva supports mirrored databases with an assumption that no other software including SQL Native (maintenance job) is taking backups of the mirrored databases.
Druva supports only active-passive FCI cluster setups.
Transaction log backup is not recommended if Mirroring with log shipping is configured. The log chain will break and it will impact the log backups as well as log shipping.
Database for which Replication is configured is supported for backups.
During restores, Restore with replace original option will not be supported for mirrored databases, as well as databases for which replication is enabled.
Druva does not support backups of databases having an apostrophe, comma, or any non-standard ASCII character in their names. Ensure that you exclude such databases from backups.
After Druva 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.
For restoring a database from a lower version of MS-SQL server to a higher version, you must set the correct compatibility level for the database before backup. You can alter the compatibility of databases in the Database Properties window on the SQL Server Management Studio (SSMS). For more information, see ALTER DATABASE Compatibility Level (Transact-SQL) and Restore checklist and considerations.
Limitations of MS-SQL servers
The following list provides information on scenarios when a backup or restore job can fail.
If 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 Druva 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 recovery point.
The agent is tested to back up a maximum of 64 databases.
Databases which get mirrored are not supported.
Other VSS-based backup software may cause agent’s VSS recovery point 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, comma, or any non-standard ASCII character 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.
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.
Druva does not support restore of databases from availability group backup sets to Hybrid Workloads 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.
SQL FCI Key considerations and Limitations
The following list provides information on the key considerations and limitations pertaining to SQL FCI:
Key considerations
Hybrid Workloads agent 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.
Hybrid Workloads agent needs to be installed on all cluster nodes of FCI. However, the upgrade to the Hybrid Workloads agent upgrades all the Hybrid Workloads agents on all nodes.
Limitations
Availability group backup on FCI is not supported.
Druva does not support backup of FCI and stand-alone instances both on the same host.
When failover happens, the FQDN displayed on the Management Console also changes.
If there are two FCIs with alternate primary and secondary server configurations, only one of them can be configured in Druva for backup.
Next steps
Read Quick steps to set up Druva to back up databases to get started.