Resurrecting a WD MyBook Live

So I managed to kill the Guvnors NAS box and have now resurrected it. How to repair it (with a backup before hand) because we really don’t want to loose his data.

Step 1: We need to remove the hard drive from is enclosure:

(hey – we’re going fancy here and embedding video)

Anyway – I followed this for getting the thing to pieces.

Step 2: Using a SATA->USB adapter connect the box up to your linux PC (NB use on that works and is not flaky – it will save hours when trying to backup the data!)

Step 3: a quick dmesg on the command prompt will tell you which device it is:

[usb 1-4.2: New USB device found, idVendor=13fd, idProduct=1340
usb 1-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4.2: Product: External        
usb 1-4.2: Manufacturer: Generic 
usb 1-4.2: SerialNumber: 57442D5743415A414B343135
usbcore: registered new interface driver uas
Initializing USB Mass Storage driver...
scsi6 : usb-storage 1-4.2:1.0
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.

scsi 6:0:0:0: Direct-Access     Generic  External         2.08 PQ: 0 ANSI: 4
sd 6:0:0:0: Attached scsi generic sg2 type 0
sd 6:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
sd 6:0:0:0: [sdb] Write Protect is off
sd 6:0:0:0: [sdb] Mode Sense: 21 00 00 00
sd 6:0:0:0: [sdb] No Caching mode page present
sd 6:0:0:0: [sdb] Assuming drive cache: write through
sd 6:0:0:0: [sdb] No Caching mode page present
sd 6:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1 sdb2 sdb3 sdb4
sd 6:0:0:0: [sdb] No Caching mode page present
sd 6:0:0:0: [sdb] Assuming drive cache: write through
sd 6:0:0:0: [sdb] Attached SCSI disk

This shows the drive registered as /dev/sdb with 4 partitons, the data is stored on /dev/sdb4 however for some reason WD decided to use 16k block sizes which, unless you want to rebuild your kernel, most prebuilt kernels can use.  Enter debugfs!

Step 4: We want to backup the data on /dev/sdb4 incase we totally cockup.  As we can’t mount the partiton we can use a tool called debugfs, will allows us to do all sores of useful things, like recover deleted files etc.  What we are using it for is just a way to read the file off the disk and make a copy of them elsewhere.

debugfs /dev/sdb4

Now we want to copy the contents of the share directory.

rdump share /backup/

To all intents and purposes this is the equivalent of cp -rvp /mnt/shares /backup/ if we were actually able to mount the drive.  Beware this can take a loooong time and you will have no feedback whatsoever (unless it fails and you get lots of short reads due to using a dodgy SATA->USB adapter!)

Step 5: Okay! So we got the data backed up! Hurrah! Now we need to get the debrick script from here

or

wget http://205.196.122.104/brrbf21zprxg/g2xexkaaya34a9r/debrick.rar

unrar the script

unrar e debrick.rar

Step 6:And we need a copy of the firmware

wget http://download.wdc.com/nas/apnc-023205-046-20120910.deb

Step 7:Now we need to extract the rootfs.img from the firmware

unzip ap2nc-024202-012-20130401.zip
dpkg -c  ap2nc-024202-012-20130401.deb

Which gives us a new folder called CacheVolume and in there is a folder called uploads and in there you will find rootfs.img
Step 8:Run the script:

bash debrick.sh /path_to/rootfs.img /dev/sdb

and answer the questions prompted:

********************** DISK           **********************

script will use the following disk: 

Model: Generic External (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 3      15.7MB  528MB   513MB                primary
 1      528MB   2576MB  2048MB  ext3         primary  raid
 2      2576MB  4624MB  2048MB  ext3         primary  raid
 4      4624MB  2000GB  1996GB  ext4         primary

is this REALLY the disk you want? [y] y

********************** IMAGE          **********************

********************** IMPLEMENTATION **********************

everything is now prepared!
device:       /dev/sdb
image_img:    rootfs.img
destroy:      false

this is the point of no return, continue? [y] y

mdadm: /dev/sdb1 appears to contain an ext2fs file system
    size=1999808K  mtime=Tue May  7 14:45:05 2013
mdadm: size set to 1999808K
mdadm: creation continuing despite oddities due to --run
mdadm: array /dev/md0 started.
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
125184 inodes, 499952 blocks
24997 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=515899392
16 block groups
32768 blocks per group, 32768 fragments per group
7824 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912

Checking for bad blocks (read-only test): done                                                 
Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done 

mdadm: added /dev/sdb2

synchronize raid... done

copying image to disk... 
3999616+0 records in
3999616+0 records out
2047803392 bytes (2.0 GB) copied, 436.436 s, 4.7 MB/s
mdadm: stopped /dev/md0

all done! device should be debricked!

Step 9: OK so now we have the system restored to the drive and with any luck your backup is now redundant!

Unplug the HDD, and reassemble the unit.

Step 10: Plugin the device to the network access it and double check that the firmware is at the latest version.  Do any updates, recreate you shares and users and off you go!