Это была моя домашняя настройка хранения файлов. Он не имеет резервных копий, потому что установка RAID должна была быть избыточной. Я не учел то, что произошло, и я расплачиваюсь Настройка:
- Ubuntu 16.04
- Четырехдисковый массив RAID 5 с использованием mdadm (4x2 ТБ): /dev /md0
- На массиве PV и LV управляются LVM.
- На логическом томе с именем vg0, файловая система XFS.
Обратите внимание, что хост Linux, включая /etc и /boot, установлен на другом диске и полностью доступен (поэтому у меня есть доступ к /etc /lvm /archive). RAID-массив является чисто файловым хранилищем, процесс загрузки не зависит от него вообще, кроме его записи в /etc /fstab.
По какой-то причине я загрузился с установщика FreeDOS, который я пытался понять. Я думаю, что, возможно, сказал это перераспределить этот объем, хотя я не могу помнить, делая это В любом случае, когда я перезагружался в Linux (Ubuntu 16.04), меня переводили в приглашение режима восстановления в качестве пользователя root. Не удалось смонтировать UUID группы томов, как определено в /etc /fstab.
Прошло достаточно много времени с тех пор, как я изначально настроил этот RAID-массив, и я полностью забыл, как работает LVM, или что я даже использовал LVM для создания тома. (10-12 лет, замена жестких дисков и изменение размера массива в течение этого времени.) Итак, сначала я попытался использовать testdisk [ 1 ], чтобы найти и восстановить информацию о разделе. Это никогда не работало, раздел всегда имел неправильный размер (524 ГБ вместо 4,5 ТБ) и никогда не находился на «границе физического сектора». Я экспериментировал с различными геометриями, думая, что существует волшебная комбинация, которая прекрасно восстановит раздел. Вот текущее состояние диска в соответствии с 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
У меня также есть несколько резервных копий тома LVM в /etc /lvm /archives, последняя из которых выглядит следующим образом:
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"? И тогда мне нужно будет расширить диск и запустить что-то вроде xfs эквивалента fsck? Или мои данные потеряны для меня на этом этапе? :'(
Пожалуйста, дайте мне знать, если я могу добавить что-нибудь, чтобы облегчить отладку этой проблемы. Спасибо!