I've had a series of different issues with recovering a RAID disk, ending with the error reported in the subject. Please skip the long story to come to the conclusions if you want.
- I set up an ubuntu server machine a couple of years ago with two 1TB disks in RAID1.
- recently the machine was faulty and I dismantled it, taking the two HDD.
- I managed to connect one of the disks to my laptop via USB and browse it correctly through mdadm.
- Bought a Synology NAS and placed the other disk inside it, to create a new RAID system. Of course this way it was formatted and I had only one good disk with my old data.
- Connected the good disk to the NAS via USB with the intent to copy all the old data to the freshly formatted disk inside the NAS. I managed to create a mdadm array in the NAS thanks to this guide http://forum.synology.com/wiki/index.php/How_to_manually_mount_a_USB_Hard_Disk,_including_a_disk_that_was_part_of_a_RAID1_array and managed to see that the disk had memory of its previous RAID configuration (in my laptop): mdadm --examine --scan /dev/sdk3 returned the line of information I expected
- However the NAS at the end could not mount the disk (/dev/sdq1) to the filesystem (say /mnt/usb), with a generic "No such device" error. Apparently it seems mount in busybox (on which the NAS is based) is reluctant on giving further suggestions (http://www.silas.net.br/tech/linux/busybox-troubleshooting.html)
- Then I thought "well, if I can't copy data via USB in the NAS I will connect the disk to my laptop and transfer trough ethernet". Good idea. Unfortunately, in the process of creating the array the NAS probably destroyed the original superblocks, so when I connected it to the laptop (Linux Mint ubuntu version) the partition showed up inside the file manager (mdadm worked fine and mapped the partition in /dev/mapper) but could not be mounted: raid mount: /dev/md1: can't read superblock
- trying to fix with e2fsck didn't help
- trying to fix with e2fsck -b didn't help
- All the information were ok, like those in mdadm --examine --scan /dev/sdk3
- I rebooted the laptop. Now the raid is not even assembled automatically by mdadm... I think the disk lost its UUID? Can it be? I see dmesg correctly connects the disk:
sd 7:0:0:0: [sdb] Attached SCSI disk
and a partition sdb1, but I cannot find the disk in /dev/disk/by-uuid
The RAID info is lost: mdadm --examine --scan /dev/sdk3 returns no information
- Trying to manually create a new md returns: $ mdadm -A --verbose --run /dev/md3 /dev/sdb1 mdadm: looking for devices for /dev/md3 mdadm: no recogniseable superblock on /dev/sdb1 mdadm: /dev/sdb1 has no superblock - assembly aborted
I tried to restore a number of backup superblocks with:
e2fsck -b /dev/sdb1
e2fsck 1.42.9 (4-Feb-2014) e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
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 or e2fsck -b 32768
I got the superblock backup address with mke2fs -n /dev/sdb1
Is the disk totally fried??? Is it normally so that utilities overwrite important info on a disk and make it unusable?
$ fdisk -l /dev/sdb
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Device Boot Start End Blocks Id System /dev/sdb1 1 1953525167 976762583+ ee GPT
Welcome to GNU Parted! Type 'help' to view a list of commands.
Model: SAMSUNG HD103SI (scsi) Disk /dev/sdb: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt
Number Start End Size File system Name Flags 1 17,4kB 1000GB 1000GB raid