problem Linux Raid1 : one disk crashed : how to recover the files?

[Muug]

Hi,
my name is Paul and a friend asked if I could recover his files. He had an Iomega Storcenter ix200 but one disk crashed badly, completely unusable. So he asked me to give it a go.

Now I've got this disk plugged in to my Ubuntu desktop and i can see it. It's 1TB in size, has two partitions: /dev/sdb1 and /dev/sdb2, being 21GB and 979 GB in size.

fdisk -l tells me this:

Disk /dev/sdb: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 4BE19A4C-1054-4CCB-B023-F9201ECAD9B0

Device Start End Sectors Size Type
/dev/sdb1 72 41961848 41961777 20G Microsoft basic data
/dev/sdb2 41961856 1953525106 1911563251 911,5G Microsoft basic data

cat /proc/mdstat says this:

Disk /dev/sdb: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 4BE19A4C-1054-4CCB-B023-F9201ECAD9B0

Device Start End Sectors Size Type
/dev/sdb1 72 41961848 41961777 20G Microsoft basic data
/dev/sdb2 41961856 1953525106 1911563251 911,5G Microsoft basic data

So /dev/md0 = /dev/sdb1 and /dev/md1 = /dev/sdb2

I did this too: mdadm --examine /dev/sdb1
The result:

sudo mdadm --examine /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 0.90.00
UUID : e097c76b:a54c273b:f54a779e:01f1e211
Creation Time : Fri Jun 8 03:49:47 2012
Raid Level : raid1
Used Dev Size : 20980800 (20.01 GiB 21.48 GB)
Array Size : 20980800 (20.01 GiB 21.48 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0

Update Time : Mon Oct 19 11:52:13 2015
State : clean
Active Devices : 1
Working Devices : 2
Failed Devices : 1
Spare Devices : 1
Checksum : cd8e4133 - correct
Events : 407215


Number Major Minor RaidDevice State
this 2 8 17 2 spare /dev/sdb1

0 0 8 1 0 active sync /dev/sda1
1 1 0 0 1 faulty removed
2 2 8 17 2 spare /dev/sdb1

and mdadm --examine /dev/sdb2
gives:

jan@Jan-PC:~$ sudo mdadm --examine /dev/sdb2
/dev/sdb2:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x2
Array UUID : ebec697a:78a228a2:e11877b5:9da45b49
Name : ix2-200-TI84CS:1
Creation Time : Fri Jun 8 04:00:12 2012
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 1911562976 (911.50 GiB 978.72 GB)
Array Size : 955781488 (911.50 GiB 978.72 GB)
Super Offset : 1911563232 sectors
Recovery Offset : 955782144 sectors
Unused Space : before=0 sectors, after=256 sectors
State : clean
Device UUID : bdb50fac:9ef1fd46:5cecd941:d4b7089c

Update Time : Mon Oct 19 11:51:56 2015
Checksum : 8a196cea - correct
Events : 239418


Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
jan@Jan-PC:~$

More info:

jan@Jan-PC:~$ sudo mdadm -D /dev/md0
/dev/md0:
Version : 0.90
Raid Level : raid0
Total Devices : 1
Preferred Minor : 0
Persistence : Superblock is persistent

State : inactive

UUID : e097c76b:a54c273b:f54a779e:01f1e211
Events : 0.407215

Number Major Minor RaidDevice

- 8 17 - /dev/sdb1

and

jan@Jan-PC:~$ sudo mdadm -D /dev/md1
/dev/md1:
Version : 1.0
Raid Level : raid0
Total Devices : 1
Persistence : Superblock is persistent

State : inactive

Name : ix2-200-TI84CS:1
UUID : ebec697a:78a228a2:e11877b5:9da45b49
Events : 239418

Number Major Minor RaidDevice

- 8 18 - /dev/sdb2

and

jan@Jan-PC:/mnt$ sudo mdadm --examine --scan
ARRAY /dev/md0 UUID=e097c76b:a54c273b:f54a779e:01f1e211
spares=1
ARRAY /dev/md/1 metadata=1.0 UUID=ebec697a:78a228a2:e11877b5:9da45b49 name=ix2-200-TI84CS:1

More info:

an@Jan-PC:/mnt$ sudo e2fsck /dev/md1
e2fsck 1.42.12 (29-Aug-2014)
e2fsck: Invalid argument while trying to open /dev/md1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>

and

jan@Jan-PC:/mnt$ sudo e2fsck /dev/md0
e2fsck 1.42.12 (29-Aug-2014)
e2fsck: Invalid argument while trying to open /dev/md0

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>

So this is all very nice, and Google is a great friend, but now I don't know anymore what to do.
I've got a big puzzle and lots of pieces but I just can't get it together.
Can you guys tell me what to do ? I just want to recover these files, that's all.

 

[ddrueding]

The easiest way to recover data from a NAS where you haven't lost your redundancy is to leave the drive in the NAS. Pull the bad drive, leave the good one. Either copy off the data you care about or (better) put in a replacement drive and let the system rebuild the array on its own. You may have broken this ability by pulling the good drive and messing with it.

 

[Muug]

The easiest way to recover data from a NAS where you haven't lost your redundancy is to leave the drive in the NAS. Pull the bad drive, leave the good one. Either copy off the data you care about or (better) put in a replacement drive and let the system rebuild the array on its own. You may have broken this ability by pulling the good drive and messing with it.

Hi,
of course we did what you're saying. I thought it was not necessary to mention that.
- we did put a new drive in.
- we waited a week to give the system enough time to rebuild it
- we were not able to make a connection to the web console
- we had a white LED flashing all the time
- we searched Google and learned that this NAS is known to be unreliable, to fail easily without warnings, to have a flashing white LED...
and that's when we decided we had to try another method of recovering those files.

 

[ddrueding]

Any chance you can have the NAS replaced under warranty and put the drive into the new one?

I'd also suggest that before you try too much, make a complete image of the drive just in case your recovery efforts break something.

 

[Muug]

Any chance you can have the NAS replaced under warranty and put the drive into the new one?

Alas, it's too old.

 

[Handruin]

If you're able to can you clone the disk somewhere else before experimenting like ddrueding suggested?

If not, can you try running the command: madadm -A /dev/sdb2 to see if this assembles the device into a new mdraid device but with a single member?

If that doesn't work, what about trying this article? I'm guessing you may have seen references to both of those in your googling but if not maybe they'll help.

 

[Muug]

the mdadm -A did nothing, but the foremost recovered about 34 files: a few thumbnails, a few pictures, a few exe's and a few pdf's. Nothing more :-( But it's the closest I ever got, so thank you for that. When foremost started, it looked good at first, but then some gibberish filled the terminal screen, and suddenly foremost was finished.
My friend told me he had first tried to do a reset, and he had replaced the failed disk with a new one, and he had tried to rebuild the RAID... well, perhaps the good disk lost its info somewhere along his trials....

 

[Muug]

well
foremost gave me some files,
and R-Studio(.com) gave me more or less the same files, so I suppose that the owner of the disk has lost his files while trying whatever he did.....
thanks for the info, but I give up.