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

Question

Solía dd​​​​clonar 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 por recordarle que el disco de destino debe ser del mismo tamaño o más grande que el de origen. ¿Eso tiene que ser absolutamente cierto?

Ahora entiendo perfectamente que si clono en un disco más pequeño no puedo esperar particiones iguales.parcialmente "fuera de límites" para que el objetivo esté intacto.

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

Por cierto, al investigar esto, he visto valores recomendados para bs=todo, desde bs=1024hasta bs=32M, ¿qué es realmente mejor?

Answer 1

Como otros han mencionado aquí, el uso simplemente ddno funcionará debido a la copia de la tabla GPT colocada al final del disco.

Logré realizar una migración a una unidad más pequeña usando el siguiente método:

Primero: inicie la distribución LiveCD de su elección.

Cambie el tamaño de las particiones de la unidad de origen para que se ajusten a las limitaciones de la unidad más pequeña (usando, gpartedpor ejemplo). Luego, asumiendo sdaque es el disco de origen, usando sgdisk, primero cree una copia de seguridad de la tabla GPT desde la unidad de origen para estar seguro: `

    sgdisk -b=gpt.bak.bin /dev/sda

Suponiendo sdbque es el destino, replica la tabla desde la unidad de origen al destino:

    sgdisk -R=/dev/sdb /dev/sda

sgdiskAhora se quejará de que intentó colocar la copia del encabezado fuera de los límites del disco de destino, pero luego retrocederá y colocará el encabezado correctamente en el límite superior del disco de destino.

Verifique que se haya creado un clon correcto de la tabla de particiones en la unidad de destino utilizando la herramienta de su elección ( gpartedpor ejemplo).

Usando dd, copie cada partición de la unidad de origen al destino:

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...

Obviamente, si mezclas los nombres de las unidades al replicar la tabla de particiones GPT sin una copia de seguridad o al ddcopiar el contenido, puedes despedirte de tu contenido :)

Answer 2

La unidad física no debería empezar a echar humo, al menos, pero hay muchas posibilidades de que su sistema de archivos ya no funcione (es decir, el sistema de archivos de destino; si simplemente copió y no tocó nada en la fuente, la fuente en sí debería estar bien). ). Los datos dentro de una partición no necesariamente se asignan en orden creciente. Parte puede estar al final de la partición incluso si la partición no está llena (de hecho, creo que esto sucede de manera determinista con algunos sistemas de archivos, pero no sé lo suficiente como para entrar en 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 dicha copia.

Si desea hacer esta copia, primero debe reducir la partición con alguna herramienta que conozca su estructura interna y sea capaz de 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, normalmente la mejor idea es realizar un par de pruebas antes de comenzar con la copia real. Existen algunas herramientas que te ayudan a automatizar esta verificación, pero no recuerdo el nombre. En mi experiencia, el mejor rango suele estar entre 4M y 16M. Por encima de eso ya no se gana mucho. Pero depende de muchas cosas, incluidos los propios discos. Por ejemplo, rara vez trabajé con discos reales de alta gama, que pueden ser adecuados para valores más altos debido a la mayor velocidad y tamaño de caché.

EDITARSi una partición está completamente copiada, podrá utilizarla sin problemas. Sin embargo, como han subrayado otros, 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 están descritas 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 desde el primero. Por supuesto, es aconsejable hacerlo lo antes posible; otras respuestas fueron más precisas al respecto.

Answer 3

Aunque en un principio el “reto” propuesto pueda parecer difícil, inviable o sonar 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 suficiente espacio libre para que los datos ocupados quepan en el disco de destino es un requisito necesario.

La idea es pensar en agregar 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 archivos 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, ha reducido los sistemas de archivos dentro de las particiones afectadas que se truncarían. Para esto, use la herramienta resize2fs (asumiendo que estamos hablando de un fs ext2/ext3/ext4; otros FS modernos también tienen herramientas de cambio de tamaño 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 con seguridad. El truco de seguridad aquí es reducir "más de lo necesario". Por ejemplo: imagina que tienes un sistema de archivos de 1 TB que deseas migrar a una unidad de 500 Gigas. En este caso, sugiero reducir fs a, digamos, 450 Gigas (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 Gigas). Los 50 Gigas de espacio aparentemente desperdiciados se solucionarán después de la migración de datos.

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

3) agregue los datos utilizando los dispositivos de partición y no el dispositivo de disco (es decir, utilícelos dd if=/dev/sda# of=/dev/sdb#para cada partición en lugar de utilizar if=/dev/sda of=/dev/sdb). NOTA: sda y sdb aquí son sólo ejemplos; NOTA IMPORTANTE: Al realizar dd desde 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 tipo de mensaje de error, puede especificar el tamaño de la copia utilizando parámetros bs=y count=para que coincidan con el tamaño reducido del sistema de archivos, pero esto requerirá algunos cálculos (simples), pero si se hace incorrectamente puede poner en riesgo sus datos.

4) Después de agregar los datos, cambie el tamaño de los respectivos sistemas de archivos 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 Gigas crecerá nuevamente para ocupar toda la partición de 500 Gigas y no se desperdiciará ningún byte. (El enfoque de "reducir más de lo necesario" evita que accidentalmente especifique tamaños incorrectos y arriesgue 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 desea copiar, lo cual es muy probable que sea el caso, puede agregar los primeros KB del disco usando 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, proceda a utilizar los dispositivos de partición como se describe anteriormente para agregar una partición a la vez. Hice operaciones como esta muchas veces. Recientemente, realicé con éxito una migración compleja al actualizar desde un disco duro que contenía una combinación de instalaciones de MacOSX y Linux a un SDD más pequeño en mi MacMini6,2. En este caso, tuve que iniciar Linux desde una unidad externa, agregar el administrador de arranque, ejecutar gdisk para arreglar el GPT en el nuevo disco y finalmente agregar cada partición que contenía los sistemas de archivos recién reducidos. (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 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 realizar este tipo de operación. Un error y seguramente puedas dañar tus datos de forma irrecuperable.

Y por si acaso no lo enfaticé lo suficiente: ¡haga una copia de seguridad de sus datos antes de la migración! :)

Answer 4

Me gustaría compartir mi experiencia con este tema, por si resulta útil para otro lector. Recientemente uséDRESCATEpara recuperar el primer tercio de una partición NTFS de un disco duro defectuoso y reconstruyó 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 de 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 copias de seguridad de archivos, por lo que la mayoría de los archivos estaban al comienzo del disco, con un valor de aproximadamente 160 GB. Un miembro de la familia tiró el disco duro (montado externamente) al suelo; ¡nunca volvió a funcionar correctamente después de eso! Usando ddrescue (minuciosamente) pude recuperar una gran parte del comienzo del viaje. Debido al daño físico, se apagó con mucha frecuencia durante todo el proceso...

Tenía un disco duro de computadora portátil pequeño disponible de 150 GB (montado externamente), al que extraje los datos de ddrescue directamente. Alternativamente, podría haber extraído los datos a 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 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. De lo contrario, ningún sistema operativo reconocerá 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 que 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 (yo 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, se tuvo que cambiar el valor de los sectores totales de la partición. En cada caso, el valor numérico se redujo para igualar la "dimensión" reducida 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 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 desde el disco duro dañado. Los archivos que estaban fuera del 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 no pudo abrir de forma nativa la partición del disco duro para ver 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!

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