The server crashed while raid-1 /dev/md2 with /dev/sda3 + /dev/sdb3 was resyncing from /dev/sdb3 to /dev/sda3. sadly, /dev/sdb was lost completely due to a hardware fault.
I'm now left with only /dev/sda3 which is part of /dev/md2 but not suitable.
mdadm --assemble --scan --verbose
[..]
mdadm: /dev/sda3 is identified as a member of /dev/md2, slot 2.
mdadm: No suitable drives found for /dev/md2
Output of examine:
mdadm -E /dev/sda3
/dev/sda3:
Magic : a92b4efc
Version : 0.90.00
UUID : e5249c1c:02d996e3:776c2c25:004bd7b2 (local to host rescue)
Creation Time : Wed May 4 13:48:24 2011
Raid Level : raid1
Used Dev Size : 730202368 (696.38 GiB 747.73 GB)
Array Size : 730202368 (696.38 GiB 747.73 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 2
Update Time : Fri Jun 7 22:06:35 2013
State : clean
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
Checksum : d56f21ea - correct
Events : 13242378
Number Major Minor RaidDevice State
this 2 8 3 2 spare /dev/sda3
0 0 0 0 0 removed
1 1 8 19 1 active sync /dev/sdb3
2 2 8 3 2 spare /dev/sda3
Is there any option to reassemble md2 from sda3 alone, making it somehow suitable again?
(Of course, there's the alternative to mount it as ext3, copy files to spare disk and recreate the raid, but I'd like to reuse the already existing disk if possible.)
Best Answer
Probably the metadata knows several steps of "Does this disk belong to an array?". I am not familiar with those details; I just assume that it is similar to the dirty flag of a file system. When you take a new disk into an array then it is probably marked as spare until it is completely in sync. After that the metadata is probably changed to "is a full member of the array".
The best solution would indeed be to create a new array and restore from backup.
If you do want to give the disk a chance (knowing that the "truncation" will get the file system into really bad mood) then you should create a new array from this disk: