¿Se puede usar 'dd' para clonar en un HDD más pequeño, sabiendo que las particiones necesitarán edición?

Solía ddclonar discos como este:

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

Y siempre ha funcionado bien. Todos y cada uno de los documentos en 'dd' se esfuerzan para recordarle que el disco de destino debe ser del mismo tamaño o más grande que la fuente. ¿Eso tiene que ser absolutamente cierto?

Ahora, entiendo bastante bien que si clono en un disco más pequeño, no puedo esperar que ninguna partición que esté parcialmente 'fuera de límites' en el objetivo esté intacta.

Sin embargo, sabiendo muy bien que necesitaría editar mis particiones en el objetivo más tarde, eliminando las 'fuera de límites', ¿podría usar 'dd' para hacer una copia de la fuerza bruta de la fuente hasta los límites de la tamaño físico del objetivo? O 'dd' reduciría el objetivo a una pila humeante de restos cuando alcanzara el límite de su tamaño ;-)

Por cierto, la investigación de este, he visto los valores recomendados para bs=todo, desde bs=1024hasta bs=32M, lo que es realmente mejor?

El disco físico no debería comenzar a fumar, al menos, pero es muy probable que su sistema de archivos ya no funcione (es decir, el sistema de archivos de destino; si solo copió y no tocó nada en la fuente, la fuente en sí debería estar bien ) Los datos dentro de una partición no se asignan necesariamente en orden creciente. Algo de esto puede estar al final de la partición, incluso si la partición no está llena (en realidad, creo que esto sucede de manera determinista con algún sistema de archivos, pero no sé lo suficiente para obtener los detalles). Los datos allí pueden ser esenciales para la integridad del sistema de archivos. Por lo tanto, le recomiendo encarecidamente que no confíe en esa copia.

Si desea hacer esta copia, primero debe reducir la partición con alguna herramienta que tenga en cuenta su estructura interna y que pueda reasignar todo en buen orden en una partición más pequeña. Entonces puedes hacer la copia. gpartedes una buena interfaz GUI para hacer este tipo de cosas.

Por el bsvalor, por lo general, la mejor idea es tener un par de pruebas antes de comenzar la copia real. Existen algunas herramientas que lo ayudan a automatizar esta verificación, pero no recuerdo el nombre. En mi experiencia, el mejor rango suele ser entre 4M y 16M. Más alto que eso, ya no ganas mucho. Pero depende de muchas cosas, incluidos los discos mismos. Por ejemplo, rara vez trabajé con discos reales de gama alta, que pueden ser adecuados para valores más altos debido a una mayor velocidad y tamaño de caché.

EDITAR Si una partición se copia por completo, puede usarla sin problemas. Sin embargo, como otros han subrayado, también debe asegurarse de que la tabla de particiones esté intacta (al menos, las entradas relevantes). Con las cuatro particiones primarias de MBR no hay problemas, ya que se describen en los primeros 512 bytes del disco. Las particiones lógicas se describen en toda la partición extendida, por lo que las entradas pueden perderse (pero describirían particiones que se perderían de todos modos). Con GPT hay una copia de la tabla de particiones tanto al principio como al final del disco. Pierdes el segundo, pero puedes reconstruirlo a partir del primero. Por supuesto, es aconsejable hacerlo lo antes posible; otras respuestas fueron más precisas con respecto a eso.

Aunque al principio el "desafío" propuesto puede parecer difícil, no factible o ingenuo como algunos han comentado, no lo es. La idea principal detrás del uso de dd para migrar de un disco más grande a uno más pequeño está perfectamente bien y tiene beneficios para migrar los datos. Por supuesto, tener un espacio libre suficiente para que los datos ocupados quepan en el disco de destino es un requisito necesario.

La idea es pensar en dd'ing cada partición individualmente y no todo el disco a la vez como se propuso inicialmente. Se puede lograr aún más: las particiones que se truncarían también se pueden migrar de forma segura con un poco de ayuda de las herramientas de cambio de tamaño del sistema de archivos. De hecho, este tipo de migración es interesante para preservar los matadatos del sistema de archivos y los atributos de archivo extendidos que no se pueden copiar fácilmente con herramientas como cp, rsync, pax, ... que operan en la capa del sistema de archivos y no bloquean la capa del dispositivo. El uso de dd elimina la necesidad de reinstalar el sistema operativo o tener que volver a etiquetar el FS para evitar problemas con SELinux.

A continuación se muestra lo que suelo hacer para realizar tareas similares:

1) Primero debe reducir los sistemas de archivos dentro de las particiones afectadas que se truncarían. Para esto, use la herramienta resize2fs (suponiendo que estamos hablando de una fs ext2 / ext3 / ext4; otras FS modernas también tienen herramientas de redimensionamiento para el mismo propósito). Tenga en cuenta que aunque, por razones obvias, un sistema de archivos no puede ser más grande que la partición en la que reside, puede ser más pequeño de forma segura. El truco de seguridad aquí es reducir "más de lo necesario". Por ejemplo: imagine que tiene un sistema de archivos de 1TB que desea migrar a una unidad de 500 Gig. En este caso, sugiero reducir el fs a, digamos, 450 Gig (por supuesto, debe tener suficiente espacio libre para esto, es decir, el espacio actualmente ocupado en este sistema de archivos no puede exceder los 450 Gig). El aparente desperdicio de 50 Gig de espacio se solucionará después de la migración de datos.

2) Particionar el disco de destino con la geometría apropiada considerando sus limitaciones de espacio;

3) dd los datos usando los dispositivos de partición y no el dispositivo de disco (es decir, use dd if=/dev/sda# of=/dev/sdb#para cada partición en lugar de usar if=/dev/sda of=/dev/sdb). NOTA: sda y sdb aquí son solo ejemplos; NOTA IMPORTANTE: Al pasar de un dispositivo de partición más grande a uno más pequeño, dd se quejará de intentar escribir una publicación al final del dispositivo de bloque, eso está bien ya que los datos del sistema de archivos se habrían copiado por completo antes de llegar a ese punto. Para evitar este mensaje de error, puede especificar el tamaño de la copia usando bs=y count=parámetros para que coincida con el tamaño del sistema de archivos reducido, pero esto requerirá un cálculo (simple), pero si se hace incorrectamente puede arriesgar sus datos.

4) Después de modificar los datos, cambie el tamaño de los sistemas de archivos respectivos dentro de las particiones de destino nuevamente usando resize2fs. Esta vez no especifique el nuevo tamaño del sistema de archivos. Cuando se ejecuta sin una especificación de tamaño, resize2fs hace crecer el sistema de archivos para que ocupe el tamaño máximo permitido, por lo que, en este caso, el sistema de archivos de 450 Gig volverá a crecer para ocupar toda la partición de 500 Gig y no se perderá ningún byte. (El enfoque de "reducir más de lo necesario" le evita especificar accidentalmente tamaños incorrectamente y arriesgar sus datos. Tenga en cuenta que las unidades GB frente a GiB pueden ser complicadas).

Nota para operaciones más complejas: si tiene un administrador de arranque que tiene la intención de copiar, lo cual es muy probable que sea el caso, puede eliminar los primeros KB del disco utilizando el dispositivo de disco en lugar de los dispositivos de partición (como dd if=/dev/sda of=/dev/sdb bs=4096 count=5), y luego reconfigure la geometría en / dev / sdb (que contendrá temporalmente una geometría no válida para la nueva unidad pero un administrador de arranque intacto y válido). Finalmente, continúe usando los dispositivos de partición como se describió anteriormente para realizar una partición a la vez. Hice operaciones como esta muchas veces. Recientemente, realicé con éxito una migración compleja cuando actualicé desde un HDD que contenía una combinación de instalaciones MacOSX y Linux a un SDD más pequeño en mi MacMini6,2. En este caso, tuve que arrancar Linux desde una unidad externa, ejecuté el gestor de arranque, ejecuté gdisk para arreglar el GPT en el nuevo disco y finalmente eliminé cada partición que contenía los archivos de archivos recién encogidos. (Tenga en cuenta que el esquema de partición GPT mantiene dos copias de la tabla de particiones, una al principio y otra al final del disco. gdisk se queja mucho porque no puede encontrar la segunda copia del PT y porque las particiones exceden el tamaño del disco, pero soluciona correctamente el problema de la copia del PT después de redefinir la geometría del disco). Este fue un caso mucho más complejo, pero vale la pena mencionarlo porque ilustra que este tipo de operación también es perfectamente factible.

¡Buena suerte! ... y lo más importante, recuerde hacer una copia de seguridad de todos los datos importantes antes de este tipo de operación. Un error y seguramente puede dañar sus datos irremediablemente.

Y en caso de que no haya enfatizado lo suficiente: ¡haga una copia de seguridad de sus datos antes de la migración! :)

Si desea colocar un automóvil en un pasadizo que es 20 cm más estrecho que el automóvil y corta los 20 cm izquierdos del automóvil, ¿seguirá funcionando? Probablemente no.

Si copia el comienzo de un disco a otro disco y corta la copia porque el disco de destino es más pequeño, el resultado no funcionará. Incluso si hubiera suficiente espacio para todos los archivos en el disco de destino, cortar después de N bytes desde el inicio del disco no le dará un sistema de archivos que funcione.

Si el disco está dividido en particiones estilo PC (GPT o MBR), funcionarán todas las particiones que quepan completamente en el destino. Hay una excepción: con las particiones MBR, si las particiones lógicas no están numeradas en orden de disco, tan pronto como la cadena abandone el área de destino, las particiones ya no aparecerán en la lista. (Si no comprende esto, esa es una razón más para no hacer una copia parcial del disco). Tendría mucho más sentido copiar las particiones que desea conservar, en lugar de copiar desde el principio y terminar con lo que sea apropiado . La partición parcialmente copiada al final no será utilizable.

Si el disco o una partición parcial es un volumen físico LVM, y usted hace una copia parcial de ese volumen físico, tampoco puede estar seguro de obtener datos útiles del resultado.

Si desea copiar solo algunos de los datos de un disco grande a un disco más pequeño, cree particiones en el disco más pequeño. Si desea copiar una partición a una partición del mismo tamaño, puede hacerlo con cat. Si desea copiar una partición en una partición más pequeña, cree un sistema de archivos en la partición de destino y haga una copia a nivel de archivo con algo como cp -ao pax -rw -pe -t.

Puedes usarlo en ddlugar de catsi eres un masoquista. ddtiene una sintaxis extraña y suele ser más lenta que acat menos que encuentre el tamaño correcto de búfer. No existe un valor óptimo único para el tamaño del búfer, depende de las características de su hardware. Si el tamaño es demasiado pequeño, ddperderá tiempo haciendo muchas transferencias pequeñas. Si el tamaño es demasiado grande, ddperderá tiempo leyendo completamente un búfer antes de comenzar a escribir el siguiente. El tamaño óptimo para una transferencia de disco a disco suele ser de unos pocos megabytes (1024 bytes es ridículamente pequeño). catelegirá un tamaño decente sin ningún esfuerzo de su parte.

Me gustaría compartir mi experiencia con este tema, si esto resulta útil para otro lector. Recientemente utilicé DDRESCUE para recuperar el primer 1/3 de una partición NTFS de un disco duro defectuoso 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é al 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 de aproximadamente 160 GB. Un miembro de la familia golpeó el disco duro (montado externamente) en el piso, ¡después de eso nunca funcionó correctamente! Usando ddrescue (minuciosamente) pude recuperar una gran parte del comienzo de la unidad. Debido al daño físico, se apaga con mucha frecuencia durante todo el proceso ...

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

El truco clave para el rescate fue editar manualmente tanto el MBR como los datos del sector de arranque NTFS en el disco duro de rescate. Sin hacerlo, el disco duro no es reconocido por ningún sistema operativo. 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 que sigue siendo útil (vea 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

Utilizando 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, el sector final del disco duro yb) el sector final de la partición NTFS. En el sector de arranque NTFS, el valor de Sectores totales de la partición tuvo que cambiarse. En cada caso, el valor numérico se redujo para coincidir con la "dimensión" disminuida del disco duro más pequeño (los sectores finales cambiaron 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 NTFS

Al editar los campos antes mencionados, Windows reconoció la partición como una partición válida aunque dañada. Ingresé al símbolo del sistema y ejecuté el programa de Windows Chkdsk en el disco duro dañado (chdsk D :). ¡Fue emocionante ver que 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.

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

Esperemos que este método de sierra para recuperar archivos de un disco duro grande en un disco duro más pequeño resulte útil para alguna otra alma pobre además de mí. ¡Salud!

Primero debe reducir las particiones en la fuente (o eliminarlas fuera de los límites).
De ddy después de que probablemente tendrá que reparar la tabla de particiones mediante el uso gdisk /dev/sd<target>
y la secuencia de teclas para reparar la tabla es v r d w
lo que sugeriría Shring las particiones un poco más pequeño de lo necesario y después expandirse de nuevo al tamaño completo del disco de destino.
(Esta respuesta se basa en mi experiencia personal al clonar mi HDD en una SSD más pequeña)