최근 집에 전원 문제가 있어서 파일 서버 디스크를 설치하는 데 어려움을 겪었습니다. 장치 중 하나의 이름이 sdb에서 sdd로 변경되었으며 이제 모든 LVM 메타데이터가 손실된 것으로 나타났습니다. pvscan, lvscan, vgscan 등을 사용하면 모두 내 시스템 파티션만 표시됩니다. 다시 시작하면 장치가 이전 상태인 sdb 및 sdc로 되돌아가는 것처럼 보였습니다. mdadm을 사용하여 RAID를 재조립했지만 RAID 장치의 UUID가 변경되었기 때문에 vgcfgrestore를 사용하여 lvm 구성을 다시 생성할 수 없습니다. 내 원래 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
자동 네이밍으로 레이드를 재조립 하는데 성공했는데 /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을 게시하는 것이 유익할 것입니다. 따라서 해당 출력을 보고 싶을 수도 있습니다.
몇 가지 생각:
디스크가 2개뿐인가요?
내 첫 번째 생각은 md가 잘못 재조립된 것 같다는 것이었습니다. 예를 들어 장치 중 하나를 잘못된 장치로 덮어썼습니다.
"UUID" "3JWsYl-FmEP-gpsa-7grO-VlLU-x7uC-EevgFc"를 사용하여 vg0을 복원하려고 합니다.
vg0 {
id = "3JWsYl-FmEP-gpsa-7grO-VlLU-x7uC-EevgFc"
하지만 md 장치의 다리에는 다른 "UUID"를 가진 vg0이 있습니다.
vg0 {
id = "IwXCM3-LnxU-Oguo-PXiN-nXwq-VFaU-ZmgySs"
하지만 PV에는 올바른 ID가 있는 것 같습니다.
pv0 {
id = "3fgedF-F7Dc-c300-svuP-b3Q3-qSnb-CukkLq"
3fgedFF7Dcc300svuPb3Q3qSnbCukkLq
한쪽 다리로 서 있는 것과 비교됩니다.
그래서 나는 메타데이터 영역에 나중에 뭔가 다른 것이 있을 것이라고 가정하고 있습니다. 예를 들어, 이것은 복제된 vg였으며 나중에 ID를 변경했습니까?
두 번째로 보면 다리 중 하나가 몇 바이트 이동한 것으로 보입니다(또는 장치의 일부가 0으로 덮여 있습니까? 이것이 바로 od/hexdump를 사용해야 하는 이유입니다). 따라서 md에는 쓰레기 외에는 아무것도 표시되지 않습니다. 두 디스크의 데이터가 실제로 다르기 때문입니다.
어떤 방식으로든 파티셔닝을 조작하고 있나요? 커널을 업데이트하셨나요? 다른 머신의 디스크를 보고 계십니까? 이는 정렬 문제일 수 있습니다.
다리 중 하나에 올바른 PV 헤더가 있는 것 같습니다. LVM은 가비지를 반환하는 md를 보고 있기 때문에 이를 보지 못합니다. 그리고 LVM은 md의 다리를 보지 않습니다.
가능한 해결책
한 가지 가능한 해결책은 md를 별도의 분기로 분해하고(기억: 슈퍼블록을 0으로 만들지 마십시오!) 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 배포판에 직접 설치하면 안 됩니다.