Environment:
- Veeam Backup & Replication 13.0.2.29 (Premium, evaluation)
- Backup source: Veeam Agent backup (Windows) of a file server, ~16TB data disk (D:)
- Repository: QNAP NAS (TS-433) via SMB, share \\192.168.0.253\Veeam_Repo
- Original restore target: Hyper-V VM (SRV-FS01) hosted on physical host SRV-APP01
- Backup type in console: shows as "Disk (Imported)"
Issue:
Volume Restore (Restoring FILES D:) consistently fails partway through with:
"An unexpected network error occurred. Asynchronous request operation has failed.
[requestsize = X] [offset = Y] Unable to retrieve next block transmission command.
Number of already processed blocks: [N]. Failed to download disk 'Volume ...'"
Troubleshooting so far:
1. Initial attempts failed almost immediately (~10 min) with
"Failed to use DB:GetRepository in restore mode (UnauthorizedAccessException)"
— traced this to using the VM being restored (SRV-FS01) as its own Windows mount
server (circular dependency). Fixed by adding the physical Hyper-V host (SRV-APP01)
as a new mount server instead.
2. After that fix, restore progressed much further before failing:
- Attempt 2: failed after ~8:44 min, 13,331 blocks processed
- Attempt 3: failed after ~1:05:45, 96,551 blocks processed
Same error signature both times, just further along.
3. Ruled out:
- RBAC/permissions in Veeam (account has Backup Administrator role)
- Share/NTFS permissions on QNAP (Read/Write confirmed for the service account)
- Quota on QNAP (disabled)
- Malware Remover on QNAP (scheduled weekly, doesn't overlap with failure times)
- MTU/Jumbo Frames (both sides at standard 1500/1514, consistent)
- Checksum Offload on the Hyper-V host NIC (already disabled as a test)
4. Currently suspecting either:
- The data disk (Dados.vhdx) being Dynamic rather than Fixed VHDX, causing
progressive I/O overhead/latency during long sustained writes
- QNAP-side SMB session duration limits (not idle timeout, since transfers
were active throughout)
- Physical network/switch intermittent packet loss under sustained load
Questions for the community:
- Has anyone seen this exact "Unable to retrieve next block transmission command"
error correlate with Dynamic VHDX destination disks during large Volume Restores?
- Are there known SMB/QNAP session duration settings (separate from idle timeout)
that could cause a hard cutoff around the 1-hour mark on very large transfers?
- Any recommended Veeam-side timeout/retry settings for large (10TB+) Volume Restores
over SMB repositories that could help ride out transient network issues?
Happy to share full logs (Svc.VeeamBackup.log excerpts) if helpful.