Dave's Mess > Blog

How to recover your data after a crash

Years ago, back in the days of 33MHz processors and Mac OS 7, my little brother was writing a letter to our Granny when the computer he was using crashed. Crashes were good in those days; you got a little box on your screen with a picture of a bomb in it, a cryptic crash message and a restart button. As I was the resident computer geek, I was immediately called for and asked if anything could be done.

Luckily, at the time I had a voracious appetite for anything that looked like it could teach me how to program and I had read everything remotely technical I could find on the internet. I had, at the time, recently read about how to use Mac OS's built in debugger to save the contents of RAM to a file on the hard disk and I guessed that this could be used to recover my brother's letter. It took me a couple of goes to remember how to do it as I couldn't have the tutorial open while I was in the debugger but I did eventually remember. Shortly afterwards we had a 4MB file sitting on the hard drive that hopefully contained my brother's letter. A quick search through the file and we had recovered nearly all of the letter and put it back in SimpleText where it belonged.

Fast forward to today and things have changed a bit. Operating systems don't have built in debuggers that you can invoke with a keystroke (Well, some do, but not usually by default.) and 4MB of RAM is not considered enough to stir your coffee with, let alone boot a kernel into.

None the less, there are still things that can be done if you don't panic and are willing to think about your problem a bit. In my case, I was busy writing up a new blog post. Quite a rant if I remember correctly. I had poured my anger into the keyboard and was just going through it once more to check for spelling errors before posting it when Firefox disappeared. Gone. No warning, no crash dialog, no error message. Just gone.

Immediately I started Firefox back up again hoping I could recover my rant. I didn't want to have to type it all out again. I was hoping that when it restored my session with all it's tabs it would also restore the contents of the blog post field. Alas, it was not to be.

Since that idea had failed to produce any results, I tried the same trick that worked for my brother all those years ago: Save the contents of RAM to a file on the hard disk and look through it for what I had just been writing. Not being sure of how to do this, I fell back on something I did know how to do: copy the contents of virtual memory. I checked /etc/fstab to find out where my swap partition was and then typed dd if=/dev/hdd5 of=/home/dave/swap_partition on the command line.

This saved the contents of swap to a file. Next, I ran the command strings swap_partition > swap_strings.txt which grabbed anything that looked like an ASCII string out of that file. Basically, any text in virtual memory would now be in the file swap_strings.txt. With trepidation, I grepped through the file for a word I know I had typed several times in the blog post. Nothing. I tried another word, and another. Although I was finding plenty of occurrences of the words, none of them were part of the blog post I had just written.

Since another idea had failed to recover my work, I needed to think again. Where else could this data have been saved ? Logically, the next most likely place was the .mozilla directory in my home directory. This is where Firefox saves all of your user-specific profile settings. Under Windows this would be in C:\Documents and Settings\Username\Application Data and on a Mac it would be in /Users/username/Library/Application Support.

Firefox saves all the tabs and all the windows you currently have open on a frequent basis so that if it crashes or shuts down untidily for any reason, at any time, it can start up again exactly where it was and recover any work you were doing. In my case, Firefox had opened all my tabs and remembered what was in the text fields such as the headline and date fields and I had been hoping that it would remember the textarea which contained the majority of the post. I was to be initially disappointed.

Although Firefox hadn't filled the large textarea in when I had returned to the page, I had a feeling that it may have been saving it's content somewhere on disk even though it hadn't been automatically recovered. Sure enough, I ran the strings command over every file I found in the .mozilla directory and one of them - sessionstore.bak - had my blog post in it. The data appeared to have been URL encoded and was mixed up with every other bit of data about the session that had just crashed but neither of these problems were difficult to work around. A few quick search-and-replace commands later and I had recovered all of my writing.

Maybe this will work for you, maybe it won't. The important thing to remember is that even though your data may look to be gone, there's still probably another copy of it floating around somewhere and if you know a couple of good tricks, you might just be able to recover it.

2007-10-16 - Update: I did a bit more research and found out how to dump the contents of RAM and the contents of any single process. [dave@dave-desktop:~] # sudo cat /dev/mem | strings > ~/mem

[dave@dave-desktop:~] # sudo gcore -o ~/coredump pid The first command will save any ASCII string in RAM to the file mem in your home directory. To save the entire contents of RAM, just remove the | strings part of the command. This will save all the RAM, even if there isn't a running process using some part of it.^[1]

The second command will save the memory of the process pid where pid is actually the process id of the process whose memory you want to dump.

I also found a great page on someone else's experiences with MacsBug almost exactly mirroring mine.

[1]: I tested this by starting vi and typing in "thisisanabsolutelyuniqueteststring", killing the vi process without saving the file and running the command above immediately with a small modification. Instead of piping the output to a file, I piped it to grep thisisanabsolutelyuniquetest. The grep command found itself, as it always does, but it also found the original string, identified by the rest of the unique string that I didn't include in the grep command.
You have to be careful when search through running memory. I now remember having this problem with the Mac all those years ago. Whenever I searched for parts of my brother's letter, I would just end up finding the part of memory that contained the search string.