Restore to HPE VME fails when source backup uses 8 MB block size (assertion failed)

[marco.mosca]

Sharing this here as well as via support (Case #08187451), since it looks like a gap in the VME restore path that other people are likely to hit.

Environment:
VBR: 13.1.0.411
Veeam Plug-in for HPE Morpheus VM Essentials: 13.2.0.160
HPE Morpheus VM Essentials: 9.0.0
Source backups: VMware vSphere VMs, Direct-to-Object on Cloudian HyperStore, immutability enabled
Storage Optimization on the source job: 8 MB

Symptom:
Restore Entire VM → HPE Morpheus VM Essentials fails:
Failed to perform restore. Assertion failed: The required buffer size is larger than the available one

Reproducible on multiple VMs from the same job.

What I found:

The source job uses an 8 MB block size, set because Cloudian's Veeam integration guide recommends 8 MB for their platform (4 MB is allowed but not recommended by them). As you know, 8 MB is only selectable after setting UIShowLegacyBlockSize (REG_DWORD = 1) on the backup server.

Controlled test: I created a temporary job for the same workload with Storage Optimization set to 4 MB, ran a backup, and restored it to the same VME target. It completed successfully. Block size is the only variable.

One more data point that I think is the interesting one: on the same backup server, with the registry key present, the 8 MB option is not offered for backup jobs targeting VME workloads, while it is still offered for VMware vSphere jobs. So the restriction appears to be known and already enforced on the backup side — it just isn't enforced or validated on the restore side when the source is a VMware backup.

Why I think this deserves attention beyond a validation fix

An explicit pre-flight error instead of an internal assertion would obviously be an improvement, but it wouldn't solve the actual problem.

13.1 added automatic VirtIO driver injection for restoring VMware backups directly to VME, which effectively makes VBR the migration and long-term recoverability path for people moving off vSphere. In that scenario the limitation can't be worked around after the fact:

• Changing block size requires a new active full and breaks the chain.

• It does nothing for existing GFS restore points, which stay at 8 MB for their full retention — often years, on immutable object storage.

So following the object storage vendor's own sizing guidance quietly makes years of archived restore points non-restorable to the platform you're migrating to. For anyone running D2O with immutability and long GFS retention, that's a recoverability problem rather than a tuning preference.

Questions

• Can someone confirm 8 MB source block size is unsupported for restore to VME?

• Is there any plan to support it, or is 4 MB the hard ceiling for this data path?

• Is there a supported workaround for restoring existing 8 MB chains to VME? Disk export and manual import presumably loses the VirtIO injection — is that correct?

• Could this at least be documented as a known limitation in the meantime?

Best regards
Marco

[cody.ault]

Thank you for the information. I'll check internally with our QA team and try to get you an answer.