LinuxソフトウェアRAID（mdraid）の一部であった古いGPTパーティションディスクにバックアップGPTヘッダーを復元しました。これは、partprobeが破損したヘッダーを報告するために行われます。
実際、ソフトウェアRAIDはディスク全体を管理する必要がありますが、サーバーを別の方法で使用しても以前に使用したパーティション情報はそのまま残ります。
GPTが私の設定に関連していないことに気づき、gdiskエキスパートモードでGPT情報を完全に削除しました。
ただし、現在懸念されているのは、GPTテーブルの回復/ GPT情報の削除によってソフトウェアRAIDが破損する可能性があることです。
システム自体にはこれが真であることを示すものは表示されませんが（まだ起動してデータにアクセスできます）、私の仕事でデータがまだ破損する可能性があるかどうかを提案できる人がいるかどうか、またはどのように整合性を確認できるのか疑問に思います。します。材料。
ベストアンサー1
バージョン1.2メタデータは、ブロックデバイスの先頭から4Kで保存されます。多くの場合、データ自体が非常に重要です。たとえば、これはmdadm -E私のアレイの1つにあるディスク（の一部）です。
/dev/sda3:
Magic : a92b4efc
Version : 1.2
⋮
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=2224 sectors
⋮
ご覧のとおり、（8 * 512バイト/論理セクタ= 4KiB）の8つのセクタがアレイスーパーブロックです。データは実際には128MiBとはるかに大きいです。
GPTレイアウトの最初のセクタ（＃0）は保護MBRで、次の33セクタ（＃1〜＃33）はGPTパーティションテーブルとエントリです。ディスクストレージバックアップの最後の33セクタです。
したがって、バックアップGPTパーティションテーブルから復元すると、最初の34個のセクタを上書きできます。ただし、距離が20万セクタよりはるかに遠いため、データには影響しません。後で使用していないスペースの量によって、最後にバックアップを作成しても破損は発生しません。 （私の配列にスペースが多かったので、あなたのスペースは異なる場合があります。）
しかし、すでに配列を組み立てているため、スーパーブロックは破壊されていないようです。それぞれのディスクを確認してみますmdadm -Eが、その他には破損した部分はないようです。 （a）が使用中で、（b）が内部の場合、書き込み意図ビットマップはスーパーブロックとデータの間のスペースに格納されるため、消去して再度有効にする必要があります。