Comprobación y reparación de sistemas de archivos: fsck, xfs_repair y btrfs check en un sistema de archivos desmontado

Objetivo

Comprobar si un sistema de archivos Linux presenta corrupción y repararlo solo cuando la herramienta y el modo empleados sean seguros para el estado de ese sistema de archivos.

Requisitos previos

El sistema de archivos de destino debe estar desmontado (si es el sistema de archivos raíz, arranque antes en modo de rescate o emergencia, o bien desde un sistema live o de rescate); acceso root; copias de seguridad recientes si se espera que la reparación sea destructiva.

Pasos

1. Confirme que el sistema de archivos está desmontado antes de comprobarlo. El manual de e2fsck indica claramente que no debe ejecutarse sobre sistemas de archivos montados y que, incluso cuando -n lo hace técnicamente seguro, los resultados mostrados mientras el sistema de archivos está montado no son válidos. El front-end genérico fsck invoca el verificador específico de cada sistema de archivos (fsck.ext4, etc.).
2. Para ext2/3/4: ejecute primero e2fsck -fn /dev/<device> (comprobación completa forzada, sin cambios) y después e2fsck -f /dev/<device> para reparar de forma interactiva, o -y para responder "sí" a todas las preguntas sin intervención, lo que también acepta correcciones destructivas.
3. Para XFS, el fsck genérico invoca fsck.xfs, que normalmente termina simplemente con código 0; use xfs_repair, que se niega a trabajar sobre un sistema de archivos montado. Ejecute primero xfs_repair -n /dev/<device> ("no modify mode", modo sin modificaciones): informa de lo que se repararía sin cambiar nada y devuelve 1 si detectó corrupción y 0 si no. Sin -n, devuelve 0 al completarse, 1 ante un error de ejecución (vuelva a lanzarlo) y 2 cuando no puede continuar porque el log está sucio. Si el log está sucio, monte y desmonte el sistema de archivos una vez (en una máquina con la misma arquitectura de CPU) para que el kernel reproduzca el log, y vuelva a ejecutar la herramienta. xfs_repair -L pone el log a cero en su lugar: se pierden todas las actualizaciones de metadatos en curso en el momento del fallo, lo que según el manual puede causar daños considerables; úselo solo como último recurso y después de hacer una copia en imagen.
4. Para Btrfs: btrfs check no modifica el dispositivo por defecto (--readonly solo lo reafirma); btrfsck es un alias obsoleto. Su manual desaconseja --repair "unless you are advised to do so by a developer or an experienced user" (salvo que se lo aconseje un desarrollador o un usuario con experiencia) y señala que ningún verificador puede corregir todos los tipos de corrupción. Si existe un snapshot o una copia de seguridad, es preferible restaurar a usar --repair; en un sistema de archivos montado, btrfs scrub start <mountpoint> verifica las sumas de comprobación en línea, pero no es una comprobación estructural.
5. Para forzar la comprobación del sistema de archivos raíz durante un único arranque, añada fsck.mode=force en el menú de arranque (si se mantiene en la configuración, fuerza una comprobación en cada arranque; auto es el valor por defecto y skip desactiva las comprobaciones); fsck.repair= (preen, yes, no) controla con qué agresividad responde systemd-fsck a las solicitudes de reparación durante esa comprobación automática.
6. Interprete el código de salida del fsck genérico como una suma a nivel de bits: 0 sin errores, 1 errores corregidos, 2 el sistema debe reiniciarse, 4 errores sin corregir, y bits superiores para fallos operativos; los códigos de varios sistemas de archivos comprobados en una misma ejecución se combinan con OR, así que, si un script necesita un resultado preciso, compruebe un único sistema de archivos por invocación.

Resultado esperado

Una pasada limpia no informa de corrupción (código de salida 0, o código 0 de xfs_repair -n); una pasada de reparación deja el sistema de archivos montable y el resumen de la propia herramienta indica qué se ha corregido.

Límites y base de verificación

XFS y Btrfs definen sus propios códigos de salida y opciones; no asuma que coinciden con los de fsck. btrfs check --repair todavía no funciona junto con --mode=lowmem. Haga una copia de seguridad (o un snapshot) antes de cualquier reparación que no sea una simulación: un verificador puede empeorar un sistema de archivos dañado.