Linux 소프트웨어 RAID(mdraid)의 일부였던 이전 GPT 파티션 디스크에 백업 GPT 헤더를 복원했습니다. 이는 partprobe가 손상된 헤더를 보고하기 때문에 수행됩니다.
이제 실제로는 소프트웨어 RAID가 디스크 전체를 관리해야 하는데, 서버를 다른 방식으로 사용해도 이전에 사용했던 파티션 정보가 그대로 남아있습니다.
GPT가 내 설정과 관련이 없다는 사실을 깨닫고 gdisk 전문가 모드를 통해 GPT 정보를 완전히 삭제했습니다.
그러나 현재 우려되는 점은 GPT 테이블 복구/GPT 정보 삭제로 인해 소프트웨어 RAID가 손상될 수 있다는 것입니다.
시스템 자체에는 이것이 사실이라는 표시가 표시되지 않지만(여전히 부팅되고 데이터에 액세스할 수 있음) 내 작업으로 인해 데이터가 여전히 손상될 수 있는지 제안할 수 있는 사람이 있는지 또는 어떤 방법으로 무결성을 확인할 수 있는지 궁금합니다. 자료.
답변1
버전 1.2 메타데이터는 블록 장치 시작 부분부터 4K로 저장됩니다. 종종 데이터 자체가 매우 중요합니다. 예를 들어, 이것은 mdadm -E
내 어레이 중 하나에 있는 디스크(의 일부)입니다.
/dev/sda3:
Magic : a92b4efc
Version : 1.2
⋮
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=2224 sectors
⋮
보시다시피, (8 * 512바이트/논리 섹터 = 4KiB) 중 8개 섹터가 배열 슈퍼블록입니다. 데이터는 실제로 128MiB로 훨씬 더 큽니다.
GPT 레이아웃의 첫 번째 섹터(#0)는 보호 MBR이고 다음 33개 섹터(#1~#33)는 GPT 파티션 테이블과 항목입니다. 디스크 저장소 백업의 마지막 33개 섹터입니다.
따라서 백업 GPT 파티션 테이블에서 복원하면 총 처음 34개 섹터를 덮어쓸 수 있습니다. 그러나 거리가 20만 섹터보다 훨씬 더 멀기 때문에 데이터에는 영향을 미치지 않습니다. 나중에 사용하지 않은 공간의 양에 따라 마지막에 백업을 작성하더라도 손상이 발생하지 않습니다. (내 배열에 공간이 많았으므로 귀하의 공간은 다를 수 있습니다.)
그러나 이미 배열을 조립했기 때문에 슈퍼블록이 파괴되지 않은 것 같습니다. 각각의 디스크를 확인해 보도록 하겠습니다 mdadm -E
만, 그 외에는 파손된 부분은 없는 것 같습니다. (a)가 사용 중이고 (b)가 내부인 경우 쓰기 의도 비트맵이 슈퍼블록과 데이터 사이의 공간에 저장되므로 지우고 다시 활성화해야 할 수도 있습니다.