Problem description
Microsoft SQL Server backup jobs (both Full and Transaction Log) consistently fail with Error SQL74.
During the snapshot phase, the Druva Hybrid Workloads agent attempts to resolve the system paths for all configured databases in the backup set.
If a database (e.g.,
TEST_LIVE) was physically removed or dropped from the SQL instance without updating the corresponding Druva backup set, the backup agent continuously queries for the obsolete.MDFand.LDFfiles. Because the files no longer exist on the server filesystem, snapshot initialization fails, creating critical data protection gaps.
Cause
Stale Configuration: The backup set (
TESTSQL#bset10) was not updated or reconfigured after theTEST_LIVEdatabase was removed from the SQL instance. The agent continues to look for files that no longer exist.VSS Storage Constraints: The shadow copy storage limits on drives
E:andF:are configured too low. When the VSS engine attempts snapshot execution, the required data footprint overflows the assigned limits, causing the system to automatically delete the snapshots mid-process.VSS Writer Instability: Due to the combination of missing physical file references and insufficient shadow storage overhead, the system's
SQLWriterandSqlServerWriterentered transient error or failed states.
Traceback
The following errors are logged in the ioserver.log during the snapshot phase:
level=error ... filename=backup_agent.go:489 message="Walk error while scanning VSSPath" Error="Lstat : The system cannot find the path specified."
level=error ... filename=backup_agent.go:512 message="Failed to get stats for snapshot file" path=TEST_LIVE.LDF Error="CreateFile TEST_LIVE.LDF: The system cannot find the file specified."
level=error ... filename=backup_agent.go:512 message="Failed to get stats for snapshot file" path=ADR_LIVE.MDF Error="CreateFile TEST_LIVE.MDF: The system cannot find the file specified."
Resolution
To resolve this issue, execute the following troubleshooting procedures:
Step 1: Clean Up and Optimize the Backup Set
Log in to the Druva Phoenix Management Console.
Locate the defunct backup set (
TESTSQL#bset10).Edit the backupset and unselect the inactive database and save the backupset.
Step 2: Adjust Volume Shadow Copy (VSS) Storage Limits
Open an elevated Command Prompt (
cmdrun as Administrator) on the affected SQL server.Check the current shadow storage sizes by running:
vssadmin list shadowstorage
Increase the shadow copy storage limits on drives
E:andF:to ensure there is enough overhead space during snapshot creation. For example, to set the limit to Unbounded or to a specific size (e.g., 20GB), run:vssadmin resize shadowstorage /for=E: /on=E: /maxsize=20GB vssadmin resize shadowstorage /for=F: /on=F: /maxsize=20GB
(Note: Adjust
/maxsizebased on your disk capacity and data change rate).
Step 3: Clear VSS Writer and Service Error States
Open the Windows Services console (
services.msc).Locate the Volume Shadow Copy (VSS) service and click Restart.
Locate the SQL Server VSS Writer service and click Restart.
Verify the status of the writers via Command Prompt:
vssadmin list writers
Ensure
SqlServerWritershows a status of[1] StablewithNo error.
Verification
Run
vssadmin list writersto confirm that all Microsoft SQL writers are stable and error-free.Navigate to the Druva Phoenix Management Console.
Trigger the manual backup using Backup Now.
Verify that the job successfully passes the snapshot phase and completes without generating the
SQL74error.