Recuperación de una partición completa que ha sido formateada de alguna manera (en serio desordené un sistema de archivos externo de HD)

0

Tengo un problema embarazoso pero muy urgente. Un amigo mío me pidió que configurara su nuevo HD externo para Time Machine y el almacenamiento de archivos, y que transfiriera los archivos de su HD anterior. Comencé a particionar la nueva unidad con la Utilidad de Discos, pero la opción de partición estaba atenuada. Todo el disco estaba formateado como exFat, así que pensé en formatearlo como HFS +. Comencé a hacerlo con diskUtil: diskUtil erasedisk hfs+ External /dev/disk2 (Nota: esto está en una Macbook Pro que ejecuta El Capitán)

Sin embargo, escribí mal. La nueva unidad no era disk2, era disk3. En su lugar, había empezado a borrar el disco antiguo, que contiene datos importantes. Me di cuenta de mi problema en un instante y ^C d salí de allí, pero el daño ya estaba hecho. Aquí está el sitch:

  • La salida del terminal dice:

    Starting erase on disk2
    Unmounting disk
    diskutil:interrupted
    $ diskUtil list
    ...
    /dev/disk2 (external, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *1.0 TB     disk2
       1:                        EFI EFI                     209.7 MB   disk2s1
       2:                  Apple_HFS                         999.8 GB   disk2s2
    
  • Como puede ver, OSX reconoce la unidad como GPT y la partición como HFS +. Sin embargo, la unidad no se mostrará en el Finder.

  • Windows (10) reconoce que tengo un HD externo conectado, pero no aparece nada en "Volúmenes" cuando veo su dispositivo en el Administrador de dispositivos.
  • Linux (Arch) reconoce la unidad y la partición, al igual que OSX. Intenté ejecutar ntfsfix, pero fue en vano. (Me dio una advertencia que decía algo acerca de no poder solucionarlo e intentar usar chkdsk).
  • No estoy 100% seguro de cuál era el estado de este HD antes de formatearlo a medias. Se usó por primera vez y se le dio formato a una computadora portátil Windows barata cuando Vista era el sistema operativo más nuevo de Windows, por lo que pensaría que era NTFS en un esquema MBR antes de violarlo. (Quizás me equivoque y alguien sepa mejor, pero eso es lo que me han hecho creer).

De todos modos, aquí estoy. Necesito recuperar unos 700 GB de datos, tal vez NTFS / MBR, en una unidad que piensa que es HFS + / GPT. Todos los datos deben estar allí, más o menos al menos, pero necesito ayuda para acceder a ellos. Si tiene alguna idea o conocimiento que pueda ayudarme, realmente lo apreciaría.

(Por último, descargué e instalé un software de recuperación de datos de Easeus. Se está ejecutando un "escaneo" en la unidad, y sospecho que solucionará mi problema si entrego más de $ 90. Esto es solo una Sin embargo, como último recurso, realmente preferiría que este dolor de cabeza no se vuelva costoso, y dado que está recogiendo una gran cantidad de datos, sé que debe haber una manera de resolver esto con algo de codo.)

    
pregunta cogeary 26.08.2016 - 04:21

2 respuestas

1

Debería poder restaurar al menos los límites del antiguo volumen NTFS:

Windows (como OS X) usa algunos esquemas de partición predeterminados para particionar y formatear un disco.

Un disco MBR / NTFS generalmente tiene un MBR en el primer bloque (block0). La primera partición generalmente comienza en el límite de 1 MB (bloque 2048) con un bloque especial, el Sector de arranque NTFS, y termina con un bloque especial. Ambos bloques comienzan con EB 52 90 4E 54 46 53 20 (hex) o ∂RENTFS (x20) . Los últimos 4096 bloques (2 MiB) suelen ser espacios vacíos.

Dependiendo de cuánto se haya escrito al crear ("borrar") el nuevo volumen principal de HFS + (generalmente entre 120 y 160 MB después de que finalice el proceso) el éxito de una recuperación de datos puede variar.

¡Desconecta cualquier unidad externa excepto la que está rota!

Para recuperar los antiguos límites de volumen NTFS, debe eliminar la tabla de particiones GUID y restaurar un esquema de partición MBR:

Para eliminar el GUIDpt, primero abra Terminal.app y obtenga una visión general (a continuación asumo que el identificador de disco del disco con formato falso es disk2):

diskutil list
sudo gpt -r show disk2

El resultado es similar al de abajo (su tamaño total - aquí 1953525760 bloques y el volumen principal - aquí 1952853936 bloques - puede diferir ligeramente):

         0          1         PMBR
         1          1         Pri GPT header
         2         32         Pri GPT table
        34          6         
        40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
    409640 1952853936      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
1953263576     262151         
1953525727         32         Sec GPT table
1953525759          1         Sec GPT header

Eliminar el GUIDpt:

diskutil umountDisk disk2
sudo gpt destroy disk2 
dd if=/dev/zero of=/dev/disk2 bs=512 count=1

Busca en el disco la cadena ∂RENTFS (x20) en los últimos sectores del disco:

hexdump -s 930g /dev/rdisk2  | grep "eb 52 90 4e 54 46 53 20"

-s: omite los bytes de desplazamiento desde el principio de la entrada. El tamaño es KiB / MiB / GiB. En mi ejemplo, el disco tiene un tamaño de 931.51 GiB, por lo que busqué solo en los últimos 1.51 Gib.

El resultado es e8e0bffe00 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 con e8e0bffe00 siendo el desplazamiento en hexadecimal. Convertido con un hex2dec service esto significa un desplazamiento de 1000203091456 (dividiendo esto por 512, el resultado es igual a bloque 1953521663).

Dado que este bloque es el último en el volumen anterior, puede determinar el tamaño del volumen anterior: 1953521663 (último bloque) - 2048 (bloque de inicio probable) + 1 (el conteo comienza con 0). ¡El resultado debe ser divisible por 8!

También puede verificar los primeros bloques del disco con:

hexdump /dev/rdisk2  | grep "eb 52 90 4e 54 46 53 20"

Debería obtener al menos una línea como esta: 800 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 . Este es el sector de arranque NTFS en el bloque 2048, el límite de 1 MB, ya que la Utilidad de Discos generalmente no borra estos bloques. Ingrese ctrl C para detener el volcado hexadecimal.

Ahora que tiene el primer bloque y el último bloque del volumen NTFS, debería poder restaurar la antigua partición MBR con fdisk:

fdisk -e /dev/disk2
Would you like to initialize the partition table? [y] y
fdisk:*1> auto dos
fdisk:*1> edit 1
     Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
*1: 0C    0   1   1 - 1023 254  63 [        63 - 1953525697] Win95 FAT32L
Partition id ('0' to disable)  [0 - FF]: [C] (? for help) 07
Do you wish to edit in CHS mode? [n] n
Partition offset [0 - 1953525760]: [63] 2048 #probable start of the NTFS volume
Partition size [1 - 1953523712]: [1953523712] 1953519616 #use the probable size of YOUR NTFS volume found previously here.
fdisk:*1> write
Writing MBR at offset 0.
fdisk: 1> q

Ahora puede tener suerte y el volumen NTFS simplemente aparece o tiene que usar una herramienta de recuperación de datos.

    
respondido por el klanomath 26.08.2016 - 11:15
0

¿Se puede probar CGSecurity testdisk?) enlace

Simplemente porque tengo mucho tiempo para restaurar datos a este programa Este proyecto tiene - aplicación testdisk para la partición de recuperación y los datos en las particiones - aplicación de photorec para recuperar datos perdidos de una unidad flash

    
respondido por el iTux 26.08.2016 - 13:16

Lea otras preguntas en las etiquetas