ReFS - confused

[aschepers]

Hi all,

I'm struggling to understand the things I should do to get a proper ReFS backupjob.

I have a physical Veeam server (Windows 2016) with a 16TB ReFS volume. This resides on a HP MSA1040 SAN via FibreChannel. I created the volume, formatted with 64kb blocks and Veeam says all is well. Also the fsutil checks to see if the ReFS volume ticks all the right boxes is OK.

I'm struggling to find any good best practices as how to setup proper backupjobs to this repository. So far, by reading blogs and technical documentation, I have deduced the following options to be "best practice":

Backup tab:
Incremental backup mode with the option "Create synthetic full backups periodically" ENABLED.
Active Full DISABLED

Maintenance tab:
Perform health checks ENABLED (as extra check on top of Microsoft's own ReFS checks)

Storage tab:
Enable inline data deduplication NOT SURE
Compression NOT SURE
Storage optimization LAN Target

Can anyone tell me if these options are right, if not why not and what options I should use in the Storage tab? Or redirect me to some good documentation about this?

Thanks in advance!

[dellock6]

Hi,
there are no specific parameters ti leverage ReFS, you can keep inline dedupe enabled and choose the compression level you want, since compression impacts proxy cpu performance and thus processing time, not repository performance, even if higher compression may give you a bit more space savings, but I'd honestly keep the default value, which is a good balance between space and processing effort. Same goes for storage optimization.

Since ReFS also leverages blockclone, indeed weekly synthetic fulls are good, but forever forward incremental is even better: because the weekly full is just a virtual clone created using the existing blocks in the filesystem, and only metadata are updated, there's really no need to create it, other than having a break in the chain.

[jayscarff]

Hi,

How much data is getting backed up ? there is a forum on Refs issues so be aware that there are users who have had issues with Refs versions!

[Mike Resseler]

There are indeed ReFS issues with larger volumes (veeam-backup-replication-f2/refs-4k-hor ... 40629.html). We expect the Microsoft fix for this in February. (I believe manual in February, with CU in March) that should fix all of these issues. As far as I am aware that fix is already in the 1709 version of Windows Server.

Cheers
Mike

[aschepers]

Hi,
there are no specific parameters ti leverage ReFS, you can keep inline dedupe enabled and choose the compression level you want, since compression impacts proxy cpu performance and thus processing time, not repository performance, even if higher compression may give you a bit more space savings, but I'd honestly keep the default value, which is a good balance between space and processing effort. Same goes for storage optimization.

Since ReFS also leverages blockclone, indeed weekly synthetic fulls are good, but forever forward incremental is even better: because the weekly full is just a virtual clone created using the existing blocks in the filesystem, and only metadata are updated, there's really no need to create it, other than having a break in the chain.

Thanks. So I should just uncheck the "Create synthetic full backups periodically" option, right?

[driley]

Luca,
Would the ReFS synthetic full provide any benefit in the case of a full VM or entire volume restore?
Thanks,
Dennis

[Mike Resseler]

Hi Dennis,

Not really. There are 2 ReFS block cloning benefits.
1. The creation of a synthetic full is much faster because there is limited IO. Instead of creating a whole new file (with the consequent reads and writes) ReFS simply uses metadata to create pointers to the corresponding blocks.
2. Because it uses pointers, it will also avoid saving that data twice so you will have space gaining's. Note that it is not deduplication but it does save space

Hope it helps
Mike

[Mike Resseler]

PS: Welcome to the forums Dennis! I did remove your duplicate post. From now on you can post without any delay. We only need to approve the first post to avoid spam and even worse messages

Cheers
Mike