Hi @KEV-IT !  I went right to our SME about this for more information.  What we have around Hyper-V VM folder-level compression seems to be around where the VM is stored being compressed and NOT within the VM having folders compressed. However, they can restore the VHD file out of place and attach it to the VM they plan on restoring it to in order to manually pull the files over for right now.

I can confirm and get to you by EOD Thursday.

Thanks!

Hi Mike, thanks for your reply. Ah okay thanks for the clearification. Yes I´ll ask them if they have enough space to do so in this case. However would be intersting to know anyway what caused the issue for future restore.

Thanks!

Hi Mike,

the customer agreed to the workaround. However we are interested if this was a “one-time-problem” or reproducable for this and other systems. Should I open a case for this?

Kind regards

Hi @Mike Struening 

did you managed to find out, if restoring files inside a VM which are compressed by Windows-OS are restorable/supported using “Restoring Guest Files and Folders for Hyper-V”?

Kind regards

Hi @Mike Struening 

did you managed to find out, if restoring files inside a VM which are compressed by Windows-OS are restorable/supported using “Restoring Guest Files and Folders for Hyper-V”?

Mike is no longer with us - but I’ll try see if I can get info for you. Do you know if you have granular recovery (aka metadata collection) enabled on the subclient? If yes it means that we try to create a map of the files on the NTFS file system and restore them by being file system aware. If no, it means we simply mount the volume to a windows machine and ‘copy’ the files out of the backup - no need to understand all the weird and wonderful NTFS quirks as the OS takes care of it all.

So double check that option, and if enabled, try disable it and see how you go. Restores will take slightly longer on the browse, but should be must faster overall.