Recover RAW SSD.

[jmac150]

I've been trying to recover a windows 10 C: drive using Ubuntu 20.04.4 and RecuperaBit. Drive became RAW for no apparent reason. I created a disk image using dd (sudo dd if=/dev/sdb of="/media/jmac150/New Volume/image.dd" bs=4K conv=noerror,sync status=progress) and ran RecuperaBit against it. RecuperaBit found virtually nothing CSV file attached: list.csv To check, I ran photorec against the image and it found around 150Gb of files. So, files are there but not really useable. What am I doing wrong with RecuperaBit? Command I ran was: sudo python3 /home/jmac150/Desktop/RecuperaBit-1.1.6/main.py "/media/jmac150/New Volume/image.dd" -o "/media/jmac150/New Volume/recuperabit_output"

Thanks. PS I am a Ubuntu newbie!

[Lazza]

I ran photorec against the image and it found around 150Gb of files

You are comparing apples and oranges: PhotoRec does file carving, it will not read any filesystem structure and will not recover file names or paths, nor it will work in case of fragmentation. Conversely, RecuperaBit reads the MFT or parts of it and reconstructs the directory tree. For any file in the tree it can read where the data is, even if the files are fragmented.

It could be that parts of the MFT are damaged or have been overwritten. It could also be that you are checking the CSV file list on the wrong partition number.

[jmac150]

Thanks for response. Can you point me in the right direction for info. on which is the correct partition to analyse?

[Lazza]

As a rule of thumb, it is usually the one with the largest number of files among those in the recoverable list. But you should also check out other partitions with a large number of files so you can verify if you found what you are looking for.

[jmac150]

I have obviously misunderstood Recuperabit. I thought that it worked from the bottom up, reconnecting file fragments until whole file/directory was recovered. I thought it didn't need MFT?

[jmac150]

Hi, I have run Recuperabit against disk image. "Recoverable" finds plenty of partitions some of which have 100k+ files in them but file names are mostly meaningless. Would you advise? Thanks

[Lazza]

it worked from the bottom up, reconnecting file fragments until whole file/directory was recovered

This is slighlty incorrect, it rebuilds the directory tree from the bottom up by using individual records (or you could say fragments) of the Master File Table. When the directory tree is rebuilt, that part is done. Then the boundaries of the partition must be identified in order to recover file contents.

This is because MFT records include runlists and they are relative to the start of the file system.

More information can be found here: https://www.youtube.com/watch?v=AMYaagS6KF4

plenty of partitions some of which have 100k+ files

This is not entirely uncommon, especially for drives that were fragmented.You can try checking them one by one in order to find where the files are. Hopefully the data has not been pruned by the usual TRIM procedures that run on SSDs.

[jmac150]

Hi Not sure why you closed this as I still have some queries (I appreciate that your time is precious and that you are doing this out of the goodness of your heart!). As I said, "Recoverable" finds an awful lot of partitions (See attached screenshot and there are pages and pages of partitions.) but even the ones with thousands of files do not contain anything I am looking for. This disk went to RAW for no apparent reason and has been untouched since so nothing should have been overwritten or trimmed. Is the only answer to trawl through all these partitions to try to find my data? Thanks for your help.

[Lazza]

If you don't find the data, maybe it is not recoverable or maybe the program is not the right tool for your case. You can surely compare it to other solutions, and you could get better results with other software (it happens).

You could also try and merge those two large partitions with the same offset, keeping in mind this is an experimental feature and it should be done only if they are really two parts of the same fragmented MFT (so file record identifiers do not overlap).

Personally I would not have made a copy of a potentially failing drive with dd, skipping entire blocks of 4K bytes when it encounters an error, I'd rather use ddrescue, but this is just a preference.

[jmac150]

Hi thanks for response. I used GNU ddrescue to copy the drive, as I understood it was better than dd_rescue. How can I tell if the two large partitions are part of the same MFT and what do you mean by "same offset"? Thanks

[Lazza]

I mean those with the same offset value, for instance most of those seen in your screenshot have an offset of 206848 sectors.