Hyper-V deduped VHDX

[Progenitor]

Hello Backup Experts,

I have some questions about backup & restore of deduplicated VHDX. First, a few information about the running infrastructure:

We are operating a Windows Server 2012 R2 as Storage Server, providing an iSCSI volume to our Hyper-V Cluster. This volume has enabled the Server 2012 deduplication feature for the VHDX.

First question: Is it recommended to turn of Backup Compression in this scenario? I have noticed, that with setting compression to "optimal", backup time increases significant.

Second question: How is a full VM restore handled, as VHDX files are deduped on storage level?

Thank you in advance.

Kind regards
Progenitor

[foggy]

Sascha, just to make sure I understand your setup right, are you going to run live production VMs from a deduplicated volume?

[nmdange]

Any particular reason you are using iSCSI and not SMB 3 as your storage protocol?

[Progenitor]

Sorry for the late response.

@foggy: Yes. VHDX Files are provided to the Hyper-V Cluster on the iscsi volume that has the windows deduplication feature enabled.

@nmdanage: Yes. The techs, that have setup the storage server are "old school" boys, which means they only have experience with traditional storage scenarios. Since SMB3.0 has been introduced to Server 2012, i can only assume they have no experience with it regarding the improvements made with SMB 3.0+.

[foggy]

Running production VMs from a deduplicated volume is not the best practice from performance perspective. Anyway, this doesn't actually affect job settings, since data are compressed after being re-hydrated and retrieved from the production datastore and then are stored compressed in the backup repository. Longer backup times with compression enabled are expected due to the time required to compress data. What bottleneck stats do your jobs report?

As to your second question, this is also transparent to Veeam B&R. VM disks are placed on the target volume "as is" and then (in your case) deduplicated according to the volume deduplication settings.

[Progenitor]

Thanks for your assessment.

The indicated primary bottlenet has been the source, both pre and post enabling deduplication. The spinning disks of the storage server are utterly slow, but the running VMs in their usual workload don't face a huge negative impact. Their IOpS are pretty low.