我最近家里出现了电源问题，并且在安装文件服务器磁盘时遇到了问题。事实证明，其中一个设备已将自身从 sdb 重命名为 sdd，并且所有 LVM 元数据现在都丢失了。使用 pvscan、lvscan、vgscan 等都只显示我的系统分区。再次重新启动，设备似乎回到了之前的状态：sdb 和 sdc。我已设法使用 mdadm 重新组装 raid，但无法使用 vgcfgrestore 重新创建我的 lvm 配置，因为显然我的 raid 设备的 UUID 已更改。我原来的 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自动命名为重新组装了raid /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 显示垃圾）。我注意到其中只有一个有 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
LABELONEpu+ 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 -sm第三：发布由（其中包含例如 /var/log/messages - 因此您可能需要查看其输出）生成的 tarball 将是有益的。
一些想法：
这是仅有的两个磁盘吗？
我的第一个想法是，这看起来像 md 被错误地重新组装 - 例如使用错误的设备覆盖您的一个设备：
您正在尝试使用“UUID”“3JWsYl-FmEP-gpsa-7grO-VlLU-x7uC-EevgFc”恢复 vg0：
vg0 {
id = "3JWsYl-FmEP-gpsa-7grO-VlLU-x7uC-EevgFc"
但在 md 设备的腿上有 vg0 具有不同的“UUID”
vg0 {
id = "IwXCM3-LnxU-Oguo-PXiN-nXwq-VFaU-ZmgySs"
但PV似乎有正确的id：
pv0 {
id = "3fgedF-F7Dc-c300-svuP-b3Q3-qSnb-CukkLq"
3fgedFF7Dcc300svuPb3Q3qSnbCukkLq与在其中一条腿上相比。
所以我假设元数据区域稍后还有其他内容。例如：这是一个克隆的 vg，并且您后来更改了它的 id？
第二次看时，其中一条腿似乎移动了几个字节（或者设备的一部分被零覆盖？这就是应该使用 od/hexdump 的原因）。所以 md 除了垃圾之外看不到任何东西 - 因为两个磁盘上的数据确实不同。
您是否以某种方式操纵分区？更新内核了吗？您正在查看不同机器上的磁盘吗？这可能是一个对齐问题。
其中一条腿似乎具有正确的 PV 标头。 LVM 没有看到它，因为它正在查看返回垃圾的 md。而且LVM不看md的腿。
可能的解决方案
一种可能的解决方案是将 md 拆卸为单独的分支（请记住：不要将超级块归零！）并让 LVM 查看分支：在分区上运行 pvscan - 如果分支正确，其中之一可能没问题。
您的元数据显示只有一个线性 LV，只有一个段跨越整个磁盘 - 这可能很有用。设备上有什么文件系统？如果您有/etc/lvm/backup，我想您也有/etc/fstab。另一种可能的解决方案是找到 FS 的启动并直接使用 dmsetup 创建映射：https://wiki.gentoo.org/wiki/Device-mapper#Linear。
最后同样重要的是：尝试将原始设备保持为只读。
答案2
所以我最终自己解决了这个问题。我在某处读到，真正旧版本mdadm使用的元数据较少，而新版本使用的元数据较多。由于我从 Ubuntu 10.10 系统迁移到 CentOS 6.9（尽管它已经在 CentOS 6.9 上成功安装了几周），我想这可以解释为什么该/dev/md0设备比原始 PV 小。一旦我启动备份 Ubuntu 10.10 系统，组装 raid，并vgcfgrestore在原始卷组上运行，raid 就安装得很好，我的数据再次可用。
因此，基本上，基于旧版本 mdadm 构建的 raid 文件系统不应该直接安装在较新的 Linux 发行版上。