Came across a new error a bit ago within the Veeam Agent and I’m sharing this for my future self (and anyone else).  If all of the actions I performed took care of the issue, or if it it was just a single item, but here’s what I had to do for the below errors.

The Errors

10/18/2023 1:35:22 AM :: Data Partition (F:) (604.9 GB) 342.2 GB read at 69 MB/s
10/18/2023 3:00:25 AM :: Error: The device is not ready. Failed to schedule asynchronous read operation Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}. Exception from server: The device is not ready. Unable to retrieve next block transmission command. Number of already processed blocks: o1402697]. Failed to download disk '0f9d11e0-8171-459b-819c-ebf55d31c45c'

The Actions/Resolution

In my case, researching this error indicated there was an issue with the volume, possibly with a disk table not matching the actual size or something along those lines.  It was indicated that I should try shrinking the volume.  There was supposed to be a calculation of how much to decrease it but I wasn’t sure of the amount to decrease by so I shrank it by about 1GB or so.  Didn’t matter, it didn’t work. 

During more research, a different error indicated that increasing the disk size may assist, so I added 5GB to the VMDK and then expanded the volume.  Still no dice.  I also checked the vss writers (vssadmin list writers) but all checked out okay.

Next up, I read something indicating there could be an issue with shadow copies.  I registered the VSS files (granted, this article applies to Windows 2003 and not all dll’s were available for registering).  I also rebooted the system and found that Windows updates were pending.  Once the updates were applie, tried again, no dice.

Next up I checked to make sure that there weren’t any shadows copies (vssadmin list shadows).  Turns out there were a couple.  So I tried to delete them (vssadmin delete shadows /All) but I received an error that I couldn’t delete them because they were outside of my context.  A quick google search yielded that I can still delete those by decreasing the allocated space for shadow copies to the minimum so that they shadows are deleted, and then reincreasing them them to unlimited (unbounded) with the below commands.

vssadmin resize shadowstorage /for=F: /on=F: /maxsize=401MB

vssadmin resize shadowstorage /for=F: /on=F: /maxsize=unbounded

Still no dice.  So I opened a case with Support.  Support advised to gather logs, and also wanted to make sure that the shadow storage space was set to 20% of the free disk space or unbounded.  I advised as such, but I went back and check and it turned out the space for F: was set at 320MB.  Not exactly sure what happened there as I know I ran the command, but I reset it to unlimited.

And success!

I think it may have been a combination of a couple items - I believe the shadows that I couldn’t delete and the limited space for shadow copies was preventing a good shadow from being created and preventing the backups from running.  Hope this helps someone else out as well.