¿Está el sr. Klaus Fuchs en la sala?, hágale pasar, tenemos un tema delicado entre manos.
--- Fecha: lun 14 ene 2025 16:04:16 CET ---
Mucha gente conoce dd, "Data Duplicator", porque es un viejo comando que lleva con nosotros desde que se inventó la rueda.
Seguramente mucha gente conoce dd, pero porque en algún momento se han cargado los datos de algún disco o pendrive que no debía. Sí, amigos/as/es, yo a dd lo llamo "disk destroyer" porque todo en Linux es tratado como un archivo, para el pingüino, /dev/sda (el disco duro) es un archivo como /home/moribundo/.bashrc. El comando dd machaca todo lo que le pongas por delante, así que:
NOTA: ASEGURATE BIEN de los discos que quieres copiar y ser copiados, o puedes tener problemas serios.
Cuando hay que clonar un disco, hay que asegurarse bien del disco al que copiarás los datos, y para ello hay varias formas.
El primer método es el comando dmesg (diagnostic message) que lista los mensajes del kernel. A veces uso el modo audit: lanzo dmesg y pincho el pendrive donde quiero clonar la ISO de alguna distribución:
NOTA: Este comando debe lanzarse como root
[ 8323.203639] usb 3-1: new high-speed USB device number 10 using xhci_hcd [ 8323.339136] usb 3-1: New USB device found, idVendor=18a5, idProduct=024a, bcdDevice= 1.10 [ 8323.339153] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 8323.339159] usb 3-1: Product: STORE N GO [ 8323.339164] usb 3-1: Manufacturer: Verbatim [ 8323.339168] usb 3-1: SerialNumber: 070B5A63A3F60103 [ 8323.342026] usb-storage 3-1:1.0: USB Mass Storage device detected [ 8323.343375] scsi host6: usb-storage 3-1:1.0 [ 8323.365146] Code: e5 04 fb ff 66 0f 1f 44 00 00 41 55 41 54 55 53 48 83 ec 08 85 f6 0f 8e 8e 01 00 00 49 89 fc 89 f3 83 fe 01 0f 84 90 01 00 00 <8b> 02 48 89 d5 f6 c4 80 75 49 48 8b ba 88 00 00 00 80 3d 48 ad 16 [ 8324.358477] scsi 6:0:0:0: Direct-Access Verbatim STORE N GO PMAP PQ: 0 ANSI: 6 [ 8324.444790] sd 6:0:0:0: [sdc] 30253056 512-byte logical blocks: (15.5 GB/14.4 GiB) [ 8324.445596] sd 6:0:0:0: [sdc] Write Protect is off [ 8324.445604] sd 6:0:0:0: [sdc] Mode Sense: 45 00 00 00 [ 8324.445975] sd 6:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 8324.462464] sdc: sdc1 sdc2 [ 8324.462944] sd 6:0:0:0: [sdc] Attached SCSI removable disk
Todo esa turra de datos realmente me dice que he pinchado un "USB Verbatim" modelo "Store n go" en sdc y que tiene 15 Gb de espacio y además tiene 2 particiones, sdc1 y sdc2
El segundo método, el que más uso, es el comando lsblk que lista los dispositivos de bloques que haya en el sistema.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 931,5G 0 disk ├─sda1 8:2 0 60G 0 part / ├─sda2 8:3 0 4G 0 part [SWAP] └─sda3 8:4 0 817,4G 0 part /home sdb 8:8 0 596,2G 0 disk ├─sdb1 8:9 0 298G 0 part └─sdb2 8:10 0 298,2G 0 part sdc 8:20 1 14,4G 0 disk ├─sdc1 8:21 1 1,1G 0 part /run/media/moribundo/VOID_LIVE └─sdc2 8:22 1 32M 0 part
Como ves, aquí me muestra todos mis dispositivos en modo árbol, de una manera que visualmente es muy intuitiva.
Ahí veo que aparece sdc con 14,5 Gb automontado en /run/media/moribundo/VOID_LIVE
Un tercer método sería lanzar el programa gráfico gparted como root, y daría el mismo resultado. Pero si estás en mitad de un sistema sin entorno gráfico, no podrás usarlo.
Lo que está claro es que mi pendrive USB, que sé que es de 15 Gb, aparece en /dev/sdc, y ya no hay forma posible de equivocación.
Hemos amansado al destructor de discos, convirtiéndolo en lo que realmente es, un duplicador de datos.
NOTA: Recuerda que el principal error de un sistema se encuentra entre la silla y el teclado.
Antes de nada, hay que desmontar el pendrive si ha sido automontado. Se puede copiar en "caliente" pero la copia puede salir corrupta.
Para desmontar se usa el comando umount, y como ves en el listado de lsblk, sdc está montado como sdc1 en /run/media/moribundo/VOID_LIVE.
Puedes desmontar de dos formas:
Puedes usar cualquier otro gestor, como udiskie o los propios gestores de archivos.
Ahora el pendrive sigue existiendo para el kernel, pero no está montado. El comando dd lo va a poder usar igualmente.
La estructura es "Copia" desde "imagen.iso" hacia "pendrive usb":
NOTA: Recuerda que es con una "f", no pongas off con dos "f" o te volverás loco/a/e pensando por qué no funciona. No me ha pasado a mi, me lo han contado...
Al cabo de un rato te devuelve el prompt, pero mientras tanto no sabes qué está pasando. Si quieres un modo "verboso", añade lo siguiente:
Ahora te mostrará los avances que va haciendo.
dd copia en bloques de 512 bytes, que es muy poco, pero se puede ampliar. Has de saber que tamaños de bloque más grandes hacen que la transferencia sea más rápida, sin embargo, tamaños de bloque más pequeños hacen que la transferencia sea más fiable (parecido a la velocidad de escritura de un DVD).
Hay benchmarks que han arrojado que no por poner tamaños de bloque más grandes hay mejor velocidad, de echo, pasado cierto umbral, ya puedes poner 4 MB o 400 MB que te va a dar igual en cuanto a velocidad.
Verás que en algunas webs de las distribuciones indican los parámetros adecuados para la copia; síguelos.
Si no hay indicaciones, leerás en muchos sitios que puedes meterle 4 MB de tamaño de bloque. Yo prefiero ponerle 1 MB (mi grabadora de DVDs permitía 32x y siempre grababa a 16x porque me cansé de tirar DVD inservibles)
Para modificar el tamaño se usa el modificador bs y yo voy a usar 1 MB:
Ahora la copia se hará más rápida que con la opción por defecto.
Para mucha gente el sincronizado de datos parece no ser importante.
Cuando copias datos, muchas veces aparece el mensaje de "Copia finalizada", y cuando te dispones a desmontar el USB, no puedes. Si el pendrive tiene led de copia, ves que sigue parpadeando, ¿por qué?.
La transferencia a un USB es más lenta que de disco a disco. Cuando haces una copia, el sistema envía los datos al dispositivo, pero si este ya no acepta más porque va a tope, el sistema los pasa a caché y va a buscar más. Cuando el USB se desahoga, recupera de la cache los datos, a la espera de que el sistema le envíe más, y vuelta a empezar.
Cuando el sistema finaliza de enviar datos, avisa de que ya ha acabado la copia, porque es verdad, pero realmente el USB sigue copiando datos de la caché.
Si no tienes en cuenta esto puede pasar que saques a la fuerza el pendrive y no esté completa la copia, que corrompas los datos, o peor, que inutilices el pendrive.
Para evitar esto se inventó el comando "sync" que todos/as/es deberíais usar, ya sea con el comando dd, o arrastrando y soltando desde vuestro gestor preferido (estos últimos, si son punteros, ya lo llevan incorporado).
Así pues, voy a copiar una ISO a un pendrive.
NOTA: He añadido el comando sync después de dd en la misma linea, pero también puedes hacer dd primero y sync después.
1146093568 bytes (1,1 GB, 1,1 GiB) copied, 28 s, 40,9 MB/s 1107+1 records in 1107+1 records out 1161789440 bytes (1,2 GB, 1,1 GiB) copied, 31,1471 s, 41,8 MB/s
Al cabo de un rato, los valores que arroja status=progress se paran, parece como si el sistema se hubiera congelado. No te preocupes, es normal, y puede durar un buen rato, es debido a la acción de sync.
Como puede verse, la primera línea me dice que se ha copiado en 28 segundos. Aquí hubiera finalizado todo y yo podría haber intentado desmontar el USB y haber fracasado, o peor, haberlo sacado a lo bruto y haber corrompido la copia.
Pero cuando dd me devuelve el prompt, la segunda linea de tiempo me dice que en realidad han sido 31,1471 segundos, que es lo que ha tardado el pendrive en recuperar los datos de caché, copiarlos y avisar a sync de que ya ha acabado.
En este caso, la ISO es de pocos MBs, pero si hubieran sido de varios GBs, la diferencia de tiempo habría sido mayor. También dependerá del equipo, si usas USB 2.0 o 3.0, etc.
Espero que con este artículo hayas perdido el miedo a dd. Ya sabes, la clave está en identificar bien los discos, y en no ir con prisas.
Tags #dd
=> ◄ Listado de noticias | ◄◄ Inicio This content has been proxied by September (ba2dc).Proxy Information
text/gemini; charset=utf-8