Windows Server Backup fails with "semaphore timeout" (0x8004245f) or unknown error"
Windows Server Backup fails with "semaphore timeout" (0x8004245f) I'm using Windows Server 2022. At the beginning, full backups were no problem. Now, the first backup attempt fails with "Unknown error (0x8004245f)" / "The semaphore timeout period has…
Windows Server Backup fails with "semaphore timeout" (0x8004245f) I'm using Windows Server 2022. At the beginning, full backups were no problem. Now, the first backup attempt fails with "Unknown error (0x8004245f)" / "The semaphore timeout period has expired." After it fails, if I run the backup again, it completes without any issues. But if I try to run another backup right after that success, it fails again. If I try to back up multiple drives, or do a full server backup, it fails. It only succeeds if I back up one drive at a time and even then, only after a failed attempt in between. I've restarted the server, and vssadmin list writers always shows everything stable. I've also tried backing up to both an external drive and a shared folder same issue either way. Does any one has the same issue?
已收录讨论
Why use Windows server backup when Veeam free agent exists?
One would presume that if server. It’s for business use, Veeam agent is not free for commercial use, nor do you have any options for second and or third copies of data because it’s all locked behind paid versions.
When did they amend the T's&C's? It was fine for business and enterprise use the last time I checked.
👀 I've been getting this same error, but on Win11 client (23H2), when running Windows Sandbox. This started after the July CU. Restored from backup, Sandbox works. I'll see with August.
0x8004245f (semaphore timeout expired) isn't really a VSS problem, which is why vssadmin list writers looks clean - it's the storage transport timing out under sustained I/O, and the tell is exactly what you described: single drive works, full/multi-drive fails, and a retry succeeds because the disk had a moment to settle. Check the System event log for disk/Ntfs/storahci timeout events around each failure - if the target is a USB or eSATA external, that enclosure/cable is the usual culprit, and an SMR drive will do the same thing once its cache fills mid-backup. Move the target to an internal SATA disk or a different enclosure and the intermittency almost always disappears.
Another thing to check is the number of shadow copies, I'm sure I've had similar errors before and in the end we tracked it down to our EDR tool keeping an excessive amount of shadow copies as part of its anti-ransomware feature.
What's the backup destination you are backing up to?