What’s the issue?
SQL Server supports the Volume Shadow Copy Service (VSS) framework, which allows external backup tools to take consistent snapshots of database volumes. When a VSS backup runs, the SQL Server VSS Writer instructs the engine to freeze I/O on the affected databases, holds that freeze while the snapshot is taken, and then thaws I/O so normal activity resumes.
Each freeze and thaw is recorded in the SQL Server error log with messages indicating the database and the duration of the freeze. Under normal conditions the freeze lasts a very short time, typically a few seconds or less, and the impact on the workload is minimal.
This finding identifies instances where recent I/O freeze events appear in the SQL Server error log for one or more databases. The events are almost always attributable to VM-level backups or other backup products that use VSS to capture consistent volume snapshots.
Why is this a problem?
While I/O is frozen, the affected databases cannot complete write operations. Queries that need to write pages, commit transactions, or flush log records wait until the thaw occurs. A short freeze produces negligible impact, but a longer freeze can stall the workload noticeably, producing query timeouts, blocking chains, and application errors.
Extended freezes can also affect Always On Availability Groups and clustering. A freeze that lasts long enough can trigger health check timeouts, cause a replica to appear unresponsive, or in extreme cases contribute to an unnecessary failover. The cluster and AG health mechanisms cannot distinguish a frozen instance from a failing one.
The most common cause of concern is a team being unaware that VSS-based backups are running at all. Virtual machine backups configured by the infrastructure team, storage-level snapshot products, and endpoint backup agents all commonly use VSS, and the database team may not be involved in the configuration. The result is periodic I/O freezes on production databases that no one on the database side anticipated.
What should you do about this?
Review the SQL Server error log for freeze and thaw messages, capturing the affected databases, the timestamps, and the freeze durations. Look for patterns in the timing that correlate with known backup schedules, and note any freezes that lasted longer than a few seconds.
Identify which tools in your environment are using VSS. Work with the infrastructure, virtualization, and backup teams to inventory the products taking VM-level or volume-level snapshots of the SQL Server hosts, and confirm the schedules, the scope, and whether database consistency is actually required for each one.
Coordinate the VSS backup schedule with your workload so freezes occur during low-activity windows where possible, and confirm the SQL Server native backup strategy is not redundant with the VSS-based snapshots. Many environments run both without a clear understanding of which one is the actual recovery mechanism, which adds complexity and overhead without adding protection.