Comando dd incorrecto en la unidad principal: ¿cómo recuperar datos?

Question

Bien, sucedió algo molestamente estúpido. Quería copiar un archivo ISO de Arch Linux a mi memoria USB, pero tenía prisa y accidentalmente ingresé mi unidad principal como parámetro of.

Aquí están los detalles:

$ sudo dd bs=4MB if=archlinux-2017.08.01-x86_64.iso of=/dev/nvme1n1

/dev/nvme1n1debería haber sido /dev/sdb.

Mi disco principal /dev/nvme1n1contenía dos particiones:

• Una partición de arranque EFI de 512 MB
• Una partición ext4 que abarca el resto de la unidad de 1 TB

El tamaño del archivo archlinux-2017.08.01-x86_64.isoes 541065216 bytes, o516 megas

La computadora todavía está funcionando y parece estar funcionando bien, y tengo el resultado de lsblkydf -h antesejecutando el ddcomando. La salida esexactamente lo mismocomo cuando ejecuto los comandos ahora. Supongo que porque los datos están almacenados en caché:

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme1n1     259:5    0 931.5G  0 disk 
├─nvme1n1p1 259:6    0   512M  0 part /boot
└─nvme1n1p2 259:7    0   931G  0 part /

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme1n1p2  916G   22G  848G   3% /
/dev/nvme1n1p1  511M   36M  476M   7% /boot

ls /boottodavía imprime el contenido del directorio (probablemente información almacenada en caché), pero el contenido del archivo está dañado y se está ejecutando ls /boot/EFIo ls /boot/loaderllena la pantalla con caracteres aleatorios, incluidos muchos Input/output error.

Aquí hay más información:

$ cat /proc/partitions
major minor  #blocks  name

 259        5  976762584 nvme1n1
 259        6     524288 nvme1n1p1
 259        7  976237255 nvme1n1p2

$ sudo fdisk -l /dev/nvme1n1
Disk /dev/nvme1n1: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x282bad86

Device         Boot Start     End Sectors  Size Id Type
/dev/nvme1n1p1 *        0 1056767 1056768  516M  0 Empty
/dev/nvme1n1p2        164  131235  131072   64M ef EFI (FAT-12/16/32)

Al observar el resultado de fdisk, queda bastante claro que la tabla de particiones (y probablemente todos los datos de la partición de inicio) fueron destruidos. Debería ser un gpttipo de etiqueta de disco y los tamaños/tipos de partición son incorrectos. Desafortunadamente, debido al tamaño del archivo ISO (516 MB), también sobrescribió los primeros 4 MB de mi partición raíz.

Una salida ligeramente diferente de gdisk:

$ sudo gdisk /dev/nvme1n1

# selected GPT when asked "Found valid MBR and GPT. Which do you want to use?"

Command (? for help): p
Disk /dev/nvme1n1: 1953525168 sectors, 931.5 GiB
Model: Samsung SSD 960 EVO 1TB                 
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): <guid>
Partition table holds up to 248 entries
Main partition table begins at sector 2 and ends at sector 63
First usable sector is 64, last usable sector is 1056704
Partitions will be aligned on 8-sector boundaries
Total free space is 1 sectors (512 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   2             164          131235   64.0 MiB    0700  ISOHybrid1

Un par de preguntas relacionadas que encontré:

• https://askubuntu.com/questions/94421/hay-una-manera-de-recuperar-archivos-de-un-dispositivo-de-almacenamiento-sobrescrito-parcialmente-con
• Accidentalmente sobrescribí el disco incorrecto con dd, ¿cómo recuperarlo?

Ya instalé la testdiskutilidad, que parece prometedora, pero quiero asegurarme de realizar los pasos correctos.mientras la computadora aún está funcionando. Si lo apago ahora, ya no arrancará, así que aquí están las preguntas:

• ¿Cuál es la mejor manera de recuperarse de esta situación?
• ¿Cómo restauro la tabla de particiones al formato anterior y cómo vuelvo a crear la partición /boot? Estoy ejecutando Arch Linux con el kernel más reciente.
• ¿Hay alguna manera de saber qué estaba contenido (y destruido) en los primeros 4 MB de mi partición raíz?

---

EDITAR: Agregar más información y detalles aquí según la sugerencia de @ WumpusQ.Wumbley de ejecutar el dumpe2fscomando.

El resultado básico (primeras 50 líneas) de dumpe2fs:https://pastebin.com/fBuFRQfE

A mí me parece bastante normal, incluso el número mágico del sistema de archivos ( 0xEF53) es correcto.

A esto le sigue Group 0:

Group 0: (Blocks 0-32767) csum 0x9569 [ITABLE_ZEROED]
  Primary superblock at 0, Group descriptors at 1-117
  Reserved GDT blocks at 118-1141
  Block bitmap at 1142 (+1142)
  Inode bitmap at 1158 (+1158)
  Inode table at 1174-1685 (+1174)
  21349 free blocks, 8177 free inodes, 2 directories, 8177 unused inodes
  Free blocks: 11419-32767
  Free inodes: 16-8192

A lo que luego le siguen MUCHOS grupos que dicen [...]8192 free inodes, 0 directories, 8192 unused inodes [...]El primer grupo que realmente informa sobre algunos directorios no es hasta Group 3648, o alrededor de 25.000 líneas después:

Group 3648: (Blocks 119537664-119570431) csum 0xa9ea [ITABLE_ZEROED]
  Block bitmap at 119537664 (+0)
  Inode bitmap at 119537680 (+16)
  Inode table at 119537696-119538207 (+32)
  23930 free blocks, 1670 free inodes, 614 directories, 1670 unused inodes
  Free blocks: 119546502-119570431
  Free inodes: 29890939-29892608

Hay muchos superbloques de respaldo en todo el sistema de archivos:

$ sudo dumpe2fs /dev/nvme1n1p2 | grep -i superblock | wc -l
dumpe2fs 1.43.5 (04-Aug-2017)
19

Answer 1

Supongo que la tabla de particiones y la partición de arranque se pueden recrear fácilmente, así que me centraré en la partición ext4.

El diseño del sistema de archivos depende en cierta medida de las opciones utilizadas al crearlo. Describiré el caso común. Puede ver si esto coincide con el suyo ejecutándolo dumpe2fsen el dispositivo (que con suerte encontrará todos los metadatos de nivel superior en la memoria caché en lugar de leerlos desde el disco).

El tamaño de bloque normal para los sistemas de archivos ext4 es 4096 bytes, por lo que ha perdido 1024 bloques.

Lo primero que se sobrescribió fue el bloque 0, el superbloque primario. Esto no es un problema en sí mismo, porque hay superbloques de respaldo. Después de eso está la tabla de descriptores de grupo, que también tiene copias de seguridad dentro del sistema de archivos.

Luego están los mapas de bits de bloques y los mapas de bits de inodos. Aquí es donde las noticias empiezan a empeorar un poco. Si alguno de estos está debajo del bloque 1024, que probablemente lo esté, habrá perdido información sobre qué inodos y bloques están en uso. Esta información es redundante y fsck la reconstruirá en función de lo que encuentre al atravesar todos los directorios e inodos, si están intactos.

Pero lo siguiente es la tabla de inodos, y aquí probablemente haya perdido muchos inodos, incluido el directorio raíz, el diario y otros inodos especiales. Será bueno tenerlos de vuelta. Obviamente, al menos el directorio raíz sigue funcionando, o casi todos los comandos que intente ejecutar ya estarían fallando.

Si ejecuta dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024ahora, obtendrá una copia de seguridad de lo que esté actualmente en su caché, mezclada con los datos incorrectos de los bloques que no están almacenados en caché. Luego, después de iniciar un disco de rescate, puede hacer lo mismo dda la inversa, para volver a colocar esos datos parcialmente buenos en el disco, sobrescribiendo todo el material malo que está allí ahora.

Después de esto, es posible que las herramientas de recuperación automatizadas ( fsck, testdisk) funcionen bastante bien. De lo contrario, tiene un mapa que puede utilizar para ayudar con la recuperación manual. Usando las listas de "bloques libres" de dumpe2fs, sabrás qué bloques ignorar.

La mayor parte de lo que perdiste probablemente sean inodos. En realidad, es bastante probable que no tuvieras ningún archivo.contenidoen los primeros 4MB del disco. (Ejecuté mkfs.ext4sin opciones en un archivo de imagen de 1 TB y el primer bloque que no era metadatos resultó ser el bloque 9249)

Cada inodo que logres recuperar identificará los bloques de datos de un archivo completo. Y esos bloques de datos pueden estar ubicados por todo el disco, no necesariamente cerca.

Dia 2

El volcado publicado en Pastebin revela una gran noticia:

Group 0: (Blocks 0-32767) csum 0x9569 [ITABLE_ZEROED]
  Primary superblock at 0, Group descriptors at 1-117
  Reserved GDT blocks at 118-1141
  Block bitmap at 1142 (+1142)
  Inode bitmap at 1158 (+1158)
  Inode table at 1174-1685 (+1174)
  21349 free blocks, 8177 free inodes, 2 directories, 8177 unused inodes
  Free blocks: 11419-32767
  Free inodes: 16-8192

Como creemos que solo se han sobrescrito 4 MB al inicio del sistema de archivos, solo debemos preocuparnos por los bloques 0-1023. ¡Y los bloques GDT reservados llegan hasta el bloque 1141! Este es el tipo de daño que debe repararse con una simple operación e2fsck -b $backup_superblock_number(después de reiniciar). Al menos podrías intentarlo para -nver qué piensa.

Answer 2

Si el disco usaba GPT, la tabla de particiones debería poder recuperarse utilizando los datos GPT de respaldo al final del disco. Puedes hacer esto con gdisk; verla gdiskdocumentación sobre recuperación de datospara detalles. En resumen: cuando inicie gdisken el disco, seprobablementeobserve el daño y le pregunte si desea utilizar los datos GPT de respaldo o los datos MBR. Si elige la opción GPT y luego escribe los cambios, la tabla de particiones se arreglará. Si gdiskno se le pregunta qué tabla de particiones usar, es posible que aún pueda cargar la tabla de respaldo usando la copción en el menú de recuperación y transformación.

Si esto falla, aún puede volver a crear la tabla de particiones (o al menos, los puntos de inicio y finalización de las particiones) utilizando los datos en los archivos /sys/block/nvme1n1/nvme1n1p1/starty /sys/block/nvme1n1/nvme1n1p1/size(y de manera similar para /dev/nvme1n1p2). Sin embargo, si recurre a estos datos, es imperativo queNOapague la computadora, al contrario de lo que recomendó hek2mgl. Dicho esto, hek2mgl no se equivoca al decir que seguir usando el disco en su estado actual corre el riesgo de empeorar las cosas. En general, diría que el mejor compromiso es intentar solucionar el problema de la tabla de particiones lo más rápido posible y luego cerrar y solucionar el problema del sistema de archivos desde un disco de emergencia.

Desafortunadamente, tu ESP está acabado. Dado el diseño de su disco, supongo que montó el ESP /booty almacenó sus núcleos allí. Por lo tanto, necesitarás reinstalar los paquetes del kernel usando chrootalgún otro medio. Lo mismo ocurre con su gestor de arranque o administrador de arranque.

Answer 3

1. Apague la computadora (inmediatamente)
2. Arranque con un sistema de rescate.
3. Ejecute testdiskpara intentar recuperar sus datos. (Si tiene suficiente espacio, tome una imagen del dispositivo que usa ddy ejecútela testdisken esa imagen)

¿Por qué debería apagar la computadora inmediatamente? Si se creará un nuevo archivo (algo en /run probablemente) o se agregará a (/var/log/...), entonces el sistema de archivos necesita observar la información existente (¡mala!) para decidir dónde almacenar los datos. Cuando esta decisión se toma basándose en información errónea, existe un alto riesgo de que se sobrescriban los bloques de datos existentes. Eso los hace perderse para siempre. Incluso para herramientas como testdisky photorec.