Cuando a pesar de haber realizado backups de nuestro sistema (ya sea utilizando el método descrito en un post anterior o siguiendo alguna estrategia más robusta y guardándolos off-site) observamos errores al intentar montar un dispositivo, deberemos recurrir a un chequeo del sistema de archivos para investigarlos y solucionarlos de ser posible. Para realizar la tarea de reparar errores en un sistema de archivos en Linux, contamos con una herramienta muy útil llamada fsck, y en este post explicaremos su uso.
Tenemos que tener en claro que los procedimientos explicados en esta oportunidad deben considerarse un último recurso luego de contar con la existencia de backups y de sistemas de energía redundantes para nuestros equipos críticos.
¿Cuándo aparecen errores en un sistema de archivos?
Si el sistema se apaga abruptamente (por ejemplo, durante un corte de energía, y no se cuenta con UPSs), pueden ocasionarse errores en un sistema de archivos si se están realizando operaciones de lectura y escritura sobre el mismo. Para intentar solucionarlos, debemos desmontar el sistema de archivos (si el mismo se encuentra montado) o no intentar hacerlo. La regla de oro para el uso de fsck es la siguiente:
Nunca debemos intentar correr fsck sobre un dispositivo que se encuentre montado a fin de minimizar el riesgo de pérdida o corrupción de archivos.
Supongamos que deseamos chequear el sistema de archivos en /dev/vg00/vol01. Luego de desmontarlo
[pastacode lang=»bash» manual=»sudo%20umount%20%2Fdev%2Fvg00%2Fvol01″ message=»» highlight=»» provider=»manual»/]
Corremos fsck utilizando utilizando la ruta al dispositivo:
[pastacode lang=»bash» manual=»sudo%20fsck%20%2Fdev%2Fvg00%2Fvol01″ message=»» highlight=»» provider=»manual»/]
En este caso, el sistema de archivos está limpio (clean) como podemos ver en la Fig. 1:
Para forzar un error en el sistema de archivos, escribamos 100 MB de ceros en el primer volumen físico subyacente (/dev/sdb):
[pastacode lang=»bash» manual=»sudo%20dd%20if%3D%2Fdev%2Fzero%20of%3D%2Fdev%2Fsdb%20bs%3D1M%20count%3D100″ message=»» highlight=»» provider=»manual»/]
Al correr fsck nuevamente veremos el error que aparece en la Fig. 2. Elijamos la opción y (de yes) para continuar las veces que sean necesarias.
Alternativamente podríamos cancelar la operación con Ctrl + c y luego ejecutar fsck con la opción -y (para confirmar las reparaciones automáticamente). Luego de la reparación el sistema de archivos debería estar limpio nuevamente tal como mostramos en la Fig. 1 arriba.
TIP: Para simular la reparación en vez de ejecutarla, podemos utilizar la opción -n. De esta manera,
[pastacode lang=»bash» manual=»sudo%20fsck%20-n%20%2Fdev%2Fvg00%2Fvol01″ message=»» highlight=»» provider=»manual»/]
nos mostraría las operaciones a realizar como si estuviera llevando a cabo la reparación.
Espero que este post les haya resultado de utilidad. En el próximo post mostraremos cómo agendar un chequeo para que se realice de manera automática. ¡No se lo pierdan!