The ReFS filesystem is commonly used for Virtualization, Backup, and Microsoft Exchange because of its resiliency, real-time tier optimization, faster virtual machine operations, and great scalability. But until recently, ReFS didn’t support data deduplication, which was available on NTFS formatted volumes only. Data deduplication can provide significant savings on storage costs by using block-level technology to reduce the number of space files take up on a disk. Windows Server 2019: Dealing with Performance Problems between Backup Jobs and ReFS.
What is Data Deduplication?
Most likely if you have been around storage or virtualization technologies for any length of time, you have no doubt heard about data deduplication or deduplication for short. This can certainly be used as a buzzword among storage vendors. However, it is an important technical feature of today’s modern storage solutions.
What exactly is Deduplication?
Most of today’s complex storage systems store data in various chunks of data using different technologies. When storing very similar servers, files, and other stored items, it is very probable you will have multiple bits of data that could be identical between a number of servers stored on a volume such as is found in storage backing a Hyper-V virtualized environment.
One common complaint about ReFS has been a lack of support tools in case things do go wrong. Looks like Microsoft also recognized this as one of the blockers to ReFS adoption – because they did add one called ReFSutil.exe to Windows Server 2019, which is designed for triaging corruption and salvaging data from corrupted volumes. I was unable to find much documentation regarding all available options, but for salvaging specifically the command line looks to be refsutil salvage. Unfortunately, looks like this utility only works with Windows Server 2019, simply copying it to Windows Server 2016 didn’t work.
Veeam B&R v11 and Cloning Perfomance:
Currently, Windows ReFS appears to be solid on both Windows Server 2016 and Windows Server 2019 with the latest updates installed, and I no longer recommend using 2016 over 2019, as I did at the beginning of this year for maturity reasons. At this time, both seem to provide comparable levels of stability and performance. And even if we do have a few cases open by Windows Server 2019 users, if anything they actually give me more confidence about ReFS in Windows Server 2019, as Microsoft developers dig through OS dumps looking at ReFS metrics and don’t see any issues or bottlenecks in some of the largest ReFS deployments we know. One of those long-living cases on poor fast cloning performance was finally resolved today actually, and the issue was confirmed not to be related to ReFS. It is already addressed in v11 due to one major architectural change, meanwhile, a simple workaround for Veeam B&R v10 is to ensure your Backup to Tape jobs do not overlap with Synthetic Full schedule of their source jobs. Because whenever both need to read data from the same backup file, the Synthetic Full will come to a crawl for all jobs targeting the volume where such file resides, whether the volume is formatted with ReFS or NTFS.
Dealing with Performance Problems between Backup Jobs and ReFS:
• Ensure Trim is disabled
fsutil behavior set DisableDeleteNotify ReFS 1
• Set RefsEnableLargeWorkingSetTrim = 1
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem Value Name: RefsEnableLargeWorkingSetTrim Value Type: REG_DWORD Value Data: 1
Note: Don’t forget to perform the antivirus exclusions. Hardware: Powerful physical RAID controller (with cache).