How to Recover Data From a Netgear ReadyNas

Has your Netgear ReadyNas Duo V2 died? All is not lost, using some linux tools like ddrescue and testdiskyou can hopefully recover the data again.

TL;DR

If you just want the step by step commands, check out this Gist..

Photo by 铮 夏 on Unsplash

Many years ago I bought a ReadyNas Duo V2 RAID enclosure so I could keep all my work safe and secure in the knowledge that it had not 1 but 2 disks mirroring all my data.

If one disk dies, thats fine — you simply swap out the dead disk and everything syncs. I’ll never loose this data.

That is, until I turned it on after not running it for a few months and… nothing.

Both discs would just spin up and down making lots of noise but never mount.

Great.

After a lot of swearing I got to work on recovering the data, and I did manage to get it all back, so for anyone else in this situation heres how I did it.

Note: This is for the V2 Duo, the V1 had a very different RAID software, but these steps may well still work as we don’t get involved with trying to re build the RAID array, we just mount one of the disks as a standalone drive.

Step 1: Linux

First off you are going to need linux to mount the ReadyNas disks. Whilst you can mount ext4 file systems on macs with some tools such as ext4fuse and Paragon’s extFS for Mac (and similar solutions for windows) the LVM format of the drives, and the funky disk block size makes it almost impossible.

Anyway, the drives are dead and wont mount so we need to use some linux recovery tools.

I couldn’t use Docker as I could not see how to pass through the USB host controller to docker — you need the drive to mount in the host to share it to docker — which wont work in this case.

I used VM in VMWare Fusion to create an Ubuntu Server (distro’s like Alpine are too simple for what we need to do)

Step 2 : Find Some Hard Disks

To recover the files, you will need another disk with equal or greater capacity than the damaged drive — and potentially a 2nd drive if you want to get the files off the ReadyNas RAID format and on to standard windows / mac drive.

I had some old 3.5inch SATA drives kicking about, and some SATA to USB adapters. If you do use 3.5" drives, make sure you get powered adapters as they draw more energy than USB can provide.

Attach one of your old dead drives — leave the new one disconnect for now so as to make it easy to identify the disk.

Step 3: Check the Damaged Disk

Login to linux and check the locations / status of your drive.

$ sudo fdisk -l

This will print out where the drives are, and which devices / partitions that can be found on them.

Your drive will be something like this.

My corrupted ReadyNas drive is under /dev/sdb.

If your partition tables are corrupted you wont see anything listed under Device, (sdb1, sdb2 etc).

If you can see the partitions you might be lucky and you could possibly mount the drive (explained later) and copy the data off it.

However, the chances are, like me, you will have so many I/O errors that copying the data will keep crashing and you will get into a right mess.

As you can see here, I have partitions, but they have issues and mounting them was not going to work.

Step 4: Clone the Damaged Disk

Hook up the new working recovery disk, and check where it is.

$ sudo fdisk -l

You can now see I have a /dev/sdc as my new drive that I’ll be cloning to.

NOTE: Take care when noting down the locations of the two disks — if you get them the wrong way round you could delete all your data by accident.

We are going to use ddresuce to clone the data. Its designed for exactly this: retrying bad blocks until it can get valid data copied over to another drive.

sudo ddrescue -f -r3 /dev/{BAD DISK} /dev/{GOOD DISK} /tmp/ddresuce.log

BE VERY CAREFUL HERE. Make sure you have the corrupted NAS drive first (/dev/sdb for me) and the new drive second (/dec/sdc for me)

sudo ddrescue -f -r3 /dev/sdb /dev/dsc /tmp/ddresuce.log

This will perform a clone of the whole disk from sdb to sdc.

-f : Will force wipe the destination drive, which is needed to do disk to disk copying.

-r3: Will try up to three passes to recover bad blocks of data

See this article for more on the other options you can do such as cloning to an image.

Step 5: Go and Do Something Else

ddrescue took 30 hours to run for my 1TB hard disk. Best not sit and wait for it to complete.

30 hours later…

Step 6: Check the New Disk

$ sudo fdisk -l

This should now show you the cloned new disk, and fingers crossed you can see 2 partitions — the Linux LVM is the ReadyNas partition with your data!

If you can see the partitions above, then skip to mounting the drive.

However, if like me, you could still not see the partitions on the new recovered drive, we need to so some more work.

Step 7 : Recover the Partitions

Install the testdisk tool to fix the partitions.

$ sudo apt install testdisk
$ sudo testdisk

When testdisk starts, hit create

Select the NEW disk (sdc for me)

Select EFI GPT

And choose Analyse it will show some data on the disk and the choose Search

This will scan the disk for partitions.

If it finds any that can be repaired, there will be a P next to them in the list.

If you cant see any, try a Deep Search which will take a few hours.

Hopefully you can see the partitions now. Choose the Linux LVM partition, and then choose Write to fix the partition table on the disk .

testdisk prompts you to reboot, after that run fdisk again and hopefully we can see the partitions…

$ sudo fdisk -l

And now we have a working disk!

Step 8: Mount the New Disk

The ReadyNas uses Logical Volumes, so we need to use the LVM tools on linux to prep the volume for mounting.

$ sudo vgscan

This shows us it has found the ReadyNas volume group called “C”

To activate that run

$ sudo vgchange -ay c

Next we need to use fuse to mount the drive. The RedayNas drives use an odd block size that causes mount to error with

mount: wrong fs type, bad option, bad superblock on /dev/c/c,
       missing codepage or helper program, or other error

So install fuse

$ sudo apt install fuse

And then mount the drive

$ sudo fuse-ext2 -o sync_read,allow_other,rw+ /dev/c/c /media/readyNasDuo

Where dev/c/c is your active logical volume and media/readyNasDuo is the mount point.

and test your mount…

$ ls /media/readyNasDuo

Step 9: Copy the Files

If you want to get the files off the ReadyNas Linux odd format that needs fuse to mount, then you can now just simply copy all the content of the disk to another drive.

I used a 2nd hard disk attached to the host as a shared drive/folder for the VM.

Using VMWare tools, I got this mounted in the VM like so.

vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other

And now I have a mount that is mapped to the OSX host under /mnt/hgfs/aNewDrive

so finally, you can now copy all the recovered files off the linux drive back on to an OSX drive

rsync -av /medai/readyNasDuo /mnt/hgfs/myNewDrive

Step 10: Clean Up the OSX Drive

The final thing I did was to clean up all the dot files on the new OSX drive.

When OSX copies files onto a linux drives it can sometimes write meta data into a separate hidden file, these appear as AppleDouble and ._FileName files.

Once all out data was back on a OSX managed disk (APFS this time) we no longer need all these forked files — so you can merge them back in to the original files with the following command on OSX

dot_clean -m

And we are Done!

Hopefully this helps someone who has the same issue — all is not lost!

Here are all the commands in a Gist