Аварийное восстановление. MDADM/LVM2 Некоторый прогресс, но застрял на окончательном креплении
Мы сделали глупое обновление на работающем сервере, используя неправильные репозитории, и система стала полностью не загружаемой.
Система, SLES 11, мы использовали для обновления репозиторий openSuse, и все пошло ужасно неправильно. Он загружается сейчас только в (восстановить файловую систему).
При загрузке не удается смонтировать RAID1 для основных LVM. На данный момент мы заинтересованы только в доступе к данным для их перемещения на функциональный сервер.
Имеется 2 жестких диска по 2 ТБ, загрузочный (корневой) раздел 4G, раздел подкачки и основной раздел. Загрузочный раздел (/dev/md1) есть.
При загрузке он не может собрать большой рейд (/ dev/md3) и не может создать группу томов и LVM.
После загрузки в файловой системе восстановления мы попытались выполнить следующие шаги для восстановления raid:
mdadm --assemble /dev/md3 /dev/sda3 /dev/sdb3
(repair filesystem) # cat /prot c/mdstat
Personalities : [raid1] [raid0] [raid10] [raid6] [raid5] [raid4]
md3 : active raid1 sda3[0] sdb3[1]
1947090880 blocks super 1.2 [2/2] [UU]
md1 : active raid1 sda1[0] sdb1[1]
4194240 blocks [2/2] [UU]
unused devices: <none>
Затем я зашел в /etc/lvm/backup/vg00, где хранилась резервная копия группы томов, и обнаружил UUID физического тома, так как он был недоступен.
pvcreate --uuid 12pHfn-ibCI-pS8a-YOcc-LVNy-UMyp-lg9tG2 /dev/md3
vgcfgrestore vg00
vgchange -a y vg00
После этих шагов создается группа томов, и есть LVM... вывод команд...
(repair filesystem) # pvdisplay
--- Physical volume ---
PV Name /dev/md3
VG Name vg00
PV Size 1.81 TiB / not usable 4.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 475395
Free PE 192259
Allocated PE 283136
PV UUID 12pHfn-ibCI-pS8a-YOcc-LVNy-UMyp-lg9tG2
(repair filesystem) # vgdisplay
--- Volume group ---
VG Name vg00
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 9
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 4
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 1.81 TiB
PE Size 4.00 MiB
Total PE 475395
Alloc PE / Size 283136 / 1.08 TiB
Free PE / Size 192259 / 751.01 GiB
VG UUID e51mlr-zA1U-n0Of-k3zE-Q5PP-aULU-7rTXhC
(repair filesystem) # lvdisplay
--- Logical volume ---
LV Name /dev/vg00/usr
VG Name vg00
LV UUID SxlDZT-KYf9-q4jS-i5kz-FzRl-Xttk-ilJLuP
LV Write Access read/write
LV Status available
# open 0
LV Size 302.00 GiB
Current LE 77312
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 1024
Block device 253:0
--- Logical volume ---
LV Name /dev/vg00/var
VG Name vg00
LV UUID lTHXSr-wUea-gqLI-n2KX-OBEE-fGRt-JLYWbk
LV Write Access read/write
LV Status available
# open 0
LV Size 200.00 GiB
Current LE 51200
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 1024
Block device 253:1
--- Logical volume ---
LV Name /dev/vg00/home
VG Name vg00
LV UUID 853Lhz-J6DX-DTgc-zleK-RHIb-XDOA-tHguo9
LV Write Access read/write
LV Status available
# open 0
LV Size 600.00 GiB
Current LE 153600
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 1024
Block device 253:2
--- Logical volume ---
LV Name /dev/vg00/srv
VG Name vg00
LV UUID 7KKWlv-ADsx-WeUB-i8Vm-VJhL-w0nX-5MhmP2
LV Write Access read/write
LV Status available
# open 0
LV Size 4.00 GiB
Current LE 1024
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 1024
Block device 253:3
(repair filesystem) # cat /etc/fstab
/dev/md1 / ext3 acl,user_xattr 1 1
/dev/sda2 none swap sw
/dev/sdb2 none swap sw
/dev/vg00/usr /usr xfs defaults 1 2
/dev/vg00/var /var xfs defaults 1 2
/dev/vg00/home /home xfs defaults 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
Поэтому после этого я возлагал большие надежды на возможность восстановления данных и попыток переместить их в новый ящик. Но когда я пытаюсь смонтировать тома... (я использую srv LVM, потому что он пустой или неважный)
mkdir /mnt/srvb
mount vg00-srv /mnt/srvb
mount: you must specify the filesystem type
(repair filesystem) # fsck /dev/vg00/srv
fsck from util-linux-ng 2.16
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/dm-3
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
e2fsck -b 32768 /dev/mapper/vg00-srv
Я продолжаю пытаться....
(repair filesystem) # mke2fs -n -S /dev/mapper/vg00-srv
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=1 blocks, Stripe width=1 blocks
262144 inodes, 1048576 blocks
52428 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1073741824
32 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
А также...
(repair filesystem) # e2fsck -b 32768 /dev/mapper/vg00-srv
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/vg00-srv
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Не повезло ни с одним из них. Также я не уверен, почему, но я боюсь, что есть несоответствие с типами файловой системы, я очень сомневаюсь, что это xfs, они должны быть ext-4 или ext-3 (как основной раздел, который работает.)
Я не могу быть уверен, потому что они были созданы автоматически в центре обработки данных сервера. Новые серверы используют ext4, но этот был старше и со старой ОС, так что я думаю, что будет ext3.
Попытка использования приведенных выше команд в качестве fsck.ext3 все еще дает те же результаты.
Может ли кто-нибудь немного подсказать мне, куда идти дальше? Я настаиваю на том, что мне просто необходим доступ к данным в /home LVM, чтобы попытаться скопировать их на новый компьютер.
Большое спасибо. Я надеюсь, что я был ясен и желаю, чтобы кто-нибудь мог мне помочь.
---- РЕДАКТИРОВАТЬ -----
rescue:~# lsblk --fs
NAME FSTYPE LABEL MOUNTPOINT
sda
|-sda1 linux_raid_member
| `-md1 ext3 root
|-sda2 swap
`-sda3 linux_raid_member rescue:3
`-md3 LVM2_member
|-vg00-usr (dm-0)
|-vg00-var (dm-1)
|-vg00-home (dm-2)
`-vg00-srv (dm-3)
sdb
|-sdb1 linux_raid_member
| `-md1 ext3 root
|-sdb2 swap
`-sdb3 linux_raid_member rescue:3
`-md3 LVM2_member
|-vg00-usr (dm-0)
|-vg00-var (dm-1)
|-vg00-home (dm-2)
`-vg00-srv (dm-3)
Команда /blkid /dev/vg00/srv не дает результата
rescue:~# blkid
/dev/sda1: UUID="a15ef723-f84f-7aaa-1f51-fb8978ee93fe" TYPE="linux_raid_member"
/dev/sda2: UUID="804e745e-8bc4-47bc-bf2e-5e95c620d9ca" TYPE="swap"
/dev/sda3: UUID="3b31972d-e311-8292-4fc6-2add1afd58fe" UUID_SUB="f6d18087-8acd-3229-523d-a0a9960c1717" LABEL="rescue:3" TYPE="linux_raid_member"
/dev/sdb1: UUID="a15ef723-f84f-7aaa-1f51-fb8978ee93fe" TYPE="linux_raid_member"
/dev/sdb2: UUID="143565ee-04ac-4b20-93c2-4c81e4eb738e" TYPE="swap"
/dev/sdb3: UUID="3b31972d-e311-8292-4fc6-2add1afd58fe" UUID_SUB="1c8aa8bc-4a43-17c5-4b94-f56190083bdb" LABEL="rescue:3" TYPE="linux_raid_member"
/dev/md1: LABEL="root" UUID="635b7b96-6f32-420d-8431-074303eeee11" SEC_TYPE="ext2" TYPE="ext3"
/dev/md3: UUID="12pHfn-ibCI-pS8a-YOcc-LVNy-UMyp-lg9tG2" TYPE="LVM2_member"
rescue:~# mdadm --detail /dev/md3
/dev/md3:
Version : 1.2
Creation Time : Wed Mar 4 01:03:28 2015
Raid Level : raid1
Array Size : 1947090880 (1856.89 GiB 1993.82 GB)
Used Dev Size : 1947090880 (1856.89 GiB 1993.82 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Sat Mar 14 19:58:45 2015
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : rescue:3 (local to host rescue)
UUID : 3b31972d:e3118292:4fc62add:1afd58fe
Events : 450
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3
Я не могу загрузиться с Live CD, но я могу загрузиться с помощью спасения Debian 64, которое кажется более стабильным, поскольку нормальная загрузка теперь также испорчена плохими библиотеками из-за неправильного обновления ядра.
Тем не менее я не могу найти способ монтировать LV в любой загрузке.
Также это появляется при загрузке спасения:
[ 5.693921] md: Waiting for all devices to be available before autodetect
[ 5.707605] md: If you don't use raid, use raid=noautodetect
[ 5.719376] md: Autodetecting RAID arrays.
[ 5.775853] md: invalid raid superblock magic on sdb3
[ 5.786069] md: sdb3 does not have a valid v0.90 superblock, not importing!
[ 5.821768] md: invalid raid superblock magic on sda3
[ 5.831986] md: sda3 does not have a valid v0.90 superblock, not importing!
[ 5.846010] md: Scanned 4 and added 2 devices.
[ 5.855010] md: autorun ...
[ 5.860707] md: considering sda1 ...
[ 5.867974] md: adding sda1 ...
[ 5.874524] md: adding sdb1 ...
[ 5.881491] md: created md1
[ 5.887204] md: bind<sdb1>
[ 5.892738] md: bind<sda1>
[ 5.898262] md: running: <sda1><sdb1>
Я могу смонтировать / dev / md1 без проблем, но это был оригинальный загрузочный / корневой раздел без VG.
1 ответ
Для md3 он сообщает "Время создания: ср. 4 марта 01:03:28 2015", что, по-видимому, является относительно недавней настоящей датой создания. Возможно, воссоздание было сделано?
В любом случае, если это RAID1, вы должны иметь возможность запустить тестовый диск на одном из разделов и позволить ему искать файловую систему. Попробуйте... testdisk /dev/sda3
Обратите внимание, что в ситуациях восстановления данных ошибочно выполнять операции записи на исходных дисках, если вы не уверены в результатах.