Encoding Q

[jho...@gmail.com]

First I'd like to give some gold to TwinDB - these sort of tools are just one of so many things that make the open source community so great. I would have had no chance of interacting with these DB's in the way I have without these tools, and after my DB was dropped Aleks took the time to answer many of my Q's over chat and was SO helpful. Thank you.

Aleks, I followed your advice and have had mixed success. I am not sure yet if I will recover my databases, but I have an update, and would love to know if you or anyone else in the community sees any solutions that I don't see.

I am developing a website on a Macbook using MAMP. I had an accidental drop database situation last week, catastrophic to the development project. I shut down the server right away. After talking to you, Aleks, I shut down my MAC and went into recovery mode. From there, I was able to create a disk image (using dd) of the 120 GB  hard drive.

After reading the list of Linux distros the UNDROP tools were tested with, I went ahead and did a fresh install of Ubuntu 14.04 LTS on my second computer. The UNDROP tools compiled easily, and I was able to very quickly get a significant amount of dictionary information from ibdata1

Next I proceeded to this tutorial: https://twindb.com/recover-after-drop-table-innodb_file_per_table-is-on/

After running stream_parser on the disk image, the directory was created FIL_PAGE_INDEX but there were no files in it. At this point I thought maybe I had failed to recover any tables. Only a little forensics suggests another line of troubleshooting.

 I had searched for hex-value converted text strings (pulled from the dropped databases) in the disk image several times, and come up with nothing. To test, and make sure my HEX search was getting information from the data, I arbitrarily chose a text file on my Macbook unrelated to my website (that was definitely in that disk image) and searched for a hex-value converted string. This should have come up with a result, but it did not, which points to some other problem needing to be troubleshooted before I proceed to try stream_parser again.

Is there an encoding factor that must be accounted for in my situation, so that the HEX search finds data successfully, and stream_parser finds tables? The MYSQL files I am looking for were originally created on the Mac. The disk image was created on the Macbook, as well, which uses Mac's unique journaling.

Thank you!

[Aleksandr Kuzminsky]

Hi Jonathan,

It sounds indeed like the disk is encrypted, compressed or encoded somehow. 

Otherwise stream_parser would find at least something - existing InnoDB pages.

Unfortunately I don't know MacOS file system (apfs?). If you find any way to convert the image into readable format, could you please share?

Best,

Aleks

[jho...@gmail.com]

Well I've dived a little deeper into the problem and have come up with some solid answers.

Understanding APFS now, I have a 120 GB disk image with files encrypted in APFS. I installed apfs-fuse tools from github, they are unable to mount the disk image, either, because the dd image needs to be repaired, it became corrupt at some point in the process, and every mount avenue I've undertaken has ended at that. My intuition is that once I get the image mounted, UNDROP will have a return for me.

Extensively searched for a tool that would repair the disk image. fsck did not do the job; mac disk utility needs to mount it to repair it (?!?) [and gives a message cannot mount, image corrupted]. People recommend disk warrior etc but it is not even clear if it will be able to repair a disk image. There is one data recovery software company that offers "free up to 250 GB" and that is my next avenue of inquiry. Like I said, I believe that once the disk image is repaired and mounted, the files are there, i just need to fix the dd image first.