☰

LVMメタデータが失われました。 LVMを使用してraid 1を再生成してみてください。

tag-icon • tag-icon raid lvm software-raid mdadm raid1
LVMメタデータが失われました。 LVMを使用してraid 1を再生成してみてください。

最近、家に電源の問題があったため、ファイルサーバーディスクをインストールするのが困難になりました。デバイスの1つの名前がsdbからsddに変更され、すべてのLVMメタデータが失われたことがわかりました。 pvscan、lvscan、vgscanなどを使用すると、すべて私のシステムパーティションのみが表示されます。再起動すると、デバイスは以前の状態のsdbとsdcに戻るように見えました。 mdadmを使用してRAIDを再構築しましたが、RAIDデバイスのUUIDが変更されたため、vgcfgrestoreを使用してlvm構成を再作成することはできません。私の元のVG名は「vg0」でした。 vgcfgrestoreの結果は次のとおりです。

  Couldn't find device with uuid 3fgedF-F7Dc-c300-svuP-b3Q3-qSnb-CukkLq.
  Cannot restore Volume Group vg0 with 1 PVs marked as missing.
  Restore failed.

私の/etc/lvm/backup/vg0ファイルには以下が表示されます。

vg0 {
    id = "3JWsYl-FmEP-gpsa-7grO-VlLU-x7uC-EevgFc"
    seqno = 3
    format = "lvm2"         # informational
    status = ["RESIZEABLE", "READ", "WRITE"]
    flags = []
    extent_size = 8192      # 4 Megabytes
    max_lv = 0
    max_pv = 0
    metadata_copies = 0

    physical_volumes {

        pv0 {
            id = "3fgedF-F7Dc-c300-svuP-b3Q3-qSnb-CukkLq"
            device = "/dev/md0" # Hint only

            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 3907028992   # 1.81935 Terabytes
            pe_start = 384
            pe_count = 476932   # 1.81935 Terabytes
        }
    }

    logical_volumes {

        data {
            id = "Sqjebo-rnKh-mgQH-a90E-Q0n7-idp1-1xPP56"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 476932   # 1.81935 Terabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 0
                ]
            }
        }
    }
}

だから私が経験している問題は、pv UUIDがもはや有効ではなく、今何をすべきかさえ知らないということです。--scan自動ネーミングでレイドの再組み立てに成功しましたが/dev/md1、vg0バックアップファイルで変更してもあまり効果がありませんでした。私はまだ新しいpv UUIDが何であるかよくわかりません。

# cat /proc/mdstat
Personalities : [raid1] 
md1 : active raid1 sdc1[1] sdb1[0]
      1953383488 blocks super 1.2 [2/2] [UU]
      bitmap: 0/15 pages [0KB], 65536KB chunk

unused devices: <none>

同様に、pvs、lvs、およびvgsはすべて、私のルート/システムボリュームとvgのみを表示し、vg0の内容は表示しません。次のステップの提案がありますか？どちらのドライブもデータでいっぱいですが（ほとんどバックアップされています）、ファイルシステムを保存するために必要なすべてのことをしたいと思います。

編集する：

両方のディスクのヘッドを表示します（/dev/md1 はガベージを表示します）。そのうちの1つだけLABELONEラベルがあることを確認しました。

[root@host ~]# head /dev/sdb1
üN+©Ûüþy {Gyì˧Rjedi:1RUYܯÜ1á×iSû«nZsH$ÊWYuQÿÿÿÿÿÿÿÿ>4þÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿvg0 {
id = "IwXCM3-LnxU-Oguo-PXiN-nXwq-VFaU-ZmgySs"
seqno = 1
format = "lvm2"
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
metadata_copies = 0
[root@host ~]# head /dev/sdc1
LABELONEp­u+ LVM2 0013fgedFF7Dcc300svuPb3Q3qSnbCukkLqÁÑðüN+©Ûüþy {Gyì˧Rjedi:1RUYܯÜÒÆûPFlO!H$ÊWYuQÿÿÿÿÿÿÿÿ
ª9Úþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿþÿvg0 {
id = "IwXCM3-LnxU-Oguo-PXiN-nXwq-VFaU-ZmgySs"
seqno = 1
format = "lvm2"
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
metadata_copies = 0

50セントの質問は、基本的なファイルシステムを損傷することなくLVMラベルを復元する方法です。

修正する:

したがって、デフォルトでは、vgcfgrestore新しいPV UUIDを使用してlvmバックアップ構成の有効なコピーを正常に実行し、そのドライブを使用して/ dev / md0を組み立てることができましたが、今、私のPVが割り当てられたスペースよりも小さいというメッセージが表示されます。デフォルトでは、私の物理的な範囲が476932から476900に減少したことを報告します。ディスクのサイズは変更されておらず、PVに実際に正しい空き範囲の数があることを確認しました。 (最後の行を参照)

[root@host /]# pvs -v --segments /dev/md0
    Using physical volume(s) on command line.
    Wiping cache of LVM-capable devices
    Wiping internal VG cache
  Device /dev/md0 has size of 3906766976 sectors which is smaller than corresponding PV size of 3907028992 sectors. Was device resized?
  One or more devices used as PVs in VG vg0 have changed sizes.
  PV         VG   Fmt  Attr PSize PFree Start SSize  LV   Start Type   PE Ranges
  /dev/md0   vg0  lvm2 a--u 1.82t    0      0 476932 data     0 linear /dev/md0:0-476931

最後の行は、正しいサイズの0〜476931の範囲を報告することを示しています。 LVMヘッダ自体が少しスペースを取ることができると思いますが、これは新しいボリュームではなく、何年も問題なく使用されており、サイズ変更されていません。ボリュームが一時停止しているように見えます。

  LV Status              suspended
  # open                 0

USBサムドライブでPVを拡張してみました（動作するとは思わなかったが動作しませんでした）。このファイルシステムを一時的にマウントすることができれば、データをコピーして最初から完全なRAIDを作成できると思いました。しかし、もちろんこれはうまくいきませんでした。データを保存するための次の可能なステップのアイデアはありますか？

ベストアンサー1

まず、headはバイナリデータを表示するのに最適なツールではありません。試してみるかod（hexdump類似hexdump -C -n 4096 /dev/XYZ）

第二：これはmdのIDとは何の関係もありません。 LVMは物理ボリューム（PV）ヘッダーに書き込まれた独自のIDを使用します。

lvmdump -sm3番目：生成されたtarballを（例えば/var/log/messagesを含む）公開することは有益です。したがって、その出力を見たい場合があります。

いくつかの考え：

ディスクは2つだけですか？

私の最初の考えは、mdが間違って再組み立てられたようだったことでした。たとえば、デバイスの1つを間違ったデバイスで上書きしました。

"UUID" "3JWsYl-FmEP-gpsa-7grO-VlLU-x7uC-EevgFc"を使用してvg0を復元しようとしています。

vg0 {
    id = "3JWsYl-FmEP-gpsa-7grO-VlLU-x7uC-EevgFc"

しかし、mdデバイスの脚には異なる「UUID」を持つvg0があります。

vg0 {
    id = "IwXCM3-LnxU-Oguo-PXiN-nXwq-VFaU-ZmgySs"

しかし、PVには正しいIDがあるようです。

    pv0 {
        id = "3fgedF-F7Dc-c300-svuP-b3Q3-qSnb-CukkLq"

3fgedFF7Dcc300svuPb3Q3qSnbCukkLq片足で立っているものと比較されます。

だから私はメタデータ領域に後で何か他のものがあると仮定しています。たとえば、これは複製されたvgであり、後でIDを変更しましたか？

2番目に見ると、脚の1つが数バイト移動したようです（またはデバイスの一部がゼロで覆われていますか？これがod/hexdumpを使用する理由です）。したがって、mdにはゴミ以外には何も表示されません。両方のディスクのデータが実際に異なるためです。

どのようにパーティショニングを操作していますか？カーネルを更新しましたか？他のマシンのディスクを見ていますか？これはソートの問題かもしれません。

脚の1つに正しいPVヘッダーがあるようです。 LVMはガベージを返すmdを見ているので、これは見えません。そしてLVMはmdの足を見ません。

考えられる解決策

考えられる解決策の1つは、mdを別々の分岐に分解し（記憶：スーパーブロックをゼロにしないでください）、LVMに分岐を確認させることです。パーティションでpvscanを実行します。四半期が正しい場合、そのうちの1つはおそらく大丈夫でしょう。

メタデータには線形LVが1つだけで、ディスク全体にわたるセグメントが1つしかないと表示されます。これは便利です。デバイスにはどのファイルシステムがありますか？ /etc/lvm/backup がある場合、/etc/fstab もあるとします。別の考えられる解決策は、FSの始まりを探し、dmsetupを使用して直接マッピングを作成することです。https://wiki.gentoo.org/wiki/Device-mapper#Linear。

最後に重要なのは、生のデバイスを読み取り専用に保つことです。

おすすめ記事