하드웨어 RAID 어레이가 있는데 마이그레이션 중에 디스크에 오류가 발생하고 복구 없이 컨트롤러에 오류가 발생했습니다. 저는 어레이의 현재 상태(약 160GB는 마이그레이션되고 나머지 5.TB는 마이그레이션되지 않음)를 올바르게 매핑하는 작은 Python 스크립트를 작성했으며, 해당 정보를 사용하여 파일 시스템을 새 디스크에 재구축하겠습니다. 이 과정은 시간이 오래 걸릴 수 있습니다.
따라서 내 질문은 처음 250GB를 복원하는 경우 처리하기 전에 파일 시스템의 이 부분을 마운트하고 스크립트가 올바른 작업을 수행하는지 확인할 수 있는지입니다(예: 블록/스트라이프의 순서가 올바른 것이 아닌 경우 결과는 다음과 같습니다). 쓰레기) 전체 배열? 그렇다면 설치하려면 어떤 설치 명령을 실행해야 합니까?
그런데, 파티션 테이블이 아닌 파일 시스템만 필요하다고 가정하겠습니다.
편집: 오류에 대한 좀 더 구체적인 세부 정보: 4개의 디스크 RAID 5가 있었고 온라인으로 용량을 5개의 디스크로 확장했는데 새 디스크에 오류가 발생했습니다.
지금까지 내가 한 일은 마이그레이션이 도달한 지점을 계산하는 것입니다(A xor B xor C == D를 사용하고, 이전 배열의 경우 true, 새 배열의 경우 false, 빈 공간의 결과 무시)
이전 스트라이프 크기, 새 스트라이프 크기 및 마이그레이션된 크기를 사용하여 어레이 사이의 "빈 공간"을 계산합니다. 일치하는 항목이 나올 때까지 빈 공간 블록의 끝과 마이그레이션된 블록의 끝을 비교하여 이를 다시 확인합니다. 설립하다.
지금은 스트라이핑을 다시 작성하고 배열의 두 부분을 서로 붙이고 새 디스크에 쓰는 코드를 작성하고 있습니다. 이상적으로는 코드를 작성하지 않고도 이 코드의 결과를 확인할 수 있기를 바랍니다. 전체 6TB 어레이. 처음 250GB 정도를 기록하면 복원이 완료될 때까지 며칠을 기다리지 않고도 전체 어레이 복원 프로세스를 검토하고 구체화할 수 있습니다.
답변1
파티션의 절반을 마운트할 수 없습니다. 절반 파티션은 파일 시스템의 파일 절반을 포함하는 컨테이너가 아니며 본질적으로 사용할 수 없습니다. 파일에 액세스하려면 전체 파티션에 분산될 수 있는 여러 디렉터리와 inode를 탐색해야 합니다.
그러나 파티션의 시작 부분을 확인하여 유효한 파일 시스템 헤더가 있는지 확인할 수 있습니다. 이를 위해서는 파티션 시작 부분(처음 몇 킬로바이트)만 필요합니다. file -s /dev/something특정 장치에 파티션이 포함되어 있는지 여부를 알려줍니다(재조립 중인 RAID 어레이에 대한 장치 항목이 이미 있다고 가정).
답변2
시도해 보아야 하지만 읽기 전용 방법을 사용해야 합니다. 파일 시스템 슈퍼 블록에 여전히 액세스할 수 있으면 이를 마운트할 수 있어야 합니다. 파일 시스템을 탐색하면 많은 IO 오류가 발생하고 잘못된 파일 이름과 내용이 인쇄될 수 있지만 이는 어떤 경우에도 얻을 수 있는 최선의 방법입니다( testdisk특정 파일 형식을 검사하는 도구 제외).
나는 노력할 것이다:
tune2fs -l <blockdevice>: 작동한다면 설치할 수 있어야 합니다.- `mount -o ro /mnt/recovery
답변3
마이그레이션에 대해 더 자세히 설명해주세요. 어레이를 확장하거나 축소했거나 디스크를 추가하거나 제거했습니까? 오류 대상 대신 선형 및 스냅샷을 사용하므로 각 실험의 또 다른 복사본을 생성할 필요 fsck없이 가상 레이어에서 이와 같은 실험을 실행할 수 있습니다. debugfs에 설명된 것과 유사한 방법을 사용하십시오.https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file
마운팅은 "블록/스트라이프 순서가 잘못된지 확인"하는 등의 좋은 방법이 아닐 수 있습니다. 어레이가 다른 디스크로 커지면 이전 데이터와 새 데이터 표현이 겹치는 영역이 있어야 전체 복구가 가능할 수 있습니다.