/ dev/md0にraid5アレイをmdadmで作成しましたが、約1年間問題なく動作していました。それぞれ1TBの3つのHDDで構成されています。数日前、電源障害とUPS障害がありました。残念ながら初めてではありませんでした。
OSはRAIDアレイの一部ではない別のSSDディスク(/ dev/sda)にあるため、起動しますが、アレイをマウントできませんもう。 / dev/md0がまったく存在しない場合があります。また、状況を悪化させる可能性のあることをしました。私は走ったfsck /dev/sdb -y
ディスクに何度も書き込んだ。
ファイルを復元できないのではないかと心配です。この問題の解決を手伝ってくれませんか?
ありがとう。
mount/dev/md0/mnt/raid5
mount: /dev/md0: can't read superblock
syslog:
Feb 25 15:59:53 pve kernel: [ 365.559378] EXT4-fs (md0): unable to read superblock
Feb 25 15:59:53 pve kernel: [ 365.560118] EXT4-fs (md0): unable to read superblock
Feb 25 15:59:53 pve kernel: [ 365.560216] EXT4-fs (md0): unable to read superblock
Feb 25 15:59:53 pve kernel: [ 365.560310] FAT-fs (md0): unable to read boot sector
cat/proc/mdstat
Personalities : [raid6] [raid5] [raid4]
unused devices: <none>
fdisk -l
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 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
Disklabel type: dos
Disk identifier: 0x75633c0d
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 1950353407 1950351360 930G fd Linux raid autodetect
Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 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
Disklabel type: gpt
Disk identifier: F397C12B-1549-45EA-97EA-6A41B713B58F
Device Start End Sectors Size Type
/dev/sdc1 2048 1950353407 1950351360 930G Linux RAID
Disk /dev/sdd: 931.5 GiB, 1000203804160 bytes, 1953523055 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
Disklabel type: dos
Disk identifier: 0xcced27e3
Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 1950353407 1950351360 930G fd Linux raid autodetect
時々fdisk -l
-bash: /sbin/fdisk: Input/output error
syslog:
Feb 25 16:03:25 pve kernel: [ 577.221547] ata1.00: SRST failed (errno=-16)
Feb 25 16:03:25 pve kernel: [ 577.232569] ata1.00: reset failed, giving up
Feb 25 16:03:25 pve kernel: [ 577.232640] ata1.00: disabled
Feb 25 16:03:25 pve kernel: [ 577.232643] ata1.01: disabled
Feb 25 16:03:25 pve kernel: [ 577.232658] ata1: EH complete
Feb 25 16:03:25 pve kernel: [ 577.232683] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 25 16:03:25 pve kernel: [ 577.232697] sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 05 13 a0 38 00 00 08 00
Feb 25 16:03:25 pve kernel: [ 577.232702] blk_update_request: I/O error, dev sda, sector 85172280
Feb 25 16:03:25 pve kernel: [ 577.232784] Buffer I/O error on dev dm-6, logical block 9255, lost sync page write
Feb 25 16:03:25 pve kernel: [ 577.232928] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 25 16:03:25 pve kernel: [ 577.232936] sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 02 88 6a 10 00 00 68 00
Feb 25 16:03:25 pve kernel: [ 577.232941] blk_update_request: I/O error, dev sda, sector 42494480
Feb 25 16:03:25 pve kernel: [ 577.232948] EXT4-fs error (device dm-6): kmmpd:176: comm kmmpd-dm-6: Error writing to MMP block
Sudo mdadm --examine/dev/sdb1
mdadm: No md superblock detected on /dev/sdb1.
Sudo mdadm --examine/dev/sdc1
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 34c11bda:11bbb8c9:c4cf5f56:7c38e1c3
Name : pve:0
Creation Time : Sun Jun 5 21:06:33 2016
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 1950089216 (929.88 GiB 998.45 GB)
Array Size : 1950089216 (1859.75 GiB 1996.89 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : active
Device UUID : be76ecf7:b0f28a7d:718c3d58:3afae9f7
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Feb 20 14:48:51 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : ffbc1988 - correct
Events : 2901112
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
Sudo mdadm --examine/dev/sdd1
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x9
Array UUID : 34c11bda:11bbb8c9:c4cf5f56:7c38e1c3
Name : pve:0
Creation Time : Sun Jun 5 21:06:33 2016
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 1950089216 (929.88 GiB 998.45 GB)
Array Size : 1950089216 (1859.75 GiB 1996.89 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : active
Device UUID : 7b9ed6e0:ffad7603:b226e752:355765a8
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Feb 20 14:48:51 2017
Bad Block Log : 512 entries available at offset 72 sectors - bad blocks present.
Checksum : 19b6f3da - correct
Events : 2901112
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
すべてのおかげで、データを回復しました。
残りの2つの良好なHDDからSudo mdadm --verbose --assemble --force /dev/md0 /dev/sdc1 /dev/sdd1
を実行してアレイを組み立てたところ、うまくいきました。
次に、sdbをフォーマットし、Sudo mdadm --manage /dev/md0 --add /dev/sdb1
を使用して配列に再度追加しました。新しいものを購入して、すぐに置き換えます。また、バックアップソリューションも探しています。
入出力エラーが発生した場合、1つ以上の不良ディスクがあると思います。コマンドsmartctl -a /dev/sdx
を使用して、すべてのディスクのSMART属性を確認する必要があります。コマンドUpdate Time
を使用して、各ディスクのstatus
とmdadm --examine /dev/sdx1
を確認します。最悪のスマート属性と最も古いUpdate Time
を持つ最悪のディスク魔女を1つ選択して、アレイから削除します。
不良ディスクが2つある場合は、不良ディスクを少なくする必要があり、プログラムddrecovery
によって新しいディスクに回復する必要があります。この不良ディスクを取り外し、同じ場所に新しい回復ディスクを挿入します。
次に、次のコマンドで、1つのディスクが失われたRAID 5アレイを復元できます(例:sdc
)。
mdadm --verbose --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 missing /dev/sdd1
chunk
パラメータが正常なディスクと同じであることを確認してください。
また、RAID 5アレイのメンバーではない不良sdaディスクがあります。
各コマンドには注意してください。 RAIDアレイを復元する唯一の方法があります。
例として this を読んでください。
Fsckを実行することは正しい考えでしたが、間違ったデバイスで実行したと思います。バックアップスーパーブロックを使用して、/ dev/md0でfsckを実行してみてください。 このリンク は、バックアップを見つけて修復する方法に関するヒントを提供します。特に、dumpe2fs
は、ファイルシステムのブロックサイズを見つける最善の方法です。最初のバックアップが破損している場合でも、ext4が他のバックアップを作成します。
いくつかの問題があります。
まず、/ dev/sdaは、OSがインストールされているRAIDアレイの一部ではなく、システムディスクであると言います。さて、あなたが私たちに示した正確なsyslogスニペットを見てください:
Feb 25 16:03:25 pve kernel: [ 577.232702] blk_update_request: I/O error, dev sda, sector 85172280
Feb 25 16:03:25 pve kernel: [ 577.232941] blk_update_request: I/O error, dev sda, sector 42494480
書き込み中に2つのI/Oエラーが発生し、システムディスク上の2つの異なる場所に、互いに1ミリ秒以内に報告されました。システムディスクに重大な問題があります。それを交換してください即時。あなたがそれにいる間、それにケーブルを交換することも価値があるかもしれません。私の経験では、I/Oエラーは通常、ケーブル接続またはディスクの問題を示しています(ただし、HBA canに問題があります)。この問題の結果として、システムディスク上のデータが少なくともある程度破損していることが予想されます。
2番目、fsck /dev/sdb -y
部分的なファイルシステムデータを理解し、適切と思われるものを自動的に書き出す際に、RAIDデータ全体に落書きをした可能性が非常に高いです。そのディスクを物理的に取り外し、システムから取り外し、今のところ安全な場所に置くことをお勧めします。死んだものとして扱います。
ありがたいことに、あなたは幸運です。システムはまだ3つすべてのディスクと通信しており、メタデータを保持している3つのディスクのうち2つのディスクでメタデータが正常に見えます。
3つの新しいディスクを取得し、ddrescue
を使用して、残りの2つのディスクから2つの新しいディスクに可能なすべてのものをコピーします。古いディスクを取り外し、それらを/ dev/sdbであったものと一緒に設定し(どのディスクがどれかを追跡していることを確認してください)、2つ目の新しいディスクと3つ目の新しい空の1つを接続します。
結果の配列をmdadmに送り、mdが結果の状況を理解できるように選択した神に祈ります。運がよければ、ほとんどのデータを読み取り可能状態に復元できます(新しいディスクを取り込んだため)読み取りエラーがなくなったためです。繰り返しになりますが、場所によっては破損している可能性があります。
3番目に、UPSの障害の原因を突き止めて修正し、定期的にバックアップを設定して、最悪の事態が発生した場合でも、少なくともバックアップを取得できるようにします。新しいメディアに復元できること。このインシデントを学習体験として説明します RAIDがバックアップではない理由 。