Skip to main content
All CollectionsEnterprise WorkloadsProtect MS SQL ServersTroubleshoot MS SQL Issues and FAQs
Troubleshooting SQL server issues
Troubleshooting SQL server issues
Updated over 6 months ago

This topic describes the workaround for the issues that you might encounter while backing up or restoring your SQL servers.

Troubleshoot backup issues

This section describes the common issues that you might encounter while backing SQL servers. It also contains workarounds for these issues.

Backup fails because the drive is unavailable

Issue

Backup of database files from an unavailable drive fail.

Cause

Backup fails because VSS cannot detect the databases that reside on the offline drive. VSS cannot detect the databases that reside on the offline drive.

📝 Note
​ The VSS service and the SQL Writer service takes some time to recognize that a drive from which a backup is initiated is unavailable. After the VSS service and the SQL Writer service detect the unavailable drive, the status of the databases on these drives is set to "Restoring" (in the Microsoft SQL Server Management Studio). For the next backup, Druva ignores these databases, and backs up the other databases.

You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

Resolution

  1. Wait for some time until the VSS service and the SQL Writer service register the drive information.VSS service and the SQL Writer service register the drive information.

  2. Wait for the next scheduled backup, and check the backup status after the backup completes.
    -or-
    Start a backup, and check the backup status after the backup completes.

Transaction Log backup fails with Log Chain Broken error

Issue

Transaction Log backup fails with the message "Log chain broken."

Cause

This issue occurs if you back up a SQL server using a tool other than the Enterprise Workloads agent.

For SQL server backups, the sequence is crucial. If you use any other tool for backup, Druva will not have all the backups, and thus the chain will break.

The error details are in the log file created at

C: \ProgramData\Phoenix\logsORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  1. First, disable all native and third-party SQL log backups for the affected SQL instance. Next, trigger a full manual backup from the Management Console. You can also wait for the next scheduled full backup.

  2. If you must use native backups, use the copy-only option.

  3. If you are using a file-based backup that cannot be disabled, you can create an exclude rule for SqlServerWriter. A full backup after creating this rule will resolve the error.

  4. If you need to change the recovery model of a database, create a new backup set for future backups. Do not use the older backup set for future backups, as those will fail.

📝 Note
​ In case of a Log Chain Broken error, the next scheduled log backup can be automatically converted to a full backup. This change will apply to all the backup sets. In addition, you will need the latest version of the Enterprise Workloads agent. Contact support if you would like this feature enabled.

References

Backup fails because some databases belong to a deleted drive

Issue

A backup fails if database files belong to a drive that is deleted.

You can find the error details in the log file that is created at

C: \ ProgramData  \Phoenix\  logsORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later).

Resolution

  1. Recover the databases from the deleted drive using SQL commands or the Microsoft SQL Server Management Studio.

  2. Wait for the next scheduled backup, and check the backup status after the backup completes.
    -or-

  3. Start a backup, and check the backup status after the backup completes.

Backup fails because some databases belong to an unavailable drive

Issue

A backup fails if database files belong to a drive that was previously unavailable but becomes available later.

You can find the error details in the log file that is created at

C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  1. Make the databases from the affected drive offline using SQL commands or the Microsoft SQL Server Management Studio.

  2. Make the databases from the affected drive online using SQL commands or the Microsoft SQL Server Management Studio.

  3. Wait for the next scheduled backup and check the backup status after the backup completes.
    -or-

  4. Start a backup and check the backup status after the backup completes.

Backup fails because of SQL writer issues

Issue

If the SQL Writer service is not running, a backup operation fails with the following error:

Writers are not in

correct

 state

Cause

This happens because the SQL Writer service, the Volume Shadow Copy Service, or the Druva service encounter errors. You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  1. Start the Druva service.

  2. Start the SQL Writer Service.

  3. Start the VSS service. VSS service.

Backup fails because of VSS issues

Issue

Backup operation fails with the following error:

VssException:

StartSnapshotSet

 = 0x80042316L

Cause

This happens because either the SQL Writer service, the Druva service, or the VSS service is not running.

You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  • Ensure that the SQL Writer service, the Druva service, and the VSS service is running.

Backup fails because of VSS exceptions

Issue

Backup operation fails with either of the following errors:

VssException: StartSnapshotSet = 0x80042316L
Error <class 'roboClientLib.pyvss.pyvss.VssException'>:CoInitializeSecurity = 0x80010119L

Cause

This happens because the VSS service, the SQL Writer service, or the Druva service encounters errors. You can find the error details in the log file that is created at VSS service, the SQL Writer service, or the Druva service encounters errors. You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  1. Start the Druva service.

  2. Start the SQL Writer Service.

  3. Start the VSS service.

Backup fails because databases or instances are not found

Issue

Backup operation fails because Druva cannot find a database or an instance at the location that you specified during configuration. The following error is displayed:

No instances/databases found for the backup

You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

Start the MSSQLServer service of the instance or database that are not found.

Backup fails because the SQLCMD path is not set

Issue

If the system variable path to the SQLCMD utility is not set properly, backups fail with the following error:

'sqlcmd

' is not recognized as an internal or external command

You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  • Ensure that the path to the SQLCMD utility is set correctly.

Backup fails because of SQLCMD issue

Issue

Backup might fail with the following error:

Sqlcmd: Error: Internal error at ExecuteSqlCmd (Reason: Unspecified error)

This is an error with the SQL server.

You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

Start the backup again.

Troubleshoot restore issues

This section describes the common issues that you might encounter while restoring SQL servers. It also contains workarounds for these issues.

Restore fails because databases are in the restoring state

Issue

If you initiate a restore to an instance that contains databases in the restoring state in the Microsoft SQL Server Management Studio, the restore operation that you initiated fails. You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  1. From the SQL server, remove all databases that are in the restoring state.
    Alternatively, wait till the databases are restored.

  2. Start the restore again. For instructions, see Backup and restore.

Restore completes, but databases are not created

Issue

Druva restores databases as rst_<Database_name>_<Restore_occurrence_count>. However, if the size of a database that you want to restore is small, the restored database is not created at the location that you specified. You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  1. Start the MS-SQL server service.
    Alternatively, attach the database files to a database within an instance. For instructions, see this article in the Microsoft library.

Restore fails with errors

Issue

Restores might fail with the following error message:

Restore failed [('Attempting to restore to instance [%s] not found'

.

Cause

This happens when instances to which you want to restore are offline. You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  1. Ensure that the instance to which you want to restore is available.

  2. Start the restore again.

Restore fails because the VSS service is not running

Issue

Restores fail with the following error:

VSS service is not running

Cause

This happens because the Volume Shadow Copy Service is not running. You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

Start the VSS service.

Restore fails because of SQL Writer issues

Issue

Restores fail with the following error:

Writers are not in

correct

 state.

Cause

This happens because the SQL Writer service, the Volume Shadow Copy Service, or the Druva service encounter errors. You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  1. Start the Druva service.

  2. Start the SQL Writer Service.

  3. Start the VSS service.

Restore fails because the hostname of the original server is changed

Issue

If you select to restore to the original instance on a SQL server for which the host name was changed, the restore operation fails with the following error:

Host does not match with the original backup server

You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

Restore the database using the Restore database files option. For instructions, see Microsoft SQL Server restore.

Restore fails because of path length

Issue

A restore operation might fail if the path to the restore destination is more than 260 characters. The following error is displayed on the Management Console:

Writers are not in correct state

You can find the following error message in the log file (created at C: \ ProgramData \Phoenix\ logs):

Restore may fail because

filepath

 = ‘(some restore file path)’  have length greater than equal to 260 character

At the time of restore, Druva writes the data to: <destination path>\<snapshot>\<Request ID>\<Fileset>\<Actual file>. You must provide <destination_path>, to which Druva appends <snapshot>\<Request ID>\<Fileset>\<Actual file>. The <destination path> must be such that the complete path (< destination path>\<snapshot>\<Request ID>\<Fileset>\<Actual file> ) is no more than 260 characters long.

Resolution

Make sure that <destination path> is such that the complete path (< destination path>\<snapshot>\<Request ID>\<Fileset>\<Actual file> ) is no more than 260 characters long.

Restore fails because of insufficient free space

Issue

If the location to which you choose to restore your database does not have sufficient space, a restore operation fails with the following error:

Not enough space is available for restore data files on disk

You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

Specify a location where sufficient space is available.
Alternatively, create space at the location by deleting files and folders.

Restore fails because of VSS issues

Issue

Restore operation to original instance might fail with the following error:

VssException: StartSnapshotSet = 0x80042316L

Cause

This happens because either the SQL Writer service, the Druva service, or the VSS service are not running.

You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  • Stop and start the SQL Writer service.

  • Stop and start the Druva service.

  • Stop and start the the VSS service.

Restore fails because of VSS exceptions

Issue

Restore to the original instance might fail with either of the following errors:

VssException: StartSnapshotSet = 0x80042316L
Error <class 'roboClientLib.pyvss.pyvss.VssException'>:CoInitializeSecurity = 0x80010119L

Cause

This happens because the VSS service, the SQL Writer service, or the Druva service encounters errors. You can find the error details in the log file that is created at

 C: \  ProgramData  \Phoenix\  logs ORC:\ProgramData\Druva\EnterpriseWorkloads\logs\mssql(for agent version 7.0.0-455423 or later)

.

Resolution

  1. Start the Druva service.

  2. Start the SQL Writer Service.

  3. Start the VSS service.

Restore might fail if you initiate a restore after an earlier failed restore operation

Issue

Restore might fail if you initiate a restore after an earlier failed restore operation .

Resolution

Before you initiate a restore after a previous failed attempt, ensure that the disk space at the restore location is sufficient for the restore dataset.

Troubleshoot discovery issues

This section describes the common issues that you might encounter while Druva discovers SQL servers. It also contains workarounds for these issues.

Unable to discover SQL databases

Issue

Hybrid Workloads agent is unable to discover databases, and displays the following error:
​

[2022-03-30 12:37:16,707] [ERROR] Error[('08001', u'[08001] [Microsoft][ODBC SQL Server Driver][Shared Memory]SSL Security error (18) (SQLDriverConnect); [08001] [Microsoft][ODBC SQL Server Driver][Shared Memory]ConnectionOpen (SECDoClientHandshake()). (772)')] while connecting with instance [AMZOESSQL01] using SQL Server driver
[2022-03-30 12:37:16,710] [ERROR] Error[('IM002', u'[IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified (0) (SQLDriverConnect)')] while connecting with instance [AMZOESSQL01] using SQL Server Native Client driver
[2022-03-30 12:37:16,710] [ERROR] SyncError: Phoenix SQL agent found no instance/database on the server to backup or the SQL service is not running or the backup content is set to exclude all the databases.
[2022-03-30 12:37:16,710] [INFO] Error[Phoenix SQL agent found no instance/database on the server to backup or the SQL service is not running or the backup content is set to exclude all the databases. (#100030006) (Error Code : SQL6)] while getting product info for instance [AMZOESSQL01]
[2022-03-30 12:37:48,790] [ERROR] Error[('08001', u'[08001] [Microsoft][ODBC SQL Server Driver][Shared Memory]SSL Security error (18) (SQLDriverConnect); [08001] [Microsoft][ODBC SQL Server Driver][Shared Memory]ConnectionOpen (SECDoClientHandshake()). (772)')] while connecting with instance [AMZOESSQL01] using SQL Server driver
[2022-03-30 12:37:48,790] [ERROR] Error[('IM002', u'[IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified (0) (SQLDriverConnect)')] while connecting with instance [AMZOESSQL01] using SQL Server Native Client driver
[2022-03-30 12:37:48,790] [ERROR] SyncError: Phoenix SQL agent found no instance/database on the server to backup or the SQL service is not running or the backup content is set to exclude all the databases.
[2022-03-30 12:37:48,792] [INFO] Error[Phoenix SQL agent found no instance/database on the server to backup or the SQL service is not running or the backup content is set to exclude all the databases. (#100030006) (Error Code : SQL6)] while getting product info for instance [AMZOESSQL01]
[2022-03-30 12:37:48,792] [DEBUG] sql discovery info ={'cluster_name': '', 'instances': {}, 'discovery_node_name': ''}
[2022-03-30 12:37:48,793] [INFO] Killing SQL Client discovery Instance

Cause

This error occurs as TLS 1.2 is not enabled on the server where the agent is installed.

Resolution

Enable TLS 1.2 and make sure that TLS 1.0/1.1 is disabled.

Related Articles
How to enable or disable debug logging for SQL server agent
Enterprise Workloads agent logs and configuration details
Agent logs and configuration details
Logging, configuration files, and services for MS-SQL
Troubleshoot common SQL server issues
Did this answer your question?