NAS data recovery
Tuesday January 24th, 2012

Back in 2008, I bought a Western Digital MyBook "World" 500GB NAS. It was a decent NAS, but mine had some cooling issues which were probably related to where I kept it. It was on top of a closet, where it was pretty dusty and warm, which isn't very beneficial for hard disks. So after a while it started developing issues: it would randomly give time-outs and become unresponsive. After a reboot it would work for a while, but after a week or so it would give timeouts again.

I quickly moved all essential data to my computer's hard disk, and powered down the NAS until I had found a replacement and would copy the rest of the data as well. But I made a cardinal sin when I powered down the NAS: I made an assumption. As we all know, assumption is the mother of all fuckups and Finagle's law will apply. I assumed that by turning off the NAS via the big button on the front, it would completely shut down the NAS. Unfortunately, I found out that this was not the case when I had a new storage device a while back and was ready to migrate all my data. The NAS felt quite warm, which surprised me to say the least. Apparently when you push the big "on/off" button at the front, it only powers down the little main board; but it keeps the hard disks spinning. To power down the hard disks, you have to unplug the power supply or flip a small switch on the back of the device. When I tried to boot up the NAS, it didn't do anything at all.

Crap! now what ? Did I just lose a large portion of my data ? I wasn't ready to give up just yet. My geek-credibility would be at stake. Since the NAS was essentially dead, I carefully dismantled it and took the Hard drive out. Because i didn't know what the state of the hard drive would be, I didn't want to plug it directly onto my computer's main board; after all, Finagle's law was in effect and I didn't want to blow up my main board just yet. I went online and bought a SATA/IDE to USB 2.0 Adapter. Since it was a Linux based NAS, I installed Ubuntu Linux on a USB stick and booted up my laptop.

First order of business was to determine if the Hard drive would be salvage-able. As soon as I plugged in the power to the hard drive I could hear a soft whirl indicating that it was still spinning up. Since it would be the third SATA device (the first being my laptop's internal hard drive, and the DVD-ROM the second) connected to my laptop, it would have to be /dev/sdc that I was looking for. A quick peek in the boot log confirmed that the system had indeed detected the hard drive. Next up was to see if the hard drive would still operate, and which part I had to restore:

root@ubuntu:/# sfdisk -l /dev/sdc

Disk /dev/sdc: 60801 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdc1          3     368     366    2939895   fd  Linux raid autodetect
/dev/sdc2        369     381      13     104422+  fd  Linux raid autodetect
/dev/sdc3        382     504     123     987997+  fd  Linux raid autodetect
/dev/sdc4        505   60800   60296  484327620   fd  Linux raid autodetect

Well, well... this is interesting. Even though the NAS only had one hard drive, Western Digital still made all the partitions part of a raid set. My best guess is that Western Digital did that because the MyBook line also featured larger models with two hard drives in it; and they would be able to use the same configuration for those. In my opinion a sloppy solution, but more about that in a moment. In any case, the device showed four partitions, of which one was roughly 480GB. This was clearly my target. Since you can't just mount a raid partition, I first had to find a way to recover the raid set:

root@ubuntu:/# mdadm --examine --scan /dev/sdc1 /dev/sdc2 /dev/sdc3 /dev/sdc4
ARRAY /dev/md4 UUID=dee2de1f:eec30950:726acf0d:54e86bff
ARRAY /dev/md3 UUID=e1e3ad6e:0753b0ae:86339bf0:ca6e9d49
ARRAY /dev/md2 UUID=51a4640a:c27e3a2e:4b454248:eeac819a
ARRAY /dev/md1 UUID=6afd8edb:48c319d6:c6d492e3:868da876

Good news so far, Linux recognized the arrays. Now we could attempt to reassemble the raid sets:

root@ubuntu:~# mdadm --assemble --scan
mdadm: /dev/md1 has been started with 1 drive (out of 2).
mdadm: /dev/md3 has been started with 1 drive (out of 2).
mdadm: /dev/md4 has been started with 1 drive (out of 2).

Of course, with a raid1 array the system would expect two drives. But since the NAS only had one hard drive, it would mean that the array would always be in a "degraded" state. This won't stop the array from working, but to me it seems rather sloppy. It also seemed strange to me that it wouldn't reassemble /dev/md2, but since /dev/md4 was my main concern and the hard drive would be scrapped anyway, I couldn't be bothered to investigate it further. Fortunately, /dev/md4 was reassembled properly and I was able to mount it and access my files:

root@ubuntu:~# mount /dev/md4 /media/nas_backup
root@ubuntu:~# cd /media/nas_backup
root@ubuntu:/media/nas_backup# ls -l
total 24
drwxr-xr-x 2 root     www-data  4096 2009-04-25 18:10 backup
drwx------ 2 root     root     16384 2002-02-28 12:30 lost+found
drwxr-xr-x 3 www-data www-data  4096 2010-05-07 05:31 PUBLIC

Copying the data took quite a bit longer than I thought. It was only 93GB, but it took well over 3 hours to copy it from the hard drive to my new storage system. A possible cause for the lack of speed was the fact that it was an USB adapter, and I'm not sure if I actually hooked it up to a USB 2.0 port on my laptop. On the other hand, the hard drive wasn't in the best state either, so that could also have been a bottleneck. It was totally worth the wait though; my data was secured.

*phew*

Filed under: tech, how-to.
Sorry, there are no comments on this story yet.
Post a comment