SQL Backup Jobs Fail with Error Code SQL112 Due to VSS Writer Overload

Problem Description

Microsoft SQL Server backup jobs fail unexpectedly with a generic error code SQL112. In this scenario, the user interface and basic logs do not immediately specify which individual database caused the failure within a multi-database backup set. This issue typically occurs in environments hosting a large number of databases on a single instance where all databases are grouped sequentially into a single backup policy.

Cause

The root cause of this failure is the overload of the Volume Shadow Copy Service (VSS) SQL Writer. When a backup set contains an excessively high number of databases (e.g., more than 40–50 databases, or 81 databases in this specific case) within a single backup set, the VSS framework attempts to snapshot all of them concurrently.
This volume triggers severe performance degradation, causing the Microsoft VSS SQL Writer to hang and remain stuck in a Waiting for Completion state. Consequently, memory access violations occur within native system processes, leading to intermittent ioserver.exe crashes and forcing Druva backup jobs to terminate with error code SQL112.

Traceback

The Windows Event Viewer and Druva agent logs exhibit the following signature events during the failure sequence:

VSS Error (Event ID 12289): Volume Shadow Copy Service error: Unexpected error DeviceIoControl...
Application Error (Event ID 1000): Faulting application name: ioserver.exe, exception code: 0xc0000005 (Memory Access Violation)

VSS Admin Status Command Output:

Writer name: 'SqlServerWriter'
   State: [9] Failed
   Last error: Time-out / Waiting for Completion

Resolution

To resolve the VSS writer timeout and eliminate the SQL112 failure, optimize the backup topology and clear the agent state by executing the following procedures:

Restructure into Smaller Backup Sets: Divide the single large backup set into multiple smaller, logical backup sets. Limit each backup set to a maximum of 10–15 databases.
Stagger the Backup Schedules: Modify backup policies so that the newly created backup sets do not trigger simultaneously. Stagger the execution times by 30-to-60-minute windows.
Clear Druva Agent Cache and Restart Services:
- Stop the Druva Phoenix Client Service.
- Navigate to the Druva agent installation directory and delete the temporary cache folder contents.
- Restart the Druva Phoenix Client Service.
Align Database Recovery Models: Ensure database recovery models are correctly configured. For databases requiring Transaction Log (T-Log) backups, use the Full recovery model and verify log truncation.

Include and Exclude Filters

Inclusion Rules: Use precise text string patterns or wildcard rules (e.g., DB_Prod_*) to dynamically add matching databases into targeted, smaller backup groups.
Exclusion Rules: Apply exclusions to filter out legacy, temp, or scratch databases that do not require production SLAs, reducing unnecessary load on the VSS SQL Writer.

Verification

Run the command vssadmin list writers in an elevated command prompt and confirm that the SqlServerWriter shows State: [1] Stable and Last error: No error.
Manually trigger an on-demand backup for one of the newly segmented backup sets via the Druva Console.
Monitor the job progress to confirm successful completion without any SQL112 error codes or ioserver.exe application fault entries in the Windows Event Viewer.