'dd' có thể được sử dụng để sao chép vào một ổ cứng nhỏ hơn, biết rằng các phân vùng sẽ cần chỉnh sửa?

Tôi đã từng ddsao chép các đĩa như thế này:

 dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync

Và nó luôn hoạt động tốt. Bất kỳ và tất cả các tài liệu trên 'dd' đều đau đớn để nhắc nhở bạn rằng đĩa đích phải có cùng kích thước hoặc lớn hơn nguồn. Điều đó hoàn toàn phải là sự thật?

Bây giờ, tôi hoàn toàn hiểu rằng nếu tôi sao chép vào một đĩa nhỏ hơn, tôi không thể mong đợi bất kỳ phân vùng nào thậm chí còn nằm ngoài giới hạn một phần trên mục tiêu vẫn còn nguyên vẹn.

Tuy nhiên, biết rõ rằng tôi cần phải chỉnh sửa các phân vùng của mình trên mục tiêu sau đó, xóa các phân vùng 'ngoài giới hạn', tôi vẫn có thể sử dụng 'dd' để tạo một bản sao mạnh mẽ của nguồn theo giới hạn của kích thước vật lý của mục tiêu? Hoặc sẽ 'dd' giảm mục tiêu xuống một đống đổ nát hút thuốc khi nó đạt đến giới hạn kích thước của nó ;-)

BTW, nghiên cứu điều này, tôi đã thấy các giá trị được đề xuất cho bs=tất cả mọi thứ từ bs=1024lên đến bs=32M, cái gì thực sự là tốt nhất?

Ổ đĩa vật lý không nên bắt đầu hút thuốc, ít nhất, nhưng rất có thể hệ thống tệp của bạn sẽ không hoạt động nữa (ý tôi là, hệ thống tệp đích; nếu bạn chỉ sao chép và không chạm vào bất cứ thứ gì trong nguồn, thì nguồn đó sẽ ổn ). Dữ liệu trong một phân vùng không nhất thiết phải được phân bổ theo thứ tự tăng dần. Một số có thể nằm ở cuối phân vùng ngay cả khi phân vùng không đầy đủ (thực ra, tôi nghĩ rằng điều này xảy ra một cách nhất định với một số hệ thống tập tin, nhưng tôi không biết đủ để có được thông tin chi tiết). Dữ liệu có thể cần thiết cho tính toàn vẹn của hệ thống tập tin. Vì vậy, tôi khuyên bạn không nên dựa vào một bản sao như vậy.

Nếu bạn muốn thực hiện bản sao này, trước tiên bạn phải thu nhỏ phân vùng bằng một số công cụ nhận thức được cấu trúc bên trong của nó và có thể sắp xếp lại mọi thứ theo thứ tự tốt vào một phân vùng nhỏ hơn. Sau đó, bạn có thể làm bản sao. gpartedlà một giao diện GUI tốt để làm những việc này.

Đối với bsgiá trị, thường thì ý tưởng tốt nhất là có một vài thử nghiệm trước khi bắt đầu bản sao thực sự. Có một số công cụ giúp bạn tự động hóa kiểm tra này, nhưng tôi không nhớ tên. Theo kinh nghiệm của tôi, phạm vi tốt nhất thường là từ 4M đến 16M. Cao hơn là bạn không kiếm được nhiều tiền nữa. Nhưng nó phụ thuộc vào nhiều thứ, bao gồm cả các đĩa. Ví dụ, tôi hiếm khi làm việc với các đĩa cao cấp thực sự, có thể phù hợp với các giá trị cao hơn do tốc độ và kích thước bộ đệm lớn hơn.

EDIT Nếu một phân vùng được sao chép toàn bộ, thì bạn có thể sử dụng nó mà không gặp vấn đề gì. Tuy nhiên, như những người khác đã gạch chân, bạn cũng phải chắc chắn rằng bảng phân vùng còn nguyên vẹn (ít nhất là các mục có liên quan). Với bốn phân vùng chính của MBR, không có vấn đề gì, vì chúng được mô tả trong 512 byte đầu tiên của đĩa. Các phân vùng logic được mô tả trong toàn bộ phân vùng mở rộng, do đó các mục có thể bị mất (nhưng chúng sẽ mô tả các phân vùng sẽ bị mất bằng mọi cách). Với GPT, có một bản sao của bảng phân vùng ở đầu và cuối đĩa. Bạn mất cái thứ hai, nhưng bạn có thể xây dựng lại từ cái thứ nhất. Tất nhiên nên làm điều đó càng sớm càng tốt; câu trả lời khác chính xác hơn đối với điều đó.

Mặc dù lúc đầu, "thử thách" được đề xuất có vẻ khó khăn, không khả thi hoặc nghe có vẻ ngây thơ như một số người đã nhận xét, nhưng không phải vậy. Ý tưởng chính đằng sau việc sử dụng dd để di chuyển từ đĩa lớn hơn sang đĩa nhỏ hơn là hoàn toàn tốt và có lợi ích cho việc di chuyển dữ liệu. Tất nhiên, có đủ không gian trống để dữ liệu bị chiếm trong đĩa đích là một yêu cầu cần thiết.

Ý tưởng là suy nghĩ trong việc tạo từng phân vùng riêng lẻ chứ không phải toàn bộ đĩa cùng một lúc như đề xuất ban đầu. Thậm chí nhiều hơn có thể được thực hiện: (Các) phân vùng sẽ bị cắt ngắn cũng có thể được di chuyển một cách an toàn với một chút trợ giúp của các công cụ định cỡ lại hệ thống tập tin. Thật vậy, kiểu di chuyển như vậy rất thú vị để bảo toàn siêu dữ liệu hệ thống tệp và các thuộc tính tệp mở rộng không thể sao chép dễ dàng bằng các công cụ như cp, rsync, pax, ... hoạt động trong lớp hệ thống tệp và không chặn lớp thiết bị. Sử dụng dd cho thấy sự cần thiết phải cài đặt lại HĐH hoặc phải dán lại tên của FS để tránh các vấn đề với SELinux.

Dưới đây là những gì tôi thường làm để hoàn thành các nhiệm vụ tương tự:

1) Trước tiên, bạn đã giảm (các) hệ thống tập tin trong các phân vùng bị ảnh hưởng sẽ bị cắt ngắn. Đối với điều này, hãy sử dụng công cụ resize2fs (giả sử chúng ta đang nói về một ext2 / ext3 / ext4 fs - các FS hiện đại khác cũng có các công cụ thay đổi kích thước cho cùng một mục đích). Lưu ý rằng mặc dù - vì lý do rõ ràng - một hệ thống tệp không thể lớn hơn phân vùng mà nó nằm trong đó, nó có thể nhỏ hơn một cách an toàn. Thủ thuật an toàn ở đây là giảm "nhiều hơn mức cần thiết". Ví dụ: hãy tưởng tượng bạn có hệ thống tệp 1TB mà bạn muốn di chuyển sang ổ đĩa 500 Gig. Trong trường hợp này, tôi khuyên bạn nên giảm fs xuống, giả sử là 450 Gig (bạn phải có đủ không gian trống cho việc này, tất nhiên, tức là không gian bị chiếm dụng trong hệ thống tệp này không thể vượt quá 450 Gig). 50 Gig không gian bị lãng phí rõ ràng sẽ được sửa sau khi di chuyển dữ liệu.

2) Phân vùng đĩa đích với hình dạng phù hợp xem xét các ràng buộc không gian của nó;

3) dd dữ liệu bằng cách sử dụng (các) thiết bị phân vùng chứ không phải thiết bị đĩa (nghĩa là sử dụng dd if=/dev/sda# of=/dev/sdb#cho từng phân vùng thay vì sử dụng if=/dev/sda of=/dev/sdb). LƯU Ý: sda và sdb ở đây chỉ là ví dụ; LƯU Ý QUAN TRỌNG: Khi chuyển từ thiết bị phân vùng lớn hơn sang thiết bị phân vùng nhỏ hơn, dd sẽ phàn nàn về việc cố gắng viết bài vào cuối thiết bị khối, điều đó không sao vì dữ liệu hệ thống tệp sẽ được sao chép hoàn toàn trước khi đến điểm đó. Để tránh thông báo lỗi như vậy, bạn có thể chỉ định kích thước của bản sao bằng cách sử dụng bs=và count=các tham số để khớp với kích thước hệ thống tệp bị thu hẹp, nhưng điều này sẽ yêu cầu một số tính toán (đơn giản), nhưng nếu thực hiện sai có thể gây rủi ro cho dữ liệu của bạn.

4) Sau khi lấy dữ liệu, thay đổi kích thước (các) hệ thống tệp tương ứng trong (các) phân vùng đích một lần nữa bằng cách sử dụng resize2fs. Lần này không chỉ định kích thước hệ thống tập tin mới. Khi chạy mà không có đặc tả kích thước, resize2fs sẽ phát triển hệ thống tệp để nó chiếm kích thước tối đa được phép, do đó, trong trường hợp này, hệ thống tệp 450 Gig sẽ phát triển lại để chiếm toàn bộ phân vùng 500 Gig và sẽ không lãng phí byte nào. (Cách tiếp cận "giảm nhiều hơn mức cần thiết" giúp bạn vô tình chỉ định sai kích thước và rủi ro cho dữ liệu của bạn. Lưu ý rằng các đơn vị GB so với GiB có thể khó khăn).

Lưu ý đối với các thao tác phức tạp hơn: Nếu bạn có trình quản lý khởi động mà bạn dự định sao chép, rất có thể là trường hợp này, bạn có thể sử dụng vài KB đầu tiên của đĩa bằng thiết bị đĩa thay vì các thiết bị phân vùng (như dd if=/dev/sda of=/dev/sdb bs=4096 count=5), và sau đó cấu hình lại hình học trong / dev / sdb (sẽ tạm thời chứa hình học không hợp lệ cho ổ đĩa mới nhưng trình quản lý khởi động nguyên vẹn và hợp lệ). Cuối cùng tiến hành sử dụng các thiết bị phân vùng như được mô tả ở trên để tạo một phân vùng tại một thời điểm. Tôi đã làm các hoạt động như thế này nhiều lần. Gần đây, tôi đã thực hiện thành công việc di chuyển phức tạp khi nâng cấp từ ổ cứng chứa hỗn hợp cài đặt MacOSX & Linux lên SDD nhỏ hơn trong MacMini6,2 của tôi. Trong trường hợp này, tôi đã phải khởi động Linux từ một ổ đĩa ngoài, đã khởi động trình khởi động, chạy gdisk để sửa GPT trong đĩa mới và cuối cùng đã lấy từng phân vùng chứa các tệp tin bị thu nhỏ. (Lưu ý rằng lược đồ phân vùng GPT giữ hai bản sao của bảng phân vùng, một ở đầu và một ở cuối đĩa. gdisk phàn nàn rất nhiều vì nó không thể tìm thấy bản sao thứ hai của PT và vì các phân vùng vượt quá kích thước đĩa, nhưng nó đã khắc phục chính xác vấn đề sao chép PT sau khi bạn xác định lại hình dạng đĩa). Đây là một trường hợp phức tạp hơn nhiều, nhưng đáng nói vì minh họa rằng loại hoạt động này cũng hoàn toàn khả thi.

Chúc may mắn! ... Và quan trọng nhất là nhớ sao lưu tất cả dữ liệu quan trọng trước khi hoạt động như vậy. Một sai lầm và bạn chắc chắn có thể làm hỏng dữ liệu của bạn không thể phục hồi.

Và chỉ trong trường hợp tôi không nhấn mạnh đủ: sao lưu dữ liệu của bạn trước khi di chuyển! :)

Nếu bạn muốn đặt một chiếc xe hơi ở một lối đi hẹp hơn chiếc xe 20 cm, và bạn cắt bên trái chiếc xe 20 cm, chiếc xe có còn hoạt động không? Chắc là không.

Nếu bạn sao chép phần đầu của đĩa sang đĩa khác và cắt ngắn bản sao vì đĩa đích nhỏ hơn, kết quả sẽ không hoạt động. Ngay cả khi có đủ không gian để chứa tất cả các tệp trên đĩa đích, việc cắt sau N byte từ đầu đĩa sẽ không cung cấp cho bạn một hệ thống tệp đang hoạt động.

Nếu đĩa được chia trong các phân vùng kiểu PC (GPT hoặc MBR), thì tất cả các phân vùng phù hợp hoàn toàn với mục tiêu sẽ hoạt động. Có một ngoại lệ: với các phân vùng MBR, nếu các phân vùng logic không được đánh số theo thứ tự đĩa, thì ngay khi chuỗi rời khỏi vùng đích, các phân vùng sẽ không còn được liệt kê. (Nếu bạn không hiểu điều này, đó là một lý do nữa để không sao chép một phần đĩa.) Sẽ có ý nghĩa hơn nhiều khi sao chép các phân vùng bạn muốn giữ, thay vì sao chép từ đầu và kết thúc với bất kỳ điều gì phù hợp . Phân vùng được sao chép một phần ở cuối sẽ không thể sử dụng được.

Nếu đĩa hoặc phân vùng một phần là ổ đĩa vật lý LVM và bạn tạo một bản sao một phần của ổ đĩa vật lý đó, bạn cũng không thể chắc chắn nhận được bất kỳ dữ liệu hữu ích nào từ kết quả.

Nếu bạn chỉ muốn sao chép một số dữ liệu từ một đĩa lớn sang một đĩa nhỏ hơn, hãy tạo các phân vùng trên đĩa nhỏ hơn. Nếu bạn muốn sao chép một phân vùng vào một phân vùng cùng kích thước, bạn có thể làm điều đó với cat. Nếu bạn muốn sao chép một phân vùng vào một phân vùng nhỏ hơn, hãy tạo một hệ thống tệp trên phân vùng đích và thực hiện một bản sao ở cấp độ tệp với một cái gì đó như cp -ahoặc pax -rw -pe -t.

Bạn có thể sử dụng ddthay vì catnếu bạn là một masochist. ddcó một cú pháp lạ và thường chậm hơncat trừ khi bạn tìm đúng kích thước bộ đệm. Không có giá trị tối ưu duy nhất cho kích thước bộ đệm, nó phụ thuộc vào đặc điểm của phần cứng của bạn. Nếu kích thước quá nhỏ, ddsẽ lãng phí thời gian thực hiện nhiều lần chuyển nhỏ. Nếu kích thước quá lớn, ddsẽ lãng phí thời gian để đọc đầy đủ một bộ đệm trước khi bắt đầu viết bộ đệm tiếp theo. Kích thước tối ưu để truyền từ đĩa sang đĩa thường là vài megabyte (1024 byte là nhỏ một cách lố bịch). catsẽ chọn một kích thước khá mà không cần nỗ lực từ phía bạn.

Tôi muốn chia sẻ kinh nghiệm của tôi với chủ đề này, nếu điều này chứng minh hữu ích cho người đọc khác. Gần đây, tôi đã sử dụng DDRESCUE để khôi phục 1/3 phân vùng NTFS đầu tiên từ ổ cứng bị hỏng và xây dựng lại thành công phân đoạn đã khôi phục của phân vùng vào một ổ cứng nhỏ hơn - qua đó cứu các tệp bị bắt (và mất phần còn lại). Sau đây là các bước tôi đã thực hiện (chắc chắn là cách tiếp cận HACKSAW !!) ...

Ổ cứng nguồn bao gồm 750GB được định dạng ở dạng NTFS với tệp có thể ghi MBR. Tôi đã sử dụng nó chỉ một vài lần để sao lưu các tập tin, vì vậy hầu hết các tập tin đều ở đầu ổ đĩa, trị giá khoảng 160 GB. Một thành viên trong gia đình đã đập ổ cứng (gắn bên ngoài) xuống sàn - nó không bao giờ hoạt động bình thường sau đó! Sử dụng ddresTHER (siêng năng) tôi đã có thể phục hồi một phần lớn của đầu ổ đĩa. Do thiệt hại vật lý, nó tắt rất thường xuyên trong suốt quá trình ...

Tôi đã có một ổ cứng máy tính xách tay nhỏ có sẵn 150 GB (được gắn bên ngoài), tôi đã trích xuất dữ liệu ddresTHER trực tiếp. Ngoài ra, tôi có thể trích xuất dữ liệu vào một tệp hình ảnh và sau đó gắn tệp đó, tuy nhiên tôi nghĩ rằng việc ghi dữ liệu trực tiếp vào ổ cứng sẽ dễ dàng hơn.

Thủ thuật chính để giải cứu là chỉnh sửa thủ công cả dữ liệu MBR và NTFS Boot sector trên ổ cứng cứu hộ. Không làm như vậy, ổ cứng không được nhận ra bởi bất kỳ hệ điều hành nào. Tôi không thể tìm thấy một chương trình phù hợp trong linux để làm như vậy, vì vậy tôi đã chuyển sang windows. Có một gói tiện dụng có tên Windows Support Tools, không còn được duy trì tuy nhiên vẫn hữu ích (xem liên kết bên dưới)! Công cụ tôi sử dụng để chỉnh sửa phân vùng là Disk dò. Đảm bảo biết giá trị cung cuối của ổ cứng của bạn (Tôi đã sử dụng fdisk -l trong Ubuntu)

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

Sử dụng một máy tính tốt và một số sáng tạo, tôi đã tải lên và gắn ổ cứng vào Disk dò trong Windows và chỉnh sửa các giá trị của phần cuối. Trong MBR, hai bộ giá trị phải được thay đổi, cụ thể là a) khu vực cuối ổ cứng và b) khu vực cuối phân vùng NTFS. Trong khu vực khởi động NTFS, giá trị phân vùng Tổng số phân vùng phải được thay đổi. Trong mỗi trường hợp, giá trị số đã giảm để phù hợp với "kích thước" giảm của ổ cứng nhỏ hơn (các cung cuối thay đổi từ 750GB thành 150GB). Nhấp vào tab Xem để chỉnh sửa các giá trị này.

Dưới đây là hình ảnh của Disk dò trong hành động chỉnh sửa dữ liệu NTFS Boot sector

Khi chỉnh sửa các trường đã nói ở trên, Windows đã nhận ra phân vùng là phân vùng hợp lệ mặc dù bị hỏng. Tôi đã nhập dấu nhắc lệnh và chạy chương trình windows Chkdsk trên ổ cứng bị hỏng (chdsk D :). Thật vui mừng khi thấy phân vùng trở lại với cuộc sống, từng tệp! Chương trình đã xây dựng lại bảng phân vùng và ánh xạ lại thành công tất cả các tệp đã được sao chép từ ổ cứng bị hỏng. Các tập tin nằm ngoài phạm vi (không được sao chép) không được tìm thấy và do đó đã bị loại bỏ.

Phần tiếp theo tôi không hiểu lý do, vì các cửa sổ đã xây dựng lại thành công ổ cứng 150 GB với các tệp được bao gồm. Tuy nhiên, các cửa sổ tự nhiên không thể mở phân vùng ổ cứng để xem tệp (có một số lỗi). Tuy nhiên, Ubuntu để giải cứu! Tôi đã khởi động lại vào Ubuntu, gắn ổ cứng ngoài và không có vấn đề gì, tất cả các tệp được khôi phục đều xuất hiện!

Hy vọng rằng phương pháp bẻ khóa này để khôi phục các tập tin từ một ổ cứng lớn vào một ổ cứng nhỏ hơn sẽ chứng minh được sự hữu ích cho một số linh hồn tội nghiệp khác ngoài tôi. Chúc mừng!

Trước tiên, bạn cần thu nhỏ các phân vùng trên nguồn (hoặc xóa các giới hạn đó).
Hơn ddvà sau khi bạn có thể sẽ cần sửa chữa bảng phân vùng bằng cách sử dụng gdisk /dev/sd<target>
và trình tự khóa để sửa bảng là v r d w
tôi khuyên bạn nên tách các phân vùng nhỏ hơn một chút so với mức cần thiết và sau khi mở rộng chúng trở lại kích thước đầy đủ của đĩa đích.
(Câu trả lời này dựa trên trải nghiệm cá nhân của tôi khi sao chép ổ cứng của tôi vào ổ SSD nhỏ hơn)