Reparación de errores de disco al arrancar: Qué hacer antes de que empeore

Qué significa realmente “Repairing disk errors” (y qué no significa)

Ese mensaje al arrancar suele ser una de tres cosas:

• Se está ejecutando una comprobación de consistencia del sistema de archivos (Windows: CHKDSK; Linux: fsck; macOS: fsck_apfs). Esto puede ser rutinario tras un apagado incorrecto, o puede haberse disparado porque se detectó corrupción.
• El SO está reproduciendo un journal (común en ext4, XFS, NTFS). Los sistemas de archivos con journal intentan restaurar la consistencia después de un fallo. La mayoría de reproducciones de journal son rápidas. Si va lento, eso es una pista.
• La capa de almacenamiento está descontenta: el disco devuelve errores de lectura/escritura, tarda demasiado en responder o el controlador se reinicia. En ese caso, “reparar” es el SO intentando leer metadatos y reescribir estructuras mientras el disco falla intermitentemente.

Esto es lo que no significa: no garantiza que el SO esté arreglando algo de forma segura, y no promete que tus datos queden intactos después. Las herramientas de reparación de sistemas de archivos están diseñadas para restaurar consistencia, no para preservar cada archivo. En un disco sano, ese intercambio suele ser aceptable. En un disco moribundo, es jugar a los dardos a oscuras.

Actitud accionable: trata las reparaciones al arrancar como un síntoma, no como una solución. Tu objetivo es determinar si estás ante (a) un apagado sucio puntual, (b) corrupción recurrente por software/firmware/energía, o (c) una falla inminente del disco.

Una idea parafraseada, porque es la actitud adecuada para esta situación: paraphrased idea de Werner Vogels (mentalidad de fiabilidad): todo falla eventualmente; diseña y opera como si eso fuera seguro.

Broma corta #1: Una herramienta de reparación de sistemas de archivos es como un dentista: útil, pero no quieres que improvise mientras la silla está en llamas.

Guía de diagnóstico rápido (primera/segunda/tercera comprobación)

Si estás en la consola y el sistema está “reparando” o atascado, necesitas un bucle cerrado: observar → clasificar → decidir. Esta es la versión que puedes ejecutar a las 2:00 AM sin inventar nuevos problemas.

Primero: determina si el disco está fallando físicamente

• Si puedes acceder a un shell o entorno de recuperación, extrae salud SMART/NVMe y registros del kernel.
• Busca: sectores reasignados, sectores pendientes, errores no corregibles, errores CRC, errores de medios NVMe, reinicios de controlador, timeouts de I/O.
• Decisión: si estos están presentes o aumentando, deja de “reparar” y empieza a “copiar”. Clona/imagen primero.

Segundo: determina si el sistema de archivos está corrupto pero el hardware está bien

• Revisa errores de montaje, bucles de reproducción del journal y si fsck/chkdsk informa un número estable de correcciones.
• Decisión: si SMART está limpio y los errores se correlacionan con cortes de energía o reinicios forzados, puedes proceder con una reparación offline—pero después de hacer copias de seguridad.

Tercero: determina si estás bloqueado por otra cosa (no el disco)

• UEFI/BIOS detectando mal el orden de arranque, controlador RAID en estado degradado, cable SATA defectuoso, backplane inestable, initramfs roto o un problema de driver del kernel pueden simular “errores de disco”.
• Decisión: si los registros muestran I/O limpios pero el arranque falla al montar root, céntrate en el bootloader/initramfs y en cambios de nombres de dispositivos.

Regla operativa: cuanto más se “cuelgue” el sistema, más sospecha debes tener de timeouts y reintentos. Las reparaciones saludables tienden a ser ruidosas y rápidas. Los discos enfermos son silenciosos y lentos.

Datos interesantes y contexto histórico (por qué vuelve a ocurrir)

• Dato 1: CHKDSK se remonta a las primeras herramientas de DOS; sus formas modernas aún heredan la misma misión: hacer consistente el sistema de archivos, aunque eso signifique eliminar entradas cuestionables.
• Dato 2: Los sistemas de archivos con journaling (como ext3/ext4, NTFS, XFS) se volvieron populares en parte porque las reparaciones sin journal tras fallos podían tardar horas—o requerir escaneos completos—en discos grandes.
• Dato 3: El paso de discos giratorios a SSD redujo algunas fallas mecánicas pero introdujo otras: bugs de firmware, desgaste relacionado con read disturb y comportamientos de “modo solo lectura” en algunos dispositivos.
• Dato 4: Los errores de enlace SATA (errores CRC) suelen ser causados por cables/backplanes, no por la unidad. Parecen terroríficos en los logs y con frecuencia se arreglan con un cable de 6 € y mejor enrutado.
• Dato 5: Los “sectores defectuosos” no siempre son permanentes. Los discos pueden reasignar sectores, y a veces un error de lectura transitorio vuelve a leerse—justo antes de fallar otra vez. Por eso “funcionó una vez” es una trampa.
• Dato 6: Los sistemas de archivos no son bases de datos. No rastrean invariantes a nivel de negocio, y las herramientas de reparación no pueden adivinar tu intención; solo restauran la integridad interna.
• Dato 7: RAID nunca fue una copia de seguridad, y la industria repite esa frase desde que RAID se hizo popular en servidores. Sigue siendo verdad.
• Dato 8: Las comprobaciones de sistemas de archivos en arranque solían programarse por defecto con más agresividad (p. ej., comprobaciones por contador de montajes en ext2/ext3). Los sistemas modernos a menudo reducen estas comprobaciones para mejorar la velocidad de arranque—a veces ocultando corrupción de lento desarrollo.

La primera regla: protege los datos antes de “arreglar” nada

Si hay cualquier posibilidad de que el disco esté fallando, tu prioridad es capturar datos con el menor estrés adicional posible para el disco. Las herramientas de reparación pueden castigar intensamente los metadatos y provocar mucho I/O aleatorio—justo lo que al medio débil más le perjudica.

Qué significa en la práctica “proteger los datos”:

• Si el sistema aún arranca: copia primero los datos más valiosos (bases de datos, directorios de usuario, configuraciones, claves). No empieces ejecutando chequeos de disco completos.
• Si no arranca: usa un entorno live para montar en solo lectura, o imagena el disco.
• Si es un servidor con redundancia (RAID/ZFS/Ceph): céntrate en reemplazar el componente fallido y reconstruir con seguridad. No ejecutes comprobaciones destructivas en un array degradado a menos que sepas exactamente qué tocan.

Broma corta #2: Lo único más optimista que “probablemente arrancará” es “voy a ejecutar fsck en producción a la hora del almuerzo.”

Tareas prácticas con comandos: salidas, significado y decisiones

Estas tareas asumen Linux porque ahí verás las señales más directas, pero la lógica se aplica a Windows/macOS: observar salud, capturar datos, reparar offline, verificar y luego prevenir recurrencias.

Tarea 1: Identificar en qué dispositivo de bloque está el sistema raíz

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
NAME   TYPE  SIZE FSTYPE MOUNTPOINTS MODEL            SERIAL
sda    disk  1.8T        ST2000DM008  ZFL123AB
├─sda1 part  512M vfat   /boot/efi
├─sda2 part    2G ext4   /boot
└─sda3 part  1.8T ext4   /

Qué significa: Ahora sabes qué disco está involucrado (sda) y qué particiones importan (sda3 es root). Si ves LVM, mdraid, dm-crypt o ZFS, tu “disco” es una pila—no te saltes las capas inferiores.

Decisión: Si root está en una pila compleja, debes recopilar datos de salud tanto de los dispositivos físicos como de la capa lógica (mdadm, LVM, ZFS).

Tarea 2: Revisar mensajes recientes del kernel en busca de errores de I/O y reinicios

cr0x@server:~$ sudo dmesg -T | egrep -i "error|fail|reset|timeout|I/O|ata|nvme" | tail -n 30
[Mon Feb  5 09:11:22 2026] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Mon Feb  5 09:11:22 2026] ata1.00: failed command: READ DMA EXT
[Mon Feb  5 09:11:22 2026] blk_update_request: I/O error, dev sda, sector 1953525160 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Mon Feb  5 09:11:23 2026] ata1: soft resetting link
[Mon Feb  5 09:11:28 2026] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Qué significa: Errores reales de I/O a nivel de bloque. El SO intentó leer un sector y el disco/controlador no pudo entregar. El reinicio del enlace sugiere que el disco o la ruta son inestables.

Decisión: Trata esto como un problema de hardware o conectividad hasta que se demuestre lo contrario. Procede a revisar SMART y cables/backplane; prioriza la imagenación/copia de seguridad.

Tarea 3: Extraer salud SMART para discos SATA/SAS

cr0x@server:~$ sudo smartctl -a /dev/sda
SMART overall-health self-assessment test result: PASSED
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   097   097   010    Pre-fail  Always       -       24
197 Current_Pending_Sector  0x0012   098   098   000    Old_age   Always       -       8
198 Offline_Uncorrectable   0x0010   098   098   000    Old_age   Offline      -       8
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Qué significa: “PASSED” no es una garantía; solo significa que la unidad no ha cruzado un umbral del proveedor. Sectores pendientes y errores no corregibles son mala señal: el disco no puede leer algunas ubicaciones de forma fiable. Sectores reasignados indican que ya ha tenido que remapear áreas dañadas.

Decisión: Si 197/198 son distintos de cero y no estables, reemplaza el disco. Antes del reemplazo, imagina si necesitas los datos. Si 199 es alto, sospecha primero del cable/backplane.

Tarea 4: Extraer salud NVMe (media errors, porcentaje usado)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 44 C
available_spare                     : 100%
percentage_used                     : 62%
media_errors                        : 12
num_err_log_entries                 : 98

Qué significa: Un media_errors distinto de cero es el equivalente NVMe de “el dispositivo no pudo leer/escribir datos correctamente.” No es un indicador cosmético.

Decisión: Si los errores de medios aumentan, planifica el reemplazo. Si el sistema está en bucle de reparaciones al arrancar, ve directamente a la imagenación y migración.

Tarea 5: Revisar estado del sistema de archivos y últimos resultados de fsck (ejemplo ext4)

cr0x@server:~$ sudo tune2fs -l /dev/sda3 | egrep -i "Filesystem state|Errors behavior|Last checked|Last mount time|Mount count|Check interval"
Filesystem state:         clean
Errors behavior:          Continue
Last mount time:          Mon Feb  5 09:02:10 2026
Last checked:             Mon Feb  5 09:01:55 2026
Mount count:              34
Check interval:           0 (<none>)

Qué significa: ext4 considera que está limpio ahora, pero eso no implica que el disco esté bien. Además, “Errors behavior: Continue” es un peligro en sistemas críticos; puede seguir funcionando mientras corrompe silenciosamente.

Decisión: Si has visto reparaciones en el arranque repetidamente, cambia el comportamiento de errores a “remount-ro” después de estabilizar, y arregla la causa subyacente (energía, disco, controlador).

Tarea 6: Ejecutar una comprobación no destructiva del sistema de archivos (solo lectura) desde un entorno live

cr0x@server:~$ sudo fsck.ext4 -n /dev/sda3
e2fsck 1.46.5 (30-Dec-2021)
/dev/sda3: clean, 412156/117440512 files, 98123456/469760000 blocks

Qué significa: -n no modifica el sistema de archivos. “clean” sugiere que el sistema de archivos es consistente.

Decisión: Si el sistema de archivos está limpio pero el arranque sigue desencadenando reparaciones, sospecha timeouts de hardware o reinicios de controlador. Si fsck informa errores incluso después de un apagado limpio, sospecha controladores subyacentes (disco, RAM, controlador, energía).

Tarea 7: Ejecutar una reparación offline (solo cuando la ruta del disco parezca estable)

cr0x@server:~$ sudo fsck.ext4 -f -y /dev/sda3
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Inode 924844 has invalid mode.  Clear? yes
Pass 2: Checking directory structure
Entry 'cache.tmp' in /var/tmp (924900) has deleted/unused inode 924844.  Clear? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda3: 412155/117440512 files, 98123450/469760000 blocks

Qué significa: La herramienta hizo cambios. Eso puede estar bien. También puede significar que acabas de perder metadatos de archivos que te importaban. Si esto se repite, no es “mala suerte”.

Decisión: Si fue un caso aislado tras un fallo y SMART está limpio, continúa. Si las reparaciones siguen ocurriendo, detente y diagnostica hardware y estabilidad de energía.

Tarea 8: Verificar que la ruta del disco no esté falseando (errores CRC SATA y estabilidad del enlace)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "UDMA_CRC_Error_Count|SATA Version|Error"
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       214

Qué significa: Los errores CRC suelen indicar corrupción de datos en el cable, no dentro del disco. Piensa en cable, conector, backplane, vibración o ruido en la alimentación.

Decisión: Resitúa/reemplaza el cable, mueve las bahías, revisa el backplane. Tras arreglar la ruta física, observa si CRC deja de aumentar. Si sigue aumentando, trata todo el camino como sospechoso.

Tarea 9: Revisar fallos de arranque en systemd por problemas de montaje (común en servidores Linux)

cr0x@server:~$ systemctl --failed
  UNIT                          LOAD   ACTIVE SUB    DESCRIPTION
● boot.mount                    loaded failed failed /boot
● local-fs.target               loaded failed failed Local File Systems

Qué significa: El arranque está fallando en los puntos de montaje del sistema de archivos. Eso puede ser corrupción, dispositivo ausente, UUID equivocado o RAID degradado que no se ensambló.

Decisión: Siguiente comprobación: logs del journal para ver por qué falló el montaje, luego verifica UUIDs y la presencia del dispositivo de bloque.

Tarea 10: Inspeccionar logs del journal por “superblock” y “wrong fs type”

cr0x@server:~$ sudo journalctl -b -p err --no-pager | tail -n 30
Feb 05 09:01:44 server kernel: EXT4-fs (sda3): bad geometry: block count 469760000 exceeds size of device (0)
Feb 05 09:01:44 server systemd[1]: Failed to mount /.
Feb 05 09:01:44 server systemd[1]: Dependency failed for Local File Systems.

Qué significa: Los metadatos del sistema de archivos no coinciden con lo que el kernel cree que es el tamaño del dispositivo. Esto puede ocurrir con dispositivos que fallan, controladores rotos o RAID/LVM mal ensamblados presentando un dispositivo más pequeño.

Decisión: Detén intentos de reparación hasta confirmar que el dispositivo de bloque subyacente está correctamente detectado (capacidad, modelo, lecturas estables). Revisa capas RAID/LVM y logs del controlador.

Tarea 11: Confirmar que la capacidad del dispositivo sea estable y no esté “encogiéndose”

cr0x@server:~$ sudo blockdev --getsize64 /dev/sda
2000398934016

Qué significa: Tamaño en bytes. Si esto cambia entre arranques o tras reinicios, estás frente a un problema de controlador/firmware/ruta.

Decisión: Si el tamaño es inconsistente, trata el subsistema de discos como inestable. Cambia de puertos/controladores si es posible, luego imagena por la ruta más estable.

Tarea 12: Ensamblar y verificar el estado de mdraid (si aplica)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      976630336 blocks super 1.2 [2/1] [U_]
      [==============>......]  recovery = 72.3% (706000000/976630336) finish=45.0min speed=100000K/sec

Qué significa: RAID1 está degradado: un lado falta ([U_]). La recuperación está en curso, lo que genera mucho I/O.

Decisión: Si tus reparaciones de arranque empezaron durante la recuperación, considera pausar la reconstrucción pesada para estabilizar y capturar datos. Reemplaza el miembro fallido, asegura que el disco superviviente está sano antes de forzar una reconstrucción completa.

Tarea 13: Comprobar salud del pool ZFS y estado de scrub (si aplica)

cr0x@server:~$ sudo zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device and run 'zpool clear'.
  scan: scrub repaired 0B in 00:12:31 with 3 errors on Mon Feb  5 08:40:22 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     FAULTED     12     0     3  too many errors

Qué significa: ZFS te está diciendo que vio errores e incluso menciona corrupción. Ese es un momento de “detenerse y arreglar hardware”, no de “escarbar más” con scrub.

Decisión: Reemplaza el dispositivo con fallo y vuelve a escanear. También revisa cableado/firmware del HBA; ZFS suele sacar a la luz problemas aguas arriba antes que otras pilas.

Tarea 14: Imaginar un disco fallando con reintentos mínimos (ddrescue)

cr0x@server:~$ sudo ddrescue -f -n /dev/sda /mnt/recovery/sda.img /mnt/recovery/sda.map
GNU ddrescue 1.26
Press Ctrl-C to interrupt
rescued:   1999 GB,  errsize:   1024 kB,  current rate:   120 MB/s
ipos:   2000 GB,  errors:      12,  average rate:   118 MB/s
opos:   2000 GB,  time from start:   04:45:12
Finished

Qué significa: Conseguiste casi todo; el mapfile registra lo que falló. -n hace una primera pasada sin rascar agresivamente—menos estrés. Los errores restantes pueden recuperarse en una segunda pasada, o pueden perderse para siempre.

Decisión: Si la imagen está mayormente completa, trabaja desde la imagen (monta con loopback, ejecuta fsck sobre una copia). No sigas golpeando el disco original a menos que los sectores faltantes contengan datos críticos y aceptes el riesgo de fallo total.

Tarea 15: Montar un sistema de archivos en solo lectura para extraer datos con seguridad

cr0x@server:~$ sudo mount -o ro,norecovery /dev/sda3 /mnt
cr0x@server:~$ ls -lah /mnt | head
total 96K
drwxr-xr-x  24 root root 4.0K Feb  5 09:02 .
drwxr-xr-x   3 root root 4.0K Feb  5 08:59 ..
drwxr-xr-x   2 root root 4.0K Jan 20 11:10 bin
drwxr-xr-x   4 root root 4.0K Feb  4 18:12 boot

Qué significa: El montaje en solo lectura reduce escrituras. norecovery (cuando está disponible) evita reproducir journals al montar, lo que puede escribir en disco.

Decisión: Si esto funciona, copia inmediatamente los datos más valiosos. Si falla, vuelve a la imagenación y a una recuperación más profunda.

Tarea 16: Encontrar qué archivos están en bloques defectuosos (sistemas ext)

cr0x@server:~$ sudo badblocks -sv /dev/sda3
Checking blocks 0 to 469760000
Checking for bad blocks (read-only test): done
Pass completed, 12 bad blocks found. (12/0/0 errors)

Qué significa: Existen bloques defectuosos. En un disco giratorio, esto suele correlacionar con fallo creciente. En SSDs, “bloques defectuosos” es más complicado por la remapeo, pero los no corregibles siguen importando.

Decisión: No los “marques y sigas” a menos que estés dispuesto a continuar en un dispositivo comprometido (no deberías, para nada importante). Reemplaza el disco.

Tarea 17: Verificar que la RAM no sea la cómplice silenciosa (porque la corrupción no siempre es del disco)

cr0x@server:~$ sudo journalctl -k --no-pager | egrep -i "mce|machine check|EDAC|memory error" | tail -n 20
Feb 05 08:58:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

Qué significa: Errores ECC corregibles son advertencias. Si aumentan, pueden corromper datos en memoria antes de que se escriban en disco. Eso después parece “errores de disco”.

Decisión: Si ves errores ECC, programa el reemplazo de DIMMs y ejecuta pruebas de memoria. No culpes al sistema de archivos por lo que rompió el subsistema de memoria.

Tres historias corporativas desde las trincheras

1) El incidente causado por una suposición errónea: “PASSED significa sano”

Una empresa mediana tenía una flota de servidores de compilación on‑prem. Uno empezó a mostrar “repairing disk errors” al arrancar, pero finalmente arrancaba. El on-call revisó SMART, vio “PASSED” y siguió—porque la pipeline estaba en rojo y todos querían gráficos verdes antes de la reunión matinal.

La máquina cojeó durante una semana. Las compilaciones se volvieron más lentas, luego intermitentes. Cada reinicio disparaba otro ciclo de reparación. La suposición operativa fue: “es solo churn de sistema de archivos tras eventos de energía.” Excepto que el servidor no tenía eventos de energía. Tenía reintentos de lectura, timeouts y una pila creciente de sectores pendientes que nadie miró porque la línea resumen parecía bien.

Luego llegó el día en que no volvió. El disco falló por completo a mitad del arranque, justo cuando la herramienta de sistema de archivos estaba escribiendo metadatos. Lo más doloroso no fue la interrupción; fue la ambigüedad. ¿Estaba corrupto el cache del repo? ¿Eran corruptos los artefactos? ¿Qué compilaciones eran sospechosas? A nadie le gusta explicar a dirección que “los datos podrían estar mal”.

Resultado del postmortem: dejaron de tratar SMART “PASSED” como veredicto. Empezaron a alertar por atributos específicos (sectores pendientes/no corregibles, errores de medios NVMe, errores CRC de enlace) y añadieron una línea al runbook: “Si la reparación en arranque se repite, imagen primero.” No es glamoroso. Muy efectivo.

2) La optimización que salió mal: “Omitir comprobaciones para arrancar más rápido”

Otra organización ejecutaba servicios sensibles a latencia en metal desnudo. La velocidad de arranque importaba porque los reinicios en rolling eran parte de su ritmo de parches. Alguien afinó ext4 para minimizar comprobaciones programadas y ajustó opciones de montaje para mantener todo en movimiento. Fue un clásico “optimizar el estado estable”.

Meses después, un bug menor del kernel más un par de reinicios abruptos por watchdog causaron inconsistencias en metadatos. Los sistemas seguían arrancando, en su mayoría. Pero entraban en “repairing disk errors” con más frecuencia, y la ventana de reparación se alargó cada vez. Nadie lo correlacionó porque las comprobaciones eran raras y la flota grande. Las fallas lentas eran difusas—perfectas para ser ignoradas.

Luego un nodo falló de forma especialmente inoportuna: se quedó atascado reparando durante una ventana de mantenimiento automatizada. Perdió su slot, volvió tarde y desencadenó fallos en cascada porque la planificación de capacidad supuso que el nodo volvería rápidamente. Un ajuste de “arranque rápido” había convertido silenciosamente un caso recuperable en una interrupción predecible.

Revirtieron los ajustes más agresivos, introdujeron scrubs/comprobaciones offline periódicas en ventanas de baja carga y—esto es clave—se aseguraron de que cada evento de “repair on boot” generara un ticket. No una tormenta de alertas. Un ticket con dueño humano. Las optimizaciones están bien; ocultar evidencias no.

3) La práctica aburrida pero correcta que salvó el día: restauraciones probadas y reemplazo en etapas

Una empresa del entorno financiero (regulada, alérgica a sorpresas) ejecutaba sus sistemas centrales en almacenamiento en espejo con disciplina operativa estricta. Una mañana, un host de base de datos arrancó en pantalla de reparación. El on-call no intentó ser héroe. Siguió el runbook: capturar logs, comprobar salud del disco, sacar el nodo de rotación y hacer failover.

SMART mostraba un aumento de no corregibles en un disco y un puñado de errores CRC en otro. El equipo no discutió qué métrica “importaba más”. Reemplazaron el cable, reemplazaron el disco y programaron una reconstrucción controlada. Mientras la reconstrucción corría, mantuvieron el nodo fuera del tráfico crítico.

Esta es la parte que suena aburrida hasta que la necesitas: habían probado restauraciones. Cuando alguien preguntó “¿y si la reconstrucción del mirror corrompe la base de datos?” la respuesta no fue una reunión. La respuesta fue: “Podemos restaurar la snapshot de la noche anterior en un host limpio; lo ensayamos el mes pasado.”

El incidente fue una no-evento. Un intercambio de hardware, una validación y ticket cerrado. Nadie recibió medalla. Así es el éxito en operaciones: calma y algo aburrido.

Errores comunes: síntoma → causa raíz → solución

1) La reparación se ejecuta cada arranque, pero “finalmente funciona”

Síntoma: La reparación al arrancar dura más cada vez; congelamientos ocasionales; cierres inesperados de aplicaciones.

Causa raíz: El disco acumula sectores ilegibles o el controlador se reinicia bajo carga.

Solución: Revisa SMART/NVMe y dmesg. Si existen sectores pendientes/no corregibles/errores de medios, imagena el disco y reemplázalo. Si dominan los errores CRC, reemplaza cable/backplane y vuelve a probar.

2) “Tipo de fs incorrecto” o “superblock dañado” tras una actualización

Síntoma: systemd cae a modo emergencia; montaje falla; la herramienta de reparación dice que no encuentra un sistema de archivos.

Causa raíz: Cambió el nombre del dispositivo (desajuste de UUID), no se ensambló RAID/LVM o initramfs carece del driver correcto.

Solución: Verifica UUIDs en /etc/fstab contra blkid. Confirma activación de mdraid/LVM en initramfs. No ejecutes fsck a ciegas en el nodo de dispositivo equivocado.

3) CHKDSK/fsck “arregla” cosas, pero los archivos desaparecen

Síntoma: Tras la reparación, los directorios contienen fragmentos en lost+found o faltan archivos.

Causa raíz: La corrupción de metadatos forzó a la herramienta a desacoplar inodos/registros huérfanos. Esto es comportamiento esperado bajo daño.

Solución: Restaura desde copia de seguridad/snapshot si es posible. Si no, recupera desde una imagen usando herramientas forenses. Detén reparaciones repetidas en discos fallando; aumentan el daño.

4) La reparación está “atorada” en cierto porcentaje

Síntoma: El progreso se detiene; LED del disco sólido; ventiladores normales; sin errores visibles.

Causa raíz: La herramienta está reintentando una región difícil de leer, a veces durante horas. La interfaz no muestra los reintentos.

Solución: Revisa logs del kernel en busca de timeouts de I/O. Si están presentes, aborta e imagena con ddrescue. Si no hay errores de I/O y la CPU está a tope, puede ser un escaneo masivo de directorios—déjalo correr, pero monitoriza.

5) La reconstrucción RAID inicia y luego el sistema empieza a “reparar errores de disco”

Síntoma: Tras reemplazar un disco, la reconstrucción del array provoca chequeos de arranque, ralentizaciones y errores de lectura esporádicos.

Causa raíz: El disco superviviente ya estaba débil; la carga de reconstrucción lo expone. O el controlador/backplane es marginal.

Solución: Valida los discos restantes antes de la reconstrucción. Si aparecen errores, detén la reconstrucción, imagena los datos y planifica una migración más segura. Reemplaza componentes cuestionables primero.

6) El SSD de repente se vuelve solo lectura o desaparece durante la reparación

Síntoma: El montaje pasa a solo lectura; NVMe se reinicia; bucles de arranque.

Causa raíz: Modo de protección del firmware del SSD, problemas con power loss protection o fallo del controlador. A veces desencadenado por eventos térmicos/eléctricos.

Solución: Extrae SMART/logs NVMe. Asegura refrigeración y alimentación estable. Reemplaza el dispositivo; no confíes en él nuevamente para cargas intensivas de escritura.

Listas de verificación / plan paso a paso (haz esto, luego aquello)

Escenario A: Un portátil/escritorio muestra “Repairing disk errors” una vez

1. Déjalo terminar una vez. Si completa rápido y arranca normalmente, regístralo como advertencia de todos modos.
2. Tras el arranque, recopila señales de salud: SMART/NVMe, logs de eventos del SO y eventos de energía recientes.
3. Haz backup inmediatamente. No más tarde.
4. Si SMART/NVMe muestra sectores pendientes/no corregibles/errores de medios, reemplaza la unidad.
5. Si aparecen errores CRC/enlace, resitúa/reemplaza cables (escritorio) o inspecciona conectores.

Escenario B: Se repite cada arranque o se queda atascado

1. Deja de reiniciar repetidamente. Los reinicios no son diagnósticos; son pruebas de estrés.
2. Arranca un entorno live (o modo recovery) y recoge dmesg más logs SMART/NVMe.
3. Si aparecen errores de hardware: imagena con ddrescue, luego trabaja desde la imagen.
4. Si el hardware parece limpio: ejecuta fsck en solo lectura primero; luego reparación offline si es necesario.
5. Tras la reparación, valida: comprobaciones de integridad de archivos, comprobaciones de aplicaciones y revisión de logs.

Escenario C: Servidor con RAID/ZFS y impacto en producción

1. Haz failover o drena tráfico si puedes. No depures bajo carga a menos que disfrutes del arrepentimiento.
2. Revisa primero la salud del array/pool (mdadm/zpool). Un conjunto degradado cambia cada cálculo de riesgo.
3. Identifica el componente que falla: disco vs cable vs HBA vs backplane.
4. Reemplaza hardware sospechoso, luego reconstruye/resilver con monitorización.
5. Ejecuta un scrub/chequeo después de la reconstrucción y confirma que no quedan errores silenciosos.

Escenario D: Necesitas los datos y el disco está claramente muriendo

1. Prioriza la imagenación por encima de la reparación. La imagen conserva opciones.
2. Usa ddrescue con mapfile; haz una primera pasada de bajo estrés.
3. Trabaja sobre la copia de la imagen: intenta montar en solo lectura; ejecuta comprobaciones de sistema de archivos sobre una imagen duplicada, no sobre la única copia.
4. Sólo intenta lecturas agresivas en el original si los datos faltantes justifican el riesgo de fallo total.

Preguntas frecuentes

1) ¿“Repairing disk errors” siempre significa que mi unidad está muriendo?

No. Puede ser una respuesta normal a un apagado incorrecto. Pero si se repite, se ralentiza o coincide con errores de I/O en los logs, asume riesgo de hardware hasta que se demuestre lo contrario.

2) ¿Debo interrumpir el proceso de reparación?

Si sospechas fallo físico del disco (errores de I/O, reinicios, sectores pendientes, errores de medios NVMe), sí—porque las reparaciones que escriben pueden empeorar la pérdida. Si es una reproducción de journal puntual en hardware sano, déjalo terminar.

3) ¿Por qué SMART dice “PASSED” cuando el disco claramente falla?

El resumen “overall health” de SMART es por umbrales y específico del proveedor. Atributos como sectores pendientes, no corregibles y media errors suelen ser más accionables que la línea resumen.

4) ¿Cuál es la diferencia entre corrupción del sistema de archivos y sectores defectuosos?

La corrupción del sistema de archivos son metadatos/estructuras rotas (a menudo por crashes, bugs o escrituras defectuosas). Los sectores defectuosos/errores de medios son que el disco no puede almacenar o leer datos de forma fiable. La corrupción puede repararse; el medio defectuoso tiende a empeorar.

5) ¿Ejecutar fsck/chkdsk arreglará un disco que está fallando?

No. Puede hacer consistente el sistema de archivos encima de un disco fallando, pero no cura el hardware. En un disco moribundo puede acelerar la falla provocando mucho I/O aleatorio.

6) Si reemplazo el disco, ¿puedo confiar en la copia de sistema de archivos reparada?

A veces. Si reparaste después de imagenar y verificaste la integridad a nivel de aplicación, puedes tener confianza razonable. Si el disco devolvía corrupción silenciosa (raro, pero real), necesitas checksums y validación a nivel superior.

7) ¿RAID previene esta situación de reparación al arrancar?

Reduce el tiempo de inactividad por fallos de un solo disco, pero no evita comprobaciones de sistema de archivos, problemas de controlador, cables malos, bugs de firmware o fallos correlacionados de múltiples discos. Además: las reconstrucciones RAID pueden ser el momento en que el segundo disco se rinde.

8) ¿Cuál es la forma más segura de recuperar datos de un disco que falla?

Imaginalo con una herramienta diseñada para medios fallando (ddrescue) usando un mapfile, luego realiza la recuperación sobre la imagen. Montar en solo lectura y reintentos mínimos son tus aliados.

9) ¿Por qué la reparación tarda una eternidad en discos grandes?

Algunas comprobaciones son esencialmente escaneos completos de metadatos. Si el disco está lento por reintentos, timeouts o comportamiento SMR bajo lecturas aleatorias, puede prolongarse mucho. Los logs te dirán con cuál estás lidiando.

10) Si veo errores CRC, ¿debo reemplazar el disco igualmente?

No inmediatamente. Los errores CRC suelen implicar el cable/backplane. Arregla la ruta y observa si el contador CRC deja de aumentar. Si además ves sectores pendientes/no corregibles, reemplaza el disco sin dudar.

Próximos pasos que puedes dar hoy

Si tu sistema está “repairing disk errors” al arrancar, deja de tratarlo como un parte meteorológico. Es un sistema de alerta temprana que es fácil ignorar hasta que deja de ser temprano.

1. Obtén señales: captura dmesg/journalctl más salud SMART/NVMe de los dispositivos subyacentes.
2. Toma la decisión: si ves media/pending/uncorrectable errors o reinicios/timeouts repetidos, imagena primero y reemplaza hardware.
3. Repara con sensatez: ejecuta comprobaciones en solo lectura antes de reparaciones offline; no repitas “arreglar” un sistema de archivos en un disco que falla.
4. Verifica: confirma montajes, ejecuta chequeos de aplicación, revisa logs y vigila errores recurrentes durante los próximos días.
5. Prevén recurrencias: aborda estabilidad de energía, cables/backplanes, firmware de controladores y configura alertas en atributos de salud significativos—no solo “PASSED”.

Realidad operacional: al disco no le importan tus plazos. Tu mejor movimiento es actuar antes de que él tome la decisión por ti.