☰

fdisk는 "백업 GPT 테이블이 손상되었지만 기본 테이블이 정상으로 나타나므로 이를 사용하게 됩니다."라고 불평합니다.

tag-icon • tag-icon hard-drive arch-linux gpt
fdisk는 "백업 GPT 테이블이 손상되었지만 기본 테이블이 정상으로 나타나므로 이를 사용하게 됩니다."라고 불평합니다.

최근에 2개 샀어요서부 디지털(WD)이지스토어8TB 외장 USB 드라이브껍데기WD Red를 사용하세요나스내 컴퓨터 내부에 드라이브(아치 리눅스). 첫 번째는 결국 WD White 라벨 드라이브(WD80EMAZ-00WJTA0)였고 두 번째는 실제로 Red(WD80EFAX-68LHPN0)였습니다.

화이트를 설치했는데 모든 것이 괜찮아 보였습니다. 5TB에 가까운 데이터를 문제 없이 복사했지만 나중에 다음과 같은 메시지가 표시되었습니다.GPT사용시 오류GParted내가 작업하고 있던 다른 드라이브에서. 내 데이터에 접근할 수 있는 것 같아서 아직 아무 것도 하지 않았습니다.

오늘 저는 Red 드라이브를 설치했는데 파티션을 나누거나 포맷하기 전에 해당 드라이브에서도 똑같은 오류가 발생했습니다. 나는 해결책을 찾고 있었고 그것이 갖는 것과 관련이 있다고 생각했습니다.호스트 보호 구역(HPA), 하지만 이를 확실히 확인하는 방법이나 그렇다면 어떻게 해야 할지 모르겠습니다. 화이트 드라이브에 있는 데이터를 그대로 유지하면서 이 문제를 해결할 수 있나요? Red 드라이브를 실험해 볼 수 있지만 무엇을 시도해야 할지 잘 모르겠습니다.

sudo gdisk /dev/sdb

산출:

GPT fdisk (gdisk) version 1.0.3

Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): p
Disk /dev/sdb: 15628053168 sectors, 7.3 TiB
Model: WDC WD80EMAZ-00W
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 6837F2B2-3A65-4260-B87E-B4682BAEE5FF
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 15628052446
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048     15628050431   7.3 TiB     0700  WD_8TB

Command (? for help): v

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Identified 1 problems!

그리고..

sudo hdparm -N /dev/sdb

산출:

/dev/sdb:
max sectors   = 15628053168/15628053168, HPA is disabled

답변1

귀하의 hdparm결과는 HPA가장애가 있는,그래서 그 문제는 그것과 관련이 없습니다.

여기와 다른 포럼에 게시된 유사한 문제로 판단할 때 이 문제의 가장 일반적인 원인은 마더보드 기반 소프트웨어 RAID(기만적인 용어이지만 "가짜 RAID"라고도 함)의 사용입니다. 이러한 유형의 소프트웨어 RAID의 문제점은 사용할 데이터 구조에 동의하기 위해 최소한 두 개의 소프트웨어 구성 요소, 즉 펌웨어와 OS가 필요하다는 것입니다. 다중 부팅 컴퓨터의 경우 모든 OS는 동일한 RAID 데이터 구조를 이해해야 하므로 일치시키려면 3개 이상의 구성이 필요합니다. 어떤 경우든 펌웨어에서는 디스크가 마더보드 기반 소프트웨어 RAID를 사용한다고 생각하지만 OS에서는 그렇지 않다고 생각하는 경우 백업 GPT 데이터 구조가 손상될 가능성이 높습니다. 그 이유는 이러한 데이터 구조가 디스크의 마지막 몇 섹터를 차지하고 마더보드 기반 소프트웨어 RAID가 일반적으로 저장하는 위치이기도 하기 때문입니다.그것은데이터 구조. 따라서 한 세트의 데이터 구조가 다른 세트를 없애게 됩니다. 괴짜가 계속됩니다. (아래를 참조하세요.) 모든 것이 동기화되면 투명해집니다. 마더보드는 데이터 구조를 디스크 끝에 배치하고 OS는 이를 이해하여 디스크의 해당 부분을 숨기므로 걱정할 필요가 없습니다.

그러나 파티션 테이블을 생성하지 않은 경우 문제는 사용자 측의 잘못된 구성으로 인해 발생한 것이 아니라 디스크 제조업체 측에서 발생했거나 중간에 디스크를 처리한 누군가(예: , 디스크를 다른 사람에게 판매한 후 반환하고 반환 상자에서 가져온 경우). 이 경우 win 을 수행하면 gdisk파티션 테이블을 다시 작성해야 하므로 오류 메시지가 사라집니다. GPT 백업 데이터 구조가 존재하는 이유는 다음과 같습니다.지원,일부 유형의 버그, 사용자 오류 또는 하드웨어 결함으로 인해 기본 데이터 구조(디스크 시작 부분에 저장됨)가 손상되는 경우에 사용됩니다. 대부분의 OS와 도구는 백업 데이터 구조가 없어도 제대로 부팅되지만, 이를 사용하지 않으면 이점을 포기하게 됩니다. 또한 일부 도구가 손상으로 인해 혼동되어 나쁜 일을 할 가능성도 있습니다. (저는 이에 대한 예를 알지 못하지만 항상 새로운 도구가 작성되고 있고 오래된 도구에서는 새로운 버그가 발생할 수 있으므로 그러한 버그가 발생할 가능성은 항상 존재합니다.)

한 가지 더: gdisk'는 v백업 파티션 데이터가 있어야 하는 디스크 끝 부분에 존재하지 않음을 나타냅니다. 이 문제를 해결하려면 x전문가 메뉴로 이동한 다음 e백업 데이터 구조를 재배치하면 됩니다 . 이 잘못 배치된 백업 파티션 테이블은 펌웨어에서 마더보드 기반 소프트웨어 RAID를 사용하는 것과 일치하지만 OS에서는 그렇지 않습니다. 또는 다양한 기타 문제(예: 확장된 하드웨어 RAID 어레이 또는 더 작은 크기에서 작은 크기로 복제된 디스크)와 일치합니다. 더 큰 디스크). 백업 데이터 구조를 재배치하는 것은 일반적으로 좋은 생각이며 어떤 경우에는 디스크의 전체 용량을 사용해야 합니다. (귀하의 경우 약 2,000개의 섹터만 복구하므로 용량 측면에서 큰 문제는 아닙니다.) 그러나 마더보드가 소프트웨어 RAID를 사용하도록 구성된 경우 백업 데이터 구조를 이동하면 지워집니다. 소프트웨어 RAID 데이터. 이로 인해 마더보드가 혼동될 수 있으며 마더보드가 데이터를 다시 쓰기 때문에 다음에 재부팅할 때 GPT가 손상될 수 있습니다. 해결 방법은 펌웨어 설정 도구에서 소프트웨어 RAID 옵션을 비활성화한 다음 gdisk다른 도구를 사용하여 GPT 데이터 구조를 이동하는 것입니다 .

답변2

WD Easystore 인클로저의 컨트롤러는 어떤 이유로 드라이브 끝에 있는 소수의 블록을 "훔칩니다". 이로 인해 드라이브의 "끝"이 변경됩니다. 드라이브가 인클로저에 있는 동안 GPT로 파티션을 나누면 백업 파티션 테이블이 일반적이지 않은 위치에 기록됩니다.진짜도난당한 블록은 보이지 않게 숨겨져 있기 때문입니다.

드라이브를 제거하면 드라이브의 실제 끝에 접근할 수 있게 되며 GPT 백업이 없기 때문에 문제가 있는 것처럼 보입니다. 자세한 내용은 다음에서 논의됩니다.레딧 스레드.

드라이브에 아무것도 없는 경우 가장 쉬운 해결 방법은 새 GPT로 다시 파티션을 나누는 것입니다. 백업 GPT를 올바른 위치에 수동으로 복사하여 문제를 해결하는 몇 가지 수동 접근 방식이 있다고 가정합니다. 이 시점에서 새로 액세스할 수 있는 공간을 사용하기 위해 마지막 파티션을 확장할지 여부를 결정할 수 있습니다. 하지만 그 변화량은 아마도 1MB도 되지 않기 때문에 그만한 가치가 없을 수도 있습니다.

관련 정보