How to fix Error 3420 on Windows Server 2025 / Windows 11

by

Troubleshooting Guide: SQL Server Error 3420 – Database Snapshot Marked Suspect

Why This Error Happens

Error 3420 occurs when the sparse file backing a database snapshot encounters an I/O failure, typically due to the underlying storage volume running out of disk space or experiencing a hardware-level read/write error. Since database snapshots rely on a copy-on-write mechanism using NTFS sparse files, any interruption—such as the source volume being disconnected, a permissions change on the snapshot directory, or disk corruption—causes SQL Server to mark the snapshot as “suspect” because it can no longer guarantee transactional consistency. Once marked suspect, the snapshot is permanently unusable and SQL Server will not attempt to self-heal it, requiring manual intervention.

Step-by-Step Resolution Guide

Step 1: Confirm the Snapshot is Unrecoverable

  • Run SELECT name, state_desc FROM sys.databases WHERE name = 'YourSnapshotName'; to confirm the state is SUSPECT.
  • Check the SQL Server Error Log (C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\Log\ERRORLOG) for accompanying I/O error details (e.g., Error 823 or 824) that may indicate the root disk issue.
  • Verify the sparse file’s underlying volume isn’t full by checking Disk Management or running Get-PSDrive in PowerShell.

Step 2: Drop the Suspect Snapshot

  • Since suspect snapshots cannot be repaired, they must be removed:
DROP DATABASE YourSnapshotName;
  • If the standard DROP DATABASE command hangs or fails due to the suspect state, force removal using:
ALTER DATABASE YourSnapshotName SET OFFLINE WITH ROLLBACK IMMEDIATE;
DROP DATABASE YourSnapshotName;

Step 3: Investigate and Resolve the Underlying Storage Issue

  • Open Event Viewer (eventvwr.msc) and navigate to Windows Logs > System to check for Disk or NTFS warnings (Event IDs 7, 11, 51, or 153) around the time of the failure.
  • Confirm the volume hosting the snapshot file has sufficient free space; sparse files grow dynamically and can consume the entire volume unexpectedly.
  • If using storage spaces or a SAN/NAS backend, verify connectivity and check the storage controller logs for transient disconnects.

Step 4: Recreate the Database Snapshot

  • Once the storage issue is resolved, recreate the snapshot pointing to a volume with adequate free space:
CREATE DATABASE YourSnapshotName ON
(
    NAME = YourDB_Data,
    FILENAME = 'D:\SQLSnapshots\YourSnapshotName.ss'
)
AS SNAPSHOT OF YourDB;
  • Ensure the SQL Server service account has write permissions on the target directory (D:\SQLSnapshots) via Properties > Security in Windows Explorer.

Step 5: Schedule Proactive Monitoring

  • Set up a SQL Agent Alert on Error 3420 or configure a PowerShell script using Get-Counter to monitor free disk space on volumes hosting snapshots.
  • Consider moving snapshot files to dedicated, monitored storage separate from production data files to avoid future space contention.

Alternative or Verification Steps

  • After recreating the snapshot, run SELECT state_desc FROM sys.databases WHERE name = 'YourSnapshotName'; and confirm the state reads ONLINE.
  • If snapshots continue to fail intermittently, consider using native backups or Always On Availability Group secondary replicas as a more resilient alternative to snapshot-based point-in-time reporting.