Thanks for the suggestions.
No partition ever on these disks.
I will try the dd method but as there was never a partition on the drive
I don't think that will return results.
The busy drive is not part of an active md array nor mounted so still a
bit bemused by that.
I know the order, after my first few muckups I number them to make sure
if I have to move them it will work. If I use assume clean, if it does
not work I can just try another order I assume. I do have a backup but
14T will take time to replicate.
Email.png
*Regards John Atkins*
Senior Systems Support, Installation & Service Engineer
AAW Control Systems Ltd
Mobile: 07780480014
Office: 01635 248589
E-Mail: john@xxxxxxxxxxx
On 26/10/2021 00:16, Roger Heflin wrote:
Raw devices or not should not matter, unless you changed in the
middle and did not quite do all of it right.
Usually when I find a missing header on disks it is because it really
was not where it was thought to be. I have seen people put on raw
disks, later partitioniongin to misplace data--sometimes this
overwrites data depending on where the header lives (reboot exposes
it), I have seen them re-create a partition with a different starting
position and misplace data (the new partition was not used until
reboot). I have also seen people label a partition and then remove
the partition and that also misplaces data. If you are lucky then it
is a data misplace from a partition table issue.
If you cannot find the header you might look a bit more carefully.
"dd if=devicename bs=1M count=20 | xxd -a | more" and compare the good
one to the bad one and see if the header begins at the same location
or at a different location. On my disk with a partition table I get
data in the first 4 512byte blocks, and then no data until the start
of the actual partition/mdadm component.
I have found LVM headers and other headers and reconstructed the
partition table using the above trick (assuming there was a partition
table).
It is also possible that the header got overwrote by something.
To use the assume clean you will need to do an mdadm --stop /dev/mdXX
device (to undo the busy).
But also note that you must get the order exactly right with the
assume clean or it won't work (wrong order means corrupted data).
Usually it is suggested to make copies of the disks before attempting it.
On Mon, Oct 25, 2021 at 8:26 AM John Atkins <John@xxxxxxxxxxx
<mailto:John@xxxxxxxxxxx>> wrote:
Good-day All
I "have" an array RAID6 6drives 1 spare. The OS got corrupted on
reboot.
On a fresh install the array is non detectable. Investigation
shows that
out of the 6 active drives only the first one has a valid super block
the rest look to be corrupt. My assumption is that this might be
down to
the fact that I raided on raw drives /dev/sdX and not on partitions
/dev/sdX1. Is this recoverable or should I load from a backup?
I assumed trying to create using --assume-clean should work but
currently the only drive with a super block shows as busy except
it is
not mounted.
Many Thanks
John Atkins
