Я использовал ddдля клонирования дисков такой способ:
dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync
И это всегда работало отлично. Любые документы по 'dd' стараются напомнить вам, что целевой диск должен быть того же размера или больше исходного. Это обязательно должно быть правдой?
Теперь я прекрасно понимаю, что если я клонирую на меньший диск, то не могу ожидать, что разделы будут ровными.частично «за пределами» цели, чтобы быть целым.
Однако, прекрасно понимая, что мне позже нужно будет редактировать разделы на цели, удаляя те, которые «вне границ», могу ли я все равно использовать «dd», чтобы сделать копию источника методом перебора до пределов физического размера цели? Или «dd» уменьшит цель до дымящейся груды обломков, когда она достигнет предела своего размера ;-)
Кстати, исследуя этот вопрос, я видел рекомендуемые значения для bs=всего от bs=1024до bs=32M, что на самом деле лучше?
решение1
Как уже упоминали другие, использование just ddне сработает из-за копии таблицы GPT, размещенной в конце диска.
Мне удалось выполнить миграцию на меньший диск, используя следующий метод:
Сначала загрузите 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...
Очевидно, если вы перепутаете имена дисков при репликации таблицы разделов GPT без резервной копии или при ddкопировании контента, вы можете попрощаться со своим контентом :)
решение2
Физический диск не должен, по крайней мере, начать дымиться, но очень велики шансы, что ваша файловая система больше не будет работать (я имею в виду целевую файловую систему; если вы просто скопировали и ничего не трогали в источнике, сам источник должен быть в порядке). Данные внутри раздела не обязательно размещаются в порядке возрастания. Часть из них может находиться в конце раздела, даже если раздел не заполнен (на самом деле, я думаю, что это происходит детерминированно с некоторыми файловыми системами, но я недостаточно знаю, чтобы вдаваться в подробности). Данные там могут быть важны для целостности файловой системы. Поэтому я настоятельно рекомендую вам не полагаться на такую копию.
Если вы хотите сделать эту копию, вам сначала нужно сжать раздел с помощью какого-то инструмента, который знает его внутреннюю структуру и может переназначить все в хорошем порядке в меньший раздел. Затем вы можете сделать копию. gparted— это хороший графический интерфейс для выполнения таких вещей.
Что касается значения bs, обычно лучше всего провести несколько тестов перед началом реального копирования. Есть несколько инструментов, которые помогают автоматизировать эту проверку, но я не помню названия. По моему опыту, лучший диапазон обычно находится между 4M и 16M. Выше этого вы уже не заработаете много. Но это зависит от многих вещей, включая сами диски. Например, я редко работал с настоящими высокопроизводительными дисками, которые могут подходить для более высоких значений из-за большей скорости и размера кэша.
РЕДАКТИРОВАТЬЕсли раздел полностью скопирован, то вы можете использовать его без проблем. Однако, как подчеркивали другие, вы также должны быть уверены, что таблица разделов не повреждена (по крайней мере, соответствующие записи). С четырьмя основными разделами MBR проблем нет, так как они описаны в первых 512 байтах диска. Логические разделы описаны по всему расширенному разделу, поэтому записи могут быть потеряны (но они описывали бы разделы, которые были бы потеряны в любом случае). С GPT есть копия таблицы разделов как в начале, так и в конце диска. Вы теряете вторую, но вы можете восстановить ее из первой. Конечно, желательно сделать это как можно скорее; другие ответы были более точными в этом отношении.
решение3
Хотя на первый взгляд предлагаемый "челлендж" может показаться сложным, невыполнимым или наивным, как некоторые комментируют, это не так. Основная идея использования dd для миграции с большего на меньший диск совершенно хороша и имеет преимущества для миграции данных. Конечно, наличие достаточного свободного места, чтобы занятые данные поместились на целевом диске, является необходимым требованием.
Идея заключается в том, чтобы думать о dd'ing каждого раздела по отдельности, а не всего диска сразу, как изначально предлагалось. Можно сделать даже больше: раздел(ы), которые будут усечены, также можно безопасно перенести с небольшой помощью инструментов изменения размера файловой системы. Действительно, такой вид миграции интересен для сохранения метаданных файловой системы и расширенных атрибутов файлов, которые нельзя легко скопировать с помощью таких инструментов, как cp, rsync, pax, ..., которые работают на уровне файловой системы, а не на уровне блочных устройств. Использование dd устраняет необходимость переустановки ОС или перемаркировки ФС, чтобы избежать проблем с SELinux.
Ниже приведено то, что я обычно делаю для выполнения подобных задач:
1) Сначала вы должны уменьшить файловую систему(ы) в затронутых разделах, которые будут усечены. Для этого используйте инструмент resize2fs (предполагая, что мы говорим о файловой системе ext2/ext3/ext4 — другие современные файловые системы также имеют инструменты изменения размера для той же цели). Обратите внимание, что хотя — по очевидным причинам — файловая система не может быть больше раздела, в котором она находится, она может быть безопасно меньше. Хитрость безопасности здесь заключается в уменьшении «больше, чем необходимо». Например: представьте, что у вас есть файловая система размером 1 ТБ, которую вы хотите перенести на диск объемом 500 ГБ. В этом случае я предлагаю уменьшить файловую систему, скажем, до 450 ГБ (конечно, у вас должно быть достаточно свободного места для этого, т. е. текущее занятое пространство в этой файловой системе не может превышать 450 ГБ). Очевидно, что 50 ГБ пространства, потраченного впустую, будут исправлены после миграции данных.
2) Разбейте целевой диск на разделы с соответствующей геометрией, учитывая ограничения по пространству;
3) dd данные, используя устройство(а) раздела, а не дисковое устройство (т. е. используйте dd if=/dev/sda# of=/dev/sdb#для каждого раздела вместо использования if=/dev/sda of=/dev/sdb). ПРИМЕЧАНИЕ: sda и sdb здесь являются лишь примерами; ВАЖНОЕ ПРИМЕЧАНИЕ: при dd с большего на меньшее устройство раздела dd будет жаловаться на попытку записи post в конец блочного устройства, это нормально, так как данные файловой системы были бы полностью скопированы до достижения этой точки. Чтобы избежать такого сообщения об ошибке, вы можете указать размер копии, используя bs=и count=параметры, соответствующие уменьшенному размеру файловой системы, но это потребует некоторых (простых) вычислений, а если сделать неправильно, то можно подвергнуть риску ваши данные.
4) После dd'ing данных снова измените размер соответствующей файловой системы(-ок) в разделе(-ах) назначения с помощью resize2fs. На этот раз не указывайте новый размер файловой системы. При запуске без указания размера resize2fs увеличивает файловую систему так, чтобы она заняла максимально допустимый размер, поэтому в этом случае файловая система размером 450 ГБ снова увеличится, чтобы занять весь раздел размером 500 ГБ, и ни один байт не будет потрачен впустую. (Подход «сократить больше, чем нужно» позволяет избежать случайного неправильного указания размеров и риска для ваших данных. Обратите внимание, что единицы измерения ГБ и ГиБ могут быть сложными).
Примечание для более сложных операций: если у вас есть менеджер загрузки, который вы собираетесь скопировать, что, скорее всего, так и будет, вы можете выполнить dd первых нескольких КБ диска, используя дисковое устройство вместо устройств разделов (например, dd if=/dev/sda of=/dev/sdb bs=4096 count=5), а затем перенастроить геометрию в /dev/sdb (который будет временно содержать недопустимую геометрию для нового диска, но невредимый и действительный менеджер загрузки). Наконец, продолжайте использовать устройства разделов, как описано выше, для dd'инга раздела за раз. Я делал такие операции много раз. Совсем недавно я успешно выполнил сложную миграцию при обновлении с жесткого диска, содержащего смесь установок MacOSX и Linux, на меньший SDD в моем MacMini6,2. В этом случае мне пришлось загрузить Linux с внешнего диска, выполнить dd'инг менеджера загрузки, запустить gdisk, чтобы исправить GPT на новом диске, и, наконец, выполнить dd'инг каждого раздела, содержащего только что сжатые файловые системы. (Обратите внимание, что схема разделов GPT сохраняет две копии таблицы разделов, одну в начале и другую в конце диска. gdisk много жалуется, потому что не может найти вторую копию PT и потому что разделы превышают размер диска, но он правильно исправляет проблему копирования PT после того, как вы переопределяете геометрию диска.) Это был гораздо более сложный случай, но его стоит упомянуть, поскольку он иллюстрирует, что этот тип операций также вполне осуществим.
Удачи! ...и самое главное не забудьте сделать резервную копию всех важных данных перед такой операцией. Ошибка и вы наверняка можете испортить свои данные безвозвратно.
И на всякий случай, если я недостаточно подчеркнул: сделайте резервную копию данных перед миграцией! :)
решение4
Я хотел бы поделиться своим опытом по этой теме, может быть, это окажется полезным для другого читателя. Недавно я использовалDDRESCUEвосстановить первую треть раздела NTFS с неисправного жесткого диска и успешно перестроить восстановленный сегмент раздела на меньший жесткий диск - тем самым спасая захваченные файлы (и теряя остальное). Ниже приведены шаги, которые я предпринял для этого(определенно, это подход НОЖОВКИ по металлу!!)...
Исходный жесткий диск состоял из 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 нужно было изменить два набора значений, а именно a) конечный сектор жесткого диска и b) конечный сектор раздела NTFS. В загрузочном секторе NTFS нужно было изменить значение общего количества секторов раздела. В каждом случае численное значение уменьшалось, чтобы соответствовать уменьшенному «размеру» меньшего жесткого диска (конечные секторы изменились с 750 ГБ до 150 ГБ). Щелкните вкладку «Вид», чтобы изменить эти значения.
Ниже представлено изображение Disk Probe в действии, редактирующего данные загрузочного сектора NTFS.
После редактирования вышеупомянутых полей Windows распознала раздел как допустимый раздел, хотя и поврежденный. Я вошел в командную строку и запустил программу Windows Chkdsk на поврежденном жестком диске (chdsk D:). Было волнительно видеть, как раздел возвращается к жизни, файл за файлом! Программа перестроила таблицу разделов и успешно переназначила все файлы, которые были скопированы с поврежденного жесткого диска. Файлы, которые были вне диапазона (не скопированы), не были найдены и поэтому были удалены.
Следующая часть, в которой я не понимаю причину, так как Windows успешно восстановила жесткий диск на 150 ГБ с включенными файлами. Тем не менее, Windows изначально не смогла открыть раздел жесткого диска для просмотра файлов (была какая-то ошибка). Однако Ubuntu спешит на помощь! Я перезагрузился в Ubuntu, смонтировал внешний жесткий диск, и без каких-либо проблем все восстановленные файлы появились!
Надеюсь, этот метод ножовки по металлу для восстановления файлов с большого жесткого диска на меньший жесткий диск окажется полезным еще кому-нибудь, кроме меня. Ура!