Cra*_*ght 5 linux disk-management lvm mdadm ubuntu
这是我的家庭文件存储设置。它没有备份，因为 RAID 设置旨在成为冗余。我没有解释发生了什么，我正在付出代价。设置：
请注意，Linux 主机（包括 /etc 和 /boot）安装在不同的磁盘上并且完全可以访问（因此我可以访问 /etc/lvm/archive）。RAID 阵列纯粹是文件存储，引导过程除了它在 /etc/fstab 中的条目外，完全不依赖它。
无论出于何种原因，我都是从一个我难以理解的 FreeDOS 安装程序启动的。我想我可能已经告诉它重新分区这个卷，虽然我不记得这样做了。无论如何，当我重新启动到 Linux (Ubuntu 16.04) 时，我以 root 用户身份进入恢复模式提示。它无法挂载 /etc/fstab 中定义的卷组的 UUID。
自从我最初设置这个 RAID 阵列已经足够长的时间，我完全忘记了 LVM 是如何工作的，或者我什至使用 LVM 来创建卷。（10-12 年，在此期间偶尔更换硬盘和调整阵列大小。）所以，首先我尝试使用 testdisk [ 1 ] 来查找和恢复分区信息。这从来没有奏效，分区总是不正确的大小（524Gb 而不是 4.5TB）并且永远不会在“物理扇区边界”上。我尝试了各种几何图形，认为有一种神奇的组合可以完美地恢复分区。下面是根据 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 --uuid xxx --restorefile yyy”吗？然后我是否需要扩展磁盘，并运行类似于 fsck 的 xfs 之类的东西？或者我的数据在这一点上丢失了？:'(
请让我知道是否可以添加任何内容以使调试此问题更容易。谢谢！
如果其中任何一个开始不起作用，或者不再有意义，请停止并询问主题专家。这是不安全的工作。对通过“dd”复制到大型存储介质上的文件或直接复制到相同或更大大小的新磁盘的磁盘映像进行操作，以保护原始数据集免遭愚弄。您可以在单个现场设备上执行这些操作，但如果您搞砸了，那么您的数据可能会受到影响。
好吧。首先，我们需要从基础磁盘级别向上有条理地修复此存储堆栈。您运行了一个 FreeDOS 安装程序，并且（可能）在其中一个磁盘上创建了分区表，从而弄乱了您的磁盘。
您的磁盘直接参与 MD 阵列，无需分区表。这是相当典型的。然而，这也是该阵列上的 0.90 修订版元数据结构，因此直接将分区表放在任何这些磁盘上都会使阵列混乱。
检查您的磁盘（从 sdb 到 sde 的任何磁盘）上是否有分区表，例如 /dev/sdb1 的形式。如果您有这样的表，则需要将其视为脏表并将其从数组中取出，并在删除该表后将其放回原处。
即使我们在其中一个磁盘上看不到分区，也需要在 /dev/md0 上运行完整性检查。执行此操作的命令很简单：
# /usr/share/mdadm/checkarray -a /dev/mdX
如果返回的不匹配计数大于零，则必须修复该阵列。如果需要的话我们会访问它，因为它目前看起来不是问题。
对于更具体的问题，testdisk 在 /dev/md0 上放置了一个 GPT，并在该磁盘上放置了一个分区 (/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（在 PV 上）：
# vgcfgrestore vg0
此后，检查您的 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
| 归档时间： |
|
| 查看次数： |
1883 次 |
| 最近记录： |