RAID6は即座に失敗し、RAID0に切り替えました-救助するチャンスはありますか？

Question

Ubuntu16.04でサーバーを実行しています。このシステムのデータストレージは、ソフトウェアRAID 6の上にlvmを使用しますが、osはlvmを使用して別のRAID1にインストールされます。レイド6は、7つのディスク上の7つのパーティションで構成されています。これらのディスクの1つでs.m.a.r.tエラーが発生した後、アレイが劣化する前に、このディスクを新しいディスクに交換することにしました。

ディスクを交換する前に、Sudo mdadm /dev/md2 --fail /dev/sdd4を実行し、続いてSudo mdadm /dev/md2 --remove /dev/sdd4を実行しました。次の起動後、すべてが問題ないようだったので、新しいディスクのパーティション分割を開始しました。他のディスクのパーティショニングを調整するためにSudo parted --listを実行しました。

この時点で、奇妙な問題が発生し、partedは古いディスクの1つにアクセスする際に問題が発生しました。別のドライブがアレイから外れ、数秒後に別のドライブがなくなったことに気づきました。アレイが失敗しました。私はショックを受け、さらなるエラーを防ぐためにシステムをシャットダウンしました。

後でシステムを再起動しようとしましたが、次のような奇妙な障害が発生しました。

ata2: irq_stat 0x00000040, connection status changed ata2: SError: { CommWake DevExch }

現時点では緊急コンソールしか持っていなかったので、問題をさらに調査するためにライブLinuxを起動しました。配列を修正するためにmdadm --assemble --scanを安全に実行できることを読みましたが、それは奇妙な状態のままなので、mdadm.confとfstabから配列を削除しただけです。

現在、レイドは7つのスペアドライブを備えたraid0として表示されていますが、残りのRAID1ではドライブは最後の数時間は正常に実行されているようです。

今何をすべきかわからないので、すべてのデータが失われることを期待していますが、データの少なくとも一部を救済する機会があることも望んでいます。バックアップはありますが、19TBのアレイだったので一部しかありません。

ディスクを交換する前の状態

chris@uranus:~$ Sudo mdadm --detail /dev/md2 /dev/md2: Version : 1.2 Creation Time : Thu Aug 6 00:45:41 2015 Raid Level : raid6 Array Size : 18723832320 (17856.44 GiB 19173.20 GB) Used Dev Size : 3744766464 (3571.29 GiB 3834.64 GB) Raid Devices : 7 Total Devices : 7 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Fri Jul 13 17:39:04 2018 State : clean Active Devices : 7 Working Devices : 7 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 512K Name : uranus:2 (local to Host uranus) UUID : 607914eb:666e2a46:b2e43557:02cc2983 Events : 2738806 Number Major Minor RaidDevice State 0 8 20 0 active sync /dev/sdb4 1 8 36 1 active sync /dev/sdc4 2 8 52 2 active sync /dev/sdd4 6 8 1 3 active sync /dev/sda1 5 8 68 4 active sync /dev/sde4 8 8 97 5 active sync /dev/sdg1 7 8 81 6 active sync /dev/sdf1

実情

chris@uranus:/$ Sudo mdadm --detail /dev/md2 /dev/md2: Version : 1.2 Raid Level : raid0 Total Devices : 6 Persistence : Superblock is persistent State : inactive Name : uranus:2 (local to Host uranus) UUID : 607914eb:666e2a46:b2e43557:02cc2983 Events : 2739360 Number Major Minor RaidDevice - 8 1 - /dev/sda1 - 8 20 - /dev/sdb4 - 8 36 - /dev/sdc4 - 8 68 - /dev/sde4 - 8 81 - /dev/sdf1 - 8 97 - /dev/sdg1

物事を明確にするために

6台のドライブに障害はなく、7台目のドライブにエラーがありましたが、新しいドライブに切り替えました。この1つの障害のあるドライブの切り替え後、スマートデータはすべてのドライブに適しています。エラー、不良ブロック、保留中、修正不可能、または再割り当てされたセクターはありません。

新しいドライブを既存のアレイに追加しなかったため、最後の--detailには6台のドライブしか表示されません。

OSが依存するレイド1は、基本的に同じ7つのディスクの3 + 1スペアでしたが、独自のパーティションでした。/dev/sddを削除すると、スペアドライブが代わりに使用されるため、スペアのない3つのパーティションで構成されます。また、これらのディスクの3つにブートパーティションがあり、これらのディスクの2つのRAID1にスワップパーティションがあります。

問題は、mdadmがcat /proc/mdstatが示すように、このアレイを7つのスペアを持つRAID 0として表示し、7つのドライブのうち6つが劣化状態にある元のraid6構成に戻す必要があることです。設定に問題があるようですが、これでは何も変更していません。アレイを復元できた場合にのみ、切り替えられた7番目のパーティションをアレイに追加して元の7番目のドライブraid6を取得します。

マンページを正しく読んだ場合、mdadm --assemble --scanは構成または/proc/mdstatに基づいてアレイ情報を復元しますが、これらはすでに間違っているようです。

さらにいくつかの出力

cat /proc/mdstat-今

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : inactive sdg1[8](S) sdf1[7](S) sdb4[0](S) sda1[6](S) sde4[5](S) sdc4[1](S) 22468633600 blocks super 1.2 md129 : active raid1 sdb3[0] sde3[4] sdc3[1] 146353024 blocks super 1.2 [3/3] [UUU] md128 : active raid1 sdb2[0] sde2[4](S) sdc2[1] 15616896 blocks super 1.2 [2/2] [UU] unused devices: <none>

cat /etc/mdadm/mdadm.conf-今

#DEVICE partitions containers # auto-create devices with Debian standard permissions CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system HOMEHOST <system> # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md128 metadata=1.2 UUID=6813258b:250929d6:8a1e9d34:422a9fbd name=uranus:128 spares=1 ARRAY /dev/md129 metadata=1.2 UUID=ab06d13f:a70de5a6:c83a9383:b1beb84c name=uranus:129 ARRAY /dev/md2 metadata=1.2 UUID=607914eb:666e2a46:b2e43557:02cc2983 name=uranus:2 # This file was auto-generated on Mon, 10 Aug 2015 18:09:47 +0200 # by mkconf $Id$ #ARRAY /dev/md/128 metadata=1.2 UUID=6813258b:250929d6:8a1e9d34:422a9fbd name=uranus:128 # spares=2 #ARRAY /dev/md/129 metadata=1.2 UUID=ab06d13f:a70de5a6:c83a9383:b1beb84c name=uranus:129 # spares=1 #ARRAY /dev/md/2 metadata=1.2 UUID=607914eb:666e2a46:b2e43557:02cc2983 name=uranus:2

cat /etc/fstab-今

# <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vgSystem-vRoot / ext4 errors=remount-ro 0 1 # swap was on /dev/md128 during installation UUID=5a5b997d-9e94-4391-955f-a2b9a3f63820 none swap sw 0 0 #/dev/vgData/vData /srv ext4 defaults 0 0 #10.10.0.15:/srv/BackupsUranusAutomatic/data /mnt/mars/uranus/automatic/data nfs clientaddr=10.10.0.10,vers=4,noatime,addr=10.10.0.15,noauto 0 0 #10.10.0.15:/srv/BackupsUranusAutomatic/media /mnt/mars/uranus/automatic/media nfs clientaddr=10.10.0.10,vers=4,noatime,addr=10.10.0.15,noauto 0 0 #/srv/shares/Videos/Ungesichert/Videorecorder /srv/vdr/video bind bind 0 0 #/dev/sdh1 /mnt/usbdisk ntfs noatime,noauto 0 0

ディスクとパーティション-問題が発生する前

Medium /dev/sda: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Typ der Medienbezeichnung: gpt Medienkennung: 98C35BD3-BFBC-4A4B-AEC9-6D4AFB775AF4 Gerät Start Ende Sektoren Größe Typ /dev/sda1 2048 7489808383 7489806336 3,5T Linux RAID /dev/sda2 7489808384 7791525887 301717504 143,9G Linux RAID Medium /dev/sdb: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Typ der Medienbezeichnung: gpt Medienkennung: 49102EF7-9FA2-4990-8C30-6C5B463B917E Gerät Start Ende Sektoren Größe Typ /dev/sdb1 2048 20479 18432 9M BIOS boot /dev/sdb2 20480 31270911 31250432 14,9G Linux RAID /dev/sdb3 31270912 324239359 292968448 139,7G Linux RAID /dev/sdb4 324239360 7814035455 7489796096 3,5T Linux RAID Medium /dev/sdc: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Typ der Medienbezeichnung: gpt Medienkennung: 6A037D00-F252-4CA0-8D68-430734BCA765 Gerät Start Ende Sektoren Größe Typ /dev/sdc1 2048 20479 18432 9M BIOS boot /dev/sdc2 20480 31270911 31250432 14,9G Linux RAID /dev/sdc3 31270912 324239359 292968448 139,7G Linux RAID /dev/sdc4 324239360 7814035455 7489796096 3,5T Linux RAID Medium /dev/sdd: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Typ der Medienbezeichnung: gpt Medienkennung: EADC29D6-C2E9-4AC8-B1B2-F01A5233467C Gerät Start Ende Sektoren Größe Typ /dev/sdd1 2048 20479 18432 9M BIOS boot /dev/sdd2 20480 31270911 31250432 14,9G Linux RAID /dev/sdd3 31270912 324239359 292968448 139,7G Linux RAID /dev/sdd4 324239360 7814035455 7489796096 3,5T Linux RAID Medium /dev/sde: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Typ der Medienbezeichnung: gpt Medienkennung: 3D7EBBFD-C00D-4503-8BF1-A71534F643E1 Gerät Start Ende Sektoren Größe Typ /dev/sde1 2048 20479 18432 9M Linux filesystem /dev/sde2 20480 31270911 31250432 14,9G Linux filesystem /dev/sde3 31270912 324239359 292968448 139,7G Linux filesystem /dev/sde4 324239360 7814035455 7489796096 3,5T Linux filesystem Medium /dev/sdf: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Typ der Medienbezeichnung: gpt Medienkennung: FCA42FC2-C5E9-45B6-9C18-F103C552993D Gerät Start Ende Sektoren Größe Typ /dev/sdf1 2048 7489824767 7489822720 3,5T Linux RAID /dev/sdf2 7489824768 7791525887 301701120 143,9G Linux RAID Medium /dev/sdg: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Typ der Medienbezeichnung: gpt Medienkennung: 8FF8C4CC-6788-47D7-8264-8FA6EF912555 Gerät Start Ende Sektoren Größe Typ /dev/sdg1 2048 7489824767 7489822720 3,5T Linux RAID /dev/sdg2 7489824768 7791525887 301701120 143,9G Linux RAID Medium /dev/md2: 17,4 TiB, 19173204295680 Bytes, 37447664640 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 524288 Bytes / 2621440 Bytes Medium /dev/md128: 14,9 GiB, 15991701504 Bytes, 31233792 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Medium /dev/md129: 139,6 GiB, 149865496576 Bytes, 292706048 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Medium /dev/mapper/vgSystem-vRoot: 74,5 GiB, 79997960192 Bytes, 156246016 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Medium /dev/mapper/vgData-vData: 17,4 TiB, 19173199577088 Bytes, 37447655424 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 524288 Bytes / 2621440 Bytes Medium /dev/mapper/vgSystem-testBtrfs: 5 GiB, 5368709120 Bytes, 10485760 Sektoren Einheiten: sectors von 1 * 512 = 512 Bytes Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes

ディスク、パーティション、RAIDデバイス、およびボリューム-問題が発生する前

NAME UUID FSTYPE MOUNTPOINT LABEL SIZE sda 3,7T ├─sda1 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T │ └─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T │ └─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T └─sda2 143,9G sdb 3,7T ├─sdb1 9M ├─sdb2 6813258b-2509-29d6-8a1e-9d34422a9fbd linux_raid_member uranus:128 14,9G │ └─md128 5a5b997d-9e94-4391-955f-a2b9a3f63820 swap [SWAP] 14,9G ├─sdb3 ab06d13f-a70d-e5a6-c83a-9383b1beb84c linux_raid_member uranus:129 139,7G │ └─md129 7QXSVM-dauj-RUQ1-uoQp-IamT-TTZo-slzArT LVM2_member 139,6G │ ├─vgSystem-vRoot fb4bfbb3-de6c-47ef-b237-27af04fa2f4c ext4 / root 74,5G │ └─vgSystem-testBtrfs 27bbab4c-3c9f-4743-83ac-61e8b41f2bd3 btrfs 5G └─sdb4 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T └─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T └─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T sdc 3,7T ├─sdc1 9M ├─sdc2 6813258b-2509-29d6-8a1e-9d34422a9fbd linux_raid_member uranus:128 14,9G │ └─md128 5a5b997d-9e94-4391-955f-a2b9a3f63820 swap [SWAP] 14,9G ├─sdc3 ab06d13f-a70d-e5a6-c83a-9383b1beb84c linux_raid_member uranus:129 139,7G │ └─md129 7QXSVM-dauj-RUQ1-uoQp-IamT-TTZo-slzArT LVM2_member 139,6G │ ├─vgSystem-vRoot fb4bfbb3-de6c-47ef-b237-27af04fa2f4c ext4 / root 74,5G │ └─vgSystem-testBtrfs 27bbab4c-3c9f-4743-83ac-61e8b41f2bd3 btrfs 5G └─sdc4 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T └─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T └─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T sdd 3,7T ├─sdd1 9M ├─sdd2 6813258b-2509-29d6-8a1e-9d34422a9fbd linux_raid_member uranus:128 14,9G │ └─md128 5a5b997d-9e94-4391-955f-a2b9a3f63820 swap [SWAP] 14,9G ├─sdd3 ab06d13f-a70d-e5a6-c83a-9383b1beb84c linux_raid_member uranus:129 139,7G │ └─md129 7QXSVM-dauj-RUQ1-uoQp-IamT-TTZo-slzArT LVM2_member 139,6G │ ├─vgSystem-vRoot fb4bfbb3-de6c-47ef-b237-27af04fa2f4c ext4 / root 74,5G │ └─vgSystem-testBtrfs 27bbab4c-3c9f-4743-83ac-61e8b41f2bd3 btrfs 5G └─sdd4 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T └─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T └─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T sde 3,7T ├─sde1 9M ├─sde2 6813258b-2509-29d6-8a1e-9d34422a9fbd linux_raid_member uranus:128 14,9G │ └─md128 5a5b997d-9e94-4391-955f-a2b9a3f63820 swap [SWAP] 14,9G ├─sde3 ab06d13f-a70d-e5a6-c83a-9383b1beb84c linux_raid_member uranus:129 139,7G │ └─md129 7QXSVM-dauj-RUQ1-uoQp-IamT-TTZo-slzArT LVM2_member 139,6G │ ├─vgSystem-vRoot fb4bfbb3-de6c-47ef-b237-27af04fa2f4c ext4 / root 74,5G │ └─vgSystem-testBtrfs 27bbab4c-3c9f-4743-83ac-61e8b41f2bd3 btrfs 5G └─sde4 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T └─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T └─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T sdf 3,7T ├─sdf1 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T │ └─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T │ └─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T └─sdf2 143,9G sdg 3,7T ├─sdg1 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T │ └─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T │ └─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T └─sdg2

アレイデバイススーパーブロック

mdadm --examine /dev/sd<array-member-harddrives>-今

7番目の「新しい」ドライブがまだアレイに追加されていないため、ドライブは6つしかありません。

chris@uranus:/$ Sudo mdadm --examine /dev/sda1 [Sudo] Passwort für chris: /dev/sda1: Magic : a92b4efc Version : 1.2 Feature Map : 0x1 Array UUID : 607914eb:666e2a46:b2e43557:02cc2983 Name : uranus:2 (local to Host uranus) Creation Time : Thu Aug 6 00:45:41 2015 Raid Level : raid6 Raid Devices : 7 Avail Dev Size : 7489544192 (3571.29 GiB 3834.65 GB) Array Size : 18723832320 (17856.44 GiB 19173.20 GB) Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=11264 sectors State : active Device UUID : 49c6404e:ee9509ba:c980942a:1db9cf3c Internal Bitmap : 8 sectors from superblock Update Time : Fri Jul 13 22:34:48 2018 Checksum : aae603a7 - correct Events : 2739360 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 3 Array State : AA.AAAA ('A' == active, '.' == missing, 'R' == replacing) chris@uranus:/$ Sudo mdadm --examine /dev/sdb4 /dev/sdb4: Magic : a92b4efc Version : 1.2 Feature Map : 0x1 Array UUID : 607914eb:666e2a46:b2e43557:02cc2983 Name : uranus:2 (local to Host uranus) Creation Time : Thu Aug 6 00:45:41 2015 Raid Level : raid6 Raid Devices : 7 Avail Dev Size : 7489533952 (3571.29 GiB 3834.64 GB) Array Size : 18723832320 (17856.44 GiB 19173.20 GB) Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=1024 sectors State : clean Device UUID : 61d97294:3ce7cd84:7bb4d5f1:d301c842 Internal Bitmap : 8 sectors from superblock Update Time : Fri Jul 13 22:42:15 2018 Checksum : 890fbe3d - correct Events : 2739385 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 0 Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing) chris@uranus:/$ Sudo mdadm --examine /dev/sdc4 /dev/sdc4: Magic : a92b4efc Version : 1.2 Feature Map : 0x1 Array UUID : 607914eb:666e2a46:b2e43557:02cc2983 Name : uranus:2 (local to Host uranus) Creation Time : Thu Aug 6 00:45:41 2015 Raid Level : raid6 Raid Devices : 7 Avail Dev Size : 7489533952 (3571.29 GiB 3834.64 GB) Array Size : 18723832320 (17856.44 GiB 19173.20 GB) Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=1024 sectors State : clean Device UUID : ee70c4ab:5b65dae7:df3a78f0:e8bdcead Internal Bitmap : 8 sectors from superblock Update Time : Fri Jul 13 22:42:15 2018 Checksum : 6d171664 - correct Events : 2739385 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 1 Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing) chris@uranus:/$ Sudo mdadm --examine /dev/sde4 /dev/sde4: Magic : a92b4efc Version : 1.2 Feature Map : 0x1 Array UUID : 607914eb:666e2a46:b2e43557:02cc2983 Name : uranus:2 (local to Host uranus) Creation Time : Thu Aug 6 00:45:41 2015 Raid Level : raid6 Raid Devices : 7 Avail Dev Size : 7489533952 (3571.29 GiB 3834.64 GB) Array Size : 18723832320 (17856.44 GiB 19173.20 GB) Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=1024 sectors State : clean Device UUID : 6ce5311f:084ded8e:ba3d4e06:43e38c67 Internal Bitmap : 8 sectors from superblock Update Time : Fri Jul 13 22:42:15 2018 Checksum : 572b9ac7 - correct Events : 2739385 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 4 Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing) chris@uranus:/$ Sudo mdadm --examine /dev/sdf1 /dev/sdf1: Magic : a92b4efc Version : 1.2 Feature Map : 0x1 Array UUID : 607914eb:666e2a46:b2e43557:02cc2983 Name : uranus:2 (local to Host uranus) Creation Time : Thu Aug 6 00:45:41 2015 Raid Level : raid6 Raid Devices : 7 Avail Dev Size : 7489560576 (3571.30 GiB 3834.66 GB) Array Size : 18723832320 (17856.44 GiB 19173.20 GB) Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=27648 sectors State : clean Device UUID : 7c4fbe19:d63eced4:1b40cf79:e759fe4b Internal Bitmap : 8 sectors from superblock Update Time : Fri Jul 13 22:36:17 2018 Checksum : ef93d641 - correct Events : 2739381 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 6 Array State : AA..A.A ('A' == active, '.' == missing, 'R' == replacing) chris@uranus:/$ Sudo mdadm --examine /dev/sdg1 /dev/sdg1: Magic : a92b4efc Version : 1.2 Feature Map : 0x1 Array UUID : 607914eb:666e2a46:b2e43557:02cc2983 Name : uranus:2 (local to Host uranus) Creation Time : Thu Aug 6 00:45:41 2015 Raid Level : raid6 Raid Devices : 7 Avail Dev Size : 7489560576 (3571.30 GiB 3834.66 GB) Array Size : 18723832320 (17856.44 GiB 19173.20 GB) Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=27648 sectors State : clean Device UUID : 36d9dffc:27699128:e84f87e7:38960357 Internal Bitmap : 8 sectors from superblock Update Time : Fri Jul 13 22:35:47 2018 Checksum : 9f34d651 - correct Events : 2739377 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 5 Array State : AA..AAA ('A' == active, '.' == missing, 'R' == replacing)

Leo · Answer

これが発生したとき、ドライブが1つダウンしていました（交換したドライブ）。

この時点で、奇妙な問題が発生し、partedは古いディスクの1つにアクセスする際に問題が発生しました。別のドライブがアレイから外れ、数秒後に別のドライブがなくなったことに気づきました。アレイが失敗しました。私はショックを受け、さらなるエラーを防ぐためにシステムをシャットダウンしました。

失敗が致命的だった場合、それは3つのドライブになります。

OSはRAID1上にあるとおっしゃいましたが、それらは2つのディスクであり、他の7つのディスクはRAID6上にあると思います。

RAID 6は、アレイ内の2つのディスクの損失に耐えることができます。 RAID 6アレイで3つの障害が発生し（障害が発生したディスクがRAID 1のものではないと仮定）、ディスクの状態が良好でない場合は、データが失われている可能性があります。

各ディスクの状態は、次の方法で確認できます。

Sudo smartctl -a /dev/sdX

そして、3つのディスクが出ているのか、それともまぐれだったのかを知ることができます。 それがまぐれで、すべてがOKであると確信している場合、配列が非アクティブのように見えるため、mdadm.confとfstabが正しいこと、次に、（警告：危険、以下の免責事項をお読みください）を使用して強制的に再アセンブルを試みることができます。

Sudo mdadm --stop /dev/md2 Sudo mdadm --assemble --scan --force

注：最後に--detail出力には、7つではなく6つのディスクが表示されます。/dev/sddが欠落しているようです。

mdadm.conf、fstabおよびLVM VG、LV、およびパーティションを貼り付けて、構成を理解するのに役立てることができます。

免責事項：RAIDが壊れているものを試すのは危険です。提供された情報に基づいた手順をお勧めします。それが機能すること、またはデータが破壊されないことを保証することはできません。あなた自身の責任の下でそしてあなた自身のリスクで走ってください。

hargut · Answer

現在の状態の概要を把握するために、分析する方法/内容についていくつかのアイデアを提供します。

最初のセクションは、あまり面白くなく、すべての配列メンバーで同じである必要があります。

 Magic : a92b4efc Version : 1.2 Feature Map : 0x1 Array UUID : 607914eb:666e2a46:b2e43557:02cc2983 Name : uranus:2 (local to Host uranus) Creation Time : Thu Aug 6 00:45:41 2015 Raid Level : raid6 Raid Devices : 7 Avail Dev Size : 7489544192 (3571.29 GiB 3834.65 GB) Array Size : 18723832320 (17856.44 GiB 19173.20 GB) Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB)

まだあまり面白くありませんが、ディスクのサイズが同じでない場合、オフセットが異なる場合があります。 UUIDはハードドライブのUUIDであり、ドライブごとに一意です。

 Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=11264 sectors State : active Device UUID : 49c6404e:ee9509ba:c980942a:1db9cf3c Internal Bitmap : 8 sectors from superblock

ここでそれは面白くなり始めます、コメントは#で始まります：

 Update Time : Fri Jul 13 22:34:48 2018 # last write activity on the drive Checksum : aae603a7 - correct # should be equal on all disks, when the state is clean Events : 2739360 # Events on the disk, in bock/chunk units Layout : left-symmetric # could be relevant for rebuilding the array, left-symmetric is default for x86 Chunk Size : 512K

次のセクションは、特にコマンドを作成するときにDevice Roleが重要である場合に配列を再構築するために興味深いものです。

 Device Role : Active device 3 Array State : AA.AAAA ('A' == active, '.' == missing, 'R' == replacing)

配列の状態は情報を提供するだけですが、あまり役に立ちません。

まず、How far have disks run apart during the failure?のアイデアを取得したいと思います

正しく思い出せば、50を試行すると、mdadmコードにassemble --forceイベントのしきい値があります。つまり、イベントに違いがある場合、>50 assemble --forceは機能しなくなります。 <50イベントに違いがあるとしても、アセンブリの強制が機能することを保証するものではありません。このような場合、唯一の可能性は、既存のパラメーターとまったく同じパラメーターを使用して配列を再作成し、mdadmに--create --assume-cleanを指示することです。すべてのスーパーブロックが利用可能で読み取り可能な「幸運な」状況にある場合、これは非常に「簡単に」可能であるはずですが、注意が必要です。

イベントカウントは、最初のディスクが最初に、次に最後に、次に最後に1つだけ消えたように見えます。違いは<50で、最終的にはかなり簡単になる可能性があります。

 Events : 2739360 Events : 2739385 Events : 2739385 Events : 2739385 Events : 2739381 Events : 2739377

Array Stateを正しく解釈するには、EventsカウントとDrive Roleに注意を払う必要があります。

Device Role : Active device 3 Device Role : Active device 0 Device Role : Active device 1 Device Role : Active device 4 Device Role : Active device 6 Device Role : Active device 5 Array State : AA.AAAA ('A' == active, '.' == missing, 'R' == replacing) Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing) Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing) Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing) Array State : AA..A.A ('A' == active, '.' == missing, 'R' == replacing) Array State : AA..AAA ('A' == active, '.' == missing, 'R' == replacing)

mdadmは0からカウントを開始します。ドライブ2が最初に失敗し、次にドライブ3、後でドライブ5、最後にドライブ6で失敗しました。ドライブ5は引き続きドライブ6をアクティブとしてリストし、ドライブ3は3、5、および6をアクティブとしてリストすることに注意してください。したがって、別のドライブに障害が発生したときに、ドライブがスーパーブロックを更新していない可能性があります。

Array Statesを見た後、assemble --force上の5つのデバイス間で一貫性がないため、自動Array Stateはうまく機能しないと思います。アレイはraid6で7つのディスクがあるため、この場合、Array Stateに同意し、イベントの差が50未満のディスクが5つ必要になりますが、そうではありません。

mdadm/raidは、データを失わないように構築されていることを忘れないでください。そのため、コードには、データに害を及ぼす可能性のあるアクションからmdadmを防ぐメカニズムがあります。自動再アセンブリは、-forceを使用しても、成功する可能性が非常に高いアクションのみをトリガーします。 mdadmが保存を決定するのに十分な/一貫性のある情報がスーパーブロックにない場合、失敗します。自分が何をしているのかを本当に知っている場合は、スーパーブロックをcreate --assume-cleanと、レイドを操作に戻すために必要なすべての情報で簡単に書き直すことができます。ただし、これは手動のタスクであり、管理者/ユーザーとしてソフトウェアに正確に何をするかを指示する必要があります。

ここでは、コピー＆ペーストコマンドを提供しません。このような状況では、「repair-my-raid」コマンドを実行する前に何をするかを知っておくことが不可欠だと思うからです。そして知識を深めるには、Linux RAIDWikiのRAIDRecovery関連の記事全体を読むことが不可欠であり、この答えに対する私の結論です。

https://raid.wiki.kernel.org/index.php/Linux_Raid#When_Things_Go_Wrogn https://raid.wiki.kernel.org/index.php/RAID_Recovery https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID

hargut · Answer

mdadmはsuperblocksを使用して、ディスクの組み立て方法などを決定します。このような場合、物理ドライブの実際のスーパーブロックデータを確認することは常に非常に役立ち、有益です前実行任意アクション書き込み何かディスク（例：mdadm --assemble --scan --force、mdadmスーパーブロックを更新します）。

使用する mdadm --examine /dev/sd<your-array-member-harddrives>スーパーブロックに何が含まれているかを確認します。何かが失敗したときの印象、書き込みに関してディスク間にどれだけのオフセットがあるかなどがわかります。

is物理ドライブの現在の状態を明確に把握した後、問題を修正するための戦略を立てることができます。

しかし、まず第一に、メインボード/ sata-controller/scsi-controller/...に物理的な欠陥があると思います。非常に多くのディスクが非常に短い時間内に故障することはまれであり（同じメーカーのすべてのディスクを使用し、RAIDシステムを構築するために生産バッチを使用するという素晴らしいアイデアを持っていた場合を除く）、コントローラーに問題があることを示している可能性があります。ハードディスクコントローラーで破損したレイドを再構築/再同期すると、最終的に失敗しますが、災害につながるだけです。

hargut · Answer

1. Would you suggest first trying --assemble --force, maybe with an overlay file?

私の見解では、これは間違いなく最初に試すオプションです。オーバーレイファイルを使用するかどうかは、データとリスク意欲によって異なります。これまでのところ、このような状況ではバックアップがあったため、オーバーレイオプションを使用しませんでした。安全を確保したい場合は、それを使用してください。その分野で強調したい点がいくつかあります。

Mdadm < 4.0バージョンの使用を検討しないでください。バックポートを作成するか、バージョン>= 4.0をコンパイルします。 3.xにはいくつかのバグがあり、その結果、assemble --forceでうまく機能する4.0アクションが失敗しました。
assemble --force use --verboseを試すと、次の手順や何が起こったか、何が失敗したかを理解するのに役立つ一連の優れた情報が得られます。

2. If i use a --create --assume-clean, is it a better choice to create the last functioning setup with 6 disks or maybe a setup with only 5 drives that have the highest event count? The Is this even possible? My goal is restoring some important data from the array and no permanent solution.

あなたの場合、イベントオフセットがこれほど小さい場合、6/7ディスクでアレイを再作成しても問題はないと思います。 HBA（sata/ide/scsiコントローラー）に問題があると思われる場合は、最終的には疑わしいポートを除外することを検討する必要があります。しかし、それはハードウェアと配線に依存します。はい、可能ですが、レイドの種類によって異なります。 raid6を使用すると、5/7ディスクのみで再構築を試みることができますが、技術的にはそれを行うための制限はありません。重要なのは、5/7で再作成した場合、ドライブに障害が発生するオプションがなくなることです。

3. I have details about the array before the crash occured. According to this i would come up with a mdadm --create --assume-clean --level=6 --raid-devices=7 --size=3744766464 /dev/sdb4 /dev/sdc4 missing /dev/sda1 /dev/sde4 /dev/sdg1 /dev/sdf1 for 6 drives, respectively mdadm --create --assume-clean --level=6 --raid-devices=7 --size=3744766464 /dev/sdb4 /dev/sdc4 missing missing /dev/sde4 /dev/sdg1 /dev/sdf1 on a 5 drive solution. Would you agree with this?

詳細（ドライブの順序、サイズ、欠落している位置など）は確認していませんが、コマンドは適切に見えます。それでも、Linux Raid Wikiで言及されているように、レクリエーションは[〜＃〜] last [〜＃〜]リゾートと見なす必要があります。そうする必要があるとき、私は常にできるだけ具体的にするように努めます。前回mdadmのマンページを調べて、自分が持っている情報からデータを知っているすべてのオプションを追加したことを覚えておいてください（たとえば、チャンクサイズ、配置など）。省略できるデフォルトはたくさんありますが、値がはっきりしている場合は、具体的にしないでください。

私があなたの状況で試みることは次のとおりです：

mdadmを>=4.0のバージョンに引き上げます
アレイが実行されている場合は、アレイを停止します。 /proc/mdstatを確認し、mdadm --stop ...を使用します。
ディスクとHBA（sata/ide/scsiコントローラー）を確認します。 dmesgおよびsmartctlログを確認してください。ディスクからの読み取りを試みます（例：dd if=/dev/hda1 of=/dev/null bs=1M count=2048。dmesgおよびsmartctlログを再確認します。それを繰り返し、ibs=およびskip=を追加します。。dmesgおよびsmartctlログを再確認します。resets|timeouts|failuresHBAにata|sata|scsi|...が表示された場合は、そのハードウェアを使用するディスク上のすべての手順を停止します。
すべてのディスクでディスクとHBAの検証を繰り返します。
mdadm --assemble --scan --verboseを実行します。これは失敗する可能性が最も高いですが、mdadmが検出する内容の概要を示し、それをforceしたときに何が起こるかについてのアイデアを提供します。
上記の出力を調べて、表示されているものが、ドライブ/アレイに関してすでに収集した情報と一致するかどうかを確認します。
アレイが実行中または開始された場合は、アレイを停止します。
Mdadmが--assemble --scan --verboseで何をするかに満足している場合は、--forceを試してください。
それがすべて失敗した場合は、フルディスクバックアップを作成（またはオーバーレイファイルを作成）してから、[〜＃〜] last [〜＃〜]リゾートの道に戻り、全体を再作成します仮定クリーンな配列と、配列から収集したすべての情報。