Error: The device is not ready. Asynchronous read operation failed Failed to upload disk

[AlexComputerGuy]

> I have tryed the mountvol and mountvol /d command, and will update this if it is working.

That did nothing here.

I have send my log files to the support team.

[alanco]

Hi all,

got the same issue since 2 weeks at a Win10 standalone device. Before everything was fine.

Now all partions (EFI, Recovery) running well except OS C:/ .
So excluding is no option.

Don´t know if mountvol can help in that case, I´m not so experienced with that tool.
Already deleted the task and recreated it, no change as long as I include OS C: into the job.

Does anyone has a idea what to do?

[alanco]

PS: when selecting "Show system and hidden partitions" while creating a new job, there are "Operating System" and "OS (C:)". Both have identical size. Backuping "OS (C:)" works but "Operating System" fails. Can someone explain the difference between the two chooses?

Thx

[alanco]

PPS: found a solution for that problem. After disable bitlocker and again enable it (needed several hours to encrypt/decrypt the drive) Veeam accepted "Operating System" as backup source. Also full drive backup now works again.

[Dima P.]

alanco,

Operating system checkbox includes all the needed system partitions to the backup, while selecting volume C adds only the volume content to the backup. With last option you will have all the data available for the volume level restore or file level restore but you wont be able to boot the OS after Bare Metal Recovery due to the lack of the boot partitions.

[ArekP]

I have a Windows 2019 virtual machine with Veeam Agent for Microsoft 4.0.1.2169.
Unfortunately, I had the error all the time:

Error: The device is not ready. Asynchronous read operation failed Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}. Exception from server: The device is not ready. Asynchronous read operation failed Unable to retrieve next block transmission command. Number of already processed blocks: [0]. Failed to download disk.

Deleting 'Recovery Partition' helped. I also moved 'EFI System Partition' to the first position, but I don't know if it matters.
From now on full system backup is performed correctly.

[Dima P.]

Hello Arek,

Thank you for updating this thread. If you notice such behavior again please do not do any modifications with your disk layout and raise a support case: we would love to investigate this issue but need more troubleshooting information. Cheers!

[Sibelius01]

Hello,

I'm new in this Forum. Since some days the VEEAM isn't working anymore. Error: "Das Gerät ist nicht bereit. Asynchronous read operation failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}. Exeption from server:... Unable to retrieve next block transition command. Number of already processed blocks: [0]. Failed to download disk."

I checked Windows 10 (scannow / dism) - all OK. NAS (Synology) is working well. I installed VEEAM free new (with PC cleaning). No change with this error. The VEEAM is starting writing on the NAS (restore point size is > 0), but then it stops --> restore point size = 0 in the end --> Email with the error message.

I running VEEAM free on a parallel SSD - and on this SSD (same Windows version) / same NAS - absolutely no problem.

Thanks a lot (!!!) for your support and sorry if this error is a common problem - but to check a new, big Forum is difficult for a newcomer...!

Best regards

Sibelius

PS: Version of VEEAM is v5.0.0.4301

[Dima P.]

Hello Sibelius01,

I've merged your post to existing thread. Any chance you've opened a support case from Veeam Agent Control Panel and can share the case ID with us? Thanks!

[Sibelius01]

Hallo Dima,

Thanks - seems to be a common error...

Actual case is #04711839.

Thanks for handling my question.

Best regards

Sibelius

[Sibelius01]

Hi, I uninstalled the Antivirus "Bitdefender" - cleaned the PC - no change with this error...

[StevenMeier]

Hi All,

I have a Veeam Support case Open Case # 04703872

I have 2 physical Servers
Both HPE Apollo 4510 Servers running Server 2019.(Version 1809 build 17763.1817)
The Veeam agent Version is 4.0.1.2169

They are Repository Servers and Proxies.
I use the Agent on both boxes just to back up the C: Drive to the other repository Server. In case of loss /corruption etc.
For 2 years they have been working fine.

I do a full backup every wednesday and only run 1 backup per week and keep 4 copies.
Both at the same time, both Servers Get this error message , the only Difference is the Guid of the Disk.


Error: The device is not ready. Asynchronous read operation failed Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}. Exception from server: The device is not ready. Asynchronous read operation failed Unable to retrieve next block transmission command. Number of already processed blocks: [0]. Failed to download disk '1140af5b-d567-46db-9b74-11c85ca1fb25'.

To isolate I modified the Agent job to only

Backup the "C: Drive" and the "efi System partition".

The job runs fine, but because the recovery partition and operating system are not selected it warns that this backup cannot not be used for recovery.(thats a worry)

If I go back to the original Backup job Set up, Which included the "operating System" and "recovery Paritition" the job would fail with the error above.

This job config has been running for 2 years no issues.

SO I have captured all the logs and sent to veeam...but the responses so far have been somewhat lacking.....ie "Fix the disk with the error"
Ok How do I fix the recovery partition as both the Server it Self has no errors or issues.
At A loss as to where best to start as the info given so far by the support team and call is more like its from a play sheet rather than engaging to narrow the focus or point me in right direction.

Help forum folk as I am sure someone has seen this before.,

[Natalia Lupacheva]

Hi Steven,

Moved your post to the existing thread. Please take a look at the discussion above, might help you with the solution. There are advices from those who've faced this issue (for example here).

Thanks!

[Sibelius01]

Hi,

I could solve my problem by deletion of the "Windows" "hidden" partitions (EFI, MSR and Recovery). I have two Windos 10 installations on two separate SSD's (it supports to solve such errors by working from one SSD to repair the Windows on the other SSD and vice versa.... If backup "with OS" is selected then VEEAM selects all hidden partitions (before I deleted these hidden partitions) on both (!) SSD drives and not only on the actual C: drive. I know, it isn't a nice solution - not "state of the art" for Windows 10 on GPT drive, but it works... And could be an hint for others to find the error with a better solution.

Best regards

[StevenMeier]

The problem with this long thread as there are many possible solutions and normal in the thread one solution comes out as the winner....but this one does not seem to have a winner.

I have seen
reg settings
Mount drives
Delete drives...
change the job selections.
Bit locker stuff

From reading there is no consistent real fix and seems very hypothetical and maybe more luck that fact based reasoning. What is Veeam's recommended path or do veeam even have a recommendation for this error and are they any of the suggestions in this post.

I am reluctant to try any of these without a good reason as it could create further issues.

Interested in thoughts on this.

This is not a criticism, I am just worried there seems to be one real answer for this that by default as become the de facto solution.

[Natalia Lupacheva]

Hi Steven,

sometimes you can face issues that can be caused by different reasons - your environment, hardware, some specific configuration, or something else.
That's why we usually recommend opening a Support case when you get some technical issue: Support engineers can analyze your logs and find the solution for your environment.
But sometimes it helps to check the others' solutions in case if someone has the same issue as you've got. And that's why it's a good practice to share your solution if you suppose someone else can also face the same problem.

You don't have to try all the suggested solutions from this thread, but please keep working with support to solve this.

Thanks!

[StevenMeier]

SO my Veeam Support engineer found the most likely cause of the agent backup failing with the error.
The recovery partition after a windows update has "Converted" or "changed" to a RAW format .
I have attached an image. He suggested I convert it .....this is easier said than done .DiskPart Convert is not working/Available to me to do this even though it says it can.
I have tried to find a way to re create the recovery partition and the info in it natively...but no Luck.
Looking for options ideas.
https://ibb.co/Q60YPgn

[Mildur]

A raw disk should be formated, not converted.
If it‘s raw, then the partition is corrupted:

format fs=ntfs quick

We have to find a solution to recreate your recovery partition. I‘l try google for you, because I don‘t know the answer yet

[StevenMeier]

if you look at the image you see it does not have a drive letter , or are you saying from within DiskPArt do the format after selecting the volume ?

[StevenMeier]

I tried this and diskpart failed
"Diskpart has encountered and error: The parameter is incorrect. See system event log for more information"
So it runs the format and gets to 100 and then fails with error.
Thought this was because its "Hidden" tried to remove the attribute...same error.

And to top it off nothing in the system event logs

[Mildur]

You can try to unhide it.
I do not give any guarantee. we're operating on the open heart of Windows. With such manipulation, the OS may no longer boot. The risk is on your site
If you want to be sure, open a support ticket with Microsoft. They can help you on this matter, because it‘s not veeam related.

https://defaultreasoning.com/2009/05/29 ... -diskpart/

[StevenMeier]

very true.....but I have found Veeam Support (2nd level and above) even when its MS issue far better at solving the problem Than MS.

I had an issue open for ages which in the end turned out to be a windows defender issue...could not keep up with the rate of work of the veeam repositories (refs) and would randomly crash and blue screen the box....MS support blamed veeam and veeam 2nd level proved it was windows defender and narrowed it down, we removed windows defender completely and replaced it with crowstrike...no further issues. MS maintained that we should remove Veeam and the OS will work fine......what sort of response is the from MS 2nd level support.(sorry for the raunt).
Our repository Servers are large...apollo 4510's 192 GB of ram 48 cores 60 x 12 TB disks and fibre attached and 2 x 10 GB ethernet...so they are busy boxes.

[StevenMeier]

Hi All,
After not liking the fact that this looked like and MS call would need to be logged.
I asked a workmate to sanity check what I had done (more eyes and brains ...hopefully)
He came up with a work around.

WorkAround by Alastair Sheppard

Using Powershell on the Server

This displays that you have a "Recovery Partition"
(Get-Partition).Where({$_.type -eq "Recovery"})

This displays the attributes of your recovery partition (NOTE: the IsOffline Attribute ) , while its offline the Agent Backups will fail.
(Get-Partition).Where({​$_.type -eq "Recovery"}​) | fl

Use this command to set the IsOffline Attribute to false
(Get-Partition).Where({$_.type -eq "Recovery"})| Set-Partition -IsOffline $False

Run the agent job.....and it runs
Cavets: A Server reboot resets it back to offline.

So what we did to get around this.

We used task scheduler to create a Task that only runs after a server restart and calls the Powershell above.

Every thing is working as before Windows Updates stuffed it.

Thanks to my Workmate AL...who luvs his Powershell (ps if you system does not work after this Blame Al not me)

[Natalia Lupacheva]

Hi Steven,

Thank you for sharing! It's not the obvious solution, so I hope it could help someone else in future.

(ps if you system does not work after this Blame Al not me)

I hope it never happens but thank you for this warning

Thanks!

[ITP-Stan]

Thanks to everyone posting here.
I had the same issue with the latest version of the 4.x agent.
I excluded the Restore volume from the selection.

[ConradGoodman]

I have the same issue with a fresh textbook build of Server 2019 on a Dell PowerEdge R640.

The mountvol mountvol /d fix worked for me, however it doesn't persist a reboot.

Case raised; Case #04917554

[Dima P.]

Conrad,

Please keep working with our support team and let us know how the investigation goes. Thank you!

[Asahi]

Hello,

I am having the same problem.

Backup from Disk 0 is failing.
Disk 0 is partitioned as follows

Code: Select all

[31.01.2023 18:33:03]      Info     <2134>         Disk 0, capacity: 530GB, bus type: fiber channel, read-only state: read-write, pack state: 1
[31.01.2023 18:33:03]      Info     <2134>           Device: embedded, path: \\?\mpio#disk&ven_nec&prod_disk_array&rev_1000#1&7f6ac24&0&3030464a4c39564b4b393130303238313030303037#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}
[31.01.2023 18:33:03]      Info     <2134>           Layout: GPT, disk ID: {x}
[31.01.2023 18:33:03]      Info     <2134>             Partition 0, type ID {a} (Microsoft recovery), ID {a}, offset 1048576, length 449839104
[31.01.2023 18:33:03]      Info     <2134>             Partition 1, type ID {b} (EFI system), ID {b}, offset 450887680, length 99614720
[31.01.2023 18:33:03]      Info     <2134>             Partition 2, type ID {e} (Microsoft reserved space), ID {e}, offset 550502400, length 15728640
[31.01.2023 18:33:03]      Info     <2134>             Partition 3, type ID {c} (basic data), ID {c}, offset 566231040, length 322122547200
[31.01.2023 18:33:03]      Info     <2134>             Partition 4, type ID {d} (basic data), ID {d}, offset 322688778240, length 246392291328

Partition 3 is drive C and Partition 4 is drive D.
The volume level backup of drive D succeeds.
And the file-level backup from drive C also succeeds.

However, the volume level backup of drive C fails.
Even after adding the recovery partition to the registry key to exclude it, the backup still fails.

I have contacted Veeam support but there is no progress at present.

Case # 05848052

Kind Regards,
Asahi,
Climb Inc.

[jimwong233]

I have a Windows 2019 virtual machine with Veeam Agent for Microsoft 4.0.1.2169.
Unfortunately, I had the error all the time:

Error: The device is not ready. Asynchronous read operation failed Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}. Exception from server: The device is not ready. Asynchronous read operation failed Unable to retrieve next block transmission command. Number of already processed blocks: [0]. Failed to download disk.

Deleting 'Recovery Partition' helped. I also moved 'EFI System Partition' to the first position, but I don't know if it matters.
From now on full system backup is performed correctly.

Where to find the 'Recovery Partition' as you mention? is it in the backup proxy?

[DonZoomik]

His this case a few days ago. While investigating, I noticed in event log that VSS snap was deleted during backup due to shadow storage limits that looked very suspicious.
While checking this out via "vssadmin list shadowstorage" - showhow my system partition VSS size limit was 1% - I definitely did not set it myself.
After deleting shadowstorage, the limit resets to default (unlimited?) and backups worked fine again.

The problem is that vssadmin tools has limited options on Client SKU-s. You can edit shadowstorage still via WMI.