Problem Description
SQL Server backups triggered via Druva Phoenix fail with the following error:
Volume Shadow Copy (VSS) Internal Error (#10004ffff : 0x80042308L)
Error Code: VSS65535
This error typically indicates that the Volume Shadow Copy Service (VSS) was unable to create a snapshot required for the backup.
Cause
The failure occurs because the physical file path for one or more databases is not correctly configured. Specifically, the database file resides on a network share (e.g., \\server_name\share) instead of a supported local volume (e.g., C:\ or D:\). VSS cannot operate with database files located on remote shares or UNC paths.
How to Verify
Follow these steps to validate the issue:
1. Review the Job Logs
Download and inspect the job logs for the failed backup:
Navigate to the backup job within the Druva Phoenix console.
Click Download Logs for the specific failed job.
Extract and open the logs. In the Phoenix.log file, locate entries similar to the following:
[2023-08-09 10:51:06,555] [ERROR] <_MainThread(MainThread)> SqlAgent :SQL backup failed: Volume Shadow Copy(VSS) Internal Error (#10004ffff : 0x80042308L) (Error Code : VSS65535)
[2023-08-09 10:51:06,555] [ERROR] <_MainThread(MainThread)> Error <class 'inSyncLib.inSyncError.SyncError'>:Volume Shadow Copy(VSS) Internal Error (#10004ffff : 0x80042308L) (Error Code : VSS65535). Traceback -Traceback (most recent call last):
2. Run VSS Diagnostics
Execute the following command in an elevated Command Prompt to confirm the status of the SQL VSS writer:
vssadmin list writers
Ensure that SqlServerWriter is in a stable state with no errors.
If it shows errors or is in a failed state, a reboot may be required.
3. Check the Physical Path of Database Files
Run the following SQL query in SQL Server Management Studio (SSMS) to list all databases and their physical file paths:
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 for any entries where the physical_name starts with \\server_name, indicating a UNC path.
Example of Incorrect Physical Path:
\\FileServer\DBFiles\SalesDB.mdf
Example of Correct Physical Path:
D:\SQLData\SalesDB.mdf
Resolution
To resolve the issue:
Option 1: Correct the Physical Path
Update the database to use a local disk path instead of a network share. This typically requires:
Backing up the database.
Detaching it from SQL Server.
Moving the .mdf and .ldf files to a local disk.
Reattaching the database using the new path.
Note: Perform this action in coordination 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 immediate remediation is not possible and backup continuity is critical, apply the following temporary workaround:
Edit the backup set in the Druva Phoenix console.
Deselect the problematic database(s) with incorrect physical paths.
Save the configuration and run the backup again.
This allows other healthy databases to be backed up while you address the path issue separately.
Additional Recommendations
Periodically review SQL Server database file locations to ensure compliance with best practices.
Avoid using mapped drives or UNC paths for critical SQL databases.
Maintain regular testing of VSS functionality using tools like vssadmin list writers.
For further assistance or if the issue persists, contact Druva Support with job logs and query outputs for in-depth analysis.