背景：3x1TBディスクを使用してUbuntu Bionicシステムをセットアップして実行しています。すべてのディスクは、約15GBの1つのパーティションと残りの約983GBのパーティションに分割されます。
2 つのディスクで構成される 15 GB パーティションMD0、交換のためのraid1配列。 3つのディスクすべてが983 GBのパーティションを構成します。MD10、/用raid10 Far 2アレイ、合計約1.4TBです。
どうしたの？：ハードドライブ1台でエラーが発生しました。とにかく、raid10アレイは続きます。 md0が未使用の残りの15GBパーティションを追加するように要求しましたが、システムが起動しました。心配しないでください\ o /
次に何が起こりましたか？: 新しいドライブを注文してから数時間後、ファイルシステムが読み取り専用に変わり、再起動に失敗しました。本質的に、2番目のディスクは失敗しましたが、スマートは不良ブロックではなく一連のCRCエラーを報告しました。
この前にもRAMスティックが破損するという問題があり、同時にRAMの交換に伴うシステム安定性の問題もありました。 （今は解決しました。）
私は今どこですか？:ddrescue を使用して両方のディスクをイメージ化し、testdisk を使用してファイルシステムを確認して修復しようとしました。 （ディスクは現在再起動するためにイメージを再構築しています。）デフォルトでは、ddrescueがコピーしたときに1つのディスクは大丈夫に見え、別のディスクには不良ブロックや読み取れないセクタは表示されませんが、ファイルシステムの問題があるようです。
私の考えでは、2番目のディスクハードウェアが故障したのではなく、RAMが破損してファイルシステムエラーが発生し、ディスクが読み取れなくなったためです。
証拠 mdadm - 実際のドライブを確認します。 sdfは「良い」、sddは「不良」です。
/dev/sdf:
MBR Magic : aa55
Partition[0] : 31997952 sectors at 2048 (type fd)
Partition[1] : 1921523712 sectors at 32000000 (type fd)
/dev/sdd:
MBR Magic : aa55
Partition[0] : 32002048 sectors at 2048 (type 83)
Partition[1] : 1921519616 sectors at 32004096 (type 83)
ここでは2つのことがわかります。まず、sddパーティションがlinux raid（fd）の代わりにdirect ext4 linux（83）に復元され、2番目に、sdd0がsdd1から4096セクタを取得したようです（そのようにパーティションを作成しない限り...）。しかし、私はそれが疑わしい）。
Testdiskは、まず、良好なディスク上のファイルシステムの問題をチェックするようです。
Disk /dev/sdf - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
Partition Start End Size in sectors
1 * Linux RAID 0 32 33 1991 231 32 31997952 [zen:0]
2 P Linux RAID 1991 231 33 121601 57 56 1921523712 [zen:10]
Disk /dev/sdd - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
Partition Start End Size in sectors
1 * Linux 0 32 33 1992 41 33 32002048
Bad relative sector.
2 P Linux 1992 41 34 121601 57 56 1921519616
この問題を修正するために Testdisk を取得できません。 partedmagic のバージョンは Linux raid パーティションをサポートしていないようで、fsck を使用すると余分なスーパーブロックがあってもスーパーブロックエラーに誤ったマジックナンバーが発生します。
以下は、mdadm --examineをループデバイスマウントイメージとして調べた結果です。再び良いsdfと悪いsddが続きます。
/dev/loop1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 152533db:4e587991:5e88fe61:7fc8bfb8
Name : zen:10
Creation Time : Wed Jun 20 10:47:05 2018
Raid Level : raid10
Raid Devices : 3
Avail Dev Size : 1921261568 (916.13 GiB 983.69 GB)
Array Size : 1440943104 (1374.19 GiB 1475.53 GB)
Used Dev Size : 1921257472 (916.13 GiB 983.68 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=4096 sectors
State : clean
Device UUID : ef11197c:7461dd9e:ad2e28f6:bad63a7b
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Aug 30 15:36:14 2018
Bad Block Log : 512 entries available at offset 16 sectors
Checksum : 93267b2f - correct
Events : 55599
Layout : far=2
Chunk Size : 512K
Device Role : Active device 1
アレイの状態：AA。 ( 'A' ==アクティブ、 '.' ==不足、 'R' ==交換)
/dev/loop2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 152533db:4e587991:5e88fe61:7fc8bfb8
Name : zen:10
Creation Time : Wed Jun 20 10:47:05 2018
Raid Level : raid10
Raid Devices : 3
Avail Dev Size : 1921257472 (916.13 GiB 983.68 GB)
Array Size : 1440943104 (1374.19 GiB 1475.53 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=0 sectors
State : active
Device UUID : f70177cb:7daea233:2feafe68:e36186cd
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Aug 30 15:25:37 2018
Bad Block Log : 512 entries available at offset 16 sectors
Checksum : 3c6bebab - correct
Events : 55405
Layout : far=2
Chunk Size : 512K
Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing, 'R' == replacing)
sdd1（別名Loop2）に問題があることをもう一度言及する価値があります。 「使用された開発サイズ」はリストされていません。画像を使用してアレイを再生成しようとしましたが、動作しているように見えましたが、アレイがマウントされませんでした（再び悪い魔法のスーパーブロック）。
質問 私の考えでは、sddの破損したパーティションマップが問題の原因であるようです。これが正しいと思いますか？この問題を解決することは可能ですか？では、どのような方法で解決できますか？ fdisk？
希望する結果可能な限り大量のディスクを他のディスクにダンプできるように、アレイをマウント可能にします。私は/ etcと/ homeのバックアップを持っていますが（理論的にはまだ復元しようとしていません）、この配列を一時的に復元できれば役に立ち、心の平和を得ることができます。 photorecを簡単に実行すると、多数のファイルを回復できますが、ディレクトリ構造やファイル名なしでほぼテラバイトに達するファイルを並べ替えることがわかりました。
[解決済み] 以前に行った操作によって問題が発生しないように、私が作成したディスクイメージの新しいコピーを所定の位置に置きました。実際には1つはパーティションイメージで、もう1つはフルディスクイメージなので、マウントしてください。
losetup --show -f /recovered/imgs/sdf1-md10.img
losetup -o 16386097152 /dev/loop3 /media/adrian/855c7d84-25f0-4b2f-b8fa-a5408536aaff/sdd-801485.img
確認の結果、cat /proc/mdstatmd127などの非アクティブ状態でインストールされたため、停止して@derobertが提案したようにアセンブルを実行しました。
mdadm --stop /dev/md127
mdadm -v --assemble --force /dev/md10 /dev/loop3 /dev/loop2
そしてアレイをマウントしてアクセスできます！ \永久/
私が試み始めに研究で逃した重要な事実は、新しいシステムでアレイを再組み立てする場合は、これが可能であるという事実さえ認識せずにデバイス（アセンブリ）を指定する必要があることです。
答え1
コピーを作成し、コピーだけで作業したように聞こえます。大丈夫です！
検査出力に「Used Dev Size」が足りないのは問題だとは思わない。代わりにデバイス全体を使うという意味だと思います。もう1つは、使用されたサイズがデバイスサイズより4096小さいことを示し、これはパーティションが4096より小さいことと一致します。 （アレイを作成するとき、mdadmはすべてのデバイスに最小パーティションサイズを使用します。そうしないと、アレイを構築できません。）
パーティションテーブルが破損しているようです。書かれていないセクタが破損していることは非常にまれですが、それでもほとんど有効です。 83がmdraidのパーティションタイプであることには問題はありません。他のタイプは実際には使用されなくなり、使用しないでください。 FS以外のデータ（私の記憶が正しい場合はda）も良い選択です。
私の考えでは、それがあなたに必要なすべてだと思いますmdadm --assemble --force /dev/md«WHATEVER» /dev/loop1 /dev/loop2。最新でないデバイスを強制的に適用するように求められたら、そのデバイスはアレイを組み立てる（ダウングレード）する必要があります。その後、試してみてくださいfsck.ext4（または何でも）。/dev/md«WHATEVER»機能している場合は、システムのinitramfsですべての操作を実行して回復し、新しいmdadm -aディスクを使用して再構築できます。