知道分割區需要編輯後，可以使用「dd」克隆到較小的硬碟嗎？

Question 1

正如其他人在這裡提到的那樣，dd由於 GPT 表的副本放置在磁碟末尾，因此使用 just 不起作用。

我已成功使用以下方法遷移到較小的驅動器：

首先 - 啟動到您選擇的 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 表的副本放置在磁碟末尾，因此使用 just 不起作用。

我已成功使用以下方法遷移到較小的驅動器：

首先 - 啟動到您選擇的 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 的四個主分割區沒有問題，因為它們是在磁碟的前 512 位元組中描述的。邏輯分割區是在整個擴充分割區中描述的，因此條目可能會遺失（但它們會描述無論如何都會遺失的分割區）。對於 GPT，磁碟的開頭和結尾都有分割表的副本。你失去了第二個，但你可以從第一個重建它。當然，建議盡快這樣做；對此，其他答案更為準確。

Answer

至少實體磁碟機不應該開始冒煙，但是您的檔案系統很可能將不再運作（我的意思是目標檔案系統；如果您只是複製並且沒有觸及來源中的任何內容，則來源本身應該沒問題）。分區內的資料不一定會按升序分配。即使分區未滿，其中一些也可能位於分區的末尾（實際上，我認為這種情況在某些檔案系統中確定性地發生，但我不知道足夠的細節來了解）。那裡的數據對於檔案系統的完整性可能至關重要。所以我強烈建議你不要依賴這樣的副本。

如果要執行此複製，首先必須使用某種工具來縮小分區，該工具了解其內部結構，並且能夠將所有內容按良好順序重新映射到較小的分區中。然後就可以進行複印了。gparted是一個很好的 GUI 介面來完成這類事情。

對於bs價值，通常最好的想法是在開始真正的副本之前進行幾次測試。有一些工具可以幫助您自動執行此檢查，但我不記得名稱了。根據我的經驗，最佳範圍通常在 4M 到 16M 之間。高於這個數字你就賺不了多少錢了。但這取決於很多因素，包括磁碟本身。例如，我很少使用真正的高端磁碟，由於速度和快取大小較大，這些磁碟可能適合更高的值。

編輯如果一個分割區被完全複製，那麼您可以毫無問題地使用它。但是，正如其他人所強調的那樣，您還必須確保分區表完好無損（至少是相關條目）。 MBR 的四個主分割區沒有問題，因為它們是在磁碟的前 512 位元組中描述的。邏輯分割區是在整個擴充分割區中描述的，因此條目可能會遺失（但它們會描述無論如何都會遺失的分割區）。對於 GPT，磁碟的開頭和結尾都有分割表的副本。你失去了第二個，但你可以從第一個重建它。當然，建議盡快這樣做；對此，其他答案更為準確。

Question 3

儘管最初提出的「挑戰」可能看起來很困難、不可行，或者像一些人評論的那樣聽起來很天真，但事實並非如此。使用 dd 從較大磁碟遷移到較小磁碟的主要想法非常好，並且對遷移資料有好處。當然，有足夠的可用空間以便所佔用的資料適合目標磁碟是必要的要求。

這個想法是考慮單獨添加每個分割區，而不是像最初建議的那樣一次性添加整個磁碟。還可以完成更多工作：借助檔案系統調整大小工具的一點幫助，也可以安全地遷移將被截斷的分區。事實上，為了保留檔案系統元資料和擴充檔案屬性，這種遷移很有趣，而這些屬性不能使用 cp、rsync、pax 等工具輕鬆複製，這些工具在檔案系統層而不是區塊裝置層運行。使用 dd 無需重新安裝作業系統或重新標記 FS 以避免 SELinux 問題。

以下是我通常為完成類似任務所做的事情：

1) 首先，您需要減少受影響分區中將被截斷的檔案系統。為此，請使用 resize2fs 工具（假設我們正在討論 ext2/ext3/ext4 fs - 其他現代 FS 也具有用於相同目的的調整大小工具）。請注意，儘管出於顯而易見的原因，檔案系統不能大於它所在的分區，但它可以安全地小一些。這裡的安全技巧是減少「超過需要的」。例如：假設您有一個 1TB 的檔案系統，想要遷移到 500 Gig 磁碟機。在這種情況下，我建議將檔案系統減少到450 Gig（當然，您必須有足夠的可用空間，即該檔案系統中目前佔用的空間不能超過450 Gig）。明顯浪費的 50 Gig 空間將在資料遷移後修復。

2) 考慮到目標磁碟的空間限制，使用適當的幾何結構對目標磁碟進行分割；

3) 使用分割設備而不是磁碟設備新增資料（即，使用dd if=/dev/sda# of=/dev/sdb#每個分割區而不是使用if=/dev/sda of=/dev/sdb）。注意：這裡的sda和sdb只是範例；重要提示：當從較大的分區裝置寫入較小的分區裝置時，dd 會抱怨嘗試將post 寫入區塊裝置的末尾，這是可以的，因為檔案系統資料在到達該點之前已完全複製。為了避免此類錯誤訊息，您可以使用bs=參數指定副本的大小count=以匹配縮小的檔案系統大小，但這將需要一些（簡單的）計算，但如果操作錯誤可能會危及您的資料。

4) 新增資料後，再次使用 resize2fs 調整目標分割區內對應檔案系統的大小。這次不指定新的檔案系統大小。當在沒有大小指定的情況下運行時，resize2fs 會增長檔案系統，使其佔據允許的最大大小，因此，在這種情況下，450 Gig 檔案系統將再次成長以佔據整個500 Gig 分割區，並且不會浪費任何位元組。（「減少超過需要的數量」方法可避免您意外錯誤地指定大小並導致資料面臨風險。請注意，GB 與 GiB 單位可能會很棘手）。

對於更複雜的操作，請注意：如果您打算複製一個啟動管理器（很可能是這種情況），您可以使用磁碟裝置而不是分割裝置來新增磁碟的前幾個 KB（如dd if=/dev/sda of=/dev/sdb bs=4096 count=5），然後重新配置/dev/sdb 中的幾何結構（其中將暫時包含新磁碟機的無效幾何結構，但包含完整且有效的引導管理器）。最後繼續使用如上所述的分區設備一次新增一個分區。這樣的操作我做過很多次了。最近，當我從包含 MacOSX 和 Linux 安裝混合的 HDD 升級到 MacMini6,2 中的較小 SDD 時，成功執行了複雜的遷移。在這種情況下，我必須從外部驅動器啟動 Linux，dd'ed 啟動管理器，運行 gdisk 來修復新磁碟中的 GPT，最後 dd'ed 包含剛剛縮小的檔案系統的每個分割區。（請注意，GPT 分割區方案保留分割區表的兩份副本，一份在磁碟的開頭，另一份在磁碟的末尾。gdisk 抱怨很多，因為它找不到PT 的第二個副本，並且分割區超出了磁碟大小，但它在重新定義磁碟幾何形狀後正確修復了 PT 複製問題）。這是一個複雜得多的案例，但值得一提，因為這表明這種操作也是完全可行的。

祝你好運！ ...最重要的是記住在進行此類操作之前備份所有重要資料。一個錯誤肯定會導致您的資料受到不可挽回的損壞。

以防萬一我強調得不夠：在遷移之前備份您的資料！ :)

Answer

儘管最初提出的「挑戰」可能看起來很困難、不可行，或者像一些人評論的那樣聽起來很天真，但事實並非如此。使用 dd 從較大磁碟遷移到較小磁碟的主要想法非常好，並且對遷移資料有好處。當然，有足夠的可用空間以便所佔用的資料適合目標磁碟是必要的要求。

這個想法是考慮單獨添加每個分割區，而不是像最初建議的那樣一次性添加整個磁碟。還可以完成更多工作：借助檔案系統調整大小工具的一點幫助，也可以安全地遷移將被截斷的分區。事實上，為了保留檔案系統元資料和擴充檔案屬性，這種遷移很有趣，而這些屬性不能使用 cp、rsync、pax 等工具輕鬆複製，這些工具在檔案系統層而不是區塊裝置層運行。使用 dd 無需重新安裝作業系統或重新標記 FS 以避免 SELinux 問題。

以下是我通常為完成類似任務所做的事情：

1) 首先，您需要減少受影響分區中將被截斷的檔案系統。為此，請使用 resize2fs 工具（假設我們正在討論 ext2/ext3/ext4 fs - 其他現代 FS 也具有用於相同目的的調整大小工具）。請注意，儘管出於顯而易見的原因，檔案系統不能大於它所在的分區，但它可以安全地小一些。這裡的安全技巧是減少「超過需要的」。例如：假設您有一個 1TB 的檔案系統，想要遷移到 500 Gig 磁碟機。在這種情況下，我建議將檔案系統減少到450 Gig（當然，您必須有足夠的可用空間，即該檔案系統中目前佔用的空間不能超過450 Gig）。明顯浪費的 50 Gig 空間將在資料遷移後修復。

2) 考慮到目標磁碟的空間限制，使用適當的幾何結構對目標磁碟進行分割；

3) 使用分割設備而不是磁碟設備新增資料（即，使用dd if=/dev/sda# of=/dev/sdb#每個分割區而不是使用if=/dev/sda of=/dev/sdb）。注意：這裡的sda和sdb只是範例；重要提示：當從較大的分區裝置寫入較小的分區裝置時，dd 會抱怨嘗試將post 寫入區塊裝置的末尾，這是可以的，因為檔案系統資料在到達該點之前已完全複製。為了避免此類錯誤訊息，您可以使用bs=參數指定副本的大小count=以匹配縮小的檔案系統大小，但這將需要一些（簡單的）計算，但如果操作錯誤可能會危及您的資料。

4) 新增資料後，再次使用 resize2fs 調整目標分割區內對應檔案系統的大小。這次不指定新的檔案系統大小。當在沒有大小指定的情況下運行時，resize2fs 會增長檔案系統，使其佔據允許的最大大小，因此，在這種情況下，450 Gig 檔案系統將再次成長以佔據整個500 Gig 分割區，並且不會浪費任何位元組。（「減少超過需要的數量」方法可避免您意外錯誤地指定大小並導致資料面臨風險。請注意，GB 與 GiB 單位可能會很棘手）。

對於更複雜的操作，請注意：如果您打算複製一個啟動管理器（很可能是這種情況），您可以使用磁碟裝置而不是分割裝置來新增磁碟的前幾個 KB（如dd if=/dev/sda of=/dev/sdb bs=4096 count=5），然後重新配置/dev/sdb 中的幾何結構（其中將暫時包含新磁碟機的無效幾何結構，但包含完整且有效的引導管理器）。最後繼續使用如上所述的分區設備一次新增一個分區。這樣的操作我做過很多次了。最近，當我從包含 MacOSX 和 Linux 安裝混合的 HDD 升級到 MacMini6,2 中的較小 SDD 時，成功執行了複雜的遷移。在這種情況下，我必須從外部驅動器啟動 Linux，dd'ed 啟動管理器，運行 gdisk 來修復新磁碟中的 GPT，最後 dd'ed 包含剛剛縮小的檔案系統的每個分割區。（請注意，GPT 分割區方案保留分割區表的兩份副本，一份在磁碟的開頭，另一份在磁碟的末尾。gdisk 抱怨很多，因為它找不到PT 的第二個副本，並且分割區超出了磁碟大小，但它在重新定義磁碟幾何形狀後正確修復了 PT 複製問題）。這是一個複雜得多的案例，但值得一提，因為這表明這種操作也是完全可行的。

祝你好運！ ...最重要的是記住在進行此類操作之前備份所有重要資料。一個錯誤肯定會導致您的資料受到不可挽回的損壞。

以防萬一我強調得不夠：在遷移之前備份您的資料！ :)

Question 4

我想分享我在這個主題上的經驗，如果這對其他讀者有用的話。最近我用過DDR救援從故障硬碟中復原 NTFS 分割區的前 1/3，並成功地將復原的分割區段重建到較小的硬碟上 - 從而挽救擷取的檔案（並遺失其餘部分）。以下是我這樣做的步驟（絕對是鋼鋸方法！！）…

來源硬碟由 750GB 的 NTFS 格式和 MBR 檔案表組成。我只用過它幾次來備份文件，所以大部分文件都在驅動器的開頭，大約有160GB。一名家庭成員將硬碟（安裝在外部）撞到地板上 - 此後它就再也無法正常工作了！使用 ddrescue （煞費苦心地），我能夠恢復驅動器開頭的大部分內容。由於物理損壞，整個過程中非常頻繁地關閉...

我有一個可用的 150GB 小型筆記型電腦硬碟（外部安裝），我將 ddrescue 資料直接提取到其中。或者，我可以將資料提取到圖像文件，然後安裝該文件，但我認為將資料直接寫入硬碟更簡單。

救援的關鍵技巧是手動編輯救援硬碟上的 MBR 和 NTFS 開機磁區資料。如果不這樣做，任何作業系統都無法識別硬碟。我在linux下找不到合適的程式來做到這一點，所以我轉向了windows。有一個名為 Windows 支援工具的方便包，不再維護，但仍然有用（請參閱下面的連結）！我用來編輯分割區的工具是Disk Probe。確保知道你的硬碟的結束磁區值（我在Ubuntu中使用了fdisk -l）

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

使用一個好的計算器和一些創造力，我將硬碟載入並安裝到 Windows 中的 Disk Probe 中，並編輯了最終磁區值。在 MBR 中，必須變更兩組值，即 a) 硬碟結束磁區和 b) NTFS 分割區結束磁區。在 NTFS 開機磁區中，必須變更分割區總磁區值。在每種情況下，數值都會減小，以匹配較小硬碟所減小的「尺寸」（末端磁區從 750GB 變更為 150GB）。按一下「檢視」標籤可編輯這些值。

這是 Disk Probe 正在編輯 NTFS 開機磁區資料的影像

編輯上述欄位後，Windows 將該分割區識別為有效分割區，儘管已損壞。我進入命令提示字元並在損壞的硬碟上執行 Windows 程式 Chkdsk (chdsk D:)。看到分區逐一恢復活力真是令人興奮！該程式重建了分區表，並成功重新映射了從損壞的硬碟複製過來的所有檔案。未找到超出範圍（未複製）的文件，因此被刪除。

接下來的部分我不明白原因，因為 Windows 確實成功重建了 150GB 硬碟並包含檔案。儘管如此，Windows 本身無法開啟硬碟分割區進行檔案檢視（存在一些錯誤）。不過 Ubuntu 可以拯救你！我重新啟動到 Ubuntu，安裝了外部硬碟，完全沒有問題，所有復原的檔案都顯示出來了！

希望這種將文件從大硬碟恢復到小硬碟的鋼鋸方法將對除了我之外的其他可憐的人有用。乾杯!

Answer