This week my Pi stopped working. After hooking up a monitor I saw kernel errors related to VFS. So the file system was obviously broken. Oops.
The end conclusion is that the SD card is physically ‘broken’, but I still managed to salvage my data — which is more important than the card. Here’s how.
Broken file system: fsck or dd?
What didn’t work for me, but you might want to give a try first are fsck for file system consistency check or using dd to create a disk image.
I couldn’t check/repair the file system with fsck (it gave errors), not even when setting different superblocks. It might work for you, so you can give this blog a try.
Next, I tried to ‘clone’ the bits on the file system with dd. To get a usable image. But that didn’t work either, spewing out errors. But this is where I stumbled across ddrescue.
GNU ddrescue
I had not heard of ddrescue before but it turned out to be a life datasaver! It does what dd does, but in the process tries “to rescue the good parts first in case of read errors”. There are two versions of this program, I used the GNU version.
sudo apt-get install gddrescue
And here is what a sigh of relief looks like, after 43 minutes:
So the command is:
ddrescue -f -n /dev/[baddrive] /root/[imagefilename].img /tmp/recovery.log
The options I used came from this blog:
- -f Force ddrescue to run even if the destination file already exists (this is required when writing to a disk). It will overwrite.
- -n Short for’–no-scrape’. This option prevents ddrescue from running through the scraping phase, essentially preventing the utility from spending too much time attempting to recreate heavily damaged areas of a file.
After you have an image you can mount it and browse your data:
mount -o loop rescue.img /mnt/rescue
With this I had access to my data! So I got a new SD card copied my data over and chucked the old SD card. And remember:
'Don't ever, ever plan a backup strategy. Plan a restore strategy.' — Paul Randal
— Unix tool tip (@UnixToolTip) December 29, 2015