Backup fails if the public network is disabled

Issue

The backup job fails with a Login Failed error when a virtual network (VNet) and subnet are associated with a database, public network access is disabled, and no private endpoint is configured.

Cause

This issue occurs when the Druva application cannot connect because public access is blocked and no private endpoint exists, making the database inaccessible.

Resolution

To ensure successful backup operations, either temporarily enable public access or configure a private endpoint to allow secure connectivity. For more information, see How to set up Private Endpoints for Azure SQL.

Backup window expires

Issue

Backup job expires.

Cause

Backup jobs can expire due to several reasons, including if the Druva Quantum Bridge is stopped during the backup process. This stoppage can cause the backup window to expire.

Resolution

Retrigger the job after some time.

Backup of Azure SQL server fails

Issue

Backup of Azure SQL server on Azure VM fails and you get the following error message:

level=error ts=2025-03-28T04:53:59.149967036Z filename=backup_agent.go:220 message="Setting Error" Error="Failed to start CDC dump: failed to get LSN for timestamp for database auto_db_jwbgg: failed to get LSN for CDC: failed to run command, QueryContext: failed to run command: Failed to run command: context deadline exceeded" stack="goroutine 1 [running]:\nruntime/debug.Stack()\n\t/usr/local/go/src/runtime/debug/stack.go:24 +0x5e\ngit.druva.org/phoenixdev/falcon/pkg/logger.(*fileLogger).Error(0xc000680600, {0xc000681080?, 0x0?, 0x0?})\n\t/bld/src/azure-sql-client/vendor/git.druva.org/phoenixdev/falcon/pkg/logger/file_logger.go:203 +0x48\ngit.druva.org/enterprise-wl/azure-sql-client/ioserver/backup.(*BkpAgent).setErr(0xc0006d4500, {0x1a6b8a0?, 0xc000db49e0?})\n\t/bld/src/azure-sql-client/ioserver/backup/backup_agent.go:220 +0x12f\ngit.druva.org/enterprise-wl/azure-sql-client/ioserver/backup.(*BkpAgent).StartJob(0xc0006ecc60?)\n\t/bld/src/azure-sql-client/ioserver/backup/backup_agent.go:203+0x5f\nmain.main()\n\t/bld/src/azure-sql-client/ioserver/cmd/azsqlioserver/main.go:132 +0x11b5\n"

Cause

This issue occurs when the SQLSERVERAGENT service on the Azure VM stops if the Azure VM is restarted or shut down.

Resolution

Start the SQLSERVERAGENT service manually.

Backup of a Managed Instance database fails

Issue

Backups of databases on a managed instance fail intermittently with error AZURE_SQL 1015 and you get the following error message in azsqlioserver.logs:

mssql: The Change Data Capture 'capture' job does not exist in the system table 'msdb.dbo.cdc_jobs'. Use the stored procedure 'sys.sp_cdc_add_job' to add the Change Data Capture job.

Cause

This issue may occur if you delete a database without disabling CDC. Due to a known issue in Azure SQL Managed Instance, a stale entry for the CDC cleanup and capture jobs remains associated with the deleted database ID. If you then create a new database and back it up, the backup fails.

Resolution

Ensure you disable CDC before backing up the database, and also before deleting the database, make sure you disable CDC explicitly in the Azure SQL Managed Instance.

Backup of the restored database fails

Issue

Backup of the restored database fails, and you get the following error message:

Only active directory users can impersonate other active directory users.
Detailed log snippet.
evel=error ts=2025-01-28T12:44:33.58922772Z filename=backup_agent.go:201 messagg

e="Setting Error" Error="Failed to process schema dump: Failed to reinit CDC andd

convert to full: Failed to enable CDC: Failed to enable CDC for db foreignkey_dd

b_: failed to run command, Enable CDC failed: failed to run command, EnableCDC:  

failed to decode response: failed to run command:c040a298-babb-44da-a27c-440198dd

c0bd9, error: Internal error Error enabling CDC on database: Error enabling CDC  

on database : foreignkey_db_: mssql: Could not update the metadata that indicatee

s database foreignkey_db_ is enabled for Change Data Capture. The failure occurrr

ed when executing the command '(null)'. The error returned was 33171: 'Only actii

ve directory users can impersonate other active directory users.'. Use the actioo

n and error to determine the cause of the failure and resubmit the request." staa

ck="goroutine 1 [running]:\nruntime/debug.Stack()\n\t/usr/local/go/src/runtime/dd

ebug/stack.go:24 +0x5e\ngit.druva.org/phoenixdev/falcon/pkg/logger.(*fileLogger))

.Error(0xc0000d0100, {0xc000764b40?, 0xc000aff250?, 0x6?})\n\t/bld/src/azure-sqll

-client/vendor/git.druva.org/phoenixdev/falcon/pkg/logger/file_logger.go:203 +0xx

48\ngit.druva.org/enterprise-wl/azure-sql-client/ioserver/backup.(*BkpAgent).sett

Err(0xc0000c46c0, {0x1a20d20?, 0xc000b943a0?})\n\t/bld/src/azure-sql-client/iosee

rver/backup/backup_agent.go:201 +0x12f\ngit.druva.org/enterprise-wl/azure-sql-cll

ient/ioserver/backup.(*BkpAgent).StartJob(0xc000707440?)\n\t/bld/src/azure-sql-cc

lient/ioserver/backup/backup_agent.go:177 +0x93\nmain.main()\n\t/bld/src/azure-ss

ql-client/ioserver/cmd/azsqlioserver/main.go:132 +0x11c5\n"

Cause

This issue may occur if you change the database authentication type after backing it up and then restore it.

Resolution

Set the authentication type back to the original and try restoring the database again.

Backup jobs fail if the table, schema, or database name contains spaces

Issue

Backup fails with the following error:

level=error ts=2025-05-23T13:33:12.819427811Z filename=backup_agent.go:304 message="Command Failed" cmdID=3a7a442b-b13d-4b79-a517-6071da7a4555 Status=3 stack="goroutine 192 [running]:\nruntime/debug.Stack()\n\t/usr/local/go/src/runtime/debug/stack.go:24 +0x5e\ngit.druva.org/phoenixdev/falcon/pkg/logger.(*fileLogger).Error(0xc0006773c0, {0xc000c71560?, 0x24?, 0x0?})\n\t/bld/src/azure-sql-client/vendor/git.druva.org/phoenixdev/falcon/pkg/logger/file_logger.go:203 +0x48\ngit.druva.org/enterprise-wl/azure-sql-client/ioserver/backup.(*BkpAgent).pollCmdStatus(0xc00019a580)\n\t/bld/src/azure-sql-client/ioserver/backup/backup_agent.go:304 +0x91c\ncreated by git.druva.org/enterprise-wl/azure-sql-client/ioserver/backup.(*BkpAgent).Init in goroutine 1\n\t/bld/src/azure-sql-client/ioserver/backup/backup_init.go:142 +0x50e\n"

Cause

This issue may occur if the table, schema, or database name contains spaces.

Resolution

Get the command ID from azsqlioserver.log.
Look for the exact details in <ExtractionVMLogs>-<jobID->-<commandID>. You will see details as shown below:

Copy direction must be either 'in', 'out' or 'format'.

usage: bcp {dbtable | query} {in | out | queryout | format} datafile

[-m maxerrors] [-f formatfile] [-e errfile]

[-F firstrow] [-L lastrow] [-b batchsize]

[-n native type] [-c character type] [-w wide character type]

[-N keep non-text native] [-q quoted identifier]

[-t field terminator] [-r row terminator]

[-a packetsize] [-K application intent]

[-S server name or DSN if -D provided] [-D treat -S as DSN]

[-U username] [-P password or tokenfile]

[-T trusted connection] [-v version] [-R regional enable]

[-k keep null values] [-E keep identity values][-G Microsoft Entra ID Authentication]

[-h "load hints"] [-d database name]