다음 dd과 같이 디스크를 복제 하는 데 사용 했습니다.
dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync
그리고 그것은 항상 잘 작동했습니다. ‘dd’의 모든 문서는 대상 디스크의 크기가 소스와 같거나 커야한다는 사실을 상기시켜줍니다. 그것은 반드시 사실이어야합니까?
더 작은 디스크로 복제 하면 대상의 부분적으로 ‘범위를 벗어난’ 파티션이 손상 되지 않을 것으로 예상합니다 .
그러나 나중에 대상에서 파티션을 편집하고 ‘범위를 벗어난’파티션을 삭제해야한다는 것을 잘 알고 있으면 여전히 ‘dd’를 사용하여 소스의 무차별 사본을 대상의 실제 크기? 또는 크기의 한계에 도달하면 대상을 흡연 잔해 더미로 줄입니다.
BTW,이 연구, 나는 권장 값을 본 적이 bs=이르기까지의 bs=1024까지 bs=32M정말 최선 무엇인가?
답변
실제 드라이브는 적어도 담배를 피우지 않아야하지만 파일 시스템이 더 이상 작동하지 않을 가능성이 매우 높습니다 (대상 파일 시스템; 방금 소스에서 아무것도 복사하지 않고 소스를 건드리지 않으면 소스 자체가 양호해야 함) ). 파티션 내부의 데이터가 반드시 증가하는 순서로 할당되는 것은 아닙니다. 파티션이 가득 차지 않은 경우에도 파티션의 일부가 파티션의 끝에있을 수 있습니다 (실제로, 이것은 일부 파일 시스템에서 결정적으로 발생한다고 생각하지만 세부 사항을 알 수는 없습니다). 파일 시스템의 무결성에 필수적인 데이터가있을 수 있습니다. 따라서 나는 그러한 사본에 의존하지 말 것을 강력히 권합니다.
이 사본을 작성하려면 먼저 내부 구조를 인식하고 모든 것을 양호한 순서로 작은 파티션으로 다시 맵핑 할 수있는 일부 도구를 사용하여 파티션을 축소해야합니다. 그런 다음 복사 할 수 있습니다. gparted이런 종류의 일을하기에 좋은 GUI 인터페이스입니다.
를 들어 bs값, 일반적으로 가장 좋은 아이디어는 실제 사본을 시작하기 전에 테스트의 몇 가지를하는 것입니다. 이 검사를 자동화하는 데 도움이되는 몇 가지 도구가 있지만 이름을 기억하지 못합니다. 내 경험상 가장 좋은 범위는 일반적으로 4M에서 16M 사이입니다. 그 이상은 더 이상 벌지 않습니다. 그러나 디스크 자체를 포함하여 많은 것들에 달려 있습니다. 예를 들어, 실제 하이 엔드 디스크는 거의 사용하지 않았는데, 속도와 캐시 크기가 더 커서 더 큰 값에 적합 할 수 있습니다.
편집 파티션이 완전히 복사 된 경우 문제없이 사용할 수 있습니다. 그러나 다른 사람들이 밑줄을 긋었으므로 파티션 테이블이 손상되지 않았는지 확인해야합니다 (적어도 관련 항목). MBR의 4 개의 1 차 파티션에는 디스크의 첫 512 바이트에 설명되어 있으므로 문제가 없습니다. 논리 파티션은 확장 파티션 전체에서 설명되므로 항목이 유실 될 수 있습니다 (그러나 어쨌든 유실 된 파티션에 대해서는 설명했습니다). GPT를 사용하면 디스크 시작과 끝 모두에 파티션 테이블의 복사본이 있습니다. 두 번째 것을 잃어 버렸지 만 첫 번째에서 다시 만들 수 있습니다. 물론 가능하면 빨리하는 것이 좋습니다. 다른 답변은 그것에 대해 더 정확했습니다.
답변
처음에는 제안 된 “도전”이 어려워 보일 수도 있지만, 일부 사람들이 언급 한 것처럼 실현 가능하거나 건전하지는 않지만 어려울 수도 있습니다. 더 큰 디스크에서 더 작은 디스크로 마이그레이션하기 위해 dd를 사용하는 기본 개념은 완벽하게 훌륭하며 데이터 마이그레이션에 이점이 있습니다. 물론 점유 된 데이터가 대상 디스크에 맞도록 충분한 여유 공간이 있어야합니다.
아이디어는 처음에 제안 된대로 한 번에 전체 디스크가 아닌 각 파티션을 개별적으로 편집하는 것입니다. 더 많은 작업을 수행 할 수 있습니다. 잘린 파티션을 파일 시스템 크기 조정 도구를 사용하여 안전하게 마이그레이션 할 수도 있습니다. 실제로 이러한 종류의 마이그레이션은 장치 계층을 차단하지 않고 파일 시스템 계층에서 작동하는 cp, rsync, pax 등과 같은 도구로는 쉽게 복사 할 수없는 파일 시스템 matadata 및 확장 파일 속성을 보존하기 위해 흥미 롭습니다. dd를 사용하면 SELinux 관련 문제를 피하기 위해 OS를 다시 설치하거나 FS 레이블을 다시 지정해야합니다.
다음은 비슷한 작업을 수행하기 위해 일반적으로 수행하는 작업입니다.
1) 먼저 영향을받는 파티션 내에서 잘릴 파일 시스템을 줄입니다. 이를 위해 resize2fs 도구를 사용하십시오 (ext2 / ext3 / ext4 fs에 대해 이야기하고 있다고 가정하면 다른 최신 FS에도 동일한 목적으로 크기 조정 도구가 있습니다). 명백한 이유로 파일 시스템이 파일 시스템 내에있는 파티션보다 클 수는 없지만 안전하게 작을 수 있습니다. 여기서 안전 요령은 “필요 이상”을 줄이는 것입니다. 예를 들어, 500 기가 드라이브로 마이그레이션하려는 파일 시스템이 1TB라고 가정하십시오. 이 경우 fs를 450Gig로 줄이는 것이 좋습니다 (물론 충분한 여유 공간이 있어야합니다. 즉,이 파일 시스템에서 현재 사용중인 공간이 450Gig를 초과 할 수 없음). 데이터 마이그레이션 후 50Gig의 공간 낭비가 수정됩니다.
2) 공간 제약을 고려하여 대상 디스크를 적절한 형상으로 분할하십시오.
3) 디스크 장치가 아닌 파티션 장치를 사용하여 데이터를 기록하십시오 (즉, dd if=/dev/sda# of=/dev/sdb#대신에 각 파티션에 사용 if=/dev/sda of=/dev/sdb). 참고 : 여기에서 sda 및 sdb는 예제 일뿐입니다. 중요 참고 : 더 큰 파티션 장치에서 더 작은 파티션 장치로 dd’d 할 때, dd는 블록 장치의 끝에 포스트 쓰기 시도에 대해 불평 할 것입니다. 파일 시스템 데이터가 해당 지점에 도달하기 전에 완전히 복사되었으므로 문제가되지 않습니다. 이러한 오류 메시지를 피하기 위해 축소 된 파일 시스템 크기와 일치하도록 사본 사용 bs=및 count=매개 변수 의 크기를 지정할 수 있지만, 일부 간단한 계산이 필요하지만 잘못 수행하면 데이터가 위험 할 수 있습니다.
4) 데이터를 기록한 후 resize2fs를 사용하여 대상 파티션 내의 각 파일 시스템 크기를 다시 조정하십시오. 이번에는 새 파일 시스템 크기를 지정하지 않습니다. 크기 지정없이 실행하면 resize2fs는 파일 시스템을 확장하여 허용되는 최대 크기를 차지하므로이 경우 450Gig 파일 시스템이 다시 500GB 파티션 전체를 차지하도록 다시 커지고 바이트가 낭비되지 않습니다. “필요 이상으로 줄이면”실수로 크기를 잘못 지정하여 데이터를 위험에 빠뜨리는 것을 방지 할 수 있습니다. GB 대 GiB 단위는 까다로울 수 있습니다.
보다 복잡한 작업에 대한 참고 사항 : 복사하려는 부팅 관리자가있는 경우 파티션 장치 대신 디스크 장치를 사용하여 디스크의 처음 몇 KB를 dd로 만들 수 있습니다 (예 : dd if=/dev/sda of=/dev/sdb bs=4096 count=5)를 선택한 다음 / dev / sdb에서 지오메트리를 재구성합니다 (새 드라이브에는 유효하지 않은 지오메트리가 있지만 부트 관리자는 유효하지 않습니다). 마지막으로 한 번에 파티션을 작성하기 위해 위에서 설명한 파티션 장치를 사용하여 진행하십시오. 이런 작업을 여러 번했습니다. 최근에는 MacOSX 및 Linux 설치가 혼합 된 HDD에서 MacMini6,2의 더 작은 SDD로 업그레이드 할 때 복잡한 마이그레이션을 성공적으로 수행했습니다. 이 경우 외부 드라이브에서 Linux를 부팅하고 bootmanager를 실행하고 gdisk를 실행하여 새 디스크에서 GPT를 수정 한 다음 마지막으로 축소 된 파일 시스템을 포함하는 각 파티션을 dd했습니다. GPT 파티션 구성표는 파티션 테이블의 사본 두 개 (하나는 디스크의 시작 부분과 다른 하나는 디스크의 끝 부분)를 유지합니다. gdisk는 PT의 두 번째 사본을 찾을 수없고 파티션이 디스크 크기를 초과하기 때문에 많은 불만을 제기하지만 디스크 구조를 재정의 한 후 PT 복사 문제를 올바르게 수정합니다). 이것은 훨씬 복잡한 경우이지만, 이런 종류의 작업도 완벽하게 실현 가능하다는 것을 보여 주므로 언급 할 가치가 있습니다.
행운을 빕니다! … 가장 중요한 것은 그러한 종류의 작업 전에 모든 중요한 데이터를 백업하는 것입니다. 실수로 복구 할 수 없을 정도로 데이터가 손상 될 수 있습니다.
그리고 내가 충분히 강조하지 않은 경우 : 마이그레이션 전에 데이터를 백업하십시오! 🙂
답변
자동차보다 20cm 더 좁은 통로에 자동차를 설치하고 자동차의 왼쪽 20cm를 자르면 자동차가 여전히 작동합니까? 아마 아닙니다.
대상 디스크가 작기 때문에 디스크의 시작 부분을 다른 디스크에 복사하고 사본을 짧게 줄이면 결과가 작동하지 않습니다. 대상 디스크의 모든 파일을 수용 할 수있는 충분한 공간이 있어도 디스크 시작 부분에서 N 바이트를 초과해도 파일 시스템이 작동하지 않습니다.
디스크가 PC 스타일 파티션 (GPT 또는 MBR)으로 분할 된 경우 대상에 완전히 맞는 모든 파티션이 작동합니다. 한 가지 예외가 있습니다. MBR 파티션의 경우 논리 파티션에 디스크 순서대로 번호가 매겨지지 않으면 체인이 대상 영역을 떠나 자마자 파티션이 더 이상 나열되지 않습니다. (이를 이해하지 못하면 부분 디스크 복사를 수행하지 않는 또 하나의 이유입니다.) 처음부터 복사하고 원하는 내용으로 끝나는 대신 유지하려는 파티션을 복사하는 것이 훨씬 더 합리적입니다. . 끝에 부분적으로 복사 된 파티션은 사용할 수 없습니다.
디스크 또는 부분 파티션이 LVM 물리 볼륨 인 경우 해당 물리 볼륨의 부분 복사본을 만들면 결과에서 유용한 데이터를 얻을 수 없습니다.
큰 디스크에서 작은 디스크로 일부 데이터 만 복사하려면 작은 디스크에 파티션을 작성하십시오. 파티션을 동일한 크기의 파티션에 복사하려면을 사용하여 수행 할 수 있습니다 cat. 당신이 작은 파티션에 파티션을 복사 할 경우 대상 파티션에 파일 시스템을 생성하고 같은과 파일 수준의 사본을 cp -a하거나 pax -rw -pe -t.
당신 이 마조히스트라면 dd대신에 사용할 수 있습니다 cat. dd이상한 구문을 가지고 있으며 올바른 버퍼 크기를 찾지 않으면 일반적으로 속도가 느립니다cat . 버퍼 크기에 대한 최적의 단일 값은 없으며 하드웨어의 특성에 따라 다릅니다. 크기가 너무 작 으면 dd많은 양의 작은 전송을하는 데 시간이 낭비됩니다. 크기가 너무 크면 dd다음 버퍼를 쓰기 시작하기 전에 하나의 버퍼를 완전히 읽는 데 시간이 낭비됩니다. 디스크 간 전송에 최적의 크기는 일반적으로 몇 메가 바이트입니다 (1024 바이트는 엄청나게 작습니다). cat노력하지 않고 알맞은 크기를 선택합니다.
답변
다른 독자에게 도움이된다면이 주제에 대한 경험을 나누고 싶습니다. 최근에 DDRESCUE 를 사용 하여 고장난 하드 드라이브에서 NTFS 파티션의 첫 1/3을 복구하고 파티션의 복구 된 세그먼트를 더 작은 하드 드라이브로 성공적으로 재구성하여 캡처 된 파일을 구조화했습니다 (나머지 손실). 다음은 내가 수행 한 단계입니다 (확실히 HACKSAW 접근 방식입니다!) …
소스 하드 드라이브는 NTFS로 포맷 된 750GB로 구성되어 있으며 MBR 파일 테이블이 있습니다. 파일을 백업하는 데 몇 번만 사용했기 때문에 대부분의 파일은 드라이브 시작 부분에 약 160GB 정도였습니다. 가족이 하드 드라이브 (외부 적으로 장착)를 바닥에 두 드렸습니다. 그 후에는 제대로 작동하지 않았습니다! ddrescue를 사용하여 (빠르게) 드라이브 시작 부분의 많은 부분을 복구 할 수있었습니다. 물리적 손상으로 인해 프로세스 전체에서 매우 자주 종료됩니다 …
150GB (외부 마운트)의 작은 랩톱 하드 드라이브를 사용하여 ddrescue 데이터를 직접 추출했습니다. 또는 이미지 파일로 데이터를 추출한 후 나중에 파일을 마운트 할 수 있었지만 데이터를 하드 드라이브에 직접 작성하는 것이보다 까다 로웠다고 생각했습니다.
복구의 핵심 요령은 복구 하드 드라이브에서 MBR 및 NTFS 부트 섹터 데이터를 수동으로 편집하는 것이 었습니다. 그렇게하지 않으면 모든 운영 체제에서 하드 드라이브를 인식하지 못합니다. 나는 리눅스에서 적절한 프로그램을 찾을 수 없어서 창문으로 돌렸다. Windows 지원 도구라는 편리한 패키지가 있지만 더 이상 유지 관리되지 않지만 여전히 유용합니다 (아래 링크 참조)! 파티션을 편집하는 데 사용한 도구는 디스크 프로브입니다. 하드 드라이브의 최종 섹터 값을 알아야합니다 (우분투에서 fdisk -l을 사용했습니다)
https://ko.wikipedia.org/wiki/Windows_Support_Tools
좋은 계산기와 창의력을 사용하여 하드 드라이브를로드하여 Windows의 디스크 프로브에 마운트하고 최종 섹터 값을 편집했습니다. MBR에서 두 개의 값 세트, 즉 a) 하드 드라이브 엔드 섹터와 b) NTFS 파티션 엔드 섹터를 변경해야했습니다. NTFS 부트 섹터에서 파티션 총 섹터 값을 변경해야했습니다. 각각의 경우, 더 작은 하드 드라이브의 감소 된 “치수”에 맞추기 위해 수치가 감소되었습니다 (종료 섹터가 750GB에서 150GB로 변경됨). 이 값을 편집하려면보기 탭을 클릭하십시오.
NTFS 부트 섹터 데이터를 편집하는 Disk Probe 이미지는 다음과 같습니다. 
위에서 언급 한 필드를 편집하면 Windows는 파티션이 손상되었지만 유효한 파티션으로 인식했습니다. 명령 프롬프트를 입력하고 손상된 하드 드라이브 (chdsk D :)에서 Windows 프로그램 Chkdsk를 실행했습니다. 파티션이 파일로 다시 돌아가는 것을 보는 것은 스릴이었습니다! 프로그램은 파티션 테이블을 재 구축하고 손상된 하드 드라이브에서 복사 한 모든 파일을 성공적으로 다시 매핑했습니다. 범위를 벗어난 (복사되지 않은) 파일을 찾지 못하여 제거되었습니다.
다음 부분은 Windows가 파일이 포함 된 150GB 하드 드라이브를 성공적으로 다시 빌드했기 때문에 이유를 이해하지 못합니다. 그럼에도 불구하고 Windows는 기본적으로 파일보기를 위해 하드 드라이브 파티션을 열 수 없었습니다 (일부 오류가 있음). 그러나 우분투는 구조에! 우분투로 재부팅하고 외장 하드 드라이브를 마운트했으며 문제없이 복구 된 모든 파일이 나타났습니다!
바라건대 큰 하드 드라이브에서 작은 하드 드라이브로 파일을 복구하는이 쇠톱 방법은 저 외에 다른 가난한 영혼에게도 유용 할 것입니다. 건배!
답변
소스의 파티션을 먼저 축소하거나 범위를 벗어난 것을 삭제해야합니다.
보다 dd당신은 아마 사용하여 파티션 테이블을 복구해야합니다 후의 gdisk /dev/sd<target>
되는 테이블을 복구하고 키 시퀀스를 v r d w
난 당신이 필요보다 약간 작은 파티션을 shring에 제안 이후 다시 대상 디스크의 전체 크기를 확장합니다.
(이 답변은 HDD를 작은 SSD로 복제 할 때의 개인적인 경험을 바탕으로합니다)