간단한 배경
QNAP TS-451이 있습니다. NAS가 실패했지만 드라이브는 여전히 손상되지 않았다고 확신합니다. 새 QNAP TS-462를 교체하려고 하는데 새 시스템에서 내 데이터가 그대로 유지되는지 확인하고 싶습니다.
질문
RAID를 조립할 수 없을 때 LVM의 콘텐츠에 어떻게 액세스합니까?
(자세한 내용은 아래에서 질문)
환경
이것TS-451시스템이 멈추고 다시 시작되지 않습니다. 그 구성은 다음과 같습니다:
- 드라이브 A - 20TB RAID1 미러
- 드라이브 B - 20TB RAID1 미러
- 드라이브 C - 8TB RAID 없음
- 드라이브 D - 14TB RAID 없음
이것TS-462드라이브 A/B/C/D를 마이그레이션하려는 새로운 시스템입니다.
분리리눅스 시스템(이상적으로) 드라이브 A/B/C/D에서 무손실 데이터 읽기:
- 페도라 38
- 리눅스 커널 6.2.14-300
- 오래된 BIOS(즉, GPT 파티션에서 부팅할 수 없는 것 같습니다. 이 경우에는 문제가 되지 않습니다.)
- Pentium Dual Core E6500(이 시스템이 얼마나 오래되었는지 알려드리기 위해)
실험 1
중요하지 않은 드라이브(C 드라이브) 중 하나를 새 TS-462로 이동하려고 시도했지만 TS-462가 이를 읽을 수 없는 것 같습니다. 내가 아는 한, 파티션 테이블에 대해 혼란스러워하는 것 같습니다(fdisk는 한 가지를 보고하고 blkid/lsblk는 다른 것을 보고합니다.
별도의 Linux 시스템(Fedora 38)에서 LVM을 읽고 C 및 D 드라이브에 파티션을 마운트할 수 있었고 파일이 손상되지 않았음을 확인할 수 있었습니다.
실험 2
그래서 B 드라이브를 읽으려고 같은 작업을 시도했습니다. 드라이브 A/B는 RAID1 미러의 일부이므로 드라이브 중 하나를 (신중하게) 실험하고 다른 하나를 백업으로 유지하는 것이 괜찮을 것이라고 생각했습니다.
안타깝게도 LVM을 활성화할 수 없는 것 같습니다. 다음은 Linux 시스템에서 시도한 몇 가지 사항입니다.
# fdisk -l /dev/sdc
Disk /dev/sdc: 18.19 TiB, 20000588955648 bytes, 39063650304 sectors
Disk model: WDC WD201KFGX-68
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: DFC9F3CE-9CFA-4251-8DD1-48BF99476C04
Device Start End Sectors Size Type
/dev/sdc1 40 1060289 1060250 517.7M Microsoft basic data
/dev/sdc2 1060296 2120579 1060284 517.7M Microsoft basic data
/dev/sdc3 2120584 39045853979 39043733396 18.2T Microsoft basic data
/dev/sdc4 39045853984 39046914269 1060286 517.7M Microsoft basic data
/dev/sdc5 39046914272 39063621869 16707598 8G Microsoft basic data
제가 모은 정보로는http://www.rodsbooks.com/linux-fs-code/, 이러한 파티션이 표시된다는 사실은 Microsoft basic data문제가 아니지만 이것이 아주 오래된 Linux/fdisk 버전에 설정되어 있다는 증거일 뿐입니다. (저는 2015년경부터 TS-451을 사용했습니다.)
# gdisk /dev/sdc
GPT fdisk (gdisk) version 1.0.9
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sdc: 39063650304 sectors, 18.2 TiB
Model: WDC WD201KFGX-68
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): DFC9F3CE-9CFA-4251-8DD1-48BF99476C04
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 39063650270
Partitions will be aligned on 8-sector boundaries
Total free space is 28423 sectors (13.9 MiB)
Number Start (sector) End (sector) Size Code Name
1 40 1060289 517.7 MiB 0700 primary
2 1060296 2120579 517.7 MiB 0700 primary
3 2120584 39045853979 18.2 TiB 0700 primary
4 39045853984 39046914269 517.7 MiB 0700 primary
5 39046914272 39063621869 8.0 GiB 0700 primary
# cat /proc/mdstat
Personalities :
md123 : inactive sdc5[1](S)
8353780 blocks super 1.0
md124 : inactive sdc4[25](S)
530124 blocks super 1.0
md125 : inactive sdc1[26](S)
530108 blocks super 1.0
md126 : inactive sdc2[1](S)
530124 blocks super 1.0
md127 : inactive sdc3[2](S)
19521865728 blocks super 1.0
unused devices: <none>
# mdadm --assemble --readonly /dev/sdc3
mdadm: device /dev/sdc3 exists but is not an md array.
왜? ? ? :-(
pvdisplay그리고 다양한 LVM 도구는 처음에 LVM을 발견하지 못했습니다. 파티셔닝이 명시적으로 지정된 경우:
# pvdisplay /dev/sdc3
Cannot use /dev/sdc3: device is an md component
무엇? 하지만 mdadm은 아니라고 하더군요. :-(
# mdadm --examine /dev/sdc3
/dev/sdc3:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 5a6e38ee:eb6bf302:79856803:58887046
Name : 1
Creation Time : Wed Nov 25 03:18:54 2015
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 39043731456 sectors (18.18 TiB 19.99 TB)
Array Size : 19521865728 KiB (18.18 TiB 19.99 TB)
Super Offset : 39043733376 sectors
Unused Space : before=0 sectors, after=1920 sectors
State : active
Device UUID : f2a96ebc:996e4231:1576a39a:8606a71c
Update Time : Sun Mar 26 00:56:13 2023
Checksum : 893841dd - correct
Events : 436627
Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
체크섬은 괜찮습니다. 그렇다면 이것이 유효한 RAID 파티션이라는 뜻인가요? (다른 파티션(스왑 파티션도 포함)에서는 유효한 RAID 정보와 체크섬을 표시하므로 이것이 무엇을 의미하는지 모르겠습니다.)
다른 경로를 시도해 보자...
그런데 설정 md_component_detection=0하고 /etc/lvm/lvm.conf실행하니 pvscan --cache --devices /dev/sdcLVM 데이터를 얻을 수 있었어요...
# pvdisplay /dev/sdc3
--- Physical volume ---
PV Name /dev/sdc3
VG Name vg1
PV Size 18.18 TiB / not usable 0
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 4766080
Free PE 0
Allocated PE 4766080
PV UUID Xt2uVv-PMCy-oHuK-0UAc-43ZI-z7TH-hHAK7A
# vgdisplay vg1
--- Volume group ---
VG Name vg1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 131
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 18.18 TiB
PE Size 4.00 MiB
Total PE 4766080
Alloc PE / Size 4766080 / 18.18 TiB
Free PE / Size 0 / 0
VG UUID oNdjeV-lPuv-PgPR-J11o-zbHQ-X7az-93sr9J
# lvdisplay vg1
--- Logical volume ---
LV Path /dev/vg1/lv544
LV Name lv544
VG Name vg1
LV UUID z1gyiX-FhGG-cTaM-shPx-wZg4-G1xN-b9fS37
LV Write Access read/write
LV Creation host, time NASEFF3AE, 2015-11-25 03:18:56 -0800
LV Status NOT available
LV Size 144.00 GiB
Current LE 36864
Segments 2
Allocation inherit
Read ahead sectors 8192
--- Segments ---
Logical extents 0 to 5119:
Type linear
Physical volume /dev/sdc3
Physical extents 0 to 5119
Logical extents 5120 to 36863:
Type linear
Physical volume /dev/sdc3
Physical extents 1428360 to 1460103
--- Logical volume ---
LV Path /dev/vg1/lv1
LV Name lv1
VG Name vg1
LV UUID 4lsaNW-E4Bg-g93F-ko0a-Ep1m-wHD0-3Hc3Cb
LV Write Access read/write
LV Creation host, time NASEFF3AE, 2015-11-25 03:19:03 -0800
LV Status NOT available
LV Size 18.04 TiB
Current LE 4729216
Segments 2
Allocation inherit
Read ahead sectors 8192
--- Segments ---
Logical extents 0 to 1423239:
Type linear
Physical volume /dev/sdc3
Physical extents 5120 to 1428359
Logical extents 1423240 to 4729215:
Type linear
Physical volume /dev/sdc3
Physical extents 1460104 to 4766079
네, 그러면 드라이브를 마운트할 수 있어야겠죠?
# vgchange -ay vg1
WARNING: PV /dev/sdc3 in VG vg1 is using an old PV header, modify the VG to update.
device-mapper: reload ioctl on (253:3) failed: Device or resource busy
device-mapper: reload ioctl on (253:3) failed: Device or resource busy
0 logical volume(s) in volume group "vg1" now active
흠... 어쩌면 이것이 md_component_detection=0올바른 접근 방식이 아닌가?
실험 3
철저한 테스트를 위해 최종 결과, 메스 및 테스트 디스크를 테스트했습니다. 이것들은 훌륭한 도구이지만 현재 상황에서는 약간 번거롭다고 생각합니다. 디스크는 완벽하고 읽기 가능해야 합니다. 파티션과 파일 시스템은 손상되지 않아야 합니다. 어딘가에 버전 비호환성이 있는 것 같은데요?
목표와 문제점(재검토)
내 목표는 주로 어떻게든 (드라이브 A/B에 있는) 이전 데이터에 액세스하는 것입니다. 드라이브 중 하나를 다시 포맷하고 다른 시스템에서 마이그레이션해도 괜찮습니다. 또는 데이터에 액세스할 수 있을 것으로 합리적으로 기대되는 경우 이를 TS-462에 넣으십시오.
내 현재 경로(실험 2와 함께)에서 내가 막힌 부분은 Linux가 RAID를 인식하도록 만드는 방법을 찾는 것입니다. 나는 노력할 것 같아요프로스트슈츠훌륭한 조언기록 중 복사 덮어쓰기~와 공유 된Linux Raid1 구성원 디스크에서 파일 복구 - 가능한 한 나쁨.
하지만 저는 제안을 받아들일 준비가 되어 있습니다!
답변1
# mdadm --assemble --readonly /dev/sdc3 mdadm: device /dev/sdc3 exists but is not an md array.왜? ? ? :-(
이것은 완전히 잘못된 명령입니다. mdadm을 사용하면 /dev/md장치가 아니라 장치를 조립하게 됩니다 /dev/sd.
당신은 시도 할 수 있습니다:
mdadm --assemble --run --readonly /dev/md42 /dev/sdc3
다만, sdc3( )용 /dev/md127md 장치는 이미 조립 하였으므로 mdadm --stop /dev/md127다시 조립하기 전에 먼저 조립해야 합니다.
/dev/sdc3이 기존 md 장치는 raid 계층을 무시한 상태에서 vgchange를 시도할 때 표시되는 "장치 사용 중" 오류의 원인이기도 합니다.
답변2
QNAP 장치가 손상된 경우 Linux 컴퓨터의 디스크에 있는 파일에 액세스할 수 없습니다. 이는 QNAP가 커널 및 lvm 도구를 수정했기 때문입니다.
이러한 파일에 액세스하려면 qnap 커널과 qnap의 수정된 lvm 도구를 소스에서 컴파일해야 합니다.
동료(모델 TS-251+)를 위해 qnap 디스크에서 파일을 복구하기 위한 사이드 프로젝트로, VM을 생성하고 디스크의 파일에 액세스할 수 있도록 LVM 도구가 포함된 커널과 initrd를 컴파일했습니다.
다음에서 커널과 지침을 찾을 수 있습니다.https://github.com/thanosz/qnap-kernel-lvm