Можно ли использовать «dd» для клонирования на жесткий диск меньшего размера, зная, что разделы будут нуждаться в редактировании?

Я привык ddклонировать диски, как это:

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

И это всегда работало нормально. Любые и все документы на «dd» прилагают все усилия, чтобы напомнить вам, что целевой диск должен быть того же размера или больше, чем исходный. Это обязательно должно быть правдой?

Теперь я вполне понимаю, что, если я клонирую на меньший диск, я не могу ожидать, что какие-либо разделы, которые даже частично «выходят за пределы» на целевом объекте, не будут повреждены.

Однако, прекрасно зная, что позже мне нужно будет отредактировать мои разделы на цели, удалив «вне границ», могу ли я по-прежнему использовать «dd», чтобы сделать грубую копию источника до пределов физический размер цели? Или «dd» уменьшит цель до дымящейся груды обломков, когда она достигнет предела своего размера ;-)

Кстати, исследуя это, я видел рекомендуемые значения для bs=всего, bs=1024вплоть до bs=32M, что на самом деле лучше?

Физический диск не должен начинать курить, по крайней мере, но очень высоки шансы, что ваша файловая система больше не будет работать (я имею в виду целевую файловую систему; если вы просто скопировали и ничего не трогали в источнике, сам источник должен быть в порядке) ). Данные внутри раздела не обязательно размещаются в возрастающем порядке. Часть этого может быть в конце раздела, даже если раздел не заполнен (на самом деле, я думаю, что это происходит детерминистически с некоторой файловой системой, но я не знаю достаточно, чтобы получить подробности). Данные там могут иметь важное значение для целостности файловой системы. Поэтому я настоятельно советую вам не полагаться на такую ​​копию.

Если вы хотите сделать эту копию, вам сначала нужно сжать раздел с помощью какого-либо инструмента, который знает о своей внутренней структуре и способен преобразовать все в хорошем порядке в меньший раздел. Тогда вы можете сделать копию. gpartedхороший графический интерфейс для таких вещей.

Для bsзначения обычно лучше всего провести пару тестов перед запуском реальной копии. Есть некоторые инструменты, которые помогут вам автоматизировать эту проверку, но я не помню название. По моему опыту, лучший диапазон обычно между 4M и 16M. Выше этого вы больше не зарабатываете больше. Но это зависит от многих вещей, включая сами диски. Например, я редко работал с настоящими высококачественными дисками, которые могут подходить для более высоких значений из-за большей скорости и размера кэша.

РЕДАКТИРОВАТЬ Если раздел полностью скопирован, то вы можете использовать его без проблем. Однако, как подчеркнули другие, вы также должны быть уверены, что таблица разделов не повреждена (по крайней мере, соответствующие записи). С четырьмя основными разделами MBR проблем не возникает, так как они описаны в первых 512 байтах диска. Логические разделы описаны во всем расширенном разделе, поэтому записи могут быть потеряны (но они описали бы разделы, которые в любом случае будут потеряны). С GPT есть копия таблицы разделов как в начале, так и в конце диска. Вы теряете второй, но вы можете восстановить его из первого. Конечно, желательно сделать это как можно скорее; другие ответы были более точными в отношении этого.

Хотя поначалу предлагаемый «вызов» может показаться трудным, неосуществимым или звучать наивно, как некоторые прокомментировали, это не так. Основная идея использования dd для переноса с диска на больший и меньший - это прекрасно и дает преимущества для переноса данных. Конечно, наличие достаточного свободного места для размещения занятых данных на целевом диске является необходимым требованием.

Идея состоит в том, чтобы продумывать каждый раздел отдельно, а не весь диск сразу, как было изначально предложено. Может быть достигнуто еще больше: усеченные разделы можно также безопасно перенести с помощью инструментов изменения размера файловой системы. Действительно, такой вид миграции интересен для сохранения метаданных файловой системы и расширенных атрибутов файлов, которые нельзя легко скопировать с помощью таких инструментов, как cp, rsync, pax, ..., которые работают на уровне файловой системы, а не на уровне блочных устройств. Использование dd устраняет необходимость переустановки ОС или необходимости перемаркировки FS во избежание проблем с SELinux.

Ниже я обычно делаю для решения подобных задач:

1) Сначала вы должны уменьшить файловую систему (ы) в затронутых разделах, которые будут усечены. Для этого используйте инструмент resize2fs (если мы говорим о ext2 / ext3 / ext4 fs - другие современные FS также имеют инструменты изменения размера для той же цели). Обратите внимание, что хотя - по очевидным причинам - файловая система не может быть больше, чем раздел, в котором она находится, она может безопасно быть меньше. Уловка безопасности здесь состоит в том, чтобы уменьшить «больше, чем необходимо». Например: представьте, что у вас есть файловая система объемом 1 ТБ, которую вы хотите перенести на диск объемом 500 Гб. В этом случае я предлагаю уменьшить fs, скажем, до 450 гигабайт (для этого, конечно, должно быть достаточно свободного места, т. Е. Занимаемое в настоящее время пространство в этой файловой системе не может превышать 450 гигабайт). Кажущиеся потраченными впустую 50 гигабайтами места будут исправлены после переноса данных.

2) Разбить целевой диск соответствующей геометрией с учетом его пространственных ограничений;

3) dd данные, используя устройство (я) раздела, а не устройство диска (то есть, используйте dd if=/dev/sda# of=/dev/sdb# для каждого раздела вместо использования if=/dev/sda of=/dev/sdb). ПРИМЕЧАНИЕ: sda и sdb здесь только примеры; ВАЖНОЕ ПРИМЕЧАНИЕ: При переходе с устройства с большим разделом на устройство меньшего размера dd будет жаловаться на попытку записи сообщения в конец блочного устройства, это нормально, так как данные файловой системы были бы полностью скопированы до достижения этой точки. Чтобы избежать этого сообщения об ошибке можно указать размер копии с помощью bs=и count=параметрами в соответствии с размером усадки файловой системы, но это потребует некоторого (простой) расчета, но если сделано неправильно может рисковать данные.

4) После добавления данных измените размер соответствующей файловой системы (ов) в целевом разделе (ах) снова, используя resize2fs. На этот раз не указывайте новый размер файловой системы. При запуске без указания размера resize2fs увеличивает файловую систему так, чтобы она занимала максимально допустимый размер, поэтому в этом случае файловая система 450 Гиг будет снова расти, занимая весь раздел 500 Гига, и ни один байт не будет потрачен впустую. (Подход «уменьшить больше, чем необходимо» позволяет избежать ошибочного указания размеров и риска для ваших данных. Обратите внимание, что единицы GB и GiB могут быть сложными).

Примечание для более сложных операций: если у вас есть менеджер загрузки, который вы собираетесь скопировать, что весьма вероятно, вы можете создать первые несколько КБ диска, используя дисковое устройство вместо устройств раздела (например, dd if=/dev/sda of=/dev/sdb bs=4096 count=5), а затем перенастроить геометрию в / dev / sdb (которая временно будет содержать недопустимую геометрию для нового диска, но нетронутый и действительный менеджер загрузки). Наконец, продолжайте использовать устройства разделов, как описано выше, для добавления разделов за раз. Я делал такие операции много раз. Совсем недавно я успешно выполнил сложную миграцию при переходе с жесткого диска, содержащего набор установок MacOSX и Linux, на меньший SDD в моем MacMini6,2. В этом случае мне пришлось загружать Linux с внешнего диска, делать загрузочный менеджер, запускать gdisk для исправления GPT на новом диске и, наконец, добавлять каждый раздел, содержащий только что сжатые файловые системы. (Обратите внимание, что схема разделов GPT хранит две копии таблицы разделов, одну в начале, а другую в конце диска. gdisk часто жалуется, потому что не может найти вторую копию PT и потому что разделы превышают размер диска, но он корректно решает проблему копирования PT после переопределения геометрии диска). Это был гораздо более сложный случай, но стоит упомянуть, потому что иллюстрирует, что этот вид операции также вполне осуществим.

Удачи! ... и самое главное, не забудьте сделать резервную копию всех важных данных перед такой операцией. Ошибка, и вы наверняка можете нанести непоправимый ущерб вашим данным.

И на всякий случай я не особо подчеркнул: сделайте резервную копию ваших данных перед миграцией! :)

Если вы хотите разместить автомобиль в проходе, который на 20 см уже, чем автомобиль, и вы отрежете оставшиеся 20 см, будет ли машина работать? Возможно нет.

Если вы скопируете начало диска на другой диск и обрежете копию, потому что целевой диск меньше, результат не будет работать. Даже если будет достаточно места для размещения всех файлов на целевом диске, вырезание после N байтов с начала диска не даст вам работающую файловую систему.

Если диск разделен на разделы в стиле ПК (GPT или MBR), то все разделы, которые полностью соответствуют цели, будут работать. Есть одно исключение: с MBR-разделами, если логические разделы не нумеруются в порядке дисков, то, как только цепочка покидает целевую область, разделы больше не будут перечислены. (Если вы этого не понимаете, это еще одна причина не делать частичную копию диска.) Было бы гораздо разумнее скопировать разделы, которые вы хотите сохранить, вместо того, чтобы копировать с самого начала и заканчивать тем, что подходит , Частично скопированный раздел в конце не будет использоваться.

Если диск или частичный раздел является физическим томом LVM, и вы делаете частичную копию этого физического тома, вы также не можете быть уверены, что получите какие-либо полезные данные из результата.

Если вы хотите скопировать только некоторые данные с большого диска на меньший диск, создайте разделы на меньшем диске. Если вы хотите скопировать раздел в раздел того же размера, вы можете сделать это с помощью cat. Если вы хотите скопировать раздел в меньший раздел, создайте файловую систему на целевом разделе и сделайте копию на уровне файлов с помощью чего-то вроде cp -aили pax -rw -pe -t.

Вы можете использовать ddвместо, catесли вы мазохист. ddимеет странный синтаксис и обычно медленнее, чемcat если вы не найдете правильный размер буфера. Не существует единого оптимального значения для размера буфера, это зависит от характеристик вашего оборудования. Если размер слишком мал, ddбудет потрачено время, делая много крошечных переводов. Если размер слишком велик, ddбудет потрачено время на полное чтение одного буфера перед началом записи следующего. Оптимальный размер для передачи с диска на диск обычно составляет несколько мегабайт (1024 байта смехотворно мало). catподберет приличный размер без усилий с вашей стороны.

Я хотел бы поделиться своим опытом с этой темой, если это окажется полезным для другого читателя. Недавно я использовал DDRESCUE, чтобы восстановить первые 1/3 раздела NTFS с неисправного жесткого диска и успешно перестроить восстановленный сегмент раздела на меньший жесткий диск - тем самым восстановив захваченные файлы (и потеряв остальные). Ниже приведены шаги, которые я предпринял (определенно подход HACKSAW !!) ...

Исходный жесткий диск состоял из 750 ГБ, отформатированных в NTFS, с таблицей MBR. Я использовал его всего несколько раз для резервного копирования файлов, поэтому большинство файлов были в начале диска, около 160 ГБ. Член семьи сбил жесткий диск (установленный снаружи) на пол - после этого он никогда не работал должным образом! Используя ddrescue (кропотливо), я смог восстановить большую часть начала диска. Из-за физического повреждения он очень часто отключался на протяжении всего процесса ...

У меня был небольшой жесткий диск для ноутбука, доступный 150 ГБ (смонтированный снаружи), на который я непосредственно извлек данные ddrescue. В качестве альтернативы я мог бы извлечь данные в файл изображения, а затем смонтировать файл, однако я подумал, что запись данных напрямую на жесткий диск будет более простой.

Ключевым трюком в спасении было ручное редактирование данных MBR и загрузочного сектора NTFS на спасательном жестком диске. Без этого жесткий диск не распознается ни одной операционной системой. Я не смог найти подходящую программу в Linux, чтобы сделать это, поэтому я обратился к Windows. Существует удобный пакет под названием Windows Support Tools, который больше не поддерживается, но все еще полезен (см. Ссылку ниже)! Инструмент, который я использовал для редактирования раздела, это Disk Probe. Убедитесь, что знаете значение конечного сектора вашего жесткого диска (я использовал fdisk -l в Ubuntu)

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

Используя хороший калькулятор и немного творчества, я загрузил и установил жесткий диск в Disk Probe в Windows и отредактировал значения конечного сектора. В MBR необходимо было изменить два набора значений, а именно: а) конец жесткого диска и б) конечный сектор раздела NTFS. В загрузочном секторе NTFS значение параметра Всего секторов пришлось изменить. В каждом случае числовое значение уменьшалось, чтобы соответствовать уменьшенному «размеру» жесткого диска меньшего размера (конечные сектора изменялись с 750 ГБ до 150 ГБ). Перейдите на вкладку «Вид», чтобы изменить эти значения.

Вот изображение Disk Probe в действии, редактирующее данные загрузочного сектора NTFS

После редактирования вышеупомянутых полей Windows распознала раздел как допустимый раздел, хотя и поврежденный. Я вошел в командную строку и запустил программу Windows Chkdsk на поврежденном жестком диске (chdsk D :). Было захватывающе видеть, как раздел оживает, файл за файлом! Программа восстановила таблицу разделов и успешно переназначила все файлы, которые были скопированы с поврежденного жесткого диска. Файлы, которые были вне диапазона (не скопированы), не были найдены и поэтому были удалены.

В следующей части я не понимаю причину, поскольку Windows успешно восстановила жесткий диск на 150 ГБ с включенными файлами. Тем не менее Windows изначально не смог открыть раздел жесткого диска для просмотра файлов (произошла ошибка). Однако Ubuntu на помощь! Я перезагрузился в Ubuntu, установил внешний жесткий диск, и все без проблем все восстановленные файлы обнаружились!

Надеюсь, этот ножовочный метод восстановления файлов с большого жесткого диска на меньший жесткий диск окажется полезным для какой-то другой бедной души, кроме меня. Ура!

Сначала вам нужно сжать разделы в источнике (или удалить их за пределами).
Чем ddи после того, как вам, вероятно, потребуется восстановить таблицу разделов с помощью gdisk /dev/sd<target>
последовательности ключей для восстановления таблицы, v r d w
я предлагаю вам сократить размеры разделов немного меньше, чем необходимо, и после того, как разверните их обратно до полного размера целевого диска.
(Этот ответ основан на моем личном опыте при клонировании моего жесткого диска на меньший SSD)