LVM：PVおよびLVの破損の可能性から回復するにはどうすればよいですか？
これは私のホームファイルストレージの設定でした。 RAIDセットアップは冗長性を意図していたため、バックアップはありません。私は何が起こったのかを説明せず、代償を払っています。セットアップ：
- Ubuntu 16.04
- Mdadm（4x2TB）を使用した4ディスクRAID 5アレイ：/ dev/md0
- アレイでは、LVMによって管理されるPVとLV。
- Vg0という名前の論理ボリューム上で、XFSファイルシステム。
/ etcと/ bootを含むLinuxホストは別のディスクにインストールされており、完全にアクセス可能であることに注意してください（したがって、/ etc/lvm/archiveにアクセスできます）。 RAIDアレイは純粋にファイルストレージであり、ブートプロセスは/ etc/fstabのエントリ以外はまったく依存していません。
なんらかの理由で、私は理解するのに苦労していたFreeDOSインストーラーから起動しました。覚えていませんが、このボリュームを再パーティション化するように言ったのではないかと思います。いずれにせよ、Linux（Ubuntu 16.04）で再起動すると、rootユーザーとしてリカバリモードのプロンプトが表示されました。/etc/fstabで定義されているボリュームグループのUUIDをマウントできませんでした。
このRAIDアレイを最初にセットアップしてから、LVMの動作を完全に忘れたり、LVMを使用してボリュームを作成したりするのに十分な時間がかかりました。 （10〜12年、その間にハードディスクを交換し、アレイのサイズを変更することがありました。）そこで、最初にtestdisk [ 1 ]を使用してパーティション情報を見つけて復元しようとしました。これは機能しませんでした。パーティションは常に誤ったサイズ（4.5TBではなく524Gb）であり、「物理セクターの境界」にはありませんでした。パーティションを完全に復元する魔法の組み合わせがあると考えて、さまざまなジオメトリを試しました。 fdiskによるディスクの現在のステータスは次のとおりです。
$ Sudo fdisk -l /dev/md0
GPT PMBR size mismatch (1098853631 != 200894463) will be corrected by w(rite).
Disk /dev/md0: 4.1 TiB, 4500904476672 bytes, 8790829056 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 1048576 bytes / 3145728 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/md0p1 1 1098853631 1098853631 524G ee GPT
Partition 1 does not start on physical sector boundary.
そして別れた：
(parted) print list
Error: /dev/md0: unrecognised disk label
Model: Linux Software RAID Array (md)
Disk /dev/md0: 4501GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:
Testdiskフォーラムに質問を投稿したところ[ 2 ]、私はLVMを使用してRAIDアレイを管理していたこと、そしてこれらが従来のパーティショニングツールをまったく使用していない可能性があることに気付きました。掘り下げた「lvm物理ボリュームの回復」の調査 http://blog.adamsbros.org/2009/05/30/recover-lvm-volume-groups-and-logical-volumes-without-backups/ 。 pvckは私に次のことを教えてくれます：
$ Sudo pvck /dev/md0
Incorrect metadata area header checksum on /dev/md0 at offset 4096
Found label on /dev/md0, sector 1, type=LVM2 001
Found text metadata area: offset=4096, size=192512
Incorrect metadata area header checksum on /dev/md0 at offset 4096
また、/ etc/lvm/archivesにLVMボリュームのバックアップがいくつかありますが、最新のものは次のとおりです。
crw@bilby:~$ Sudo cat /etc/lvm/archive/vg0_00002-935168089.vg
# Generated by LVM2 version 2.02.98(2) (2012-10-15): Sun Jul 19 12:00:04 2015
contents = "Text Format Volume Group"
version = 1
description = "Created *before* executing 'lvextend /dev/vg0/lv0 /dev/md0'"
creation_Host = "bilby" # Linux bilby 3.16.0-43-generic #58~14.04.1-Ubuntu SMP Mon Jun 22 10:21:20 UTC 2015 x86_64
creation_time = 1437332404 # Sun Jul 19 12:00:04 2015
vg0 {
id = "Q4ZRRc-1l0h-FEgu-jrxA-EfW1-tAis-vv0jyL"
seqno = 5
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 262144 # 128 Megabytes
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "bKQs0l-zNhs-X4vw-NDfz-IMFs-cJxs-y0k6yG"
device = "/dev/md0" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 8790828672 # 4.09355 Terabytes
pe_start = 384
pe_count = 33534 # 4.09351 Terabytes
}
}
logical_volumes {
lv0 {
id = "pqInOe-ZLpV-t9oK-GQE1-AoIt-mB3M-4ImaV1"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 22356 # 2.729 Terabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
}
}
役立つ場合は、RAIDアレイの詳細を以下に示します。
$ Sudo mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Sun Oct 11 13:34:16 2009
Raid Level : raid5
Array Size : 4395414528 (4191.79 GiB 4500.90 GB)
Used Dev Size : 1465138176 (1397.26 GiB 1500.30 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Mon Oct 3 13:12:51 2016
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 1024K
UUID : 9be3b2f7:102e373a:822b5a8f:216da2f7 (local to Host bilby)
Events : 0.103373
Number Major Minor RaidDevice State
0 8 64 0 active sync /dev/sde
1 8 48 1 active sync /dev/sdd
2 8 16 2 active sync /dev/sdb
3 8 32 3 active sync /dev/sdc
最後に、私が残したtestdisk.logの悲しい痕跡があります： https://dl.dropboxusercontent.com/u/2776730/testdisk.log
編集：lsblkの出力：
crw@bilby:~$ Sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 59.6G 0 disk
├─sda1 8:1 0 243M 0 part /boot
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 59.4G 0 part
├─bilby--vg-root 252:0 0 43.4G 0 lvm /
└─bilby--vg-swap_1 252:1 0 16G 0 lvm [SWAP]
sdb 8:16 0 1.8T 0 disk
└─md0 9:0 0 4.1T 0 raid5
sdc 8:32 0 1.8T 0 disk
└─md0 9:0 0 4.1T 0 raid5
sdd 8:48 0 1.8T 0 disk
└─md0 9:0 0 4.1T 0 raid5
sde 8:64 0 1.8T 0 disk
└─md0 9:0 0 4.1T 0 raid5
私は完全に道に迷い、事態を悪化させたのではないかと疑っています。私の質問は次のとおりです。
LVMの問題に対処する前に、パーティション情報を「修正」する必要がありますか？ 「pvcreate--uuidxxx --restorefileyyy」を試みる必要がありますか？そして、ディスクを拡張して、fsckと同等のxfsのようなものを実行する必要がありますか？または、この時点でデータが失われていますか？ ： '（
この問題のデバッグを容易にするために追加できるものがあればお知らせください。ありがとう！
これらのいずれかが機能しなくなったり、意味がなくなったりした場合は、停止して対象分野の専門家に問い合わせてください。これは危険な作業です。 「dd」によって大容量のストレージメディア上のファイルにコピーされたディスクイメージ、または同じかそれ以上のサイズの新しいディスクに直接コピーされたディスクイメージを操作して、元のデータセットを不正行為から保護します。これらの操作は単一のライブセットで実行できますが、混乱した場合はデータに影響する可能性があります。
了解しました。まず、このストレージスタックをベースディスクレベルから系統的に修復する必要があります。 FreeDOSインストーラーを実行しましたが、ディスクの1つにパーティションテーブルを作成することで（おそらく）ディスクを台無しにしました。
ディスクはMDアレイに直接参加し、パーティションテーブルはありません。これはかなり典型的です。ただし、これはその配列の0.90リビジョンのメタデータ構造でもあるため、これらのディスクのいずれかにパーティションテーブルを直接配置すると、配列が混乱します。
たとえば/ dev/sdb1の形式で、パーティションテーブルを含むディスク（sdbからsdeまで）があるかどうかを確認します。このようなものがある場合は、それが汚れていると見なして配列から取り出し、そのテーブルを削除した後に元に戻す必要があります。
これらのディスクのいずれかにパーティションがない場合でも、/ dev/md0で整合性チェックを実行する必要があります。これを行うコマンドは簡単です。
# /usr/share/mdadm/checkarray -a /dev/mdX
それがゼロより大きい不一致カウントで戻ってきた場合、そのアレイを修復する必要があります。現在は問題とは思われないので、必要に応じて訪問します。
より具体的な問題については、testdiskはGPTを/ dev/md0に配置し、パーティションをそのディスク（/ dev/md0p1）に配置します。これは想定されていなかったため、LVMメタデータが破損しています。ボリュームグループは、最初に作成した方法であるため、/ dev/md0に直接存在することを目的としています。
まず、/ dev/md0でその誤ったGPTに対処する必要があります。 「ザッピング」する必要があります。 GPTをザッピングすると、すべてのGPT構造が空白になり、この場合のように、テーブルのないディスクに戻ります。この記事では、その詳細を詳しく説明しています： " http://www.rodsbooks.com/gdisk/wipegpt.html "。それをザッピングしないと、そのディスク上に壊れたGPT構造があり、パーティショニングユーティリティが「修正」しようとするため、今後も問題が発生します。
その後、質問に投稿したアーカイブファイルを使用して、すべてのLVMメタデータを再作成できます。ありがたいことに、機能するコマンドを渡すだけの十分な情報を提供してくれました。このプロセスについて詳しく知りたい場合は、これはすばらしいリソースです： " https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/mdatarecover.html = "。
元のメタデータをすべて使用して物理ボリュームを再作成するコマンド：
# pvcreate --uuid "bKQs0l-zNhs-X4vw-NDfz-IMFs-cJxs-y0k6yG" --restorefile /etc/lvm/archive/vg0_00002-935168089.vg
このアーカイブファイルは、/ dev/md0をボリュームグループを構成するディスクとして記述し、必要に応じてそれを使用します。 LVMアーカイブディレクトリに後のアーカイブファイルがある場合は、その代わりに使用してください。目標は、ボリュームグループを最新の有効な状態にすることです。
この後、PV、VG、およびLVの整合性をチェックすることが重要です。あなたはすでにこれを試みましたが、今回はより生産的になるはずです。ここで使用する必要があるのは、コマンドpvckおよびvgckです。
まず、pvckを実行します。
# pvck /dev/md0
それが検証されたら、vgckを実行します。
# vgck vg0
すべてのメタデータを検証したら、LVをアクティブ化する必要があります（まだアクティブ化されていない場合）。
# vgchange -ay vg0
そして最後に、/ dev/mapper/vg0-lv0（この場合はXFS）のファイルシステムで潜在的なエラーをチェックします。
# xfs_check /dev/mapper/vg0-lv0
エラーがなければ、何も返されません。何かがおかしい場合は、xfs_repairが必要になります（マウントされている間はこれを行わないでください）。
# xfs_repair /dev/mapper/vg0-lv0