DISKIO_SUSPEND Wait Type in SQL Server

Part of the SQL Server Wait Types Library.
Related deep dive: BACKUPIO and BACKUPBUFFER Wait Types.

---

DISKIO_SUSPEND occurs when a thread needs to issue I/O against a database whose I/O has been deliberately frozen. External snapshot backup tools (VSS-based agents, SAN and VM snapshot backups) freeze a database’s I/O while they capture a consistent image of the files directly, instead of streaming a native SQL Server backup. Every session that needs I/O during the freeze parks in this wait, retrying once per second, until the tool thaws I/O.

So this wait is a live recording of your backup tool holding the database still.

Is It a Problem?

The freeze itself is by design, and short freezes (a second or two for a VSS snapshot) are barely felt. It becomes a genuine incident when the freeze runs long: sessions stack up in DISKIO_SUSPEND, the application stalls, and the length of the stall depends entirely on how long the external tool takes. The error log helpfully brackets each event with “I/O is frozen on database X” and “I/O was resumed”, so you can measure every freeze precisely.

Repeated long freezes during business hours mean the backup tooling, not SQL Server, needs attention.

Common Causes

• VSS or SAN snapshot backups freezing I/O while the snapshot is created.
• A slow or struggling backup agent stretching the freeze window.
• VM-level backups quiescing the guest, freezing every database at once.
• Snapshot schedules overlapping peak workload.

What To Do

1. Pull the freeze/resume pairs from the error log and measure real freeze durations per database (our recent-errors script surfaces these).
2. Take long freezes to the backup team or vendor; the fix is on their side (snapshot method, agent version, storage performance).
3. Reschedule snapshot backups away from busy windows.
4. Reconsider the strategy where freezes are chronic: native SQL Server backups (or storage-level backups that do not require guest freezes) avoid this wait entirely.

How To See It

Rank it against everything else with Get-WaitStatistics, then confirm with the error log’s frozen/resumed messages; the timestamps will match your backup schedule.

---