Data Recovery Weekly

In forensics, turns out it is important to know timestamps reliably . In olden filesystems, like NTFS and FAT, you either have a timestamp (if the record is intact) or you don't (if the record is overwritten). Now, CoW filesystems like ReFS and BTRFS, produce a whole lot of different versions of metadata records - do you want a generation 3 timestamp or generation 8 timestamp? Considering that metadata generation numbers (as used for timestamps) do not necessarily match file pointer generation data, there seems to be no way to get forensically reliable timestamps on modern filesystems. This is probably something worth looking into.

In FAT filesystem, structures describing directories are spread over the area of data and therefore mixed with the contents of files. If a directory is deleted, easily accessible information about its location is no longer available. In this case it is necessary to do a full scan of the data area to be sure that all the directories are found. Thus, data recovery time on FAT is proportional to the size of the disk and is mainly determined by the time needed to read the entire disk. NTFS stores metadata densely at more or less known location; when recovering data from an NTFS volume, data recovery software can just look at this small area rather than scan the entire disk. Data recovery time on NTFS is mainly limited by computing resources required to recreate the file table. The total time doesn't depend on the disk capacity but it depends on the number of files actually stored on the disk. ReFS again spreads its metadata over the disk, mixing it with the content of files t...

On NTFS, the process of file deletion is not limited by only the work of the file system driver such as zero filling pointers in MFT . Physical or virtual store takes part in this process as well. The filesystem driver sends a TRIM command to the store driver informing a data storage device that the blocks containing file data are not used any longer and therefore can be erased. Depending on the type of underlying device, TRIM can lead to different results: for a volume located on a regular hard drive, TRIM has no effect; for a volume created in Storage Spaces, TRIM leads to unexpected consequences depending on how the files are located in relation to 256 MB slabs of Storage Spaces; for an SSD, exactly for which the TRIM command was introduced, the blocks that are no longer in use are erased immediately. However, it should be noted that NTFS never frees blocks with metadata and so the NTFS filesystem driver never sends the TRIM command to erase these blocks. This NT...

We probably got the first real-life (as in this is not a drill ) data recovery involving ReFS filesystem. There are still some issues to work out as far as speed is concerned, but ReclaiMe did remarkably well. Remember that the filesystem itself did not reach a production status yet, it is still a release candidate.

ReFS build 8400 still has its cluster size locked at 64KB.

We now have ReFS recovery capability in our ReclaiMe data recovery software (www.ReclaiMe.com). Obviously, this is not the final version, because the filesystem is not officially released yet. However, ReclaiMe works farily well against the current Windows 8 Server beta build.

ReFS 1. Has more disk space overhead, both per-filesystem and per-file, than probably any other filesystem in existence. 2. Does not have a CHKDSK, which they might have to correct later. 3. Looks like it cannot achieve 32767 Unicode characters in file name, stopping short by ten characters or so; however we still did not test that. 4. Has several single points of failure, regardless of what they might say.

At the moment, the most available information about ReFS looks like our new filesystem will be better than our old one, and it will contain this-and-that cool features . At the moment, we still don't know if we are going to get a more recoverable or less recoverable filesystem. Most if not all of the improvements in ReFS (compared to NTFS) are aimed at better resistance to imperfect hardware (which does not follow fail-stop model), and better handling of large files and/or files in large numbers. The recoverability depends significantly on implementation details. For example, B-Tree is fast, but often happens to be a highly vulnerable failure point, difficult to rebuild if lost. Also, steps to improve fault-prevention and ensure continuous operation often degrade the recovery capability. Once it comes to recovery, you are often better with the filesystem which crashes earlier and easier. To put it the other way round, the filesystems that crash quickly tend to be easily recoverable...