Change the size of the iSCSI volume formatted with ReFs and Veem's native enabled dedup

[sandroalves]

Hi,

I have an iSCSI volume presented to Veem's data protection server.

This volume is formatted with ReFS and 64K block according to good practices.

Native dedup is enabled on the JOB.

Is there a problem with the integrity of the repository if I expand that volume?

How: disconnecting Windows iSCSI, expanding to storage, connecting Windows iSCSI and expanding on Windows?

Thanks.

[tsightler]

There's no issue with this. Technically you don't even need to disconnect the iSCSI unless for some reason your storage system requires this. You just resize the device then rescan the devices in Windows and it will detect the new size of the device and show to space free, then resize the volume online. I do it all the time in the lab.

[sandroalves]

Hi,

Great!

Other solutions that work with hash files, if we change the disk, block references are lost.

Thanks.

[sandroalves]

There's no issue with this. Technically you don't even need to disconnect the iSCSI unless for some reason your storage system requires this. You just resize the device then rescan the devices in Windows and it will detect the new size of the device and show to space free, then resize the volume online. I do it all the time in the lab.

Hi,

if i use windows 2019 deduplication for example from the ReFS partition and need to expand, will the data remain integral?

Thanks.

[soncscy]

I think it should be fine. Windows dedup works via a "chunk store" iirc, and this just resides at some location on the volume independent of the size of the volume. I must admit, I'm not 100% certain this is the case, but from my understanding, the chunk store exist independent of the total size, and any change will be accommodated for on the next garbage collection/dedup run from the Dedup service.

Windows won't expand the files until you run Expand-DedupFile