サーバーにRAID 5アレイをインストールできません。 「スーパーブロックを読み取れません。」

サーバーにRAID 5アレイをインストールできません。 「スーパーブロックを読み取れません。」

私はサーバーとRAIDアレイを初めて使用していましたが、最近サーバーにインストールするのに問題があったRAID 5アレイを回復しようとしています。正直言って、私が最初からこのフォーメーションを立てたわけではありません。プログラムとファイルを管理するために、CentOS 7がインストールされているDell 2950 PowerEdgeサーバーを使用しています。再起動後にサーバーを起動できないときに問題が発生しました。現在の設定では、マスターサーバーの起動時にアレイをマウントしようとします。現在 /etc/fstab にあるコマンドは、起動時にサーバーの競合を引き起こすため、サーバーの起動時にコメントアウトされます。サーバーが起動したら、その行のコメントを削除します。

/dev/sdc  /array   ext4   defaults    1 2

その後、インストールしようとすると、次のようになります。

mount /array

次のメッセージが表示されます。

mount: wrong fs type, bad option, bad superblock on /dev/sdc,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

末尾のdmesg:

[1625373.377926] sd 1:2:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
[1625373.377929] sd 1:2:0:0: [sdc] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
[1625373.377931] blk_update_request: I/O error, dev sdc, sector 0
[1625373.377933] Buffer I/O error on dev sdc, logical block 0, async page read
[1633765.092732] nf_conntrack: falling back to vmalloc.
[1633765.093244] nf_conntrack: falling back to vmalloc.
[1633782.909748] sd 1:2:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
[1633782.909757] sd 1:2:0:0: [sdc] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 02 00 00 00 02 00 00
[1633782.909761] blk_update_request: I/O error, dev sdc, sector 2
[1633782.909782] EXT4-fs (sdc): unable to read superblock

間違ったスーパーブロックがあるようです。この問題を解決するには、どこから始めるべきかわかりません。可能であれば、データ損失(10TB以上)なしでアレイ全体を再フォーマットしたくありません。他の有用な情報は、これがMD対応のサーバーではないため(おそらく最初はそうではなかったことは明らかです)、mdadmコマンドが適用されないことです。 EXT4ファイルシステムに設定されています。また、このアレイが5年前に初期化されたときに正しく分割された可能性もありません。つまり、sdc0、sdc1などはありませんでした。これがもたらす可能性のある全体的な結果はわかりませんが、一部の関数/スクリプトでは配列が適切に分割されていると仮定しているため、誤って使用すると「毛が多くなる」ことがあります。この問題に関連する支援をいただきありがとうございます。問題の診断に役立つ情報を提供していない場合は、お知らせください。

更新:どのスーパーブロックが問題であるかを見つけることができることを確認したかったです。アレイをマウント解除した後、次のことを試しました。 $ dumpe2fs /dev/sdc | grep -i superblock このコマンドの出力は次のとおりです。

dumpe2fs 1.42.9 (28-Dec-2013)
dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc
Couldn't find valid filesystem superblock.

mke2fs -n /dev/sdcスーパーブロックに関するより多くの情報を得ることができるかどうかを調べるために走りました。これが結果です

# mke2fs -n /dev/sdc
mke2fs 1.42.9 (28-Dec-2013)
/dev/sdc is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
335577088 inodes, 2684616704 blocks
134230835 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
81928 block groups
32768 blocks per group, 32768 fragments per group
4096 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
        102400000, 214990848, 512000000, 550731776, 644972544, 1934917632, 
        2560000000

アップデート(2022-11-15)

ITチームの助けを借りて、サーバーのBIOSに入ることができました。 RAID 5がPERC 5 / Eであり、BIOSのスロット8ディスクが「外部」と見なされることを知っておくと便利です。スロット8のディスクを「インポート」(「削除」する代わりに)し、アレイは正常に戻りましたが、パフォーマンスが低下した状態でした。奇妙なことに、スロット0のディスクは「欠けている」とマークされています。グローバルホットスペアでアレイに接続されているディスクがあると思いますが、アレイは偽装を維持するためにそれを使用すると思います。データが失われていないことを確認するために、グローバルホットスペアをリセットする方法を学ぶ前に、「rsync」を使用して外部15TBドライブにアレイをバックアップしました。コピープロセスがスムーズに進むことに指が交差しました。みんなの助けをありがとう!

答え1

/dev/sdc

ええと。

これがハードウェアRAIDです。あなたは最初の場所にいます。しなければならない起動時にコントローラを探していました。コンピュータでLinuxを実行している間にデバイスを設定することも可能です。しかし、これには非常に難しいソフトウェアが必要です。 DELL Perc 5iまたは6iにすることができます。このコンピュータは非常に古いコンピュータなので、ソフトウェアがUbuntu / Debianで動作しない可能性があります。インターネット上で適切なソフトウェアを探す必要があります。

奇妙なことは、以前はパーティションなしで構成されていたことです。

ドライブをクリアした後に何が起こっているのか言っていませんでした。ドライブが成功を報告しているようです。今は明らかに動作していますが、コントローラでアレイを再構築し、それで不良ブロックを実行して分割し、新しいファイルシステムを作成したいと思います。

答え2

データが非常に重要な場合は、次のようにします。

  1. /dev/sdcの内容全体(画像)を収めるのに十分な大きさの別々のストレージデバイスを入手してください。 (RAID配列サイズ*1.15)

  2. RAID全体をブロックレベルのイメージファイルとしてこの別々のデバイスにダンプします。 (ddを例に挙げましょう)

  3. これで、物理RAIDアレイのデータを損傷することなく、このイメージですべてのデータ復旧、FSリカバリ、インストール、データの断片などを安全に実行できます。

  4. 問題が発生して新しいイメージをダンプする必要がある場合に備えて、物理RAIDを現在のままにしてください。

画像からコピー/彫刻/抽出されたすべてのデータは、3番目のストレージデバイスに保存する必要があります。


簡単な例:

RAIDをイメージファイルにダンプするには、まず保存するデバイス(パーティション)をマウントする必要があります。

sudo mkdir /mnt/imgfiles
sudo mount /dev/sdd2 /mnt/imgfiles

その後、使用DDraw 配列データをイメージにダンプします。

sudo dd if=/dev/sdc of=/mnt/imgfiles/array_raw.img

メモ: このコマンドは、特定のオプション(記憶されていない)をコマンドラインに追加しない限り、進行状況を報告しません。

ノート2: 時間がかかります。ハードドライブは遅く、データがたくさんあります。

答え3

コンソールでdmesgとdumpe2fsが報告したエラーは、これがファイルシステムではなくRAIDアレイ自体に問題があることを示しています。

最初にすべきことは、RAIDアレイを見て(とにかく)複数の故障したディスクがあるかどうか、または何らかのリセットが必要かどうかを確認することです。これを行う方法は、Dellハードウェアによって異なります。

ddrescue@svin83が述べたように、 ""または" "を使用して/ dev / sdcを別のバックアップデバイスにコピーできることは、デバイスが少なくともほとんど動作していることを確認dd if=/dev/sdc of=/dev/XXX bs=1M conv=sync,noerrorし、!+エラーが発生したときにOh $#を回避する良い方法です。 。いつも他のことで起こります。アレイ全体のサイズは11 TB未満であるため、数百ドルを超えると、フルバックアップに十分なサイズの12/14 TB SATA3ドライブを購入できます。

ソートの問題を回避するために、ハードウェアRAIDにパーティションテーブルがないことは珍しくありません。

関連情報