El disco duro USB de mi esposa tiene un pequeño problema cuando una carpeta se niega a abrirse (sistema de archivos NTFS). Pude crear una imagen de la unidad con Linux, pero para un sector (los sectores tienen 4096 bytes). La lectura de ese sector falla:
sudo dd if=/dev/sdb of=bloque skip=21647245 bs=4096 count=1 dd: error al leer '/dev/sdb': error de entrada/salida 0+0 registros en 0+0 registros eliminados 0 bytes (0 B) copiados, 22,9317 s, 0,0 kB/s
Reemplazar este sector con bytes nulos genera el mismo síntoma que en Windows, por lo que el sector parece estar relacionado con el directorio problemático.
Al acceder a dicho sector, la salida dmesg dice:
[20381.842495] sd 7:0:0:0: [sdb] Código de detección no controlado [20381.842506] sd 7:0:0:0: [sdb] [20381.842510] Resultado: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE [20381.842514] sd 7:0:0:0: [sdb] [20381.842517] Tecla de detección: Error de hardware [actual] [20381.842531] sd 7:0:0:0: [sdb] [20381.842535] Agregar. El sentido: No hay información sensorial adicional [20381.842539] sd 7:0:0:0: [sdb] CDB: [20381.842542] Lectura(10): 28 00 01 4a 4f 8d 00 00 01 00 [20381.842557] end_request: error de E/S, dev sdb, sector 173177960 [20381.842572] Error de E/S del búfer en el dispositivo sdb, bloque lógico 21647245
¿Hay alguna manera de leer este sector, sin formato, sin verificación CRC o lo que sea para intentar recuperar algunos de los datos corruptos?
Abrí la caja: el disco duro es USB nativo, no hay conversión de USB a SATA.
Editar: Intenté ddrescue, pero tampoco he podido recuperar el sector defectuoso. Leyendo 2Gigs alrededor del sector malo deja que las cabezas se estabilicen después de la búsqueda:
sudo ddrescue -s 2Gi -o 0 -i 87593373696 /dev/sdb blkk GNU ddrescue 1.19 Presione Ctrl-C para interrumpir rescatado: 2147 MB, tamaño de error: 4096 B, velocidad actual: 0 B/s ipos: 88667 MB, errores: 1, velocidad promedio: 8488 kB/s opos: 1073 MB, tiempo de ejecución: 4,21 m, lectura exitosa: hace 1,06 m Finalizado
La lectura hacia atrás (indicador -R) también falló.
Edición 2:Mi segundo paso planeado era utilizar técnicas forenses para intentar encontrar los archivos faltantes. Primero comencé a mirar el MFT a mano, pero esto rápidamente se vuelve muy, muy tedioso. Entonces tenía las siguientes herramientas en mi lista:
- el equipo de detectives
- ntfs-3g
- bisturí
- scrounge-ntfs
Sleuthkit no hizo nada útil y abandonó muy pronto quejándose de errores en las estructuras de metadatos.
Con Ntfs-3g (ahora Tuxera) es posible montar la imagen con salida de depuración:
sudo mount -o loop,ro,offset=258048,imagen de depuración2 ./mnt -t ntfs-3g
Intentar ingresar al directorio defectuoso provocaría un error:
El búfer de índice (VCN 0x0) del inodo de directorio 101874 tiene un tamaño (24) que difiere del tamaño especificado del directorio (4096).
Buscar ese error en DuckduckGo me lleva a la siguiente publicación: http://www.tuxera.com/forum/viewtopic.php?f=3&t=27054 Resulta que la gente de Tuxera/ntfs-3g recomienda el uso del CHKDSK de Microsoft para recuperar errores NTFS.
Ejecutar chkdsk en el disco fue mi tercer y último paso planeado, sin embargo, debería intentarlo mucho antes sabiendo quePUEDE ejecutarse en una imagen de disco, usando por ejemplo OSFMount (http://www.osforensics.com/tools/mount-disk-images.html).
La mayoría de los archivos y directorios faltantes (si no todos) han sido recuperados por chkdsk /f en la imagen del disco montado. Se han solucionado más de cien errores (la mayoría de los cuales son archivos huérfanos).
Edición 3:Acepto la respuesta de psusi. Aunque no ha demostrado ser imposible, intentar leer los sectores defectuosos es sin duda la ruta más incierta y difícil para recuperar datos de un disco duro levemente dañado.
Respuesta1
No, no es posible. Hay un comando SCSI para hacer esto, pero aún así solo obtendrías basura y no es compatible con unidades de nivel de consumidor, especialmente USB. Lo que había en ese sector ya no existe.