백업 파티션은 사용자 상호 작용 없이 UUID를 변경합니다.

백업 파티션은 사용자 상호 작용 없이 UUID를 변경합니다.

최근에 새 하드 드라이브를 구입해야 했습니다. 제가 그곳에 있었기 때문에 제안된 대로 하나 대신 두 개를 구입했습니다(둘 다 동일한 모델입니다). 두 번째 하드 드라이브에는 여전히 많은 공간이 있으므로 루트 파티션의 전체 백업에만 사용합니다.

# single user mode.
# dd if=/dev/sda1 of=/dev/sdb3 bs=32M

그런 다음 백업 파티션의 UUID를 변경하고 다른 UUID가 있는지 다시 확인했습니다.

# tune2fs -U random /dev/sdb3

그 후 몇 주 동안 모든 것이 순조롭게 진행되어 매일 부팅되고 잘 작동했습니다.

최근에 컴퓨터를 부팅한 후 갑자기 실제 루트 파티션(sda1) 대신 루트로 백업 파티션(sdb3)이 생겼습니다.

그래서 컴퓨터를 종료하고 다시 시작한 후 파티션을 다시 백업했습니다. 부팅 명령줄을 수정하고 올바른 장치(sda1)로 직접 부팅한 후 무슨 일이 일어나고 있는지 확인했습니다. 믿을 수 없지만 백업 파티션(sdb3)은 마술처럼 실제 루트(sda1)와 동일한 UUID를 가지고 있습니다.

(알려지지 않은 제3자의 악의적인 조작이 없다고 가정할 때) 어떻게 이런 일이 일어날 수 있습니까? 시스템인가요? :)

나는 나만이 물리적으로 접근할 수 있는 가정용 컴퓨터에서 데비안 테스트를 실행하고 있습니다.

편집하다:

  • 백업 슈퍼블록은 모두 UUID를 수정했습니다. dumpe2fs로 이를 확인했습니다.
  • dump 명령을 다시 실행하지 않았습니다. 실제로 제가 가장 먼저 확인한 것은 (모든 bash 기록을 검색하여) 다시 실행하지 않았다는 것입니다.
  • 모든 드라이브의 SMART 정보를 확인했습니다. 구성 저장소의 모든 버전을 관리했기 때문에 스마트 정보를 이전 버전과 비교했습니다. 의심스러운 것은 없습니다.

답변1

아직 테스트해본 적이 없어서 실제로 그런 일이 일어날지는 확실하지 않습니다. 하지만 만약에:

  1. sdb3의 기본 슈퍼 블록(예: 불량 섹터)과 백업 슈퍼 블록도 손실되었습니다(확실합니다).
  2. 자동으로 슈퍼블록을 백업하려고 시도하는 경우 e2fsck(그런 것 같지만 확실하지 않음)
  3. tune2fs메인 슈퍼블록만 업데이트하세요. (모르겠어요)

그런 다음 fsck는 백업에서 복사하여 이전 UUID를 복원하여 기본 슈퍼블록을 복구합니다.

dd하지만 현실적으로 는 새로 고침 백업을 다시 실행하고 UUID 변경을 잊어버릴 가능성이 더 높다고 생각합니다 .

partclone이나 partimage를 살펴보는 것이 좋습니다.

관련 정보