파티션을 편집해야 한다는 것을 알고 'dd'를 사용하여 더 작은 HDD에 복제할 수 있습니까?

Question 1

다른 사람들이 여기서 언급한 것처럼 dd디스크 끝에 있는 GPT 테이블의 복사본으로 인해 을 사용하면 작동하지 않습니다.

다음 방법을 사용하여 더 작은 드라이브로 마이그레이션을 수행했습니다.

먼저 - 원하는 liveCD 배포판으로 부팅합니다.

더 작은 드라이브의 제약 조건에 맞게 소스 드라이브 파티션의 크기를 조정합니다( gparted예: 사용). 그런 다음 sda소스 디스크가 이라고 가정하고 sgdisk먼저 소스 드라이브에서 GPT 테이블의 백업을 생성하여 안전한 위치에 있도록 합니다.

    sgdisk -b=gpt.bak.bin /dev/sda

대상이라고 가정하고 sdb소스 드라이브에서 대상으로 테이블을 복제합니다.

    sgdisk -R=/dev/sdb /dev/sda

sgdisk이제 대상 디스크 경계 외부에 헤더 복사본을 배치하려고 시도했다고 불평하지만 그런 다음 대체하여 대상 디스크의 상한에 헤더를 올바르게 배치합니다.

선택한 도구( gparted예:)를 사용하여 대상 드라이브에 파티션 테이블의 올바른 복제본이 생성되었는지 확인하십시오.

를 사용하여 dd소스 드라이브의 각 파티션을 대상 드라이브에 복사합니다.

dd if=/dev/sda1 of=/dev/sdb1 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda2 of=/dev/sdb2 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda3 of=/dev/sdb3 bs=1M conv=sync,noerror,notrunc status=progress
etc...

dd분명히, 백업 없이 GPT 파티션 테이블을 복제하거나 콘텐츠를 가져올 때 드라이브 이름을 혼동한다면 콘텐츠에 작별 인사를 할 수 있습니다. :)

Answer

다른 사람들이 여기서 언급한 것처럼 dd디스크 끝에 있는 GPT 테이블의 복사본으로 인해 을 사용하면 작동하지 않습니다.

다음 방법을 사용하여 더 작은 드라이브로 마이그레이션을 수행했습니다.

먼저 - 원하는 liveCD 배포판으로 부팅합니다.

더 작은 드라이브의 제약 조건에 맞게 소스 드라이브 파티션의 크기를 조정합니다( gparted예: 사용). 그런 다음 sda소스 디스크가 이라고 가정하고 sgdisk먼저 소스 드라이브에서 GPT 테이블의 백업을 생성하여 안전한 위치에 있도록 합니다.

    sgdisk -b=gpt.bak.bin /dev/sda

대상이라고 가정하고 sdb소스 드라이브에서 대상으로 테이블을 복제합니다.

    sgdisk -R=/dev/sdb /dev/sda

sgdisk이제 대상 디스크 경계 외부에 헤더 복사본을 배치하려고 시도했다고 불평하지만 그런 다음 대체하여 대상 디스크의 상한에 헤더를 올바르게 배치합니다.

선택한 도구( gparted예:)를 사용하여 대상 드라이브에 파티션 테이블의 올바른 복제본이 생성되었는지 확인하십시오.

를 사용하여 dd소스 드라이브의 각 파티션을 대상 드라이브에 복사합니다.

dd if=/dev/sda1 of=/dev/sdb1 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda2 of=/dev/sdb2 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda3 of=/dev/sdb3 bs=1M conv=sync,noerror,notrunc status=progress
etc...

dd분명히, 백업 없이 GPT 파티션 테이블을 복제하거나 콘텐츠를 가져올 때 드라이브 이름을 혼동한다면 콘텐츠에 작별 인사를 할 수 있습니다. :)

Question 2

적어도 물리적 드라이브는 연기가 나지 않아야 하지만 파일 시스템이 더 이상 작동하지 않을 가능성이 매우 높습니다(즉, 대상 파일 시스템을 의미합니다. 방금 복사하고 소스의 아무 것도 건드리지 않았다면 소스 자체는 괜찮을 것입니다) ). 파티션 내부의 데이터가 반드시 오름차순으로 할당되는 것은 아닙니다. 파티션이 가득 차지 않은 경우에도 일부는 파티션 끝에 있을 수 있습니다(실제로 일부 파일 시스템에서는 이것이 결정론적으로 발생한다고 생각하지만 세부 사항을 알 수 있을 만큼 충분하지 않습니다). 거기에 있는 데이터는 파일 시스템의 무결성에 필수적일 수 있습니다. 그러므로 그러한 사본에 의존하지 말 것을 강력히 권고합니다.

이 복사를 수행하려면 먼저 내부 구조를 인식하고 모든 것을 올바른 순서로 더 작은 파티션에 다시 매핑할 수 있는 일부 도구를 사용하여 파티션을 축소해야 합니다. 그러면 복사를 할 수 있습니다. gparted이런 종류의 작업을 수행하는 데 좋은 GUI 인터페이스입니다.

가치 측면에서 bs일반적으로 가장 좋은 아이디어는 실제 복사본을 시작하기 전에 몇 가지 테스트를 수행하는 것입니다. 이 검사를 자동화하는 데 도움이 되는 몇 가지 도구가 있지만 이름이 기억나지 않습니다. 내 경험에 따르면 가장 좋은 범위는 일반적으로 4M에서 16M 사이입니다. 그 이상은 더 이상 벌지 못합니다. 그러나 이는 디스크 자체를 포함하여 많은 요소에 따라 달라집니다. 예를 들어 실제 고급 디스크로는 작업한 적이 거의 없는데 속도와 캐시 크기가 더 크기 때문에 더 높은 값에 적합할 수 있습니다.

편집하다파티션 전체를 복사하면 문제없이 사용할 수 있습니다. 그러나 다른 사람들이 강조한 것처럼 파티션 테이블이 손상되지 않았는지 확인해야 합니다(적어도 관련 항목). MBR의 4개 기본 파티션에는 디스크의 처음 512바이트에 설명되어 있으므로 문제가 없습니다. 논리 파티션은 확장 파티션 전반에 걸쳐 설명되므로 항목이 손실될 수 있습니다(그러나 어쨌든 손실되는 파티션을 설명합니다). GPT를 사용하면 디스크의 시작과 끝 모두에 파티션 테이블 복사본이 있습니다. 두 번째 것을 잃어버렸지만 첫 번째 것부터 다시 만들 수 있습니다. 물론 가능한 한 빨리 그렇게 하는 것이 좋습니다. 이와 관련하여 다른 답변이 더 정확했습니다.

Answer

적어도 물리적 드라이브는 연기가 나지 않아야 하지만 파일 시스템이 더 이상 작동하지 않을 가능성이 매우 높습니다(즉, 대상 파일 시스템을 의미합니다. 방금 복사하고 소스의 아무 것도 건드리지 않았다면 소스 자체는 괜찮을 것입니다) ). 파티션 내부의 데이터가 반드시 오름차순으로 할당되는 것은 아닙니다. 파티션이 가득 차지 않은 경우에도 일부는 파티션 끝에 있을 수 있습니다(실제로 일부 파일 시스템에서는 이것이 결정론적으로 발생한다고 생각하지만 세부 사항을 알 수 있을 만큼 충분하지 않습니다). 거기에 있는 데이터는 파일 시스템의 무결성에 필수적일 수 있습니다. 그러므로 그러한 사본에 의존하지 말 것을 강력히 권고합니다.

이 복사를 수행하려면 먼저 내부 구조를 인식하고 모든 것을 올바른 순서로 더 작은 파티션에 다시 매핑할 수 있는 일부 도구를 사용하여 파티션을 축소해야 합니다. 그러면 복사를 할 수 있습니다. gparted이런 종류의 작업을 수행하는 데 좋은 GUI 인터페이스입니다.

가치 측면에서 bs일반적으로 가장 좋은 아이디어는 실제 복사본을 시작하기 전에 몇 가지 테스트를 수행하는 것입니다. 이 검사를 자동화하는 데 도움이 되는 몇 가지 도구가 있지만 이름이 기억나지 않습니다. 내 경험에 따르면 가장 좋은 범위는 일반적으로 4M에서 16M 사이입니다. 그 이상은 더 이상 벌지 못합니다. 그러나 이는 디스크 자체를 포함하여 많은 요소에 따라 달라집니다. 예를 들어 실제 고급 디스크로는 작업한 적이 거의 없는데 속도와 캐시 크기가 더 크기 때문에 더 높은 값에 적합할 수 있습니다.

편집하다파티션 전체를 복사하면 문제없이 사용할 수 있습니다. 그러나 다른 사람들이 강조한 것처럼 파티션 테이블이 손상되지 않았는지 확인해야 합니다(적어도 관련 항목). MBR의 4개 기본 파티션에는 디스크의 처음 512바이트에 설명되어 있으므로 문제가 없습니다. 논리 파티션은 확장 파티션 전반에 걸쳐 설명되므로 항목이 손실될 수 있습니다(그러나 어쨌든 손실되는 파티션을 설명합니다). GPT를 사용하면 디스크의 시작과 끝 모두에 파티션 테이블 복사본이 있습니다. 두 번째 것을 잃어버렸지만 첫 번째 것부터 다시 만들 수 있습니다. 물론 가능한 한 빨리 그렇게 하는 것이 좋습니다. 이와 관련하여 다른 답변이 더 정확했습니다.

Question 3

처음에는 제안된 "도전"이 일부 사람들이 언급한 것처럼 어렵고, 실행 가능하지 않거나 순진해 보일 수도 있지만, 그렇지 않습니다. dd를 사용하여 더 큰 디스크에서 더 작은 디스크로 마이그레이션하는 기본 아이디어는 완벽하게 훌륭하며 데이터 마이그레이션에 이점이 있습니다. 물론, 점유된 데이터가 대상 디스크에 맞도록 충분한 여유 공간이 있어야 합니다.

아이디어는 처음에 제안된 것처럼 전체 디스크를 한 번에 저장하는 것이 아니라 각 파티션을 개별적으로 추가하는 것을 생각하는 것입니다. 훨씬 더 많은 작업을 수행할 수 있습니다. 파일 시스템 크기 조정 도구를 사용하면 잘릴 파티션을 안전하게 마이그레이션할 수도 있습니다. 실제로 이러한 종류의 마이그레이션은 블록 장치 계층이 아닌 파일 시스템 계층에서 작동하는 cp, rsync, pax 등과 같은 도구를 사용하여 쉽게 복사할 수 없는 파일 시스템 데이터 및 확장 파일 속성을 보존하기 위해 흥미롭습니다. dd를 사용하면 SELinux 문제를 방지하기 위해 OS를 다시 설치하거나 FS 레이블을 다시 지정할 필요가 없습니다.

다음은 유사한 작업을 수행하기 위해 일반적으로 수행하는 작업입니다.

1) 먼저 영향을 받은 파티션 내에서 잘릴 수 있는 파일 시스템을 줄였습니다. 이를 위해 resize2fs 도구를 사용하십시오(ext2/ext3/ext4 fs에 대해 이야기하고 있다고 가정 - 다른 최신 FS에도 동일한 목적을 위한 크기 조정 도구가 있습니다). 분명한 이유로 파일 시스템은 해당 파티션보다 클 수 없지만 더 작을 수는 있습니다. 여기서의 안전 요령은 "필요 이상"을 줄이는 것입니다. 예를 들어 500Gig 드라이브로 마이그레이션하려는 1TB의 파일 시스템이 있다고 가정해 보겠습니다. 이 경우 fs를 450Gig로 줄이는 것이 좋습니다(물론 이를 위해서는 충분한 여유 공간이 있어야 합니다. 즉, 이 파일 시스템에서 현재 점유된 공간은 450Gig를 초과할 수 없습니다). 명백히 낭비되는 50GB의 공간은 데이터 마이그레이션 후에 수정될 예정입니다.

2) 공간 제약을 고려하여 적절한 구조로 대상 디스크를 분할합니다.

3) 디스크 장치가 아닌 파티션 장치를 사용하여 데이터를 추가합니다(예: 를 dd if=/dev/sda# of=/dev/sdb#사용하는 대신 각 파티션에 사용 if=/dev/sda of=/dev/sdb). 참고: 여기의 sda 및 sdb는 단지 예일 뿐입니다. 중요 참고 사항: 더 큰 파티션 장치에서 더 작은 파티션 장치로 dd'ing할 때 dd는 블록 장치의 끝에 post를 쓰려고 시도한다고 불평합니다. 파일 시스템 데이터가 해당 지점에 도달하기 전에 완전히 복사되었기 때문에 괜찮습니다. 이러한 오류 메시지를 방지하려면 축소된 파일 시스템 크기 bs=와 일치하도록 매개변수를 사용하여 복사본의 크기를 지정할 수 있습니다. count=그러나 이를 위해서는 몇 가지 (간단한) 계산이 필요하지만 잘못 수행할 경우 데이터가 위험해질 수 있습니다.

4) 데이터를 추가한 후 resize2fs를 사용하여 대상 파티션 내의 각 파일 시스템 크기를 다시 조정합니다. 이번에는 새 파일 시스템 크기를 지정하지 않습니다. 크기 지정 없이 실행하면 resize2fs는 허용되는 최대 크기를 차지하도록 파일 시스템을 확장합니다. 따라서 이 경우 450Gig 파일 시스템은 전체 500Gig 파티션을 차지하도록 다시 증가하고 바이트가 낭비되지 않습니다. ("필요 이상으로 줄이기" 접근 방식을 사용하면 실수로 크기를 잘못 지정하여 데이터가 위험해지는 것을 방지할 수 있습니다. GB 대 GiB 단위는 까다로울 수 있습니다.)

보다 복잡한 작업에 대한 참고 사항: 함께 복사하려는 부팅 관리자가 있는 경우(예: 그럴 가능성이 매우 높음 dd if=/dev/sda of=/dev/sdb bs=4096 count=5) 파티션 장치 대신 디스크 장치를 사용하여 디스크의 처음 몇 KB를 추가할 수 있습니다. , 그런 다음 /dev/sdb에서 구조를 재구성합니다(새 드라이브에 대한 유효하지 않은 구조가 일시적으로 포함되지만 온전하고 유효한 부팅 관리자는 포함됨). 마지막으로 한 번에 파티션을 추가하려면 위에서 설명한 대로 파티션 장치를 사용하여 진행하세요. 나는 이런 작업을 여러 번했습니다. 아주 최근에 저는 MacOSX와 Linux 설치가 혼합된 HDD를 MacMini6,2의 더 작은 SDD로 업그레이드하면서 복잡한 마이그레이션을 성공적으로 수행했습니다. 이 경우에는 외부 드라이브에서 Linux를 부팅하고, bootmanager를 추가하고, gdisk를 실행하여 새 디스크의 GPT를 수정한 다음, 마지막으로 축소된 파일 시스템이 포함된 각 파티션을 추가해야 했습니다. (GPT 파티션 구성표는 파티션 테이블의 복사본 두 개를 유지합니다. 하나는 디스크의 시작 부분에, 다른 하나는 끝 부분에 있습니다. gdisk는 PT의 두 번째 복사본을 찾을 수 없고 파티션이 디스크 크기를 초과하기 때문에 많은 불평을 합니다. , 그러나 디스크 형상을 재정의한 후 PT 복사 문제를 올바르게 수정합니다. 이것은 훨씬 더 복잡한 경우였지만 이러한 종류의 작업도 완벽하게 가능하다는 것을 보여주기 때문에 언급할 가치가 있습니다.

행운을 빌어요! ...그리고 가장 중요한 것은 이러한 종류의 작업을 수행하기 전에 모든 중요한 데이터를 백업하는 것을 기억하십시오. 실수로 인해 데이터가 복구 불가능하게 손상될 수 있습니다.

그리고 제가 충분히 강조하지 않은 경우를 대비해 마이그레이션 전에 데이터를 백업하세요! :)

Answer

처음에는 제안된 "도전"이 일부 사람들이 언급한 것처럼 어렵고, 실행 가능하지 않거나 순진해 보일 수도 있지만, 그렇지 않습니다. dd를 사용하여 더 큰 디스크에서 더 작은 디스크로 마이그레이션하는 기본 아이디어는 완벽하게 훌륭하며 데이터 마이그레이션에 이점이 있습니다. 물론, 점유된 데이터가 대상 디스크에 맞도록 충분한 여유 공간이 있어야 합니다.

아이디어는 처음에 제안된 것처럼 전체 디스크를 한 번에 저장하는 것이 아니라 각 파티션을 개별적으로 추가하는 것을 생각하는 것입니다. 훨씬 더 많은 작업을 수행할 수 있습니다. 파일 시스템 크기 조정 도구를 사용하면 잘릴 파티션을 안전하게 마이그레이션할 수도 있습니다. 실제로 이러한 종류의 마이그레이션은 블록 장치 계층이 아닌 파일 시스템 계층에서 작동하는 cp, rsync, pax 등과 같은 도구를 사용하여 쉽게 복사할 수 없는 파일 시스템 데이터 및 확장 파일 속성을 보존하기 위해 흥미롭습니다. dd를 사용하면 SELinux 문제를 방지하기 위해 OS를 다시 설치하거나 FS 레이블을 다시 지정할 필요가 없습니다.

다음은 유사한 작업을 수행하기 위해 일반적으로 수행하는 작업입니다.

1) 먼저 영향을 받은 파티션 내에서 잘릴 수 있는 파일 시스템을 줄였습니다. 이를 위해 resize2fs 도구를 사용하십시오(ext2/ext3/ext4 fs에 대해 이야기하고 있다고 가정 - 다른 최신 FS에도 동일한 목적을 위한 크기 조정 도구가 있습니다). 분명한 이유로 파일 시스템은 해당 파티션보다 클 수 없지만 더 작을 수는 있습니다. 여기서의 안전 요령은 "필요 이상"을 줄이는 것입니다. 예를 들어 500Gig 드라이브로 마이그레이션하려는 1TB의 파일 시스템이 있다고 가정해 보겠습니다. 이 경우 fs를 450Gig로 줄이는 것이 좋습니다(물론 이를 위해서는 충분한 여유 공간이 있어야 합니다. 즉, 이 파일 시스템에서 현재 점유된 공간은 450Gig를 초과할 수 없습니다). 명백히 낭비되는 50GB의 공간은 데이터 마이그레이션 후에 수정될 예정입니다.

2) 공간 제약을 고려하여 적절한 구조로 대상 디스크를 분할합니다.

3) 디스크 장치가 아닌 파티션 장치를 사용하여 데이터를 추가합니다(예: 를 dd if=/dev/sda# of=/dev/sdb#사용하는 대신 각 파티션에 사용 if=/dev/sda of=/dev/sdb). 참고: 여기의 sda 및 sdb는 단지 예일 뿐입니다. 중요 참고 사항: 더 큰 파티션 장치에서 더 작은 파티션 장치로 dd'ing할 때 dd는 블록 장치의 끝에 post를 쓰려고 시도한다고 불평합니다. 파일 시스템 데이터가 해당 지점에 도달하기 전에 완전히 복사되었기 때문에 괜찮습니다. 이러한 오류 메시지를 방지하려면 축소된 파일 시스템 크기 bs=와 일치하도록 매개변수를 사용하여 복사본의 크기를 지정할 수 있습니다. count=그러나 이를 위해서는 몇 가지 (간단한) 계산이 필요하지만 잘못 수행할 경우 데이터가 위험해질 수 있습니다.

4) 데이터를 추가한 후 resize2fs를 사용하여 대상 파티션 내의 각 파일 시스템 크기를 다시 조정합니다. 이번에는 새 파일 시스템 크기를 지정하지 않습니다. 크기 지정 없이 실행하면 resize2fs는 허용되는 최대 크기를 차지하도록 파일 시스템을 확장합니다. 따라서 이 경우 450Gig 파일 시스템은 전체 500Gig 파티션을 차지하도록 다시 증가하고 바이트가 낭비되지 않습니다. ("필요 이상으로 줄이기" 접근 방식을 사용하면 실수로 크기를 잘못 지정하여 데이터가 위험해지는 것을 방지할 수 있습니다. GB 대 GiB 단위는 까다로울 수 있습니다.)

보다 복잡한 작업에 대한 참고 사항: 함께 복사하려는 부팅 관리자가 있는 경우(예: 그럴 가능성이 매우 높음 dd if=/dev/sda of=/dev/sdb bs=4096 count=5) 파티션 장치 대신 디스크 장치를 사용하여 디스크의 처음 몇 KB를 추가할 수 있습니다. , 그런 다음 /dev/sdb에서 구조를 재구성합니다(새 드라이브에 대한 유효하지 않은 구조가 일시적으로 포함되지만 온전하고 유효한 부팅 관리자는 포함됨). 마지막으로 한 번에 파티션을 추가하려면 위에서 설명한 대로 파티션 장치를 사용하여 진행하세요. 나는 이런 작업을 여러 번했습니다. 아주 최근에 저는 MacOSX와 Linux 설치가 혼합된 HDD를 MacMini6,2의 더 작은 SDD로 업그레이드하면서 복잡한 마이그레이션을 성공적으로 수행했습니다. 이 경우에는 외부 드라이브에서 Linux를 부팅하고, bootmanager를 추가하고, gdisk를 실행하여 새 디스크의 GPT를 수정한 다음, 마지막으로 축소된 파일 시스템이 포함된 각 파티션을 추가해야 했습니다. (GPT 파티션 구성표는 파티션 테이블의 복사본 두 개를 유지합니다. 하나는 디스크의 시작 부분에, 다른 하나는 끝 부분에 있습니다. gdisk는 PT의 두 번째 복사본을 찾을 수 없고 파티션이 디스크 크기를 초과하기 때문에 많은 불평을 합니다. , 그러나 디스크 형상을 재정의한 후 PT 복사 문제를 올바르게 수정합니다. 이것은 훨씬 더 복잡한 경우였지만 이러한 종류의 작업도 완벽하게 가능하다는 것을 보여주기 때문에 언급할 가치가 있습니다.

행운을 빌어요! ...그리고 가장 중요한 것은 이러한 종류의 작업을 수행하기 전에 모든 중요한 데이터를 백업하는 것을 기억하십시오. 실수로 인해 데이터가 복구 불가능하게 손상될 수 있습니다.

그리고 제가 충분히 강조하지 않은 경우를 대비해 마이그레이션 전에 데이터를 백업하세요! :)

Question 4

나는 이 주제에 대한 나의 경험을 공유하고 싶습니다. 이 내용이 다른 독자에게 도움이 될 것입니다. 최근에 나는DDRESCUE고장난 하드 드라이브에서 NTFS 파티션의 처음 1/3을 복구하고, 복구된 파티션 세그먼트를 더 작은 하드 드라이브에 성공적으로 재구축하여 캡처된 파일을 복구합니다(나머지 손실). 다음은 내가 취한 단계입니다.(확실히 HACKSAW 접근 방식입니다 !!)...

소스 하드 드라이브는 MBR 파일 테이블이 있는 NTFS로 포맷된 750GB로 구성되었습니다. 파일을 백업하는 데 몇 번만 사용했기 때문에 대부분의 파일은 드라이브 시작 부분에 약 160GB 정도였습니다. 가족 중 한 명이 하드 드라이브(외부 장착)를 바닥에 떨어뜨렸습니다. 그 이후로는 제대로 작동하지 않았습니다! ddrescue를 사용하여 (고심해서) 드라이브 시작 부분의 상당 부분을 복구할 수 있었습니다. 물리적 손상으로 인해 프로세스 전반에 걸쳐 매우 자주 종료되었습니다 ...

나는 ddrescue 데이터를 직접 추출한 150GB(외부 장착)의 작은 노트북 하드 드라이브를 가지고 있었습니다. 또는 데이터를 이미지 파일로 추출하고 나중에 파일을 마운트할 수도 있었지만 데이터를 하드 드라이브에 직접 쓰는 것이 더 간단하다고 생각했습니다.

복구의 핵심 요령은 복구 하드 드라이브의 MBR 및 NTFS 부팅 섹터 데이터를 모두 수동으로 편집하는 것이었습니다. 그렇게 하지 않으면 운영 체제에서 하드 드라이브를 인식할 수 없습니다. 리눅스에서는 적합한 프로그램을 찾을 수 없어서 윈도우로 전환했습니다. Windows 지원 도구라는 편리한 패키지가 있습니다. 더 이상 유지 관리되지 않지만 여전히 유용합니다(아래 링크 참조)! 파티션을 편집하는 데 사용한 도구는 Disk Probe입니다. 하드 드라이브의 최종 섹터 값을 알고 있는지 확인하십시오(우분투에서는 fdisk -l을 사용했습니다).

https://en.wikipedia.org/wiki/Windows_Support_Tools

좋은 계산기와 창의력을 사용하여 하드 드라이브를 Windows의 Disk Probe에 로드하고 마운트하고 최종 섹터 값을 편집했습니다. MBR에서는 두 가지 값 세트, 즉 a) 하드 드라이브 끝 섹터와 b) NTFS 파티션 끝 섹터를 변경해야 했습니다. NTFS 부팅 섹터에서는 파티션 전체 섹터 값을 변경해야 했습니다. 각각의 경우 더 작은 하드 드라이브의 감소된 "크기"에 맞추기 위해 숫자 값이 감소되었습니다(최종 섹터가 750GB에서 150GB로 변경됨). 이 값을 편집하려면 보기 탭을 클릭하세요.

다음은 NTFS 부팅 섹터 데이터를 편집 중인 Disk Probe의 이미지입니다.

앞서 언급한 필드를 편집하면 Windows는 해당 파티션이 손상되었음에도 불구하고 유효한 파티션으로 인식했습니다. 명령 프롬프트에 들어가서 손상된 하드 드라이브(chdsk D:)에서 Windows 프로그램 Chkdsk를 실행했습니다. 파티션이 파일 단위로 다시 살아나는 것을 보는 것은 짜릿했습니다! 프로그램은 파티션 테이블을 재구축하고 손상된 하드 드라이브에서 복사된 모든 파일을 성공적으로 다시 매핑했습니다. 범위를 벗어난(복사되지 않은) 파일은 발견되지 않았으므로 제거되었습니다.

다음 부분에서는 Windows가 포함된 파일을 사용하여 150GB 하드 드라이브를 성공적으로 재구축했기 때문에 그 이유를 이해할 수 없습니다. 그럼에도 불구하고 Windows는 기본적으로 파일 보기를 위해 하드 드라이브 파티션을 열 수 없었습니다(일부 오류가 있음). 그러나 우분투를 구출하십시오! Ubuntu로 재부팅하고 외장 하드 드라이브를 마운트했는데 전혀 문제 없이 복구된 모든 파일이 표시되었습니다!

큰 하드 드라이브에서 작은 하드 드라이브로 파일을 복구하는 이 쇠톱 방법이 나 외에 다른 불쌍한 사람들에게도 유용할 것으로 기대됩니다. 건배!

Answer