SQL74 Incremental TLog Failure with VSS Event 8194 / COM Permissions and LSN Log-Chain Break

Problem Description

You may experience one or more of the following issues during SQL Transaction Log (TLog) backups:

Partial Backups / Log Chain Broken: The SQL log backup succeeds with errors because the backup of the log files for a few databases was skipped. The log chain for the skipped databases appears broken.
Complete Failures: Incremental TLog backups fail entirely with error code SQL74. This is frequently accompanied by a VSS Event 8194 error in the Windows Application Event logs.

Associated Error Codes:

PHOENIX370
PHOENIX228
SQL74

Cause

This issue generally occurs due to one of the following two reasons:

LSN / Log-Chain Break: A third-party or native SQL log backup ran on the server and truncated/backed up the transaction logs, or the database recovery model was shifted temporarily. This resets the Log Sequence Number (LSN) and breaks the log chain without the Druva agent's awareness.
VSS Event 8194 (COM Permissions): The Network Service account (or the specific service account running the SQL Server VSS Writer) lacks appropriate DCOM (Distributed Component Object Model) permissions required by the Windows VSS framework. This causes VSS snapshots to fail with an Access Denied error during incremental operations, yielding a SQL74 failure.

Traceback / Logs

1. Log Chain Broken Traceback (`Phoenix RoboSyncer` logs):

Plaintext

Line 702: [2018-06-17 07:38:08,638] [INFO] roboSyncer: Sending log to Phoenix server with message : 'Could not backup log files for 12 DBs, WH-RPT02\ProjectQuoting, WH-RPT02\LFAudit_3EDocuments, WH-RPT02\3EDocuments... Line 552: [2018-06-17 07:37:57,923] [INFO] Log chain broken: WH-RPT02:Helpdesk  Line 559: [2018-06-17 07:37:58,065] [INFO] Log chain broken: WH-RPT02:ProjectQuoting_Test

2. VSS Event 8194 Traceback (Windows Event Viewer — Application Log):

Plaintext

Event ID: 8194 Source: VSS Description: Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied.

3. Druva Phoenix UI Job Logs:

Plaintext

Job status: Failed Error Code: SQL74 (Resource contention or VSS snapshot failure during incremental TLog processing).

How to Verify Native SQL Log Backups (LSN / Log Chain Break)

You can verify if native backups were run from the Backup and Restore events report within SQL Server Management Studio (SSMS).

Method A: SSMS Standard Reports

Launch SQL Server Management Studio (SSMS).
Right-click the affected database and navigate to Reports > Standard Reports > Backup and Restore Events.
Expand the Successful Backup Operations section.
Check the Device Type column. If it shows Disk, a native or third-party backup was taken outside of Druva, breaking the LSN chain.

Method B: T-SQL Script Verification

Alternatively, execute the following query in SSMS to investigate the backup history from the last 7 days:

SQL

USE msdb;
GO

SELECT 
    bs.database_name AS 'Database Name',
    bs.backup_start_date AS 'Backup Start Date',
    bs.backup_finish_date AS 'Backup Finish Date',
    CASE bs.[type] 
        WHEN 'D' THEN 'Full Database' 
        WHEN 'I' THEN 'Differential' 
        WHEN 'L' THEN 'Transaction Log' 
        WHEN 'F' THEN 'File/Filegroup' 
        WHEN 'G' THEN 'Differential File' 
        WHEN 'P' THEN 'Partial' 
        WHEN 'Q' THEN 'Differential Partial' 
        ELSE 'Unknown' 
    END AS 'Backup Type',
    bs.is_copy_only AS 'Is Copy-Only',
    bs.first_lsn AS 'First LSN',
    bs.last_lsn AS 'Last LSN',
    bmf.physical_device_name AS 'Backup Destination (Device/Path)',
    bs.user_name AS 'Executed By'
FROM msdb.dbo.backupset bs
INNER JOIN msdb.dbo.backupmediafamily bmf 
    ON bs.media_set_id = bmf.media_set_id
WHERE 
    -- Uncomment and replace the line below to filter by a specific database
    -- bs.database_name = 'YourDatabaseName' 
    
    -- Looks at backups from the last 7 days. Adjust as needed.
    bs.backup_start_date >= DATEADD(DAY, -7, GETDATE()) 
ORDER BY 
    bs.database_name ASC,
    bs.backup_start_date DESC;

Resolution

Resolution 1: Fixing LSN / Log-Chain Breaks

Disable Conflicting Backups: Disable or remove native SQL maintenance plans or third-party log backup schedules targeting the affected instance. Afterward, run a manual Full/Differential backup from the Druva Management Console to re-establish the chain.
Use Copy-Only Native Backups: If external native backups are mandatory, configure them to run exclusively as Copy-Only backups. This ensures they do not truncate logs or break the LSN chain sequence.
Antivirus / Security Tooling Exclusions: Endpoint security software can sometimes intercept VSS queries. Ensure SqlServerWriter is explicitly excluded from active security monitoring blocks.
Scheduling Optimization: Sequence schedules so that the Druva SQL Full/Diff window triggers after any unavoidable local maintenance task or endpoint scanning routines conclude.
Recovery Model Configuration Changes: If a database recovery model is modified permanently, ensure you deselect the database from its original backup set and assign it to a new backup set tailored to its new logging structure.

Resolution 2: Fixing SQL74 and VSS Event 8194 (COM Permissions)

If logs display Event ID 8194 (Access Denied), grant appropriate DCOM access privileges to the system account running the VSS service:

Press Win + R, type dcomcnfg, and hit Enter to open Component Services.
Drill down into Component Services > Computers > My Computer.
Right-click My Computer and select Properties.
Navigate to the COM Security tab.
Under Access Permissions, click Edit Default... * Ensure the Network Service account is listed and has Local Access set to Allow.
Under Launch and Activation Permissions, click Edit Default...
- Ensure the Network Service account is listed and check the boxes to allow Local Launch and Local Activation.
Click OK to apply all modifications.
Open services.msc and restart both the Volume Shadow Copy service and the SQL Server VSS Writer service.
Trigger a manual Full backup via Druva to reset the tracking, followed by an incremental TLog run to confirm resolution.