March 3rd, 2018, 21:53
Data residing in a virtual machine can not be recovered this way, you would possibly be able to recover the container, a recovery of the data inside is only possible while being inside the virtualization. I am sorry I could not be of more assistance.
March 4th, 2018, 9:41
March 4th, 2018, 14:35
Filename: Exchange (North Pennsylvan).vhdx
Path: S:\?
Size: 288 GB (309,074,067,456)
State: Unrecoverable
Creation time: 7/3/2013 05:52
Last modification time: 3/3/2018 00:11
Last access time: 7/3/2013 05:52
Comment: File's data could not be found on the disk.
March 4th, 2018, 14:43
March 4th, 2018, 15:13
March 4th, 2018, 18:57
March 4th, 2018, 20:43
rogfanther wrote:You made the clone of the whole drive with GdB, right ?
rogfanther wrote:When trying the recovery, did you enable Deleted Files recovery ?
rogfanther wrote:Also, have you look if GdB didn´t put your file in one of those [Folder$1234] entries ?
The software will not recover the data showing up with 0.
We unfortunately do not offer any automated software solution for this incident.
March 8th, 2018, 18:00
nfi X: >Y:\Drive_X_nfi.txt
March 9th, 2018, 4:18
Did you try R-Studio ?
What's surprising here is that Recuva does give you a size, which is apparently correct (you'd have mentioned it otherwise, wouldn't you ?)
If this was stored on a SSD, with the Trim command enabled as it should be, you're almost certainly SOL, sorry...
March 9th, 2018, 4:59
rogfanther wrote:try with Recuva or R-studio
So far the .vhdx recovered with R-Undelete looks intact! I was able to attach it to a new Virtual Machine and boot it up.abolibibelot wrote:Did you try R-Studio ?
March 9th, 2018, 9:05
If it's more than 4 gb (or was, and I guess an image file could well be) then Windows erases the file cluster adresses on deletion. The data is still on disk but the entry in the MFT no longer points to it.
I think that Recuva has, in the last release or two, changed the way large files are reported. Previously, deleted files over 4 gb in size would be reported as zero bytes, and unrecoverable. Now it appears that the file size is reported, but with the comment that 'File's data could not be found on the disk.'
Although NTFS zaps both the file size and the cluster run info in the $Data attribute in the MFT record, the original file size is still available in the $File_Name attribute (although not necessarily accurate). Perhaps this is where Recuva finds the info.
If the file is under 4gb but in many extents then it may have forced the $Data attribute to become non-resident, i.e. to be held in a second MFT record for the file. In this case NTFS will, on deletion, zap the cluster run info in the MFT extension record, so the file is unrecoverable. It appears that Recuva also reports these files as 'File's data could not be found on the disk.'
I have found, from experiment and from comments elsewhere, that NTFS manages deletion of files larger than 4 gb differently from those smaller than 4 gb. In the smaller files the entry in the MFT is (relatively) simply flagged as deleted, and the dataruns - the fields that hold the address and number of clusters for each extent - are untouched. This is how Recuva can find and recover the file data. In files larger than 4 gb the dataruns are overwritten by NTFS. Although the file size is still available, the addresses of the data are not, and Recuva will show the Data not Found on Disk message. In this case no recovery programme can recover data from information in the MFT.
This also happens in smaller files which are in many extents. If the list of extents is too long to fit into a single MFT record it is placed in a MFT extension record. These too are erased on file deletion, leaving the file data unrecoverable.
March 9th, 2018, 20:46
Powered by phpBB © phpBB Group.