☰

전체 디스크로 구축된 mdadm raid1 복원(파티션 데이터 덮어쓰기)

tag-icon • tag-icon data-recovery raid luks mdadm raid1
전체 디스크로 구축된 mdadm raid1 복원(파티션 데이터 덮어쓰기)

새 PC를 설정할 때 상단에 LUKS가 있는 2개의 드라이브가 있는 새 RAID 1도 설정했습니다. 모든 데이터를 복사한 후 모든 것이 사용 가능한지 확인한 다음 기존 드라이브를 파쇄했습니다.

하지만 이제 더 이상 RAID가 없습니다. RAID를 생성할 때 파티션을 사용하는 대신 전체 디스크를 사용했기 때문에 이것이 가장 가능성이 높다는 것을 알았습니다. RAID를 복원하고 그 안의 데이터를 복구할 수 있는 방법이 있습니까? RAID를 생성하기 위한 정확한 명령을 저장했지만, 돌이킬 수 없는 문제가 발생하지 않을 것이라는 확신이 들 때까지는 아무 것도 하고 싶지 않습니다.

fdisk -l두 드라이버의 출력:

Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EFAX-68J
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: 068E27EE-055B-A24A-B51B-D0B79E3DEA00

Disk /dev/sdc: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: TOSHIBA HDWD130 
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: F4ADCB83-B715-9B4A-A6A0-96687568611E

RAID는 다음 명령을 사용하여 생성됩니다.

sudo mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc

mdadm --examine두 디스크의 출력은 동일합니다.

/dev/sdb:
   MBR Magic : aa55
Partition[0] :   4294967295 sectors at            1 (type ee)

/dev/sdc:
   MBR Magic : aa55
Partition[0] :   4294967295 sectors at            1 (type ee)

따라서 파티션 데이터가 삭제된 것처럼 보이므로 더 이상 RAID 구성원으로 표시되지 않습니다(fd 유형). 파티션 데이터를 다시 쓰고 RAID를 다시 시작할 수 있습니까?

내 줄 mdadm.conf은 다음과 같습니다.

ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=WORKSTATION:0 UUID=fe2547a6:3296c156:303989ac:febb5051 devices=/dev/sdb,/dev/sdc

구성원이 1명뿐인 RAID를 시작하고 그런 방식으로 데이터를 복구할 수 있습니까? LUKS 헤더는 두 디스크 모두에서 동일해야 합니다. 그렇죠? 아니면 다시 덮어쓰기 전에 백업해야 합니까?

도움을 주시면 정말 감사하겠습니다. 이 문제가 발생하기 전에는 약 1500GB의 데이터가 있었습니다.

PS 2개의 디스크가 크기가 다르다는 것을 알고 있습니다. 예전에는 2개의 3TB 드라이브였지만 그중 하나가 고장 나서 4TB 드라이브로 교체했습니다. 이런 일이 발생하기 전에는 RAID가 작동하고 완전히 동기화되었습니다.

답변1

RAID 1은 단순 미러이므로 RAID 문제를 무시하고 LUKS 헤더를 직접 검색할 수 있습니다. 관련된 파티션이 없으면 드라이브 시작 부분 근처에 있어야 합니다. mdadm상당히 큰 데이터 오프셋이 사용되므로 아마도 수백 MiB 오프셋이 있을 수 있습니다 .

다음 명령은 드라이브의 처음 1GiB를 검색합니다.

# hexdump -C -n 1G /dev/sdx | grep LUKS
08100000  4c 55 4b 53 ba be 00 02  00 00 00 00 00 00 40 00  |LUKS..........@.|

이 예에서는 오프셋 0x8100000(129MiB)에 잠재적인 LUKS 헤더가 있습니다.

이 오프셋에 (읽기 전용) 루프 장치를 만들고 작동하는지 확인하세요.

# losetup --find --show --read-only --offset $((0x8100000)) /dev/sdx
/dev/loop2
# cryptsetup luksOpen /dev/loop2 lukstest
Enter passphrase:
# mount -o loop,ro /dev/mapper/lukstest /mnt/somewhere

작동하는 경우 데이터를 그대로 유지하면서 복구를 시도할 수 있습니다. 하지만 어쨌든 먼저 전체 백업 복사본을 만드는 것이 좋습니다.

파티션 데이터를 다시 쓰고 RAID를 다시 시작할 수 있습니까?

이론적으로는 반드시

  1. 오프셋 1MiB(향후 파티션 오프셋)를 사용하여 두 개의 루프 장치(*)를 생성합니다.
  2. 루프 장치에서 위의 hexdump 명령을 다시 실행하여 올바른 오프셋을 확인합니다(베어 드라이브와 비교하여 -1MiB여야 함).
  3. 이러한 순환장치를 이용하여올바른 오프셋으로 RAID를 다시 생성합니다.그에 따라 mdadm.conf를 조정합니다.
  4. cryptsetup open급습,
  5. 디스크 끝에 GPT 백업 헤더를 위한 공간을 확보하기 위해 파일 시스템을 약간 줄입니다.
  6. 파일 시스템 마운트 해제(마운트된 경우), cryptsetup closeluks, mdadm --stopraid, losetup -d루프 장치 분리,
  7. 두 드라이브 모두에서 오프셋이 1MiB인 파티션을 생성합니다.

이 시점에서 파티션이 있는 드라이브, 파티션에 RAID, RAID에 Luk, Luk 내에 파일 시스템이 있어야 합니다.

그러나 이는 최선의 시나리오이며 귀하의 상황을 올바르게 이해한 경우에만 이 방식으로 작동할 것입니다. 이것이 완전히 잘못될 수 있는 방법은 여러 가지가 있습니다.

(*)

장치 끝을 손상시키지 않고 파티션을 생성하려면 먼저 파일 시스템을 축소해야 하기 때문에 루프 장치를 사용한 점프 링이 필요합니다. 그리고 RAID가 실행 중인 경우에만 파일 시스템을 축소할 수 있습니다(두 개의 드라이브에서 실행 중이고 일관성이 유지되어야 하는 경우).

파티션을 직접 생성했다면 아마도 아무 일도 일어나지 않았을 것입니다(또는 어쨌든 그런 일이 일어났을 것입니다). 그러나 기술적으로 이 경우 원시 디스크에서 파티션으로 이동하는 올바른 방법은 아닙니다.

답변2

해결되었습니다!

Frostschutz가 제공한 답변은 훌륭했습니다. 현재 모든 데이터를 다른 디스크에 백업하고 있습니다.

Google이나 다른 검색 엔진을 통해 우연히 이 질문을 발견한 경우. Frostschutz에서 제공하는 단계를 사용하여 LUKS 헤더를 찾으십시오. 아무것도 찾을 수 없으면 자신의 질문을 게시하는 것이 더 좋지만 꽤 어려울 것입니다.

mdadm raid로 전체 디스크를 사용하려면 먼저 파티션을 생성하는 것이 좋습니다. 당신이 무엇을 하고 있는지 정확히 알고 있다면할 수 있는작동하지만 디스크를 재사용하는 경우 UEFI 표준에 따라 "잘못된" 파티션 테이블을 덮어쓰는 데 사용되는 백업 테이블이 디스크 끝에 있을 수 있습니다(정보 참조).이것HN 기사)

와 의 조합을 사용하여 모든 파티션 정보를 완전히 지울 수 있습니다 sgdisk --zap. wipefs -a하지만 머리 아파하지 마시고 저와 같은 실수를 저지르지 마세요.

관련 정보