linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Rebuilding mdadm RAID array after OS drive failure
@ 2022-10-16 21:38 Steve Kolk
  2022-10-16 22:22 ` anthony
  0 siblings, 1 reply; 4+ messages in thread
From: Steve Kolk @ 2022-10-16 21:38 UTC (permalink / raw)
  To: linux-raid

I have a system that was running Ubuntu 18.04 server with a 5 drive
RAID 6 array using mdadm. I had a hard drive failure, but instead of
the array it was the OS hard drive that completely failed. I also do
not have access to the original mdadm.conf file.

In an attempt to get my array back up, I booted Ubuntu 22.04 from a
USB and tried to assemble and mount the array.  It did not work.
Trying some diagnostic steps I found online, it seems to be claiming
that there is no md superblock on any of the drives.

I've included the commands I ran and their output below. Does anyone
have any advice on what next steps I can take? I have no reason to
think these drives have failed mechanically (much less all of them). I
also tried with Ubuntu 18.04 and got the same results.

ubuntu@ubuntu:~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0    7:0    0   2.2G  1 loop /rofs
loop1    7:1    0  32.3M  1 loop /snap/snapd/12883
loop2    7:2    0  55.4M  1 loop /snap/core18/2128
loop3    7:3    0  61.8M  1 loop /snap/core20/1081
loop4    7:4    0  65.1M  1 loop /snap/gtk-common-themes/1515
loop5    7:5    0   219M  1 loop /snap/gnome-3-34-1804/72
loop6    7:6    0 241.4M  1 loop /snap/gnome-3-38-2004/70
loop7    7:7    0   2.5M  1 loop /snap/gnome-calculator/884
loop8    7:8    0   704K  1 loop /snap/gnome-characters/726
loop9    7:9    0   548K  1 loop /snap/gnome-logs/106
loop10   7:10   0   2.5M  1 loop /snap/gnome-system-monitor/163
sda      8:0    0   9.1T  0 disk
├─sda1   8:1    0   9.1T  0 part
└─sda9   8:9    0     8M  0 part
sdb      8:16   0   9.1T  0 disk
├─sdb1   8:17   0   9.1T  0 part
└─sdb9   8:25   0     8M  0 part
sdc      8:32   0   9.1T  0 disk
├─sdc1   8:33   0   9.1T  0 part
└─sdc9   8:41   0     8M  0 part
sdd      8:48   0   9.1T  0 disk
├─sdd1   8:49   0   9.1T  0 part
└─sdd9   8:57   0     8M  0 part
sde      8:64   0   9.1T  0 disk
├─sde1   8:65   0   9.1T  0 part
└─sde9   8:73   0     8M  0 part
sdf      8:80   1   7.6G  0 disk
└─sdf1   8:81   1   7.6G  0 part /cdrom

ubuntu@ubuntu:~$ sudo mdadm --assemble /dev/sda1 /dev/sdb1 /dev/sdc1
/dev/sdd1 /dev/sde1
mdadm: device /dev/sda1 exists but is not an md array.

ubuntu@ubuntu:~$ sudo mdadm --examine --verbose /dev/sd[a-e]1
mdadm: No md superblock detected on /dev/sda1.
mdadm: No md superblock detected on /dev/sdb1.
mdadm: No md superblock detected on /dev/sdc1.
mdadm: No md superblock detected on /dev/sdd1.
mdadm: No md superblock detected on /dev/sde1.

ubuntu@ubuntu:~$ sudo mdadm --assemble --scan --verbose
mdadm: looking for devices for further assembly
mdadm: no recogniseable superblock on /dev/loop10
mdadm: no recogniseable superblock on /dev/loop9
mdadm: no recogniseable superblock on /dev/loop8
mdadm: Cannot assemble mbr metadata on /dev/sdf1
mdadm: Cannot assemble mbr metadata on /dev/sdf
mdadm: no recogniseable superblock on /dev/sdb9
mdadm: no recogniseable superblock on /dev/sdb1
mdadm: Cannot assemble mbr metadata on /dev/sdb
mdadm: no recogniseable superblock on /dev/sde9
mdadm: no recogniseable superblock on /dev/sde1
mdadm: Cannot assemble mbr metadata on /dev/sde
mdadm: no recogniseable superblock on /dev/sdd9
mdadm: no recogniseable superblock on /dev/sdd1
mdadm: Cannot assemble mbr metadata on /dev/sdd
mdadm: no recogniseable superblock on /dev/sdc9
mdadm: no recogniseable superblock on /dev/sdc1
mdadm: Cannot assemble mbr metadata on /dev/sdc
mdadm: no recogniseable superblock on /dev/sda9
mdadm: no recogniseable superblock on /dev/sda1
mdadm: Cannot assemble mbr metadata on /dev/sda
mdadm: no recogniseable superblock on /dev/loop7
mdadm: no recogniseable superblock on /dev/loop6
mdadm: no recogniseable superblock on /dev/loop5
mdadm: no recogniseable superblock on /dev/loop4
mdadm: no recogniseable superblock on /dev/loop3
mdadm: no recogniseable superblock on /dev/loop2
mdadm: no recogniseable superblock on /dev/loop1
mdadm: no recogniseable superblock on /dev/loop0
mdadm: No arrays found in config file or automatically

Steve

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Rebuilding mdadm RAID array after OS drive failure
  2022-10-16 21:38 Rebuilding mdadm RAID array after OS drive failure Steve Kolk
@ 2022-10-16 22:22 ` anthony
  2022-10-17 22:46   ` Steve Kolk
  0 siblings, 1 reply; 4+ messages in thread
From: anthony @ 2022-10-16 22:22 UTC (permalink / raw)
  To: Steve Kolk, linux-raid

On 16/10/2022 22:38, Steve Kolk wrote:
> I have a system that was running Ubuntu 18.04 server with a 5 drive
> RAID 6 array using mdadm. I had a hard drive failure, but instead of
> the array it was the OS hard drive that completely failed. I also do
> not have access to the original mdadm.conf file.
> 
> In an attempt to get my array back up, I booted Ubuntu 22.04 from a
> USB and tried to assemble and mount the array.  It did not work.
> Trying some diagnostic steps I found online, it seems to be claiming
> that there is no md superblock on any of the drives.

 From this site? https://raid.wiki.kernel.org/index.php/Linux_Raid

Try https://raid.wiki.kernel.org/index.php/Linux_Raid#When_Things_Go_Wrogn
> 
> I've included the commands I ran and their output below. Does anyone
> have any advice on what next steps I can take? I have no reason to
> think these drives have failed mechanically (much less all of them). I
> also tried with Ubuntu 18.04 and got the same results.
> 
If you've got python 2.7, can you run lsdrv? Hopefully that will give us 
some more clues.

Provided the data itself isn't damaged, you should be able to retrieve 
your array. Read up the section on overlays, that will protect your data 
from being overwritten while you play around trying to recover it.

The other thing I would do here, is five drives is a lot to try and get 
right. I'd pick just three drives, and try to get them to assemble 
correctly (using overlays for safety!). Once you've got three drives to 
give you a functional array, you can then try and get the other two 
correct before the final recovery.

What can you remember about the system? What version of superblock? And 
something I've noticed that seems weird, why do your drives have 
partitions 1 & 9, but not 2-8? That is well odd ... Have you rebuilt the 
array in any way, or is it exactly as originally created? Etc etc the 
more information you can give us the better.

Let us know how you get on with this, and then we'll come back with more.

Cheers,
Wol

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Rebuilding mdadm RAID array after OS drive failure
  2022-10-16 22:22 ` anthony
@ 2022-10-17 22:46   ` Steve Kolk
  2022-10-18  7:04     ` Wols Lists
  0 siblings, 1 reply; 4+ messages in thread
From: Steve Kolk @ 2022-10-17 22:46 UTC (permalink / raw)
  To: anthony; +Cc: linux-raid

On Sun, Oct 16, 2022 at 6:22 PM anthony <antmbox@youngman.org.uk> wrote:
>
> On 16/10/2022 22:38, Steve Kolk wrote:
> > I have a system that was running Ubuntu 18.04 server with a 5 drive
> > RAID 6 array using mdadm. I had a hard drive failure, but instead of
> > the array it was the OS hard drive that completely failed. I also do
> > not have access to the original mdadm.conf file.
> >
> > In an attempt to get my array back up, I booted Ubuntu 22.04 from a
> > USB and tried to assemble and mount the array.  It did not work.
> > Trying some diagnostic steps I found online, it seems to be claiming
> > that there is no md superblock on any of the drives.
>
>  From this site? https://raid.wiki.kernel.org/index.php/Linux_Raid
>
> Try https://raid.wiki.kernel.org/index.php/Linux_Raid#When_Things_Go_Wrogn

I set up 3 of the drives with overlays and tried forcing the assembly,
but I still get the same error. I haven't tried the steps under
"Irreversible mdadm failure recovery", is there where I need to go
next?

ubuntu@ubuntu:~$ echo $OVERLAYS
/dev/mapper/sda1 /dev/mapper/sdb1 /dev/mapper/sdc1
ubuntu@ubuntu:~$ sudo mdadm --assemble --force /dev/md1 $OVERLAYS
mdadm: no recogniseable superblock on /dev/mapper/sda1
mdadm: /dev/mapper/sda1 has no superblock - assembly aborted

> >
> > I've included the commands I ran and their output below. Does anyone
> > have any advice on what next steps I can take? I have no reason to
> > think these drives have failed mechanically (much less all of them). I
> > also tried with Ubuntu 18.04 and got the same results.
> >
> If you've got python 2.7, can you run lsdrv? Hopefully that will give us
> some more clues.

ubuntu@ubuntu:~$ ./dev/lsdrv/lsdrv
PCI [ata_piix] 00:1f.2 IDE interface: Intel Corporation 6 Series/C200
Series Chipset Family Desktop SATA Controller (IDE mode, ports 0-3)
(rev 05)
├scsi 0:0:0:0 ATA      WDC WD100EFAX-68
│└sda 9.10t [8:0] Empty/Unknown
│ ├sda1 9.10t [8:1] Empty/Unknown
│ │└dm-2 9.10t [253:2] Empty/Unknown
│ └sda9 8.00m [8:9] Empty/Unknown
├scsi 0:0:1:0 ATA      WDC WD100EFAX-68
│└sdb 9.10t [8:16] Empty/Unknown
│ ├sdb1 9.10t [8:17] Empty/Unknown
│ │└dm-0 9.10t [253:0] Empty/Unknown
│ └sdb9 8.00m [8:25] Empty/Unknown
├scsi 1:0:0:0 ATA      WDC WD100EFAX-68
│└sdc 9.10t [8:32] Empty/Unknown
│ ├sdc1 9.10t [8:33] Empty/Unknown
│ │└dm-1 9.10t [253:1] Empty/Unknown
│ └sdc9 8.00m [8:41] Empty/Unknown
└scsi 1:0:1:0 ATA      WDC WD100EFAX-68
 └sdd 9.10t [8:48] Empty/Unknown
  ├sdd1 9.10t [8:49] Empty/Unknown
  └sdd9 8.00m [8:57] Empty/Unknown
PCI [ata_piix] 00:1f.5 IDE interface: Intel Corporation 6 Series/C200
Series Chipset Family Desktop SATA Controller (IDE mode, ports 4-5)
(rev 05)
└scsi 2:0:0:0 ATA      WDC WD100EFAX-68
 └sde 9.10t [8:64] Empty/Unknown
  ├sde1 9.10t [8:65] Empty/Unknown
  └sde9 8.00m [8:73] Empty/Unknown
PCI [pata_via] 03:00.0 IDE interface: VIA Technologies, Inc. VT6415
PATA IDE Host Controller
└scsi 4:x:x:x [Empty]
USB [usb-storage] Bus 002 Device 003: ID 0930:6545 Toshiba Corp.
Kingston DataTraveler 102/2.0 / HEMA Flash Drive 2 GB / PNY Attache
4GB Stick {000AEBFFB4C15B8A130501A6}
└scsi 6:0:0:0 Kingston DataTraveler 2.0
 └sdf 7.57g [8:80] Empty/Unknown
  └sdf1 7.57g [8:81] Empty/Unknown
   └Mounted as /dev/sdf1 @ /cdrom
Other Block Devices
├loop0 2.13g [7:0] Empty/Unknown
│└Mounted as /dev/loop0 @ /rofs
├loop1 61.96m [7:1] Empty/Unknown
│└Mounted as /dev/loop1 @ /snap/core20/1587
├loop2 4.00k [7:2] Empty/Unknown
│└Mounted as /dev/loop2 @ /snap/bare/5
├loop3 163.29m [7:3] Empty/Unknown
│└Mounted as /dev/loop3 @ /snap/firefox/1635
├loop4 91.69m [7:4] Empty/Unknown
│└Mounted as /dev/loop4 @ /snap/gtk-common-themes/1535
├loop5 400.80m [7:5] Empty/Unknown
│└Mounted as /dev/loop5 @ /snap/gnome-3-38-2004/112
├loop6 46.96m [7:6] Empty/Unknown
│└Mounted as /dev/loop6 @ /snap/snapd/16292
├loop7 284.00k [7:7] Empty/Unknown
│└Mounted as /dev/loop7 @ /snap/snapd-desktop-integration/14
├loop8 45.86m [7:8] Empty/Unknown
│└Mounted as /dev/loop8 @ /snap/snap-store/582
├loop9 9.09t [7:9] Empty/Unknown
│└dm-2 9.10t [253:2] Empty/Unknown
├loop10 9.09t [7:10] Empty/Unknown
│└dm-0 9.10t [253:0] Empty/Unknown
├loop11 9.09t [7:11] Empty/Unknown
│└dm-1 9.10t [253:1] Empty/Unknown
├loop12 0.00k [7:12] Empty/Unknown
└loop13 0.00k [7:13] Empty/Unknown

> Provided the data itself isn't damaged, you should be able to retrieve
> your array. Read up the section on overlays, that will protect your data
> from being overwritten while you play around trying to recover it.
>
> The other thing I would do here, is five drives is a lot to try and get
> right. I'd pick just three drives, and try to get them to assemble
> correctly (using overlays for safety!). Once you've got three drives to
> give you a functional array, you can then try and get the other two
> correct before the final recovery.
>
> What can you remember about the system? What version of superblock? And
> something I've noticed that seems weird, why do your drives have
> partitions 1 & 9, but not 2-8? That is well odd ... Have you rebuilt the
> array in any way, or is it exactly as originally created? Etc etc the
> more information you can give us the better.

I do not know the version of superblock, after the disks were
partitioned I just used "sudo mdadm --create ..." and everything went
smoothly. I didn't use any special configuration as far as I know, so
I'm not sure why the partitioning is odd. I have not rebuilt the
array, it still has the same disks as when it was created and it has
not suffered any failures.

>
> Let us know how you get on with this, and then we'll come back with more.
>
> Cheers,
> Wol

Steve

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Rebuilding mdadm RAID array after OS drive failure
  2022-10-17 22:46   ` Steve Kolk
@ 2022-10-18  7:04     ` Wols Lists
  0 siblings, 0 replies; 4+ messages in thread
From: Wols Lists @ 2022-10-18  7:04 UTC (permalink / raw)
  To: Steve Kolk, anthony; +Cc: linux-raid, Phil Turmel, NeilBrown

On 17/10/2022 23:46, Steve Kolk wrote:
> I set up 3 of the drives with overlays and tried forcing the assembly,
> but I still get the same error. I haven't tried the steps under
> "Irreversible mdadm failure recovery", is there where I need to go
> next?
> 
> ubuntu@ubuntu:~$ echo $OVERLAYS
> /dev/mapper/sda1 /dev/mapper/sdb1 /dev/mapper/sdc1
> ubuntu@ubuntu:~$ sudo mdadm --assemble --force /dev/md1 $OVERLAYS
> mdadm: no recogniseable superblock on /dev/mapper/sda1
> mdadm: /dev/mapper/sda1 has no superblock - assembly aborted

Sounds like you haven't understood what you're supposed to do.

The whole point of overlays is it is meant to protect the underlying 
device while you do stuff that could be destructive.

What you should be doing is setting up the overlays, then running "mdadm 
--create". It sounds like if you run exactly the same command as when 
you created the array, you'll get the original back.

Read up carefully on overlays to make sure you really understand what 
you're doing. And then when you create the array with the overlays, if 
you're doing as I suggested with three drives, make sure you tell it 
it's a five drive array, and tell it two of the drives are missing.

I'm just going to work, but whatever you do, DO NOT DO ANYTHING THAT 
WILL ACTUALLY WRITE TO THE DRIVES.

Cheers,
Wol

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-10-18  7:04 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-16 21:38 Rebuilding mdadm RAID array after OS drive failure Steve Kolk
2022-10-16 22:22 ` anthony
2022-10-17 22:46   ` Steve Kolk
2022-10-18  7:04     ` Wols Lists

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).