☰

헤더가 손상된 새 컴퓨터의 Luks 볼륨이 있습니까?

tag-icon • tag-icon linux raid luks
헤더가 손상된 새 컴퓨터의 Luks 볼륨이 있습니까?

raid1의 Luks 볼륨에 데이터를 백업했습니다(raid 1의 첫 번째 2개 디스크, 두 번째 Luks).

드라이브 2개를 새 서버로 옮겼더니 작동이 멈췄습니다. 가벼운 공황 발작 후에 나는 더 많은 정보를 검색했고 몇몇 웹사이트에서는 Hexdump를 사용하여 헤더 내용을 검사할 것을 제안했습니다. 하지만 많은 웹사이트에서는 그것이 어디에 있는지 잘 모릅니다. 내 데이터를 복구할 수 있는지 또는 무슨 일이 일어났는지 알려줄 수 있는 사람이 있나요?

내가 한 일은 그것들을 새 컴퓨터로 옮기는 것뿐이었습니다. 설치가 필요하지 않습니다. 명령도 없고 이상한 것도 없습니다. 기존 운영 체제가 설치된 컴퓨터를 연결하고 부팅합니다.

sudo hexdump -Cvs 0 -n 2000 /dev/sdb

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001c0  01 00 ee fe ff ff 01 00  00 00 ff ff ff ff 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  53 16 20 86 00 00 00 00  01 00 00 00 00 00 00 00  |S. .............|
00000220  af be c0 d1 01 00 00 00  00 08 00 00 00 00 00 00  |................|
00000230  8e be c0 d1 01 00 00 00  e1 8a 60 b4 82 6f 50 42  |..........`..oPB|
00000240  93 ea db 27 34 ec a7 5b  02 00 00 00 00 00 00 00  |...'4..[........|
00000250  80 00 00 00 80 00 00 00  86 d2 54 ab 00 00 00 00  |..........T.....|

다음 명령을 사용하여 RAID가 생성되었습니다. (드라이브 이름과 일치하도록 편집됨)

sudo mdadm --create --verbose /dev/md5 --level=1 --raid-devices=2 /dev/sdp /dev/sdb

lsblk는 다음을 보여줍니다.

sdb                         8:16   0   3.7T  0 disk
sdp                         8:240   0   3.7T  0 disk

fdisk -l /dev/sdb

Disk /dev/sdb: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: EFRX-68WT0N0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B4608AE1-6F82-4250-93EA-DB2734ECA75B

또한 명확히 하기 위해 원래 컴퓨터로 되돌렸는데 여전히 인식하지 못합니다. mdadm은 공격대 구성원이 아니라는 것을 보여줍니다. 심지어

mdadm --어셈블리 --스캔

아무것도 하지 않았다

답변1

하자! 알아 냈어!

그래서 하드 드라이브를 새 컴퓨터에 넣었을 때 어떻게 해서든 새로운 매핑/블록 크기를 갖게 되었는지는 모르겠습니다.

나는 파산했고

sudo hexdump -s 0 -n 1000000000 -C /dev/sdb | grep LUKS

그러면 첫 번째 GB에서 LUKS 문구가 검색됩니다.

결과 :

08000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|

다음으로 해당 오프셋에 대한 루프백을 만들었습니다.

sudo losetup -o 0x08000000 -r -f /deb/sdb

이제 내 루프백을 나열하면 다음을 볼 수 있습니다.

sudo losetup -a
/dev/loop8: [0006]:659 (/dev/sdb), offset 134217728

이제 마운트를 열고 손가락을 꼬아보자

sudo cryptsetup luksOpen /dev/loop8 luksrecover

그럼...열려요!

일반적인 설치 명령을 입력하고 다시 작업을 시작하세요! 정의. 이 헤더를 백업하세요. 데이터를 복사하고 드라이브를 다시 포맷하고 다시 넣어도 왜 이런 일이 발생하는지 전혀 알 수 없습니다.

답변2

16진수 덤프에는 블록 #0(00000000 - 000001ff)과 블록 #1의 시작 부분(00000200+)이 표시됩니다.

000001fe에서는 값이 0xaa55(리틀 엔디안)입니다. 블록 #0의 내용은 MBR 파티션 테이블이 존재한다는 기본 표시입니다. 첫 번째(이 경우 유일한) 기본 파티션 항목은 000001be - 000001cd에 있습니다. 즉:

000001b0  .. .. .. .. .. .. .. ..  .. .. .. .. .. .. 00 00  |................|
000001c0  01 00 ee fe ff ff 01 00  00 00 ff ff ff ff .. ..  |................|

이것다음과 같이 디코딩됩니다.0xee 유형의 비활성 파티션은 LBA 0x00000001에서 시작하고 길이는 0xffffffff입니다. 이는 CHS 필드가 나타낼 수 있는 것보다 크기 때문에 파티션 시작/끝 CHS 필드는 무시될 수 있습니다.

파티션 유형은 0xee이것이 GPT임을 나타냅니다.보호 MBR, 따라서 이 MBR 파티션 테이블은 완전히 무시되어야 하며실제 GPT 파티션 테이블LBA #1부터 시작하세요.

first usable LBA16진수 덤프의 00000228에서 시작하는 값이 0x00000000 00000800인 GPT 헤더 필드는 블록 2048입니다. 여기에 512바이트의 블록 크기를 곱하면 1MiB 디스크의 일반적인 값인 0x100000 또는 1048576이 됩니다. 이는 찾은 오프셋(134217728 = 디스크의 128MiB)과 일치하지 않으므로 LUKS 파티션 앞에 디스크에 LUKS가 아닌 파티션이 있을 수 있습니다. 불행하게도 GPT 파티션 항목은 블록 #2 및 후속 블록(필요한 경우)에 저장되므로 16진수 덤프에서는 유효성 검사를 허용하지 않습니다.

GPT 헤더의 필드 last usable LBA값은 0x01d1c0be8e = 7814037134이며 덤프의 오프셋 00000230에 있습니다. 이는 보고된 디스크 크기보다 34블록 작은 것으로 fdisk, 이는 올바른 것으로 보입니다. 디스크 끝에는 백업 GPT 헤더 블록을 위한 33블록과 32개의 파티션 항목 블록을 위한 공간이 있습니다. +1은 블록 번호가 블록에서 제거됨 #1 대신 #0으로 시작합니다.

이로 인해 RAID 메타데이터 영역을 위한 파티션 공간 외부에 공간이 남지 않는 것 같습니다.

RAID가 파티션 장치가 아닌 전체 디스크 장치를 사용하여 생성되었다고 확신합니까? 다시 말하면 이런 것일 수도 있겠네요

sudo mdadm --create --verbose /dev/md5 --level=1 --raid-devices=2 /dev/sdp2 /dev/sdb2

대신에:

sudo mdadm --create --verbose /dev/md5 --level=1 --raid-devices=2 /dev/sdp /dev/sdb

RAID 배열을 생성한 후 fdisk /dev/sdb이와 유사한 것을fdisk /dev/sdp 사용하여 디스크를 분할하면 GPT 파티션 테이블이 RAID 메타데이터를 덮어쓰고 재부팅 후에는 더 이상 RAID가 없고 일반 GPT가 디스크를 분할합니다. (두 번째 디스크는 현재 사용되지 않으며 곧 첫 번째 디스크와 동기화되지 않습니다.)

또 다른 가능성은펌웨어가 RAID 메타데이터를 지웠을 수 있습니다.(아니면 여기), 이전 시스템으로 돌아갈 때, 또는 디스크를 새 시스템으로 이동할 때.

기본적으로 시스템의 UEFI 펌웨어는 Linux 소프트웨어 RAID를 이해하지 못하지만 GPT 파티션 테이블을 확실히 이해합니다. 펌웨어가 디스크의 시작 부분에 GPT 기본 파티션 테이블이 있음을 발견했지만 백업 파티션 테이블이 디스크 끝 부분에 정확하게 나타나지 않는 경우(RAID 메타데이터가 메타데이터 형식 1.0 이하로 저장되어 있기 때문) 일부 UEFI 펌웨어는 last usable LBA백업 GPT를 디스크의 실제 끝에 다시 작성하여 RAID 메타데이터를 덮어쓰는 방식으로 기본 GPT를 늘려 이 문제를 "수정"합니다 .

이 "수정"은 분명히 UEFI 펌웨어 문제입니다.~해야 한다UEFI 사양에 따라 이 작업을 수행합니다. LUN 크기 조정은 엔터프라이즈 SAN 관리자에게는 편리하지만 전체 디스크 소프트웨어 RAID 구현에는 번거롭습니다.

마찬가지로, 소프트웨어 RAID 메타데이터 형식 1.1 이상(RAID 메타데이터를 디스크 시작 부분에 배치)을 사용하는 경우 펌웨어는백업 GPT그리고 이를 사용하여 "잃어버린" 마스터 GPT를 재구축하고... 다시 RAID 메타데이터를 짓밟습니다.

전체 디스크 수준 기능 소프트웨어 RAID가 있는 경우및 RAID 내의 파티션그러면 암호화된 LUKS 볼륨은~ 해야 하다이미 /dev/md/d5p2또는 와 같은 것입니다 /dev/md_d5p2.

현재 기본 GPT 이후, 첫 번째 파티션이 시작되기 전에 할당되지 않은 공간이 있는 경우 이는 RAID 메타데이터 형식 1.1 이상을 사용하고 있고 펌웨어가 RAID 메타데이터 이후부터 기본 GPT를 변경하고 있음을 의미할 수 있습니다. 디스크의 진정한 시작.

마찬가지로, 디스크가 한때 파티션에 의해 완전히 점유되었지만 이제 마지막 파티션 이후 약 64-128K의 할당되지 않은 공간이 있는 경우 RAID 메타데이터 형식 1.0 이하를 사용하고 있고 펌웨어가 이를 덮어쓴 것입니다. 둘 다에서 백업 GPT를 사용합니다. 원래 시스템과 디스크를 새 시스템으로 이동할 때.

제 생각에는 GPT는 소프트웨어 RAID 세트를 구축하는 사람이라면 누구나 알아야 할 새로운 것을 제공합니다.

  • (페어링된) 파티션에서 파티션되지 않은 RAID 세트를 만드는 데 문제가 없는 것 같습니다( 즉 , 다음 /dev/md0에서 생성 및 생성 등)./dev/sdX1/dev/sdY1/dev/md1/dev/sdX2/dev/sdY2
  • sgdisk --zap전체 디스크 소프트웨어 RAID 설정을 준비할 때 펌웨어 기반 자동 복구가 다음 부팅 시 RAID 메타데이터를 즉시 덮어쓰지 않도록 하기 위해 유사한 도구를 사용하여 기본 및 백업 GPT를 완전히 지우도록 주의해야 합니다 .
  • UEFI 시스템에서 전체 디스크 소프트웨어 RAID를 세분화할 때 펌웨어가 RAID 내부의 GPT를 감지할 수 있으므로 GPT 파티션 이외의 다른 파티션을 다음 상위 계층으로 사용하는 것이 좋습니다(전체 디스크 RAID 어레이 장치를 LVM PV로 만들 수도 있음). RAID 계층을 이해하지 못한 채 "잘못 배치된" GPT를 "수정"하려고 시도하여 컨테이너 파티션 테이블을 손상시키고 RAID 메타데이터를 손상시켰습니다.
  • 즉, UEFI 부팅 가능 시스템 디스크에서 전체 디스크 소프트웨어 RAID를 사용하는 것은 아마도 좋은 생각이 아닐 것입니다. 시스템 디스크에는 기본적으로 GPT 파티션 테이블과 EFI 시스템 파티션이 있어야 하고 펌웨어는 두 가지를 모두 완벽하게 지원할 수 있어야 하기 때문입니다. 파티션. 알아보고 방문해보세요.

관련 정보