나는 3개의 하드 디스크를 가지고 있습니다. 다음 단락에서 /dev/sda, /dev/sdb 및 /dev/sdc라는 이름의 단락에서 최신 항목이 먼저 나왔습니다. 참고: /dev/sdc에는 기본 파티션 /dev/sdc1 1개, 확장 파티션 /dev/sd2 1개, 논리 파티션 3개 /dev/sdc5, /dev/sdc6 및 /dev/sda7이 있습니다.
/dev/sda5 및 /dev/sdb5를 사용하여 성능이 저하된 RAID 5 장치 /dev/md0을 생성한 다음(RAID에 /dev/sdc5를 추가하여 일반 상태로 전환할 계획임) /dev/md0을 유일한 PV로 사용했습니다. LVM의 ext4 파일 시스템 /dev/mapper/vg0-lv0을 사용하여 lv를 생성했습니다.
아쉽게도 LVM을 탐색하고 플레이할 때 /dev/sdc1을 삭제한 후 실행해봤습니다 dd if=/dev/zero of=/dev/sdc1 bs=64M count=10. 따라서 실제로는 0이 /dev/sdc2에 기록되었고, /dev/sdc2에 저장된 파티션 테이블의 일부와 /dev/sdc5의 시작 부분이 손상되었습니다.
이것을 깨달았을 때 나는 즉시 다음과 같이 dd를 통해 /dev/sdc의 이미지를 만들었습니다 dd if=/dev/sdc of=/mount-point-of-vg0-lv0/sdc.img.
며칠 후 마침내 /dev/sdc에서 데이터 복구를 시도할 시간이 생겼습니다. 실제로는 /dev/sdc7이 백업이 없는 유일한 파티션이기 때문입니다. sdc.img 이미지 파일로 testdisk를 실행하고 빠른 검색 기능을 사용하여 파티션 테이블을 다시 만든 다음 /dev/loop0에 저장했습니다. /dev/loop0p7(/dev/sdc7의 이미지)이 다시 마운트 가능해졌으며 모든 파일이 정상인 것 같습니다. 그런 다음 find /mount-point-of-loop0p7 -type f -exec md5sum {} \; > sdc7_img.md5sum/dev/loop0p7의 모든 파일에 대한 MD5 체크섬 목록을 작성 했습니다 .
물리적 /dev/sdc 장치를 처리할 때 testdisk의 빠른 검색은 모든 파티션을 찾지 않지만 심층 검색은 검색합니다. 그런 다음 유사한 명령을 사용하여 물리적 /dev/sdc7의 모든 파일에 대한 MD5 체크섬 목록 sdc7.md5sum을 작성했습니다. sdc7_image.md5sum과 비교해보니 4개의 파일이 다른 것을 발견했습니다. 수동으로 비교한 결과 각 파일의 차이는 1바이트에 불과한 것으로 나타났습니다. 그리고 한 파일 이름에 CRC32가 있으므로 물리적인 /dev/sdc7의 파일이 올바른지 확인할 수 있습니다.
그래서 내 질문은, 왜 이런 이상한 일이 일어났는가 하는 것입니다. fsck.ext4 -c -c /dev/mapper/vg0-lv0불량 블록이 없는지 확인하기 위해 이미 실행했습니다 . 1.2TB 데이터의 4바이트 차이는 아주 작은 비율이지만 이로 인해 앞으로 /dev/mapper/vg0-lv0에 데이터를 저장하는 데 자신감이 없습니다.
업데이트: 모든 작업은 Windows 7에서 실행되는 VirtualBox 4.1.16에서 실행되는 최신 ArchLinux에서 수행되었습니다. /dev/sda, /dev/sdb 및 /dev/sdc는 모두 물리적 하드 디스크와 연결되어 있습니다. 을 통해 VBoxManage internalcommands createrawvmdk. VirtualBox는 물리적 /dev/sdc7에 대해 md5sum을 만드는 동안 VERR_ACCESS_DENIED 오류만 보고했으며, diskpartWin7을 통해 물리적 디스크를 오프라인화한 후에는 더 이상 오류가 발생하지 않았습니다.
답변1
일어날 수 있는 일이 몇 가지 있습니다. 첫째, 디스크를 이미징하기 전에 sdc7 마운트 해제를 언급하지 않았으므로 당시 데이터가 기록 중이었을 수 있습니다. 하지만 나는 그것이 사실이 아니라고 추측할 것입니다. 그렇지 않으면 당신은 묻지 않을 것입니다. "먼저 디스크 이미지를 생성하세요"에 대한 귀하의 반응을 비난할 수는 없습니다. 꽤 좋은 반응입니다. 재부팅하기 전에도 커널은 여전히 메모리에 파티션 테이블을 갖고 있었습니다 /proc/partitions. .
가장 먼저 확인해야 할 것은 메모리 오류입니다. RAM이 불량할 수 있습니다. 귀하의 데이터는 의심할 바 없이 RAM을 여러 번 통과했습니다. 나는 아마도 이것을 잡을 ECC 메모리가 없다고 가정합니다.
하드디스크에도 오류가 있습니다. 임의의 소비자 하드 드라이브 몇 개에 대한 사양 시트를 보면 100Tbit당 1개라고 나와 있습니다. 1.2TB를 최소한 몇 번 복사했습니다(소스에서 읽기, 대상에서 읽기). 이는 19Tbit 읽기와 같습니다. 약간의 오류가 있는 것은 믿을만합니다. (불행히도 사양 시트 쓰기에 대한 오류율은 제공되지 않습니다.)
단일 바이트 손상 뒤에 운율이나 이유가 있었나요? cmp -l다양한 바이트를 알려줄 수 있습니다. 예를 들어, 페이지에서 항상 동일한 오프셋(페이지 크기는 4K일 것임)이고 항상 동일한 비트인 경우 이는 거의 결정적으로 RAM 결함을 가리킵니다. 항상 동일한 비트 또는 동일한 오프셋만 있더라도 이는 매우 결정적입니다. (4개 파일 모두에 대해 CRC32가 있었나요, 아니면 하나만 있었나요?)