Cómo identificar y reparar archivos con bloques de disco corruptos/inaccesibles

Tengo una Macbook Pro de finales de 2011 que ejecuta Mavericks 10.9.2. Su único disco duro es un disco de 750 GB, formateado con Bootcamp. Todavía funciona razonablemente bien, pero al ejecutar un pase de desfragmentación, identifiqué que hay un montón de archivos que se niegan a ser movidos por el desfragmentador (iDefrag).

iDefrag informa un código de error POSIX de 5 al acceder a los archivos. Escoger uno al azar e intentar copiar el archivo a otra ubicación en el shell también reporta un error, lo que me hace pensar que el problema es real y con el disco/FS. La salida de cp es:

cp: unity_nophysx.nexe: Input/output error

El código de error 5 es "acceso denegado" hasta donde yo sé, pero el proceso de desfragmentación se ejecuta como administrador y ejecutar cp usando sudo en el archivo sospechoso no hace ninguna diferencia.

Disk Utility, fsck y Apple Hardware Test afirman que el disco está bien. No se informaron errores SMART, y aunque hubo algunos errores de permisos, no estaban con los archivos de los que se queja iDefrag, y Disk Utility afirma haberlos solucionado sin quejarse.

Hay tal vez un centenar o más de archivos dañados, pero sigue siendo una fracción muy pequeña de la unidad. Por lo que puedo decir, no se ven afectados los archivos del sistema ni los datos cruciales. Si bien sería bueno recuperar los datos, no me importa volver a instalar o hacer copias de seguridad. En este punto, no sé si realmente se está muriendo la unidad, solo algunos sectores defectuosos debido a que la unidad se movió mientras se escribía, o alguna otra corrupción menor que se puede solucionar. Estoy asumiendo el peor de los casos, y lo más probable es que tenga que obtener un disco duro un poco más grande y clonar el disco existente para evitar tener que reconstruir el sistema.

Mi pregunta es realmente cómo hago para marcar esos archivos rotos como correctamente rotos y repararlos o purgarlos , de modo que una clonación del disco tenga éxito y no se cuelgue en archivos/bloques a los que no puede acceder. Disk Utility no está viendo el problema, y ​​no conozco ninguna línea de comandos o herramientas de terceros que puedan hacer el trabajo. No quiero descartar todo el disco y comenzar desde cero, ya que la unidad parece estar en buen estado, por lo que estoy buscando herramientas de reparación/diagnóstico.

Le aconsejo que lea esta discusión similar bastante detallada sobre SuperUser: superuser.com/q/148227 .
Probé, desafortunadamente en un disco saludable :), volitans-software.com/smart_utility.php . Parece una herramienta bastante simple y seria. Puede intentarlo y, sobre todo, comprobar el contador de "sectores reasignados".

Respuestas (7)

Si se enfrenta a un sistema de archivos saludable a nivel de su estructura y desea encontrar archivos que tienen bloques defectuosos en el disco, así es como procedería:

  1. Haga una copia de seguridad completa de su disco con Time Machineo Carbon Copy Cloner

    Compruebe esta copia de seguridad.

  2. Ejecute el siguiente comando pesado y arriesgado (en caso de que tenga bloques defectuosos fuera de la estructura de su sistema de archivos) (asegúrese de que {} esté entre comillas para que funcionen los nombres de archivo que contienen espacios):

    find / -type f -print -exec dd if="{}" of=/dev/null bs=1m \;
    

Este comando pesado findimprimirá para cualquier archivo simple su nombre (por lo tanto, no lo leerá, sino solo su entrada de directorio) y luego continuará realizando una lectura completa y rápida de todos sus bloques de datos.

Al acceder al primer archivo que contiene bloques defectuosos, esto findhará que el núcleo inicie sesión read errory /var/log/system.logralentizará o detendrá el sistema por completo. Esto dependerá principalmente de la capacidad del disco duro para reubicar los bloques defectuosos que se encuentran en su grupo interno dedicado a esta tarea de reparación habitual. Este archivo que contiene bloques defectuosos será el último nombre impreso por find.

¡Escriba este nombre de archivo en una hoja de papel! Digamos que este nombre de archivo es:

/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9

En este punto, es posible que tengas la posibilidad de matar findrápidamente presionando ctrl+ C. Si matarlo bien está fallando, simplemente bloquee su Mac.

Al reiniciar su Mac, verifique directamente el archivo que contiene bloques defectuosos:

dd if='/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9' of=/dev/null bs=1m

Si el comando finaliza correctamente, entonces el error fue lo suficientemente leve como para que su disco pueda leer este archivo y reasignar los bloques defectuosos.

  • Si el comando no finaliza, no podrá eliminarlo normalmente, sus datos se perderán por completo y tendrá que bloquear su Mac una vez más.

En este último caso, debe considerar reemplazar su disco y trabajar desde sus últimas copias de seguridad. Algunos otros archivos también pueden contener bloques defectuosos y pueden haber pasado desapercibidos durante mucho tiempo, siempre y cuando no los hayas leído.

El kernel no disparará un error de lectura en un bloque que nunca lee.

Ajá, este es absolutamente el tipo de truco que esperaba. El primer paso con el script find/dd toca todos los archivos/bloques en el disco y, efectivamente, encuentro un montón de archivos que dan "Error de entrada/salida", y simplemente puedo enviar el registro del comando a un archivo y luego grep para averiguar qué archivos son duff. Parece que el comando dd no es suficiente para activar ningún tipo de reparación automática (ni siquiera sabía que OS X lo hizo), pero al menos me brinda una forma confiable de identificar los archivos.
En el lado positivo, cuando el sistema operativo intenta leer los archivos con estos bloques defectuosos, no falla ni cuelga de forma horrible. Veo una May 10 20:42:15 ICE kernel[0]: disk0s2: I/O error.ventana emergente en los registros, pero no tengo idea de qué archivo la activó. Pero luego el comando se ejecuta bastante felizmente.
Su núcleo no se bloquea con el BBFH porque su disco todavía tiene suficientes bloques disponibles dentro de su grupo para reparar los bloques defectuosos. ddno soluciona nada, el propósito de este comando es copiar datos y convertirlos lo más rápido posible. El disco aún puede reparar errores leves. Estate atento, el precio de un disco no es nada comparado con tu trabajo.
Mmm, sí, asumí que: dd solo es una herramienta tonta para extraer todos los datos de un archivo y ponerlos en otro lugar (en nuestro caso, en el aire). Lo que realmente importa es que se lea cada bloque asociado con el archivo. Lo que no entiendo es lo que esperas que haga OS X en ese caso. Claramente, el kernel no puede leer estos bloques defectuosos, pero ¿crees que el disco en sí mismo puede repararlos? Si no puede sacar los datos del bloque defectuoso original, ¿cómo va a cambiarlos a otro lugar?
Excelente pregunta. El disco hará reintentos automáticamente en los bloques de lectura. Cada vez que la posición de la cabeza es mecánicamente en una posición diferente. Si uno de estos intentos tiene éxito, los datos se copian en uno de los bloques disponibles para reparar los bloques defectuosos. El bloque defectuoso se marca como defectuoso y nunca se volverá a utilizar. Por otro lado, si todos los reintentos fallan, los datos no se guardan y, después de mucho tiempo, el disco marcará el bloque como defectuoso y asignará uno nuevo vacío al disco visible. El núcleo informará un error de disco irrecuperable.
Dado lo que estoy viendo, todos los reintentos fallan, el kernel informa el error de IO, pero el archivo permanece inaccesible (presumiblemente porque no tiene sentido colocar un bloque nuevo y vacío en su lugar, porque eso dañaría el archivo datos, y no deje ninguna pista de lo que ha sucedido). Obtendría un error de disco irrecuperable, luego cada acceso posterior devolvería silenciosamente datos corruptos. Pero si sabe que sucedió una vez, lo que no entiendo es por qué OS X no lo guarda en una lista de archivos duff y tiene una herramienta de mantenimiento que puede decirle que algunos de ellos son malos, dejándolo a usted. ¡arreglar!

Reinicie en modo de usuario único manteniendo presionado Command+ Sdurante el arranque. Cuando vea un mensaje (debería verse como root #algo similar), escriba fsck -fy presione Return. Esta es la herramienta de verificación de consistencia del sistema de archivos integrada de Mac y le permite encontrar y reparar errores con el sistema de archivos de inicio. Ejecute este comando hasta que no vea **The volume [volume name] was modified.**o la herramienta falle tres veces seguidas.

Si la herramienta falla, podría ser indicativo de un problema mayor (pero no podría decirle qué sin ver el resultado de la herramienta). En cualquier caso, asegúrese de haber hecho una copia de seguridad de todo lo que pueda antes de ejecutar cualquier herramienta de disco. Cuando haya terminado, escriba rebooten el indicador y presione Intro para (¡lo adivinó!) Reiniciar su computadora.

Para obtener información adicional, puede encontrar las páginas del manual de fsck aquí .

Interesante, pero se parece mucho a fsck, incluso con -f y en modo de usuario único, está haciendo exactamente lo que hizo la Utilidad de Discos. Al igual que la Utilidad de Discos, no encuentra nada y piensa que el disco está bien. Supongo que está escaneando los registros del sistema de archivos, pero creo que mi problema está en el nivel de bloque, es decir, el sistema de archivos está bien estructurado, pero no se puede acceder a los datos reales dentro de los archivos cuando se trata de leer. /copiarlos/desfragmentarlos.
→ MrCranky: cierto! fsck& Disk Utilityestán comprobando la integridad de la estructura del sistema de archivos. Leen los bloques de disco asignados a la estructura del sistema de archivos. No están hechos para verificar la integridad de los bloques de datos. Por lo tanto, pueden ejecutarse en un disco con bloques defectuosos sin generar ningún error de lectura. Si desea verificar su disco, incluso los bloques que pueden estar defectuosos pero que en realidad no se utilizan, simplemente use una herramienta básica como dd if=/dev/disk0 of=/dev/null ibs=1ky dentro de otra ventana de shell tail -f /var/log/system.log. Esto es gratis, extremo y no te ocultará ningún error.

Recomendaría mucho DiskWarrior para reconstruir catálogos de discos y para escanear archivos potencialmente dañados .

Durante la reconstrucción del catálogo, también puede informarle si experimenta un retraso debido a un mal funcionamiento del disco.

No soy reacio a comprar una herramienta para ayudar, pero sin prueba y sin garantía de que esté diseñada para encontrar el tipo de errores que estoy experimentando, necesitaría muchas más recomendaciones para respaldar las suyas antes de ser preparado para gastar $100 en una herramienta.
-1 No solo una respuesta, sino una combinación de comentario y respuesta.

Trabajando con la respuesta de Buscar, puede hacer esto automáticamente usando una línea de comando bastante pesada foo.

sudo find / -type f -print0  | xargs -0 -I{} dd if='{}' of=/dev/null bs=1m 2>&1 | grep 'error' >>badfiles.txt  & 
  • sudo:modo administrador
  • find -print0: ruta absoluta
  • xargs -0 -I{} : sustituye {} en el siguiente comando
  • dd 2>&1: redirigir el error estándar a la salida estándar
  • tubería stdout a grep en busca de error de cadena
  • Agregue los resultados a un archivo de lista. ( nota : esto debe estar en un medio externo si cree que su disco interno es dudoso)

Como dices, ni siquiera está claro que esos archivos estén dañados, al menos tu Mac no lo cree así.

Cada sistema operativo crea archivos inamovibles que son necesarios para sus operaciones (puntos de restauración, archivos actualmente activos, etc.). Algunas desfragmentaciones los mostrarán, otras no.

El hecho de que no puedas acceder a ellos o moverlos no significa que estén dañados.

Normalmente, los Mac son muy buenos para cuidarse a sí mismos.

El mantenimiento de Apple se realiza de la siguiente manera: abre la Terminal y escribe:

sudo periodic daily weekly monthly 

seguido de Retorno, ingrese su contraseña de administrador y OS X se encargará de todo por usted.

Busque en la consola los informes sobre ellos si está interesado.

Mientras esté en la Consola, busque (busque) cualquier error de E/S que indique que su disco está comenzando a tener problemas, para complementar la Utilidad de disco y los hallazgos de fsck.

En ocasiones utilizo una herramienta gratuita llamada OnyX para tareas de mantenimiento adicionales. Está hecho por franceses y como la comida es simplemente genial :)

OnyX es una utilidad multifunción para OS X que le permite verificar el disco de inicio y la estructura de sus archivos de sistema, ejecutar tareas misceláneas de mantenimiento del sistema, configurar algunos parámetros ocultos del Finder, Dock, QuickTime, Safari, Mail, iTunes , ventana de inicio de sesión, Spotlight y muchas de las aplicaciones de Apple, para eliminar cachés, para eliminar una cierta cantidad de archivos y carpetas que pueden volverse engorrosos, y más.

Dicho todo esto, no cuestiono su decisión de usar el desfragmentador (iDefrag) ya que no lo conozco, sino que le ofrezco soluciones alternativas.

El uso del desfragmentador no es el problema, soy perfectamente consciente de lo que hace y no hace OS X en ese sentido. Los archivos definitivamente no estaban en uso, estos eran archivos de datos para una aplicación que no estaba activa y, de hecho, la aplicación ahora no se puede mover.
En Onyx, nuevamente hace poco más que la Utilidad de disco: verifica el estado SMART del disco y luego ejecuta el diagnóstico de estilo fsck (que, como hemos establecido, cree que no hay nada malo)
Para que quede claro, para cualquier otra persona que lea esta respuesta, los archivos definitivamente estaban dañados, y la Mac lo sabía, porque no tenía permitido leerlos (copiarlos, lo que sea). Eso no se debía a que fueran archivos del sistema o estuvieran en uso en ese momento, era cierto incluso para los archivos de datos del usuario. El mantenimiento periódico no ayudó con el problema, nuevamente porque fsckparece que solo se preocupa por los problemas del sistema de archivos, no por los problemas de accesibilidad del bloque. La Consola mostró errores solo cuando intenté copiar/leer manualmente los datos de uno de estos archivos rotos, no fue de ayuda para encontrarlos.

Por irrazonable que parezca, antes de hacer cualquier cosa, debe duplicar todos sus datos en una unidad en buen estado. Si falla el arranque desde el instalador y la copia de los datos, hay una utilidad de línea de comandos llamada 'dd' que puede realizar duplicaciones de bajo nivel y de una manera mucho más inflexible.

 man dd

para obtener más información sobre dd, incluido el uso y la sintaxis adecuada.


Otro voto para la publicación de Matt, iniciar el modo de usuario único y ejecutar

 fsck -fy 

una y otra vez hasta que fsck deje de informar errores.


Un voto por la publicación de Adam, DiskWarrior es una aplicación fácil de usar pero muy poderosa que informará fallas en el disco duro, verificará archivos individuales en busca de errores y los reparará si es posible, y reconstruirá y optimizará estructuras de directorios.


Otra solución posible que puede sonar irrazonable, pero que a menudo es un último intento desesperado de recuperar datos con mucha evidencia anacdotal de éxito es sacar la unidad, protegerla de la humedad usando un par de capas de bolsas para congelar y colocarla en su congelador para 30-45 minutos. Luego, mientras la unidad está fría, monte la unidad en una base USB externa y use otro sistema temporal para volver a intentar copiar los datos dañados en otra unidad. Generalmente, esto se usa si hay un problema de hardware y la unidad está fallando. Si puede duplicar todo el disco con sus datos intactos, esto es ideal, ya que a menudo una nueva partición y un reformateo le darán al disco una nueva oportunidad de vida.

Como he dicho, fsck no informa ningún error. El disco aún no es temperamental ni informa errores aleatorios, y la lista de archivos que están dañados no parece estar creciendo, por lo que no creo que esté cerca de la etapa de 'congelar para una última extracción de emergencia' todavía. También tengo una copia de seguridad muy buena a nivel de archivo/carpeta, y no me preocupa perder datos, como dije en la pregunta. Sin embargo, es bueno escuchar otro voto para DiskWarrior.
@MrCranky: creo que se refiere a algo publicado antes de actualizar su pregunta; Estaba reforzando la idea de fsck para cualquiera que encuentre esta página buscando una solución a síntomas similares. Con respecto a todo lo que publiqué sobre la falla de HDD, nunca está de más ser exhaustivo, nuevamente, para otros y no necesariamente para usted personalmente. He visto una buena cantidad de fallas en el disco duro. A menudo, no hay indicios de falla, incluso con la tecnología SMART, hasta que ya no puede acceder a los datos por ningún medio. Si le importan los datos, le recomiendo encarecidamente que obtenga una nueva unidad y haga una copia de seguridad de sus datos.
Ciertamente no estoy en desacuerdo con la recomendación de respaldo, pero el espíritu del formato de preguntas y respuestas es responder a la pregunta que se plantea, no a una pregunta genérica de "cómo arreglo un disco roto" (de la cual hay muchas). Mucho antes de editarlo para agregarlo fscka la lista de "cosas que piensan que el disco está bien", respondí a la mención de respuesta fsckdescontando su utilidad. fscky Disk Utility realizan prácticamente la misma función, y es operar en las estructuras del sistema de archivos, no a nivel de bloque. Traté de ser bastante específico de que este es un problema de bloque, no un problema del sistema de archivos.

Para un solo archivo que no se puede leer en su totalidad debido a un error de lectura del disco, puede usar la ddutilidad para duplicar el archivo en un volumen externo, sustituyendo los bytes NUL por los bloques que no se pueden leer. Se recomienda encarecidamente duplicar en un volumen diferente (p. ej., "Disco USB" en el ejemplo siguiente).

Ejemplo:

dd if=/path/to/damaged/file of=/Volumes/USB\ Disk/file bs=512 conv=noerror,sync

Al usar bloques de 512 bytes, se recuperará la cantidad máxima de bloques legibles.

La recuperación puede llevar mucho tiempo, ya que el núcleo se bloqueará durante algún tiempo con cada lectura fallida.