This repository has been archived by the owner on Apr 20, 2022. It is now read-only.
Looking for help recovering the data off of the HD portion of a malfunctioning Fusion Drive. #15
Assignees
Labels
Comments
Have you tried afro for your case? Which issues occurred? |
|
Thank you for answering so quickly.
It seems to me that, when extracting data from drives that are, often enough, multiple terabytes in size, being able to chose where to put all of that recovered data is a necessity. As I said, perhaps number 4 is a dumb question because, to a programmer or CS engineer, the answer is so basic and obvious, it doesn't rate mentioning but, for me, I'm totally baffled. So, I just decided to run Afro on It's been running for about 30 minutes now, getting a lot of errors: There are about forty more 'body' errors before what is shown here, I didn't include them. The last error here is actually the last one, so far, and has only come up the once. Of course, at this point I have zero idea what it's really doing, how long it's going to take and where it will put the extracted files—if it actually extracts any. ¯\ _ (ツ) _ /¯ The working light on the external is still flashing away, so I'll let it run and check back on it later, unless you tell me that it's a waste of time. Thanks again for your time and efforts on this matter. |
|
afro extracts the files to the current folder. For |
|
Yeah, I kind of thought it would be that way but… Thanks again, for replying. I'm really not sure what I'm doing wrong here. |
|
True, my bad. I try to change the behavior in #16 |
|
Should be working now. |
|
Oh wow, that's awesome. Thank you very much. That fixed it. So, I ran Afro overnight…
…and it returned zero files. [sad trombone.wav] But, on the plus side, this bodyfile I can figure out quite easily:
That's it. The entire contents of disk0.dmg.carve_apsb.bodyfile. I'm running it again now with the nxsb carving method but I really have no idea what the differences are. As before, I'm getting a lot of these messages: With some of these: and the ever-present:
Which is always the last message it spits out before not printing any more messages (but, according to Activity Monitor, keeps on running and reading data at about 110MB/sec). No idea at all what they mean. I guess if nxsb doesn't work, there's always nodes. Mid-Comment–Edit: I stopped the nxsb run and am running with Thanks again for your time and efforts on this, I really appreciate the help. |
|
Unfortunately afro does not cover all variants/versions of APFS (and fusion drives have most like some special elements) and I do not have much time to improve it currently.
|
|
Totally understandable. Additionally, there is the factor that the HD is only the surviving part of a Fusion Drive. I have no idea what kind of a mess was left behind when the SSD died. At this point, it's still motoring away. Nothing new to report. When I look at Activity Monitor, it says that the python process has read ~1.05 TB of data but written 0. I can also look at the recovery folder and, yes, it is still empty. Should Afro be recovering on the go, or does it read everything and then recover? If it's the former, then this run will also be unsuccessful. Thanks for your help. |
|
Hmmmm, it finished with this error. The permission error makes me think that I should have run it as The bodyfile is 41.3 MB but, as I mentioned in my first post, I have no idea how to read it. an All of those files look like they are used by the system and not what I would consider "my files", if you know what I mean. But, having Afro return something seems like progress, though. In the end, it didn't take that long to run, I'm going to run Afro again as |
|
Pretty much the same result as before. That's a bit of a bummer because I'm starting to run out of options to try. This bodyfile is also 41.3 MB in size, I doubt that's a coincidence. The extracted folder is about 2.24 GB in size and two files, "com_apple_MobileAsset_DictionaryServices_dictionaryOSX.cpio" and "com_apple_MobileAsset_Font5.cpio" are about 1 GB each so other the other files are obviously all small. A few image files were recovered, Hockey.tif, Tennis.png, Soccer.png and so on. They are, I think, some of the standard Mac OS profile icons. It is not possible to view them with Quicklook nor open them—Preview states that they've been damaged. Some fonts were also found, they can also not be opened or viewed. I find it interesting that it is these files—all part of the OS—that are being found and "recovered" because, to my understanding, in a Fusion Drive, the OS is stored on the faster SSD portion of the Core Storage volume and my SSD is dead. Running Well, thanks for your time and efforts on this, you have been very helpful. It appears that the damage is too great, though, and that I'll have to be satisfied with the unstructured mess of files that PhotoRec recovered. So it is. I do have a Time Machine backup but, for various totally unjustifiable reasons, I have not been using it for the last couple of months. Stupid mistake on my part. |
|
Extracting files now skips files that cannot be saved (#17). This should prevent errors like the one you had. Thanks for all your feedback by the way. |
|
You're welcome for the feedback and thank you for the quick updates. As I said in my first message, I was looking for info on APFS and Fusion Drives and wasn't really finding a lot. I started to feel a bit like patient zero. Everyone else having problems with Fusion Drives seems to have bungled a Bootcamp install. Interesting but, as far as I can figure out, not helpful to my case. As for this run: Unfortunately, the result is the same as the last run. The message has a different format, though. The bodyfile is still 41.3 MB and the recovered files are again 2.24 GB in size. Interestingly, and this must be specific to my case, the last
I guess Afro is getting hung up on whatever is in that block which is unfortunate because it comes fairly early in the process—after reading about 32 GB of data—but it continues to run until it's read through the entire 2 TB image before outputting anything. Of no real importance, I did finally manage to get Mactime to output a spreadsheet file. I'll claim it as a small victory. |
|
The warning is expected, but afro does not fail in this step anymore. |
|
Ok, so, basically, what I've recovered so far is as much as can be recovered. Alright, thanks for all of your time and help on this but it looks like what is gone is really gone. So it is. Moral of the story: Back up your data kids, early and often (and then make a second set and keep it offsite). |
|
hi, i'm in the same situation now. what i did is below $ mmls ../img/nsanomac4_ssd.img
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
000: Meta 0000000000 0000000000 0000000001 Safety Table
001: ------- 0000000000 0000000039 0000000040 Unallocated
002: Meta 0000000001 0000000001 0000000001 GPT Header
003: Meta 0000000002 0000000033 0000000032 Partition Table
004: 000 0000000040 0000409639 0000409600 EFI System Partition
005: 001 0000409640 0236978135 0236568496 Customer
006: ------- 0236978136 0236978175 0000000040 Unallocated
$ afro -o 409640 -e files -m carve -c nodes ../img/nsanomac4_ssd.img
INFO Found nodes in block 449
INFO Found nodes in block 452
INFO Found nodes in block 861
:it stopped at following console output like :
INFO Found nodes in block 28722581
INFO Found nodes in block 28722664
WARNING Could not save nsanomac4_ssd.img.carve_nodes.extracted: [Errno 30] Read-only file system: '/Nintendo - Super Nintendo Entertainment System'current directory list are $ ls -l
total 930544
-rw-r--r-- 1 nsano staff 952870834 2021-01-20 13:46 nsanomac4_ssd.img.carve_nodes.bodyfile
drwxr-xr-x 3 nsano staff 102 2021-01-20 13:46 nsanomac4_ssd.img.carve_nodes.extractedand extracted files are never increased. $ tree nsanomac4_ssd.img.carve_nodes.extracted
:
├── Chrono Trigger.txt
└── Nintendo - Super Nintendo Entertainment System
10 directories, 836 filesbodyfile seems good. $ wc -l nsanomac4_ssd.img.carve_nodes.bodyfile
7241864 nsanomac4_ssd.img.carve_nodes.bodyfileQ
i have to open my imac for never responded split fusion hdd from now... regards |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have some questions, rather than an issue, that I'd love to get some help with. If this isn't the proper forum for that, please let me know. I have been searching for information regarding APFS data recovery and am having a hard time finding any.
For brevity, I'll start by pasting the output of mmls of disk4, a clone (created with DDRescue) of disk0, the HD portion of a Fusion Drive that, due to catastrophic failure, is now missing its SSD portion.
The ~2 TB of data from the HD has been cloned to a 5 TB USB external drive. Partition number 005 contains data that I want to retrieve. In
diskutilthe type for 005 is listed as Apple_APFS.I looked at TestDisk but it doesn't seem capable of dealing with APFS. I did run PhotoRec and was able to recover ~1.3 million files but, of course, they did not have their original files names and there is no file structure anymore. This is helpful but not so optimal.
Then I found and installed Afro (and Sleuthkit) and experimented with the example you provided, wsdf.dmg. That worked well although I have to admit I cannot for the life of me figure out how to output the bodyfile in some sort of human readable form. That's not important, though.
So, my questions are:
If there is more information you need or I have not been clear enough, please, don't hesitate to ask.
Any help you are able to provide with these questions is greatly appreciated and thanks for your time and efforts on this matter.
The text was updated successfully, but these errors were encountered: