Kompэто была моя домашняя настройка хранилища файлов. У него нет резервных копий, потому что настройка RAID должна была быть избыточностью. Я не учел, что произошло, и расплачиваюсь за это. Настройка:
- Ubuntu 16.04
- массив из четырех дисков RAID 5 с использованием mdadm (4x2TB): /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, и что вполне возможно, что они вообще не используют традиционный инструмент секционирования. Исследования "восстановление ЛВМ физических объемов" выкопали 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.журнал, который я оставил позади: https://dl.dropboxusercontent.com/u/2776730/testdisk.log
edit: вывод 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? Или мои данные потеряны для меня в этот момент? : '(
пожалуйста, дайте мне знать, если я могу что-то добавить, чтобы сделать отладку этот вопрос проще. Спасибо!
3438
