Forum Discussion
ReFS volume appears RAW (version doesn't match expected value) after Windows Update
I solved this by uninstalling KB5009557. The ReFS volume came back working as it should, instead of appearing as RAW.
Update: since even the February 2022 Windows Update bricks ReFS in the same way, and hints from Microsoft are that ReFS 1.x is no longer supported, we copied everything to new disks, upgrading ReFS from 1.2 to 3.4 in the process. Such a (manual) ReFS upgrade should be the solution that everyone needs, allowing to re-enable Windows Update.
stephc_msft So ReFS version 3.1 is not affected by this and the 2022-02 updates can safely be installed, correct?
Microsoftstephc_msft I have a question about the following scenario
A customer had Windows Server 2019 VM attached to a VM controller and was affected by the ReFS RAW issueThe server had 2 ReFS volumes formatted with ReFS 3.1 4k Clustersize
Both were locally attached to a VMware controller of the VM (NVMe controller)
What happened:One of the volume was affected on this machine the other was not affected.
You mentioned removable drives earlier so I wonder in which condition Windows considers SAS, SCSI or NVMe drives as removeable drives.
Thanks for taking the time to elaborate on this scenario.MikeLabatt stephc_msft Stephen can you confirm that the remaining issue for ReFS 1.x is documented in the Windows Update History for affected Windows Server and Windows Clients?
If not, I'd propose including it in Windows Update History and link to a new techcommunity article or KB article explaining the situation and solutions, so briefly what we discussed here.
If affected people with ReFS 1.x have a large amount files / data to copy instead of robocopy they can also leverage other tools. I would recommend Gurusquad GSCopy which is infact more scaleable, around 40% faster and has better reporting, open file support etc.I regularly use this for file server migrations.
If one want to stick with Microsoft Tools I would recommend to create a share on the root folder and use Windows Admin Center Storage Migration Service.
This is an easier process for those not being familiar with robocopy and it thas also good output. One needs to omit the last step to change servernames etc.
WAC SMS would only work if one creates a new machine (VM) with a ReFS 3.1 oder later volume. It is not designed to copy from one volume to another on the same machine.- I'd love to be the lone exception, but from other forums and Reddit discussions it seems I am not alone in having lost a ReFS 1.x volume that was not removable due to 2022 Windows Updates. It seems to me that AM-4566 and LarsKemmann in this thread were not using removable media either. I can understand it if Microsoft can only offer a workaround like "copy the data to a new volume", but not even admitting a problem on such a crucial technology seems a bit odd?
- stephc_msftWindows RE (Recovery OS) can read refs volumes ok
- Thanks for clarification Stephen!
One question aside if a customer uses WinPE or WinRE from Win10/2016/2019/2022 is this one able to read ReFS natively, I am aware it is not for Storage Spaces.
Some still use Windows Backup to backup files this be restored? TY. - stephc_msftAgreed. Note however that refs v1 does not get auto updated to v3
That only happens on the v3.x versions ie 3.1>3.4->3.7
Hence why 'stuck' with older refs v1 volumes in some cases
ANother option is to to boot the 'Recovery OS' or boot from an Install iso /usb and select reapir. That will be a base OS version (without patches) and can access the data on refsv1 and copy it off.
Reminder - all this hassle only affects drives that are removable or have charactereistics of removable (like on vmware).
With the exception of Mikes original issue which is a weird and unexplained one. - If you data is still RAW after installing all updates and uninstalling the defective one first, then it is very likely that your ReFS volume has been formatted pre Windows Server 2016 and is not yet on ReFS version 3.x
ReFS version gets upgraded with OS Inplace upgrades when the volume remains attached (this cannot be reverted)
https://gist.github.com/0xbadfca11/da0598e47dd643d933dc
In this case have an old Server 2012 R2 Update 1 without this bugged patch and mount this volume to this server to gain access to your data with earlier REFS version.
If you then execute and inplace upgrade from 2012 R2 to 2019 this ReFS volume would be upgraded to the specific version Microsoft supports and the patch would work with.
Hope this helps. - All these tools scan drives for signatures and include deleted files and handle moved files extremely poorly. This turned my 4TB into 9.5TB one of the tools required. I had an intact volume and didn't need a scan, only for them to read the directory structure from v1.2. R-Studio was one of the worst - they couldn't even get a list of files working and their support had no idea. Other tools didn't even respond to support request, even after I paid for their tools. Microsoft should ether document ReFS publicly or provide much better set of recovery tools for these kind of things.
- Thanks. Tried this last week and it was painful to go back - Windows Updates does a good job only within a couple of weeks or so and going back to Dec 31st, 2021 hung my whole system and I had to go through system recovery to pick a more recent configuration.
Today I tried a different approach and restored from an old bare metal backup I had to a different drive, which took me to Win10 1803, then it updated to 20H2, where the problem still persisted and there was no KB's to uninstall. Much to my surprise, when I tried to uninstall that version, it didn't take me back to 1803, but rather dropped into 2004, unfortunately still with the problem, but then two KB's appeared - KB5010342 and KB5007401. I uninstalled them both and ReFS v1.2 got mounted. It was literally the last this I could try. No idea which one.
Can't believe Microsoft would do this to their users. They should have warned that support for ReFS v1.2 will be dropped every time it mounted and they had years for that. not a squeak. Moreover, why not release `refsutil` that can read v1.2, so people can run `refsutil salvage` against it to get their data back, even if it cannot be mounted. I wasted hundreds of dollars on recovery tools and efforts. - stephc_msft
Agreed. Try removing Jan22 update, and any later updates, and confirm if the volumes are then accessable.
If they are still showing RAW then it is likely you have some other real corruption issues .
There are some utilities (including refsutil.exe from later OS versions) and 3rd party tools like www.r-studio.com that understand refs and can attempt to scan and copy out any data it can find. - AM-4566 you could try and go to Windows Update/Update history and uninstall any updates from January 2022 and later, and then pause updates to continue working on the issue. Then RoboCopy (or similar) the data to a new volume, which should be NTFS or a newer version of ReFS.
stephc_msft I lost two ReFS v1.2 volumes with 4TB of irreplaceable data on each attached to a Win10 Pro machine. These volumes were created when it was allowed and I kept them because there was no indicator of any kind in all these years that this is not a supported configuration. Neither set of drives is removable. None of the KB's mentioned in this thread here seem to exist on Win10 Pro. Can you please advise what can be uninstalled to recover the data?
Any help will be appreciated.
- The issue still persists for some, and it will reappear in the future whenever old volumes are mounted. This is quite annoying, as ReFS was supposed to be the best long-term preservation solution to contrast bitrot, etc.
This thread started with my post for a scenario with Windows Server 2019 and a ReFS 1.2 volume (on storage space, not removable). This has not been solved. It was not fixed with the January hotfix, nor in February (tried that, had to uninstall updates again). The "solution" was to copy the data to a new ReFS volume.
stephc_msft remember we had a direct exchange, also using your diagnostic tool to confirm that the volume was not flagged as removable.
By now, everyone who was affected probably already copied their data from ReFS 1.x to a newer version. Still, as many could be affected in the future they could show a helpful error message rather than volumes turning RAW, which also misleads many into thinking that the data has been lost forever (already happened this year, as seen on various other forums).
