recuperando la partición ext4 después de dd'ing sobre el inicio de HD

Accidentalmente usé ddy escribí sobre los primeros 208MB de mi disco externo. Lo que escribí es una partición por sí sola (instalador de nidos de Debian), así que lo que veo ahora no es mi partición ext4 antigua (ahora dañada) sino otra partición más pequeña. Esto limita las herramientas y consejos que podría seguir.

Mi plan era recrear la tabla de particiones testdisky luego arreglar todo con los superbloques de respaldo como se describe aquí . Perdería los primeros 208 MB, pero está bien en comparación con los otros 300 GB de datos allí. Algo como lo siguiente:

mke2fs -n /dev/sdb1   # doesn't work because sdb1 is the 208MB new partition
testdisk ...          # used this to create new correct partition table
mke2fs -n /dev/sdb1   # now works fine, get backup superblock positions
e2fsck -b backup_position -y /dev/sdb1 # returns many errors hence the -y

Sin embargo, no he podido recuperar nada. Solía testdiskescribir una nueva tabla de particiones que coincidía con lo que tenía antes. Cuando ejecuto e2fsck obtengo muchos errores diferentes. Después de eso obtengo un sistema de archivos pero está completamente vacío, no hay archivos.

El directorio perdido + encontrado está lleno de archivos (creo que los recuperados) pero necesito recuperar el árbol de directorios, no solo los archivos. Necesito el nombre del archivo y los directorios anteriores para saber cuáles son los archivos (imágenes de microscopio, datos de especificaciones de masa, etc. Sin los nombres y los directorios donde estaban, no significan nada).

Obtuve otra HD exactamente igual e hice una copia de toda la HD ddpara poder experimentar la recuperación sin perder nada. ¿Algún consejo?

Finalmente logré arreglar esto. Solo para que conste, así es como lo hice. Parte de la solución que encontré aquí e implica conocer la configuración utilizada para crear el sistema de archivos (estaba bastante seguro de que no cambié los valores predeterminados).

Básicamente tuve por primera vez para fijar la tabla de particiones para reflejar lo que en realidad tenía allí (he usado testdiskpara esto, pero parted, cfdisko fdiskdebería funcionar bien también). Acabo de eliminar las particiones incorrectas y las reemplacé por una única partición de tipo ext4 que cubre todo el disco con los valores CHS correctos.

El resto es principalmente del enlace al inicio (léalo para más detalles) pero básicamente corrí mke2fs -n /dev/xxxpara encontrar las posiciones para la copia de seguridad de superbloques. Luego usé la última copia de seguridad más cercana al final del disco (solo las que estaban al inicio del disco se habían sobrescrito con dd) para ejecutar fsck. Esto generó muchos errores, pero fsck tiene una -yopción (no es lo mismo que -a).

$ sudo e2fsck -a -b backup_block_number /dev/xxx

Pensé que esto no había funcionado porque no podía ver ningún archivo, pero en realidad todos habían sido guardados en el lost+founddirectorio.

Así que al final recuperé la mayoría de mis archivos mientras mantuve sus nombres de archivos y la estructura de directorios. Espero que esto pueda ayudar a otros en el futuro.

Ok, esto funciona para recuperarse de una unidad accidentalmente iniciada en una matriz MegaRAID. Mi controlador RAID introdujo TODAS las unidades en el RAID, no solo las de la matriz RAID6 que estaba rehaciendo. ¡Ay! Al menos hice un inicio rápido, y no un inicio lento: el inicio lento borra el disco a ceros.

Quick init borra 10M al principio y al final de las unidades. Entonces, yo con una partición ext4 en toda la unidad (bajo Linux) y una unidad, RAID0, tuve alguna oportunidad. Como la unidad era una unidad de 6 TB y casi 5 TB, estaba sudando: ¡era mi copia de seguridad de la matriz RAID6 que estaba reformando!

Por cierto, no me resbalé; el LSI MegaRAID NO debería haber instalado unidades en mi otro grupo de unidades, pero lo hizo. Como nota, lo que debería haber hecho es QUITAR LA UNIDAD DE LA CÁMARA Y volver a importarla DESPUÉS de tener el nuevo grupo de unidades RAID6. Tonto de mí. REALMENTE tonto yo ...

OK, afortunadamente, el LSI MegaRaid no hace nada lujoso con las unidades RAID0 (si hay una, supongo que no estoy seguro acerca de las múltiples). Esto es lo que hice para solucionarlo. OS = Fedora F22. Unidad = una gran partición ext4, hecha con parted. Primero tomé la unidad de disco en una unidad nueva, exactamente del mismo modelo, en un servidor de repuesto con un par de ranuras de compartimiento de repuesto :: Diez horas después terminó ...

$ dd if=/dev/sdb of=/dev/sdc bs=64M conv=notrunc
89424+1 records in
89424+1 records out
6001175126016 bytes (6.0 TB) copied, 35130.2 s, 171 MB/s

Ese fue mi respaldo dorado.

NOTA: Mi disco era /dev/sdb: debe configurarlo en el disco que está intentando recuperar. No arruines las unidades, o estarás en un lío aún más ...

Entonces, hecho eso hice lo siguiente.

(1) elimine la instantánea de la máquina (no es una tontería otra vez, puedo asegurarle, que una iría al hospital de recuperación de disco si fallaba, ¡mientras me registraba en la sala de emergencias local!).

(2) reinicie la máquina FC22 con la unidad. Ejecute parted, rehaga la partición (en mi caso, elimine la corrupta, escriba una nueva partición ext4 de 0% a 100%). DEBE saber exactamente dónde estaban las particiones originales y su tipo exacto; el siguiente paso depende de esto; si no, DETÉNGASE AQUÍ. No lo lograrás. use testdisky / photoreco similar, o para un gran disco donde realmente importa, envíelo.

(3) correr mke2fs -n /dev/sdb1(no te olvides -n, o de nuevo puedes irte ...)

Para mí, el resultado se parecía a:

$ mke2fs -n /dev/sdb1
$ mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 1464843008 4k blocks and 183107584 inodes
Filesystem UUID: 1ac318a6-7953-42d5-8d7b-0597c54e1935
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Ahí estás, ahí es donde están todos los superbloques de repuesto ... Sabemos que el primero y el último son basura, pero los del medio deberían estar bien. (Tenga en cuenta que puede mkfs.ext4 -n /dev/sdb1ser muy cauteloso y obtener el mismo resultado).

(4) Corre e2fsck -y -b 102400000 /dev/sdb1. Necesitará el -y, ya que se necesitará mucho "sí" para arreglar el desorden creado por la parte frontal faltante del disco ... y elija cualquier superbloque en el medio que desee ... y después de unos 30 minutos de silencio (use otra terminal y "arriba" para ver el progreso, o la luz del disco parpadeante) en mi caso presto, una partición montable y casi todo intacto en el /lost+founddirectorio.

De todos modos, espero que esto ayude, si estás leyendo esto cuidadosamente, te deseo la mejor de las suertes. Y gracias a los chicos que escribieron arriba. Me salvaste de un final realmente repugnante .....