veeam error code 32768 failed to create VSS snapshot
Fixes Veeam error code 32768 failed to create VSS snapshot by stabilising VSS writers, shadow copy storage and competing snapshot providers. Use when guest processing fails before data transfer starts. Not for a hypervisor snapshot failure with no VSS involvement.
TL;DR
Do not start by reinstalling the agent: check the guest VSS writers first, give the shadow copy storage room to grow, and remove competing snapshot providers from other backup tools. Error 32768 in Veeam almost always means the in guest VSS snapshot set never formed, so no backup data was ever read. Prove every writer is stable, then retry a single VM with application aware processing.
veeam error code 32768 failed to create VSS snapshotUse this when
- Veeam fails during guest processing with code 32768 and a VSS snapshot message.
- The same VM backs up fine with application aware processing turned off.
- Windows Event Viewer on the guest shows VSS or volsnap errors at job time.
Not for this skill when
- The error is a hypervisor snapshot failure on a Linux guest with no VSS. Use the snapshot creation skill instead.
- VSS writers are stable and the failure happens later during data transfer. That is a transport problem, not this one.
Steps
- Inside the guest, run vssadmin list writers from an elevated prompt and note any writer not in a stable state, especially the SQL, Exchange, System and ASR writers for the workload on that VM. A failed or waiting for completion writer blocks the whole snapshot set. Verify: every listed writer shows stable with no error after a fresh check
- Check shadow copy storage with vssadmin list shadowstorage and confirm each protected volume has allocated space and a maximum that is not tiny or already full. Raise the maximum on a volume with room, ideally to at least ten percent, rather than deleting production shadow copies blindly. Verify: shadowstorage shows headroom on every protected volume
- Read the guest Application log around the job time for VSS, volsnap and SPP entries and match the timestamp to the Veeam failure. Note any third party hardware provider listed by vssadmin list providers, since snapshot providers from old storage or backup tools commonly hijack the request. Verify: you have one named provider or event source to act on
- Remove or disable a stale third party VSS provider or a leftover backup agent that is no longer used, then restart the Volume Shadow Copy and Veeam guest processing services in a window. Do not delete the Microsoft software provider. Verify: vssadmin list providers shows only expected providers and the services start cleanly
- Restart the failed writers by restarting their owning services, for example the database or application service for a failed application writer, then recheck writer state. If a writer fails again immediately, repair that application first instead of retrying the backup. Verify: the previously failed writer returns to stable and stays there for ten minutes
- Retry one VM with application aware processing on and watch writer state during the job. If it still times out, extend the VSS preparation time in the job guest processing settings in small steps and check for slow disks under snapshot load. Verify: the job passes guest processing and writes a restore point with application consistency
Why it happens
VSS coordinates writers for each application, freezes writes briefly, and asks a provider to create shadow copies of every volume in the set. If one writer does not respond, the shadow copy storage is full, or a stale provider takes the request and fails, the whole set aborts and Veeam surfaces the generic 32768 result. Nothing is wrong with the backup files because the job never reached the read phase. Slow storage makes it worse because writers only hold the freeze for a limited window. Compatibility: Veeam Agent and Veeam Backup and Replication 11 and 12 on Windows guests with application aware processing.
Variants and edge cases
veeam 32768 failed to create VSS snapshot SQL VM
On database VMs the SqlServerWriter is the usual blocker. Check database auto close settings, volumes holding logs, and whether a native database snapshot or backup ran at the same minute before retrying.
veeam VSS snapshot failed error code 32768 after Windows update
Updates can leave writers waiting for completion until a reboot clears the state. Schedule the reboot, recheck writers before the window closes, and do not stack repeated backup retries against a half updated guest.
could not create VSS snapshot on Hyper-V guest
The same checks apply, plus the Hyper-V integration services inside the guest. An outdated integration version can make the host request fail even when in guest writers look healthy.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_YL8aEzSeXtmPlGVTR7edoA