Sql-server – SQLVDI error when backing up to Azure Storage BLOB

azurebackupsql server

I'm running a patched SQL 2014 trying to backup a database to one of our Azure Storage BLOBs, using:

BACKUP DATABASE [DB]
TO URL = N'https://storage.blob.core.windows.net/server-mssqlserver/DB.bak'
WITH CREDENTIAL = N'AzureCredential'
    ,NOFORMAT
    ,NOINIT
    ,NAME = N'DBA_DB-Full Database Backup'
    ,NOSKIP
    ,NOREWIND
    ,NOUNLOAD
    ,COMPRESSION
    ,STATS = 5
GO

but the query throws the following error:

Msg 3292, Level 16, State 9, Line 1
A failure occurred while attempting to execute Backup or Restore with a URL device specified. Consult the Windows Event Log for details.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

Checking the server's Event Logs shows the actual error as:

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQLSERVER. ErrorCode=(5)Access is denied.
. Process=4668. Thread=6596. Client. Instance=MSSQLSERVER. VD=.

I have made sure that the SQL Server Agent service's account has the Create global objects policy, and also made sure the SQL VSS Writer service is running under the Local System account. The error keeps happening!

Is there something I can do to fix it, or just log some more detailed error messages than the "SQLVDI: Loc=IdentifySQLServer" one above?

Best Answer

Crikey, this is one of those "no idea how I fixed it" things.

Before I went to lunch, I could reliably generate the error in question by running the provided T-SQL, yet when I came back from lunch the BACKUP command completed fine!

The main thing I remember changing was on the Azure side, where I created a SAS (Shared Access Signature).

This is supposedly not required for SQL 2014 as it uses an actual Azure Credential to connect to the storage instead. I actually created the SAS for an instance of SQL Server 2016 that I want backing up to the same container, and that may have opened the access pathway to the container for SQL Server 2014 too!

Many thanks to Sean Gallardy for recommending ProcMon, which showed a whole ton more error log information than the "ErrorCode=(5)Access is denied" message did.

Related Question