Problem Description

SQL Server backups triggered through Druva Phoenix may fail with the following error:

Volume Shadow Copy (VSS) Internal Error (#10004ffff : 0x80042308L)

Error Code: VSS65535

This error indicates that the Volume Shadow Copy Service (VSS) was unable to create the snapshot required for the SQL backup.

Cause

The failure occurs when the physical file path for one or more SQL databases is not configured correctly.

Specifically, the database file may be located on a network share (UNC path) such as:

\\server_name\share

instead of a local disk path, such as:

C:\ or D:\

VSS snapshots only support local volumes. If SQL database files are stored on remote shares or UNC paths, VSS cannot create the required snapshot, which results in the VSS65535 error.

How to Verify

1. Review the Backup Job Logs

Download the logs for the failed backup job.

Navigate to the backup job in the Druva Phoenix console.
Click Download Logs.
Extract the logs and open the Phoenix.log file.

Look for entries similar to the following:

[2023-08-09 10:51:06,555] [ERROR] SqlAgent :SQL backup failed: Volume Shadow Copy(VSS) Internal Error (#10004ffff : 0x80042308L) (Error Code : VSS65535)
[2023-08-09 10:51:06,555] [ERROR] Error <class 'inSyncLib.inSyncError.SyncError'>:Volume Shadow Copy(VSS) Internal Error (#10004ffff : 0x80042308L) (Error Code : VSS65535)

2. Check the VSS Writer Status

Run the following command in an elevated Command Prompt:

vssadmin list writers

Verify that SqlServerWriter is listed and in a Stable state.

If the writer shows an error or failed state, the VSS framework may need to be reset.

3. Verify the Physical Path of Database Files

Run the following query in SQL Server Management Studio (SSMS) to check the physical location of database files:

SELECT 
    d.name AS DatabaseName,
    f.name AS LogicalName,
    f.physical_name AS PhysicalName,
    f.type_desc AS TypeOfFile
FROM sys.master_files f
INNER JOIN sys.databases d
ON d.database_id = f.database_id;

Review the output and check the PhysicalName column.

Example of Incorrect Configuration

\\FileServer\DBFiles\SalesDB.mdf

Example of Correct Configuration

D:\SQLData\SalesDB.mdf

If any database files are stored on UNC paths, they must be moved to a local disk.

Resolution

Option 1: Correct the Physical Path

Move the database files from the network share to a local disk.

Typical steps include:

Back up the database.
Detach the database from SQL Server.
Move the .mdf and .ldf files to a local drive on the SQL server.
Reattach the database using the updated local file path.

Note: Perform this operation with the database administrator and during a maintenance window to avoid service disruption.

Option 2: Reboot the Server

Sometimes, rebooting the server can resolve temporary VSS inconsistencies and re-establish the correct file path context.

Important: Ensure that proper approvals and change control processes are followed before rebooting a production server.

Workaround

If the issue cannot be resolved immediately and backups must continue, use the following workaround:

Log in to the Druva Phoenix Console.
Edit the backup set for the affected SQL workload.
Deselect the database(s) that have incorrect physical paths.
Save the configuration and run the backup again.

This allows other healthy databases to continue backing up while the path issue is corrected.

Additional Recommendations

Periodically review SQL Server database file locations to ensure they follow best practices.
Avoid storing SQL database files on mapped drives or UNC network paths.
Regularly verify VSS writer status using: