Cómo usar FSCK en Linux para comprobar y reparar errores del sistema de archivos

Cuando un sistema Linux empieza a mostrar errores extraños, tarda más en arrancar o directamente no llega ni a iniciar, muchas veces el problema no está en el hardware sino en el sistema de archivos.

Ahí es donde entra en juego fsck, una herramienta crítica que todo administrador (o usuario avanzado) debería dominar.

A continuación tienes una guía completa, clara y práctica sobre cómo usar fsck para comprobar y reparar errores en discos y particiones Linux, sin poner tus datos en riesgo.

¿Qué es fsck y para qué sirve?

El comando fsck (File System Consistency Check) es una utilidad de línea de comandos que se encarga de comprobar y, si hace falta, reparar la consistencia de los sistemas de archivos en Linux.

Funciona como un “mecánico” del disco: revisa estructuras internas, inodos, bloques y metadatos, y cuando detecta incoherencias intenta arreglarlas para evitar pérdida de datos o fallos de arranque.

En realidad, fsck es un frontal genérico que llama al comprobador específico según el tipo de sistema de archivos, por ejemplo e2fsck para ext2/ext3/ext4, fsck.xfs para XFS, fsck.vfat para FAT, etc.

¿Cuándo debes usar fsck?

Aunque fsck se puede ejecutar de forma manual, en muchas distribuciones también se lanza automáticamente en ciertos escenarios.

Estos son casos típicos en los que tiene sentido comprobar el sistema de archivos:

• El sistema no arranca o entra en modo “emergency” o “rescue”.
• Aparecen errores de entrada/salida (I/O) al leer o escribir archivos.
• Un disco, SSD, USB o tarjeta SD deja de funcionar como siempre o se vuelve muy lento.
• Ha habido un apagón, un reinicio forzado o un kernel panic.
• Haces mantenimiento preventivo en servidores críticos y quieres garantizar la integridad.
• Ves mensajes de corrupción de sistema de archivos en los logs del kernel o en dmesg.

Como buena práctica, antes de programar un fsck en un sistema en producción conviene revisar logs (/var/log/syslog, /var/log/messages, journalctl) y salidas de dmesg para entender el alcance del problema.

¿Cuál es la sintaxis básica del comando fsck?

La sintaxis general es:

fsck [opciones] [filesystem]

Puntos clave:

• Debes ejecutarlo como root (directamente o con sudo).
• [filesystem] suele ser un dispositivo de bloque: /dev/sda1, /dev/sdb2, /dev/md0, etc.
• Si no indicas dispositivo pero usas -A, leerá las entradas de /etc/fstab.

Opciones más habituales de fsck

Estas son las opciones más usadas en el día a día:

¿Cómo saber qué sistema de archivos estás usando?

Antes de pasar fsck, es importante saber qué tipo de sistema de archivos tienes en cada partición, porque fsck deriva en herramientas distintas según el tipo.

Dos comandos muy útiles:

lsblk -f

Muestra dispositivos, puntos de montaje, UUID y tipo de sistema de archivos.

blkid /dev/sdb1

Devuelve información detallada sobre el dispositivo indicado, incluido el tipo de sistema de archivos.

Con eso sabrás si estás trabajando con ext4, xfs, vfat, etc.

Regla de oro a seguir: nunca ejecutes fsck en una partición montada

Ejecutar fsck sobre una partición montada (especialmente en modo escritura) puede causar aún más corrupción de datos. Siempre que sea posible, desmóntala primero.

1. Comprueba si una partición está montada:

mount | grep /dev/sdb

1. Si lo está, desmóntala:

umount /dev/sdb1

1. Si el sistema dice que el dispositivo está ocupado, identifica qué proceso lo está usando:

lsof /dev/sdb1

1. Como último recurso, puedes usar un desmontaje “perezoso”:

umount -l /dev/sdb1

Solo cuando esté realmente desmontada es seguro lanzar fsck.

Ejemplos prácticos de uso de fsck

Comprobación básica, paso a paso

Para revisar una partición y responder de forma interactiva a cada reparación:

fsck /dev/sdb1

Irá mostrando los problemas que encuentre y te preguntará si quieres corregirlos uno a uno (ideal si quieres tener control total sobre lo que se toca).

Reparación automática (ideal para scripts y servidores)

En servidores, donde a veces necesitas minimizar la intervención manual, se suele combinar fsck con la opción -y para que acepte todas las reparaciones:

fsck -y /dev/sdb1

Úsalo con cuidado y mejor tras un “dry run” previo.

“Dry run”: ver qué pasaría sin cambiar nada

Si quieres ver qué haría fsck pero sin tocar el disco:

fsck -N /dev/sdb1

Esta opción es especialmente útil en sistemas críticos: primero analizas el impacto y, si lo ves razonable, repites ya sin -N o con -y.

Forzar la comprobación aunque el sistema parezca “limpio”

A veces el sistema de archivos aparece como limpio, pero notas comportamientos raros. Puedes forzar una comprobación completa:

fsck -f /dev/sdb1

Esto obliga a revisar todas las estructuras, no solo las marcadas como dudosas.

Comprobar solo un tipo de sistema de archivos

Si en tu máquina conviven varios tipos (por ejemplo, ext4 y vfat) y quieres centrarte solo en ext4:

fsck -t ext4 /dev/sdb1

O combinado con -A:

fsck -t ext4 -A -y

Así revisas todos los sistemas de archivos ext4 definidos en /etc/fstab, reparando automáticamente.

Comprobar todas las particiones (excepto la raíz)

Para revisar de una vez todos los sistemas de archivos configurados, excepto el de raíz:

fsck -AR -y

• -A lee las entradas de /etc/fstab.
• -R omite el sistema de archivos raíz.
• -y repara sin preguntar.

En discos grandes, puedes añadir barra de progreso y salida detallada:

fsck -C -V /dev/sdb1

¿Cómo interpretar los códigos de salida de fsck?

Al terminar, fsck devuelve un código de salida que indica qué ha pasado. Puedes verlo con:

echo $?

Los códigos estándar son:

Estos códigos se combinan entre sí mediante suma (bitwise OR). Por ejemplo, un código 3 significa que hubo errores corregidos (1) y que además es necesario reiniciar (2).

En scripts o tareas programadas (cron), es buena idea capturar este valor para disparar alertas o reinicios automáticos cuando sea necesario.

Ejemplo de script sencillo:

fsck -y /dev/sdb1
EXIT_CODE=$?

if [ $EXIT_CODE -ge 4 ]; then
    echo "ALERTA: No se pudieron corregir errores en /dev/sdb1" \
      | mail -s "Alerta fsck" admin@example.com
fi

¿Cómo ejecutar fsck en la partición raíz? (/)

No puedes ejecutar fsck directamente sobre la raíz mientras está montada en modo lectura/escritura, por lo que hay que usar otros enfoques. Estos son los métodos más habituales.

Método 1: Forzar fsck en el próximo arranque con /forcefsck

En sistemas clásicos basados en SysVinit o derivados, puedes indicarle al sistema que pase fsck en el siguiente arranque creando un archivo especial:

touch /forcefsck
reboot

En el próximo boot, se ejecutará fsck sobre la raíz antes de montarla. Tras el arranque, comprueba que el archivo ya no exista (normalmente se borra solo):

ls /forcefsck

En muchas distribuciones modernas con systemd, este método se ha ido reemplazando por parámetros de kernel o configuraciones específicas de systemd-fsck.

Método 2: Forzar fsck con tune2fs (ext2/ext3/ext4)

Si tu raíz es ext2/ext3/ext4, puedes forzar una comprobación en el siguiente arranque ajustando el contador de montajes con tune2fs:

Forzar comprobación en el próximo montaje:

tune2fs -C 1 /dev/sda1

Programar comprobaciones periódicas cada cierto número de montajes:

tune2fs -c 30 /dev/sda1

De este modo, cada 30 montajes el sistema obligará a pasar fsck sobre esa partición.

Método 3: Ejecutar fsck desde modo rescue o recovery

Cuando la corrupción es seria, lo más prudente es arrancar en modo recuperación:

1. Reinicia y, durante el arranque, mantén pulsada la tecla Shift (o la tecla indicada por tu distribución) para abrir el menú de GRUB.
2. Elige “Opciones avanzadas” para tu distribución.
3. Selecciona la entrada de “Recovery mode” para tu kernel.
4. En el menú de recuperación, elige la opción “fsck”.
5. Acepta remontar la raíz en modo solo lectura si te lo pide.
6. Cuando termine, selecciona “Resume” para continuar con el arranque normal.

En este modo, la raíz no está montada en escritura, por lo que fsck puede trabajar con seguridad.

¿Cómo usar fsck en volúmenes LVM y RAID por software?

LVM (Logical Volume Manager)

Con LVM, la lógica es la misma, pero trabajas sobre volúmenes lógicos:

1. Localiza el volumen lógico:

lvdisplay

1. Desactiva el volumen antes de pasar fsck:

lvchange -an /dev/vg_data/lv_data
fsck -y /dev/vg_data/lv_data
lvchange -ay /dev/vg_data/lv_data

RAID por software (mdadm)

En sistemas con RAID por software (/dev/mdX), suele ejecutarse fsck sobre el dispositivo del array completo, no sobre cada disco físico.

Ejemplo:

fsck -y /dev/md0

Antes de hacerlo, asegúrate de que el array está en buen estado (cat /proc/mdstat) y no degradado. Si está degradado, primero hay que reconstruirlo.

Programar comprobaciones regulares con tune2fs

En servidores en producción es buena práctica no esperar a que “algo falle”, sino programar comprobaciones periódicas.

Para sistemas de archivos ext2/ext3/ext4, tune2fs permite:

Programar por intervalo de tiempo

Por ejemplo, cada 6 meses:

tune2fs -i 6m /dev/sda1

Programar por número de montajes

Por ejemplo, cada 30 montajes:

tune2fs -c 30 /dev/sda1

Puedes comprobar la configuración actual con:

tune2fs -l /dev/sda1 | grep -i "mount count\|check interval"

Esto te mostrará el estado del sistema de archivos, el número de montajes, el máximo antes de forzar fsck y el intervalo de comprobación.

¿Cómo revisar qué ha hecho fsck en los logs?

Después de ejecutar fsck (ya sea manualmente o durante el arranque), es recomendable revisar los logs para ver qué se ha corregido y si ha habido errores serios.

Algunas rutas habituales:

En RHEL/CentOS/Rocky:

grep -i fsck /var/log/messages

En Debian/Ubuntu:

grep -i fsck /var/log/syslog

Con systemd:

journalctl -b | grep -i fsck

Así tendrás un histórico de las operaciones realizadas por fsck y podrás detectar patrones recurrentes (por ejemplo, un disco que empieza a fallar).

Lista de buenas prácticas y checklist rápidos para usar fsck

Para terminar, un pequeño resumen operativo que puedes usar como checklist:

• Nunca ejecutes fsck sobre una partición montada en escritura.
• Antes de tocar nada en producción, haz un “dry run” con fsck -N.
• Haz copias de seguridad de lo importante si sospechas que el disco está muy dañado.
• Usa -y solo cuando tengas claro lo que va a hacer (ideal tras revisar la salida de un -N).
• Captura y analiza los códigos de salida de fsck en scripts y tareas automáticas.
• Para la raíz (/), usa forcefsck, tune2fs o el modo recovery, según tu distribución.
• Programa comprobaciones periódicas con tune2fs en sistemas de archivos ext.
• Vigila los logs tras cada operación para detectar problemas recurrentes.

Con estas pautas y los ejemplos anteriores, tendrás un dominio sólido de fsck y podrás reaccionar con calma ante errores de sistema de archivos en Linux, minimizando el riesgo de pérdida de datos y caídas inesperadas del servicio.