Windows Server Backup fails with semaphore timeout until I retry

It may also be worth checking shadow-copy usage rather than only checking writer status. Security or endpoint-protection software with anti-ransomware features can retain a large number of shadow copies or interfere with VSS during a backup.

Review the configured shadow-copy storage limits and look for unusually high usage. Temporarily testing with the endpoint protection backup or snapshot features excluded can indicate whether that software is contributing to the failures.

Test the destination independently with a sustained large-file copy or disk-health and throughput check. Since the issue happens with both an external disk and a shared folder, also check the server’s storage controller, network path, SMB connection, and the destination disk rather than assuming the backup service itself is broken.

If the logs show transport timeouts, try a different destination and run the backup with fewer volumes. That can confirm whether the failure is caused by throughput or timeout pressure during the initial backup pass.

That error usually points more toward storage I/O timing out than a VSS writer problem, which would explain why the VSS checks look healthy. The fact that single-volume backups work while full or multi-volume backups fail suggests the storage path is struggling under sustained load.

Check the System event log around each failure for Disk, Ntfs, storahci, or storage-controller timeout events. If the destination is connected through USB or eSATA, try a different cable, port, enclosure, or disk. Some SMR drives can also behave this way after their write cache fills. Testing an internal SATA destination or another enclosure would help isolate the problem.