'dd' может использоваться для клонирования к меньшему жесткому диску, зная, что для разделов будет нужно редактирование?

При использовании GNU grep можно использовать -r.

grep -r zenity directory

Иначе, если Ваш grep реализация не имеет никаких опций для рекурсии, можно использовать find и grep:

find directory -exec grep -H zenity {} +
14
15.11.2016, 18:52
6 ответов

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

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

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

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

7
27.01.2020, 19:51

Как упоминалось здесь, использование только 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
dd if=/dev/sda2 of=/dev/sdb2 bs=1M
dd if=/dev/sda3 of=/dev/sdb3 bs=1M
etc...

Очевидно, что если вы перепутаете имена дисков при репликации таблицы разделов GPT без резервного копирования или при ddчтении содержимого, вы можете поцеловать свой контент на прощание:)

7
22.03.2020, 13:24

Этот сценарий Bash делает то, что нужно, но не использует только sed и awk . Я уверен, что если бы больше времени было потрачено на разработку этого, его можно было бы доработать, но он, примерно, делает то, что вы хотите.

$ more cmd.bash 
#!/bin/bash

while read line; do 
    f1=$(echo "$line" | awk -F", " '{print $3}')
    f2=$(echo "$line" | awk -F", " '{print $7}')
    echo "$line" | grep  "${f1}.*$(expr ${f1:2} + 1).*${f2}.*$(expr ${f2:2} + 1)"
done <file

Пример выполнения

$ ./cmd.bash 
RZ_AUTO_1, 1cx0, C118, B, C119, B, A165, B, A166, B, CC/AA Canonical ribose-zipper
RZ_AUTO_2, 1drz, C118, B, C119, B, A165, B, A166, B, CC/AA Canonical ribose-zipper
RZ_AUTO_3, 1ffk, C208, 0, G209, 0, A665, 0, A666, 0, CG/AA Canonical ribose-zipper

Слабые места

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

-121--248796-

Если вы можете использовать perl :

$ perl -F, -anle '
    map { s/\D//g } @F;
    print if ++$F[2] == $F[4] and ++$F[6] == $F[8];
' file
RZ_AUTO_1, 1cx0, C118, B, C119, B, A165, B, A166, B, CC/AA Canonical ribose-zipper
RZ_AUTO_2, 1drz, C118, B, C119, B, A165, B, A166, B, CC/AA Canonical ribose-zipper
RZ_AUTO_3, 1ffk, C208, 0, G209, 0, A665, 0, A666, 0, CG/AA Canonical ribose-zipper
-121--248795-

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

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

Ниже приведено то, что я обычно делаю для выполнения аналогичных задач:

1) Сначала необходимо уменьшить количество файловых систем в соответствующих разделах, которые будут усечены. Для этого используйте инструмент resize2fs (предполагая, что речь идёт о ext2/ext3/ext4 fs - другие современные FS также имеют инструменты изменения размера для той же цели). Обратите внимание, что хотя по понятным причинам файловая система не может быть больше раздела, в котором она находится, она может быть и меньше. Хитрость безопасности здесь в том, чтобы уменьшить «больше, чем нужно». Например, представьте, что у вас есть файловая система 1TB, которую вы хотите перенести на диск 500 Gig. В этом случае я предлагаю сократить fs до, скажем так, 450 Gig (для этого должно быть достаточно свободного пространства, конечно, т.е. занимаемое в данный момент пространство в этой файловой системе не может превышать 450 Gig). После миграции данных будет исправлено кажущееся потраченное впустую пространство в 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 Gig снова вырастет, чтобы занять весь раздел 500 Gig, и ни один байт не будет потрачен впустую. (Подход «уменьшить больше, чем нужно» позволяет избежать случайного указания размеров и подвергнуть риску ваши данные. Обратите внимание, что единицы GB и GiB могут быть сложными).

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

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

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

2
27.01.2020, 19:51

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

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

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

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

Если вы хотите скопировать только некоторые данные с большого диска на меньший диск, создайте разделы на меньший диск. Если вы хотите скопировать раздел в раздел в том же размере, вы можете сделать это с помощью CAT . Если вы хотите скопировать раздел на меньший раздел, создайте файловую систему в целевой раздел и выполнить копию файла с чем-то вроде CP-A или PAX -RW -PE -T .

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

1
27.01.2020, 19:51

Me gustaría compartir mi experiencia con este tema, en caso de que resulte útil para otro lector. Recientemente utilicé DDRESCUE para recuperar el primer tercio de una partición NTFS de un disco duro que no funcionaba bien y reconstruí con éxito el segmento recuperado de la partición en un disco duro más pequeño -, rescatando así los archivos capturados (y perdiendo el resto ). ¡Los siguientes son los pasos que tomé para hacerlo(definitivamente un enfoque HACKSAW!)...

El disco duro de origen constaba de 750 GB formateados en NTFS con una tabla de archivos MBR. Lo había usado solo unas pocas veces para hacer una copia de seguridad de los archivos, por lo que la mayoría de los archivos estaban al comienzo de la unidad, con un valor aproximado de 160 GB. Un miembro de la familia golpeó el disco duro (montado externamente )contra el piso -¡y nunca funcionó correctamente después de eso! Usando ddrescue (minuciosamente )pude recuperar una gran parte del comienzo de la unidad. Debido al daño físico, se apagó con mucha frecuencia durante todo el proceso...

Tenía un pequeño disco duro de computadora portátil disponible de 150 GB (montado externamente ), del cual extraje los datos de ddrescue directamente. Alternativamente, podría haber extraído los datos a un archivo de imagen y luego haber montado el archivo, sin embargo, pensé que escribir los datos directamente en un disco duro sería más sencillo.

El truco clave para el rescate fue editar manualmente los datos del sector de arranque MBR y NTFS en el disco duro de rescate. Sin hacerlo, ningún sistema operativo reconoce el disco duro. No pude encontrar un programa adecuado en Linux para hacerlo, así que recurrí a Windows. Hay un paquete útil llamado Herramientas de soporte de Windows, que ya no se mantiene, pero sigue siendo útil (, consulte el enlace a continuación ). La herramienta que utilicé para editar la partición es Disk Probe.Asegúrese de conocer el valor del sector final de su disco duro (Usé fdisk -l en Ubuntu)

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

Usando una buena calculadora y algo de creatividad, cargué y monté el disco duro en Disk Probe en Windows y edité los valores del sector final. En el MBR, se tuvieron que cambiar dos conjuntos de valores, a saber, a )el sector final del disco duro yb )el sector final de la partición NTFS. En el Sector de arranque NTFS, el valor de los Sectores totales de la partición tuvo que cambiarse. En cada caso, el valor numérico se redujo para igualar la "dimensión" reducida de los sectores finales del disco duro más pequeño (que cambió de 750 GB a 150 GB ). Haga clic en la pestaña Ver para editar estos valores.

Aquí hay una imagen de Disk Probe en acción editando los datos del sector de arranque NTFSWindows Support Tools - Disk Probe

Al editar los campos antes mencionados, Windows reconoció la partición como una partición válida aunque dañada. Entré en el símbolo del sistema y ejecuté el programa de Windows Chkdsk en el disco duro dañado (chdsk D :). ¡Fue emocionante ver cómo la partición volvía a la vida, archivo por archivo! El programa reconstruyó la tabla de particiones y reasignó con éxito todos los archivos que se habían copiado del disco duro dañado. Los archivos que estaban fuera de rango (no copiados )no se encontraron y, por lo tanto, se eliminaron.

No entiendo el motivo de la siguiente parte, ya que Windows reconstruyó con éxito el disco duro de 150 GB con los archivos incluidos. No obstante, Windows de forma nativa no pudo abrir la partición del disco duro para ver archivos (, hubo algún error ). Sin embargo, ¡Ubuntu al rescate! Reinicié Ubuntu, monté el disco duro externo y, sin ningún problema, ¡aparecieron todos los archivos recuperados!

Con suerte, este método de sierra para metales para recuperar archivos de un disco duro grande en un disco duro más pequeño resultará útil para otra pobre alma además de mí. ¡Salud!

1
27.01.2020, 19:51

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

0
27.01.2020, 19:51

Теги

Похожие вопросы