Building ReFS repository: supported configurations and limitations

[dcampregher]

Hello Gostev!

Is there limmitations about the disk type to build the ReFS volume ? For example: I need to build a repositor with 20TB inside a VM, what disk type can i use ( 01 Basic GPT, many Basic GPB Spanned/Striped, Storage Spaces ...... )

Thanks!

[Mike Resseler]

Hi Diogo,

Not really. You need to choose your scenario (Storage Spaces Direct, Storage Spaces or Basic disks) which have differences. The deployment types can be found here: https://docs.microsoft.com/en-us/window ... s-overview. Based on that selection, you can review topics on the specific deployments. But since you are deploying it in a VM, it will probably be as a backup target and not as storage spaces direct or storage spaces. That will not give you resiliency.

Hope it helps
Mike

[dcampregher]

Hello Mike!

My big question is about how can i build the volumes to Support the ReFS +FastClone. The environment that i have to configure is a old FC SAN Storage with 40TB, i need build a repository server inside a Hyper-V 2016 VM with 20TB of space and format it with ReFS to use the fast clone.

So, how is the supported way to deliver this 20TB inside the VM to use the ReFS and Fast Clone ? At the Veeam and Microsoft perspective.

I can create a 20TB LUN in the storage and presente to the Hyper-V to create a VHDX and after create a Basic GPT disk and after format with 64KReFS, this is the more simple way but, the old FC SAN could have performance problems with a BIG LUN beacuse it have some years ( 08 ) and in this age in the past the BIG LUNs aren't recommended by the vendor. Understand my big question ?

[Gostev]

Hi Diogo,

I've split your topic not to derail the existing one, which was supposed to be used for sharing ReFS bugs and issues. Because of that, there are many people subscribed to one. Luckily, it has been super quiet in the past months - let's keep it this way

First and foremost, make sure your SAN is on Microsoft HCL - otherwise, you will not be supported. ReFS is very sensitive to hardware, particularly it requires certified RAID controllers with BBWC. Otherwise, you may one day lose the entire ReFS volume with all data on it (ReFS is quite sensitive to data loss during writes).

Answering your main question - in general, all these extra abstactions layers (Hyper-V, VHDX) are bad for reliability. If iSCSI is not possible, then the best approach is always to mount FC LUNs directly to the physical backup server.

Thanks!

[dcampregher]

Gostev! No worries, all right.

About the supported configuration, the major point is the way in wich the LUNs are configured inside the operating system of the backup repositor server.

If the LUNs will be presented directly to backup server across VMDK or VHDX the question is, if the ReFS can be configured with dynamic disks, storage spaces or only with basic GPT/MBR disks.

Thank you so much.

[Gostev]

In general, there are no limitations on supported configurations, it's just the matter of reliability - and extra layers reducing one. For example, most of the experienced IT folks will recommend that you stay away from dynamic disks as far as possible

[nmdange]

VHDX has a size limit of 64TB, if your repository won't grow beyond this, then you can just stick with a single VHDX file. Agree with Gostev, no dymamic disks. If you think you might grow beyond 64TB, then multiple VHDX files in a simple storage spaces pool will work fine. I have a repository set up this way without any issues.