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

다른 사람들이 여기서 언급했듯이 ddGPT 테이블의 복사본이 디스크 끝에 배치되므로 을 사용하면 작동하지 않습니다.

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

먼저 선택한 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 파티션 테이블을 복사하거나 내용을 읽을 때 드라이브 이름을 난독화하면 내용과 작별할 수 있습니다 :)

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

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

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

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

제기된 초기 "도전"은 어렵고 실행 불가능해 보일 수 있으며 일부 사람들이 언급한 것처럼 순진해 보일 수도 있지만 그렇지 않습니다. dd를 사용하여 더 큰 디스크에서 더 작은 디스크로 마이그레이션하는 주요 아이디어는 매우 좋고 데이터 마이그레이션에 좋습니다. 물론, 점유된 데이터가 대상 디스크에 맞도록 충분한 여유 공간을 확보하는 것은 필수 요구 사항입니다.

아이디어는 원래 제안된 대로 전체 디스크를 한 번에 추가하는 대신 각 파티션을 개별적으로 추가하는 것을 고려하는 것입니다. 더 많은 작업을 수행할 수 있습니다. 파일 시스템 크기 조정 도구의 도움을 받아 잘릴 파티션도 안전하게 마이그레이션할 수 있습니다. 실제로 이 마이그레이션은 블록 장치 계층이 아닌 파일 시스템 계층에서 작동하는 cp, rsync, pax 등과 같은 도구를 사용하여 쉽게 재현할 수 없는 파일 시스템 메타데이터 및 확장 파일 속성을 보존한다는 점에서 흥미롭습니다. dd를 사용하면 SELinux 문제를 방지하기 위해 운영 체제를 다시 설치하거나 FS 레이블을 다시 지정할 필요가 없습니다.

비슷한 작업을 수행하기 위해 제가 일반적으로 수행하는 작업은 다음과 같습니다.

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

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

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

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

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

행운을 빌어요! ...가장 중요한 것은 이와 같은 작업을 수행하기 전에 중요한 데이터를 모두 백업하는 것을 기억하는 것입니다. 한 번의 실수로 인해 데이터가 복구할 수 없을 정도로 손상될 수 있습니다.

아무리 강조해도 지나치지 않을 경우를 대비해 마이그레이션하기 전에 데이터를 백업하세요! :)

이 주제에 대한 내 경험이 다른 독자들에게도 도움이 된다면 공유하고 싶었습니다. 최근에 나는DDR 구조고장난 하드 드라이브에서 NTFS 파티션의 처음 1/3을 복구하고 복구된 파티션 세그먼트를 더 작은 하드 드라이브에 성공적으로 재구성하여 캡처된 파일을 복구했습니다(나머지는 손실됨). 이를 위해 내가 취한 단계는 다음과 같습니다.(물론 쇠톱방식!!)...

소스 하드 드라이브는 NTFS 형식의 750GB와 MBR 파일 테이블로 구성됩니다. 파일 백업용으로 몇 번만 사용해본 터라 대부분의 파일이 160GB 정도 되는 드라이브의 시작 부분에 들어있습니다. 가족 중 한 명이 하드 드라이브(외부 장착)를 바닥에 떨어뜨렸습니다. 그 이후로 제대로 작동한 적이 없습니다! ddrescue를 사용하여 (고심해서) 드라이브 시작 부분의 대부분을 복구할 수 있었습니다. 물리적 손상으로 인해 전체적으로 매우 빈번한 종료...

사용 가능한 작은 150GB 노트북 하드 드라이브(외부 장착)가 있고 ddrescue 데이터를 여기에 직접 추출합니다. 또는 데이터를 이미지 파일로 추출한 다음 해당 파일을 마운트할 수도 있지만 데이터를 하드 드라이브에 직접 쓰는 것이 더 간단하다고 생각합니다.

핵심 복구 기술은 복구 하드 드라이브의 MBR 및 NTFS 부팅 섹터 데이터를 수동으로 편집하는 것입니다. 이렇게 하지 않으면 어떤 운영 체제에서도 하드 드라이브를 인식하지 못합니다. Linux에서는 이 작업을 수행하는 데 적합한 프로그램을 찾을 수 없어서 Windows로 전환했습니다. 더 이상 유지 관리되지 않지만 여전히 유용한 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는 해당 파티션이 손상되었음에도 불구하고 유효한 파티션으로 인식했습니다. 명령 프롬프트에 들어가서 손상된 하드 드라이브에서 Windows 프로그램 Chkdsk(chdsk D:)를 실행했습니다. 파티션이 파일 단위로 살아 움직이는 것을 보는 것은 신나는 일입니다! 프로그램은 파티션 테이블을 다시 작성하고 손상된 하드 드라이브에서 복사된 모든 파일을 성공적으로 다시 매핑합니다. 범위를 벗어난(복사되지 않음) 파일을 찾을 수 없어 삭제되었습니다.

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

큰 하드 드라이브에서 작은 하드 드라이브로 파일을 복구하는 이 쇠톱 방법이 나 외에 다른 불쌍한 영혼에게도 유용할 수 있기를 바랍니다. 건배!