ReFS, standing for Resilient FileSystem
is a new filesystem developed by Microsoft.
ReFS will be first used in Windows 8 Server and then probably in Windows Home edition.
In fact, ReFS is designed to eventually replace the popular NTFS filesystem.
Errors associated with ReFS
When Windows cannot access a ReFS volume, it displays the following error message:
How to recover data from ReFS
The first thing you face when dealing with ReFS failure is that CHKDSK tool known to all the Windows users doesn't work with ReFS.
If you launch CHKDSK on a volume formatted to ReFS, you get the following message:
The type of the filesystem is ReFS.|
The ReFS file system does not need to be checked.
The fact that according to the design, ReFS checks and auto-corrects data on its own. So the only way to check ReFS is to try to actually read the file. If there is something wrong with the file or folder, the ReFS driver is trying to correct the damage immediately. If the correction fails, the damaged part is isolated, theoretically, without affecting the remaining "healthy" part.
If you cannot fix the damage by means of the filesystem driver, you need to recover data using ReFS-capable data recovery software - ReclaiMe File Recovery.
ReFS recovery using ReclaiMe
- Download ReclaiMe File Recovery, a tool that can recover ReFS.
- Install the tool as you regularly do with any other software.
- Launch ReclaiMe File Recovery and select a ReFS volume for the analysis.
- Within 3% of scan ReclaiMe File Recovery displays the recovered data.
Check the files and folders and if you are satisfied with the result, please purchase the Standard license key.
- Click the Save button and start copying data; otherwise, wait to see if more data is recovered.
What to expect from ReFS recovery
ReFS filesystem uses the copy-on-write feature.
This means that when it is required to edit a filesystem entry, the ReFS driver doesn't modify the original entry,
but instead it copies the entire entry along with all the required changes to a new location.
Once copying is successfully completed, all the internal filesystem links are modified to point to the new version of entry, not the old one.
This avoids problems with a partial write, a phenomenon when due to power failure only part of the large filesystem structure is written.
A side effect of the copy on write is that old versions of objects are lying all around on disk.
From data recovery point of view, it is a huge plus; the previous versions of objects which are abundant on the disk greatly
increase the chances of successful data recovery.
Even if the latest versions are destroyed, it is still possible that some of the earlier versions of the object will
be good for recovery.
Still have questions?