Debian 13 «Sistema de archivos de solo lectura»: ruta más rápida a la causa raíz y recuperación

diciembre 17, 2025 • febrero 3, 2026 • Lectura: 26 min • Views: 9

¿Te fue útil?

Siempre empieza pequeño: un despliegue que “no puede escribir en /var”, un job de logrotate que falla en silencio, una instalación de paquete que muere a mitad de camino. Entonces lo notas: Read-only file system. En Debian 13 no es una actitud: es el kernel diciéndote que detectó algo lo bastante grave como para dejar de confiar en tu disco.

Tu trabajo no es “hacer que vuelva a ser escribible”. Tu trabajo es averiguar por qué el sistema decidió que no podía escribir de forma segura, preservar pruebas y recuperar sin convertir un incidente recuperable en una historia de pérdida de datos.

Qué significa realmente “sistema de archivos de solo lectura” (y por qué Debian lo hace)

Cuando ves “Read-only file system”, típicamente estás ante una de tres realidades:

El sistema de archivos está montado como solo lectura (ya sea desde el arranque o remontado como solo lectura en tiempo de ejecución).
El dispositivo de bloque está rechazando escrituras (protección de escritura a nivel de dispositivo, medio fallando, disco virtual/SAN con problemas).
No estás escribiendo realmente donde crees (overlay/containers, montajes bind, permisos o una capa superior llena/solo lectura).

En Debian 13 con ext4 (todavía el predeterminado en muchas instalaciones), el patrón común de “sorpresa” es: una escritura falla de forma que sugiere corrupción o inestabilidad de I/O; ext4 decide que continuar puede arriesgar más daño; el kernel remonta el sistema de archivos como solo lectura para detener la hemorragia. XFS tiene un comportamiento similar de “no voy a jugar” cuando detecta ciertas clases de problemas.

No es el SO poniéndose dramático. Es el SO haciendo lo menos malo ante un almacenamiento incierto.

Aquí está la regla operativa: el cambio a solo lectura es un síntoma, no un diagnóstico. El diagnóstico vive en tus registros y en la pila de almacenamiento bajo el sistema de archivos.

Una cita para recordar: “La esperanza no es una estrategia.” — Gene Kranz. En respuesta a incidentes, eso no es motivación; es un recordatorio para no “simplemente reiniciar y ver”.

Playbook rápido de diagnóstico (primero/segundo/tercero)

Este es el camino más corto para identificar el cuello de botella: sistema de archivos vs dispositivo de bloque vs plataforma. No improvises. Haz esto en orden.

Primero: confirma qué está en solo lectura y si cambió en tiempo de ejecución

¿Es el sistema de archivos raíz o un montaje de datos?
¿Está ro en las flags de montaje?
¿El kernel lo remonto por errores?

Segundo: escanea los logs del kernel buscando la línea desencadenante

ext4: “Errors detected… remounting filesystem read-only”
XFS: “Log I/O error” o “xfs_do_force_shutdown”
capa de bloque: “I/O error”, “timeout”, “reset”, “aborted command”
dispositivo: NVMe “media errors”, SATA “UNC”, SCSI “sense key”

Tercero: decide si estás ante hardware fallando o corrupción recuperable

Si hay errores I/O/tiempos de espera/reset repetidos: trátalo como primero plataforma/hardware. Planea reemplazo/migración.
Si fue un estallido único (pérdida de energía, crash) y salud del dispositivo parece limpia: probablemente puedas reparar con fsck y seguir.

Si estás de guardia y tentado a remontar como lectura-escritura inmediatamente, recuerda: no puedes sobreconfigurar un controlador NVMe que está fallando.

Hechos y contexto interesantes (breves, concretos, útiles)

Hecho 1: ext4 hereda su comportamiento ante errores de la era ext3: cuando la integridad de metadata es cuestionable, remontar como solo lectura es una válvula de seguridad.
Hecho 2: La opción de montaje ext4 errors=remount-ro ha sido un valor por defecto porque “seguir escribiendo” es como se extiende la corrupción.
Hecho 3: XFS no hace “fsck” en el sentido tradicional; usa xfs_repair, y puede forzar el apagado del sistema de archivos cuando detecta inconsistencia en el log o errores de I/O.
Hecho 4: Las unidades NVMe exponen contadores de “Media and Data Integrity Errors”; valor distinto de cero no siempre significa muerte inminente, pero contadores en ascenso sí.
Hecho 5: Un hipervisor puede presentar un disco como solo lectura cuando el datastore está lleno, cuando las cadenas de snapshots están rotas o cuando detecta problemas en el almacenamiento subyacente.
Hecho 6: Linux puede montar un sistema de archivos como solo lectura limpiamente durante el arranque si detecta que necesita recuperación (reproducción de journal) pero no puede hacerlo de forma segura.
Hecho 7: LVM y dm-crypt típicamente pasan errores I/O hacia arriba; el sistema de archivos es la capa que decide “ahora soy solo lectura”. Por eso la causa raíz suele estar debajo del sistema de archivos.
Hecho 8: Muchos incidentes de “solo lectura” son provocados por tiempos de espera, no por corrupción: fallos transitorios de enlace (cable/backplane SATA, firmware HBA, flaps de camino SAN) pueden provocar suficientes escrituras fallidas para activar la protección.
Hecho 9: La historia de recuperación de Debian mejoró mucho cuando systemd estandarizó modos de emergencia/rescate; puedes obtener una shell sin adivinar runlevels.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas no son “ejecuta todo porque te hace sentir productivo”. Cada tarea tiene: comando, qué significa la salida y la decisión que tomas.

Tarea 1: Confirma flags de montaje (ro vs rw) y el alcance

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /
/ /dev/mapper/vg0-root ext4 rw,relatime,errors=remount-ro

Significado: La raíz está actualmente escribible (rw). Si aún ves errores, puede ser otro montaje como /var o /srv, o un overlay en un contenedor.

Decisión: Si ves ro, continúa. Si rw, localiza la ruta/dispositivo específico que está en solo lectura con findmnt -R /path o revisa el montaje del contenedor del servicio.

Tarea 2: Localiza qué sistema de archivos contiene la ruta que falla

cr0x@server:~$ findmnt -T /var/lib/postgresql -no TARGET,SOURCE,FSTYPE,OPTIONS
/var /dev/mapper/vg0-var ext4 ro,relatime,errors=remount-ro

Significado: Es /var, no la raíz. Eso cambia la recuperación: podrías desmontar solo /var en modo usuario único y repararlo, dejando la raíz intacta.

Decisión: Identifica el dispositivo (/dev/mapper/vg0-var) y enfoca el diagnóstico allí.

Tarea 3: Revisa el ring buffer del kernel para el primer error

cr0x@server:~$ dmesg -T | egrep -i 'EXT4-fs error|remounting filesystem read-only|I/O error|blk_update_request|Buffer I/O error|nvme|ata[0-9]|reset|timed out' | tail -n 25
[Sat Dec 28 11:04:10 2025] EXT4-fs error (device dm-2): ext4_journal_check_start:83: Detected aborted journal
[Sat Dec 28 11:04:10 2025] EXT4-fs (dm-2): Remounting filesystem read-only

Significado: ext4 abortó el journal en dm-2 (probablemente tu LV LVM). Eso es o bien corrupción por apagado no limpio o problemas de I/O aguas arriba.

Decisión: Ahora debes determinar si el aborto fue provocado por errores I/O debajo (disco, camino, controlador) o por un crash puntual.

Tarea 4: Correlaciona con logs del journal entre arranques

cr0x@server:~$ journalctl -k -b -1 -g 'Remounting filesystem read-only|I/O error|nvme|ata|sd ' --no-pager | tail -n 60
Dec 28 10:12:03 server kernel: nvme nvme0: I/O 123 QID 5 timeout, aborting
Dec 28 10:12:04 server kernel: nvme nvme0: Abort status: 0x371
Dec 28 10:12:05 server kernel: EXT4-fs (dm-2): I/O error while writing superblock
Dec 28 10:12:05 server kernel: EXT4-fs (dm-2): Remounting filesystem read-only

Significado: Eso no es “apagado no limpio”. Es el disco haciendo timeout. ext4 falla al escribir metadata y cambia a solo lectura.

Decisión: Trátalo primero como inestabilidad de almacenamiento. Planea migración/reemplazo. No “fsck y listo”.

Tarea 5: Mapea nombres de device-mapper a discos reales

cr0x@server:~$ lsblk -o NAME,KNAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
nvme0n1     nvme0n1  disk  1.8T
├─nvme0n1p1 nvme0n1p1 part  1G  vfat   /boot/efi
└─nvme0n1p2 nvme0n1p2 part  1.8T LVM2_member
  ├─vg0-root dm-0    lvm   80G  ext4   /
  ├─vg0-var  dm-2    lvm  200G  ext4   /var
  └─vg0-home dm-3    lvm  100G  ext4   /home

Significado: El sistema de archivos que falla está en dm-2 que mapea a /dev/mapper/vg0-var en nvme0n1p2.

Decisión: Tu radio de explosión incluye todo ese NVMe. Prepárate para un incidente de disco completo, no solo un LV.

Tarea 6: Comprueba si el dispositivo de bloque subyacente está marcado como solo lectura

cr0x@server:~$ cat /sys/block/nvme0n1/ro
0

Significado: El kernel no considera el dispositivo protegido contra escritura. El estado solo lectura probablemente está a nivel de sistema de archivos, no de protección física.

Decisión: Continúa con chequeos de salud del dispositivo; no asumas “bloqueo físico”.

Tarea 7: Instantánea SMART / salud NVMe

cr0x@server:~$ smartctl -a /dev/nvme0n1 | egrep -i 'model number|firmware|critical warning|media and data integrity errors|error information log entries|percentage used|available spare|temperature'
Model Number:                       ACME NVMe 2TB
Firmware Version:                   3B2QEXM7
Critical Warning:                   0x00
Temperature:                        63 Celsius
Available Spare:                    100%
Percentage Used:                    7%
Media and Data Integrity Errors:    12
Error Information Log Entries:      57

Significado: Errores de media/integridad no nulos y muchas entradas de error no son “óptimo”. Puede que funcione meses o que muera esta misma noche. En todo caso, tiene una historia.

Decisión: Si te importa la integridad de datos, trátalo como para reemplazar/migrar. Usa las reparaciones para estabilizar y evacuar, no para “recuperar confianza”.

Tarea 8: Discos SATA/SCSI: busca resets de enlace y sectores malos

cr0x@server:~$ dmesg -T | egrep -i 'ata[0-9].*reset|SATA link|UNC|I/O error|failed command|sense key|medium error' | tail -n 20
[Sat Dec 28 09:58:31 2025] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Sat Dec 28 09:58:33 2025] ata2.00: failed command: WRITE FPDMA QUEUED
[Sat Dec 28 09:58:33 2025] blk_update_request: I/O error, dev sdb, sector 918273645 op 0x1:(WRITE) flags 0x0 phys_seg 8 prio class 0

Significado: Flap de enlace + escrituras fallidas. Eso puede ser medio del disco, controlador, backplane, cable, alimentación o la realidad siendo cruel.

Decisión: Deja de intentar “arreglar el sistema de archivos” hasta estabilizar el transporte. Mueve la carga de trabajo y luego investiga hardware.

Tarea 9: Determina si el sistema de archivos cree que tuvo errores (ext4)

cr0x@server:~$ tune2fs -l /dev/mapper/vg0-var | egrep -i 'Filesystem state|Errors behavior|Last error|Last mount time|Last checked'
Filesystem state:         clean with errors
Errors behavior:          Remount read-only
Last error:               ext4_journal_check_start: Detected aborted journal
Last mount time:          Sat Dec 28 10:11:57 2025
Last checked:             Tue Dec 10 02:14:18 2025

Significado: ext4 registró un estado de error. Incluso si lo remontas rw, ahora estás operando sobre un sistema de archivos que admite que tuvo un mal día.

Decisión: Planea un desmontaje controlado y fsck. Si el dispositivo es inestable, hazlo después de evacuar o desde un entorno de recuperación estable.

Tarea 10: Comprueba si “disco lleno” se disfraza de solo lectura

cr0x@server:~$ df -hT /var
Filesystem              Type  Size  Used Avail Use% Mounted on
/dev/mapper/vg0-var     ext4  197G  197G     0 100% /var

Significado: Los sistemas de archivos llenos suelen causar “No space left on device”, no “read-only file system”. Pero pueden desencadenar fallos en journal, caídas de aplicaciones y estados inseguros.

Decisión: Aún así, resuelve la presión de espacio de inmediato (elimina con seguridad, rota logs, mueve cachés). Pero si el montaje está ro, también necesitas la causa real en los logs.

Tarea 11: Confirma si systemd te puso en modo de emergencia por fallo de fsck

cr0x@server:~$ systemctl status
● server
    State: degraded
     Jobs: 0 queued
   Failed: 1 units
    Since: Sat 2025-12-28 11:07:12 UTC; 2min 13s ago

cr0x@server:~$ systemctl --failed
  UNIT          LOAD   ACTIVE SUB    DESCRIPTION
● var.mount     loaded failed failed /var

Significado: El arranque prosiguió pero una unidad de montaje falló. A veces systemd te deja en una shell de emergencia; otras veces sigue con disponibilidad parcial de servicios.

Decisión: Enfócate en la unidad fallida y su dispositivo; no persigas primero errores aleatorios de aplicaciones.

Tarea 12: Intenta un remount seguro para recopilar logs (solo si el almacenamiento parece estable)

cr0x@server:~$ mount -o remount,rw /var
mount: /var: cannot remount /dev/mapper/vg0-var read-write, is write-protected.

Significado: O bien el kernel lo forzó a solo lectura por errores, o la capa de dispositivo está rechazando escrituras.

Decisión: No repitas este comando en bucle. Vuelve a logs y salud del dispositivo; considera arranque de recuperación y fsck offline.

Tarea 13: Comprueba el estado de mdadm RAID (si aplica)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[1]
      976630336 blocks super 1.2 [2/1] [U_]
      bitmap: 1/8 pages [4KB], 65536KB chunk

unused devices: <none>

Significado: RAID1 degradado: un disco falta o falló. Las lecturas pueden seguir funcionando; las escrituras pueden complicarse según el modo de fallo y la configuración.

Decisión: Reemplaza el miembro fallado. Si también hay errores de sistema de archivos, decide si primero fue el RAID o primero el sistema de archivos.

Tarea 14: Revisa LVM por PVs faltantes o activación en solo lectura

cr0x@server:~$ pvs -o pv_name,vg_name,pv_size,pv_free,pv_attr
  PV             VG  PSize  PFree  Attr
  /dev/nvme0n1p2  vg0 1.80t  1.42t  a--

Significado: PV presente y activo. Si vieras PVs faltantes o activación parcial, eso te llevaría directamente a problemas de cableado/camino de almacenamiento.

Decisión: Sigue con las comprobaciones de sistema de archivos/dispositivo; LVM no es el villano inmediato aquí.

Tarea 15: Verifica si estás en una situación de overlay de contenedor

cr0x@server:~$ mount | egrep -i 'overlay|docker|containerd' | head
overlay on /var/lib/docker/overlay2/abc123/merged type overlay (ro,relatime,lowerdir=...,upperdir=...,workdir=...)

Significado: El overlay está montado como solo lectura; eso puede ocurrir si el upperdir se montó en solo lectura o si el runtime lo remonto por problemas.

Decisión: No culpes a “Docker” de inmediato. Encuentra el filesystem que hace de upperdir y diagnostica ese montaje/dispositivo.

Mapa de causas raíz: almacenamiento, sistema de archivos, capa de bloque y usuarios

1) El sistema de archivos se protegió tras un error real de I/O

Esto es lo más común y lo más importante. ext4 y XFS no pasan a solo lectura porque sí. Lo hacen porque el kernel les dijo que una escritura falló o porque el sistema de archivos detectó inconsistencia interna.

Las líneas típicas del kernel incluyen:

blk_update_request: I/O error
Buffer I/O error
EXT4-fs error ... Detected aborted journal
XFS (dm-0): log I/O error

Las causas subyacentes van desde SSDs fallando a HBAs inestables, desde inestabilidad en caminos SAN hasta “alguien desconectó el cable de alimentación”. Tu objetivo es identificar qué capa falló primero.

2) El dispositivo (o hipervisor) te está efectivamente protegiendo contra escritura

Aunque Linux diga /sys/block/.../ro es 0, tus escrituras aún pueden fallar porque la plataforma las niega. En VMs, “solo lectura” puede ser la versión educada de “el datastore está sin espacio” o “la cadena de snapshots está rota”. En SAN, puede ser un modo de protección del array tras detectar un problema.

Pista: ves códigos SCSI de sense, timeouts persistentes o fallos consistentes en varios sistemas de archivos a la vez.

3) El sistema de archivos montó como solo lectura en el arranque porque no se pudo completar la recuperación

Si la reproducción del journal falla, o si el sistema de archivos está marcado para chequeo y la secuencia de arranque no puede hacerlo de forma segura, puedes encontrar montajes ro o caer en modo de emergencia.

En ese escenario, el sistema básicamente dice: “Podría montar esto, pero no confío lo suficiente en él para escribir sin supervisión.” Es un límite razonable.

4) No estás sobre un sistema de archivos normal

OverlayFS, squashfs, imágenes live, imágenes base inmutables y ciertos entornos con endurecimiento de seguridad pueden hacer que “solo lectura” sea la intención. La diferencia es: el solo lectura intencional es consistente y limpio; el accidental viene con errores en el kernel y normalmente un timestamp donde todo se torció.

5) El sistema está bien, tu suposición no

A veces el sistema de archivos es escribible; tu aplicación está escribiendo en un bind mount de solo lectura, o intenta escribir en una exportación NFS de solo lectura, o hay una política SELinux/AppArmor que hace que el error aparente ser “solo lectura” a nivel de aplicación. Debian 13 no es especial aquí, pero los despliegues modernos tienen tantas capas que engañan bien.

Broma #1: Los fallos de almacenamiento son como reuniones: si crees que acabarás en 15 minutos, simplemente no encontraste la verdadera agenda todavía.

Tres mini-historias corporativas (anonimizadas, plausibles e instructivas)

Mini-historia 1: El incidente causado por una suposición equivocada

La empresa operaba una flota Debian ordenada en hardware decente. Un viernes, un host de producción empezó a arrojar “Read-only file system” durante una actualización rutinaria de paquetes. El de guardia hizo lo que muchos hemos hecho bajo presión: remonto la raíz como lectura-escritura, volvió a ejecutar la actualización y declaró victoria.

La suposición equivocada fue sutil: asumieron que el remonte a solo lectura se debió a un apagado no limpio la semana anterior. Eso es una causa normal, y el host había sido reiniciado recientemente. La coherencia narrativa seduce.

Pero los logs del kernel tenían dos líneas que no encajaban: timeouts intermitentes de NVMe y comandos abortados. Se ignoraron porque la máquina “se sentía rápida” y el monitoring mostraba latencias normales la mayor parte del tiempo.

Durante el fin de semana, el modo de fallo del disco empeoró. Las escrituras de metadata fallaron más a menudo, el sistema de archivos volvió a pasar a solo lectura y la base de datos empezó a journalizar donde todavía podía escribir—hasta que dejó de poder hacerlo. El lunes no solo hubo downtime, sino una recuperación desordenada: WALs parciales, estado de aplicación inconsistente y restauración desde backup tomada bajo supervisión ejecutiva.

La solución no fue ingeniosa. Reemplazaron el NVMe, restauraron limpiamente y actualizaron los runbooks: cualquier remonte a solo lectura requiere comprobar errores a nivel de bloque antes de tocar el sistema de archivos. La segunda vez que ocurrió meses después, la respuesta fue aburrida y rápida. Aburrido es cumplido.

Mini-historia 2: La optimización que salió mal

Otra organización tenía un “equipo tigre de rendimiento”. Afinaban cargas con muchas escrituras y querían menos picos de latencia. Alguien sugirió opciones de montaje agresivas y tuning de colas, y también alargaron los intervalos de sondeo de salud del disco para reducir ruido. Quitó un poco de ruido en los gráficos. Todos se sintieron listos.

Entonces un host empezó a ver timeouts raros en su camino de almacenamiento. Con checks de salud menos frecuentes y señales tempranas reducidas, el primer síntoma visible fue ext4 remontando un volumen de datos muy ocupado como solo lectura. Para cuando alguien miró, la carga de trabajo ya había acumulado errores y reintentos, amplificando timeouts a nivel de aplicación.

El análisis post-mortem mostró que los errores de almacenamiento eran detectables antes: entradas en el log de SMART y contador de timeouts en el kernel. Pero la cadencia “optimizada” de monitoreo no captó la tendencia. El equipo había optimizado dashboards silenciosos en lugar de detección temprana.

La lección fue poco glamorosa: mantén la telemetría de salud lo bastante frecuente para detectar deriva. Un puñado de métricas extra es más barato que un congelamiento de producción al mediodía. Revirtieron el cambio de sondeo y añadieron una alerta específica para eventos “filesystem remounted read-only” extraída del kernel.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una compañía financiera ejecutaba sistemas Debian con control de cambios estricto y una costumbre que parecía casi anticuada: cada host con almacenamiento tenía un “plan de evacuación” probado y una ISO de recuperación conocida disponible por gestión remota. También mantenían una partición /var/log separada, dimensionada razonablemente y con rotación agresiva. No emocionante. Muy adulta.

Una mañana, un host puso /var en solo lectura. El equipo de aplicaciones entró en pánico porque parecía que “el servidor estaba muerto”. El SRE de guardia sacó el playbook: verificar flags de montaje, revisar logs del kernel, confirmar errores NVMe subyacentes y dejar de escribir.

Como los logs estaban en un montaje separado con suficiente espacio, la traza de errores se mantuvo intacta. Capturaron journalctl, guardaron datos SMART e iniciaron un failover planeado a un nodo en espera. Luego arrancaron el host problemático en modo de recuperación, hicieron una comprobación en solo lectura primero y solo repararon después de evacuar datos. Sin cirugía heroica a medianoche.

Les llevó más tiempo explicarle a la gerencia por qué la solución fue “reemplazar la unidad” que mantener el servicio; así es como quieres que sea.

Patrones de recuperación que no empeoran las cosas

Prioridad 1: Detén la hemorragia, preserva evidencia

Si el sistema de archivos pasó a solo lectura por errores I/O, seguir dándole con reintentos puede hacer la plataforma menos estable. Tu primer movimiento es reducir la presión de escritura:

Detén escritores pesados (bases de datos, recolectores de logs, colas).
Si es un volumen no raíz, desmóntalo si es posible.
Captura evidencia: extracto de logs del kernel, datos SMART, mapeo de lsblk y tabla de montajes.

Prioridad 2: Decide si evacuar o reparar in situ

Seré franco: si ves timeouts de dispositivo repetidos, abortos, resets o contadores SMART en ascenso, evacua primero. Reparar el sistema de archivos sobre hardware poco fiable es apostar, y la física siempre gana.

Prioridad 3: Usa la herramienta correcta, en el modo correcto, en el momento correcto

ext4: fsck.ext4 (o e2fsck). Empieza con una comprobación en solo lectura cuando puedas.
XFS: xfs_repair. Si el sistema de archivos estuvo montado, debes desmontarlo. XFS repair puede ser destructivo si se usa mal.
btrfs: la recuperación es otra guía (scrub, check, estadísticas de dispositivo). No apliques consejos de ext4 a ciegas.

Prioridad 4: Remonta en lectura-escritura solo después de eliminar la causa

Remontar rw no es una solución. Es una decisión de reanudar escrituras. Hazlo solo cuando:

la capa de dispositivo esté estable (sin I/O errors/tiempos de espera), y
el sistema de archivos esté consistente (fsck/reproducción completados), y
hayas aceptado el riesgo (o hayas migrado fuera).

Broma #2: La forma más rápida de que un sistema de archivos vuelva a ser escribible es invitarlo a cenar y prometer que no ignorarás las advertencias SMART la próxima vez.

Listas de verificación / plan paso a paso

Lista A: Triage en sistema en vivo (5–10 minutos)

Identifica el montaje que falla: findmnt -T /path
Confirma que realmente es ro: findmnt -no OPTIONS /mount
Extrae la línea desencadenante de los logs del kernel: journalctl -k -b filtra por errores I/O y eventos de remount
Mapea dm/LVM a dispositivos físicos: lsblk
Instantánea de salud del dispositivo: smartctl -a (o herramientas del proveedor si procede)
Reduce escrituras: detén servicios; considera cambiar a modo solo lectura en la capa de la aplicación
Decide: evacuar vs intentar reparar

Lista B: Recuperación controlada para ext4 en un montaje no raíz

Detén servicios que usan el montaje (bases de datos primero).
Intenta un desmontaje limpio:
```
cr0x@server:~$ umount /var
umount: /var: target is busy.
```
Significado: Algo todavía mantiene archivos abiertos.

Decisión: Identifica y detén a los ofensores antes de forzar nada.

Encuentra archivos abiertos:

cr0x@server:~$ lsof +f -- /var | head
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd  612 syslog  1w   REG  253,2  1048576  123 /var/log/syslog

Significado: El logging sigue escribiendo.

Decisión: Detén rsyslog/journald persistence (con cuidado), o redirige logs temporalmente.

Una vez desmontado, ejecuta un pase de fsck en solo lectura:

cr0x@server:~$ fsck.ext4 -fn /dev/mapper/vg0-var
e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
Inode 513124 has illegal block(s).  Clear? no

/dev/mapper/vg0-var: ********** WARNING: Filesystem still has errors **********
/dev/mapper/vg0-var: 123456/13107200 files, 9876543/52428800 blocks

Significado: Existen errores; -n se negó a modificar. Bien. Ahora sabes que se necesita reparación.

Decisión: Si el hardware está estable y tienes backups/evacuación, procede con una reparación real. Si no está estable, evacua primero.

Repara con fsck (esto modificará estructuras en disco):

cr0x@server:~$ fsck.ext4 -fy /dev/mapper/vg0-var
e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
Inode 513124 has illegal block(s).  Clear? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/vg0-var: FILE SYSTEM WAS MODIFIED
/dev/mapper/vg0-var: 123455/13107200 files, 9876501/52428800 blocks

Significado: Se aplicaron reparaciones.

Decisión: Remonta y valida el comportamiento de la aplicación, pero sigue investigando el desencadenante original (especialmente si hubo errores I/O).

Remonta:
```
cr0x@server:~$ mount /var
```
Significado: Si esto tiene éxito y monta rw, el sistema de archivos volvió.

Decisión: Mantén el host bajo observación y programa chequeos más profundos. Un sistema de archivos reparado en un disco cuestionable no está “resuelto”, está “temporalmente coherente”.

Lista C: Recuperación del sistema raíz (versión reality)

Si la raíz (/) está en solo lectura y no puedes recuperarla en línea, usa un entorno de arranque de recuperación. Dependiendo de tu entorno, eso es acceso por consola vía gestión remota, una ISO de rescate o shell initramfs.

Arranca en modo rescue/emergency (o una imagen live) y asegúrate de que el sistema raíz no esté montado como lectura-escritura.

Identifica el dispositivo de bloque raíz:

cr0x@server:~$ blkid | egrep 'ext4|xfs|btrfs|LVM2_member'
/dev/nvme0n1p2: UUID="..." TYPE="LVM2_member"
/dev/mapper/vg0-root: UUID="..." TYPE="ext4"

Significado: La raíz es un LV ext4.

Decisión: Procede con el flujo de trabajo ext4.

Ejecuta fsck offline:
```
cr0x@server:~$ fsck.ext4 -fy /dev/mapper/vg0-root
e2fsck 1.47.2 (1-Jan-2025)
/dev/mapper/vg0-root: recovering journal
/dev/mapper/vg0-root: clean
```
Significado: La reproducción del journal tuvo éxito; el sistema de archivos ahora es coherente.

Decisión: Reinicia normalmente. Si viste errores de dispositivo antes, no declares victoria; planifica remediación de hardware.

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

Error 1: “Todo es solo lectura” tras un único error de la aplicación

Síntoma: Un servicio registra “Read-only file system”, pero findmnt muestra el sistema de archivos como rw.

Causa raíz: El servicio escribe en otro montaje (bind mount, overlay de contenedor), o escribe en una exportación NFS de solo lectura, o un problema de permisos/política se reporta como “solo lectura”.

Solución: Usa findmnt -T /path y verifica montajes de contenedores. Confirma con una prueba de escritura directa en el mismo namespace del proceso.

Error 2: Reinicio inmediato para “limpiar” el solo lectura

Síntoma: La máquina pasa a ro; alguien reinicia; vuelve; el incidente “resuelto”… hasta que no lo está.

Causa raíz: El reinicio borra el síntoma pero destruye contexto forense y puede empeorar la corrupción si el dispositivo está fallando.

Solución: Antes de reiniciar: captura journalctl -k, smartctl y mapeo de dispositivos. Si es VM, revisa el estado del datastore del hipervisor. Luego decide reparar vs evacuar.

Error 3: Ejecutar fsck en un sistema de archivos montado

Síntoma: Alguien ejecuta fsck.ext4 sobre /dev/mapper/vg0-var mientras /var sigue montado.

Causa raíz: Pánico + memoria muscular.

Solución: Desmonta primero (o arranca en recuperación). Si no puedes desmontar porque está ocupado, detén servicios; si es la raíz, usa recuperación offline.

Error 4: “Es corrupción del sistema de archivos” cuando en realidad es transporte de almacenamiento

Síntoma: ext4 abortó el journal; fsck “arregla” y vuelve a ocurrir al día siguiente.

Causa raíz: Errores I/O/tiempos de espera en el dispositivo subyacente: NVMe, enlace SATA, firmware HBA, flaps SAN.

Solución: Trata los errores I/O como primarios. Reemplaza disco, actualiza firmware, re-asienta cables/backplane, investiga multipath. Luego repara el sistema de archivos.

Error 5: Remontar rw y continuar con escrituras pesadas para “comprar tiempo”

Síntoma: mount -o remount,rw tiene éxito y todo parece bien por 20 minutos.

Causa raíz: La condición de error sigue presente; la siguiente escritura de metadata fallida te devuelve a solo lectura, a veces con más daño.

Solución: Usa remount rw solo como paso controlado para evacuación de datos o validación post-reparación. No reanudes la carga normal hasta abordar el desencadenante.

Error 6: Ignorar un sistema de archivos lleno porque “solo lectura es el problema real”

Síntoma: /var está al 100%, los servicios fallan y luego el sistema de archivos se comporta raro.

Causa raíz: La presión de espacio causa caídas de aplicaciones y churn de metadata; combinado con un crash, puede dejar el sistema de archivos en estado que necesita recuperación. Además puede hacer que el logging se detenga justo cuando lo necesitas.

Solución: Resuelve la presión de espacio como parte del triage: libera espacio con seguridad, añade capacidad, separa logs y aplica retención.

Preguntas frecuentes

1) ¿Por qué Debian remonta ext4 como solo lectura en lugar de fallar solo una escritura?

Porque la integridad de metadata importa. Si ext4 detecta condiciones que implican inconsistencia (o no puede asegurar transacciones del journal), continuar escribiendo arriesga expandir la corrupción. Solo lectura es contención.

2) ¿Puedo simplemente ejecutar `mount -o remount,rw` y seguir?

Puedes, pero estás apostando explícitamente que la causa subyacente desapareció. Si los logs del kernel muestran errores I/O o timeouts, esa apuesta suele ser errónea. Usa remount rw para evacuación controlada, no para negación.

3) Si `fsck` lo arregla, ¿significa que el hardware está bien?

No. Los sistemas de archivos suelen fallar “después” de que un dispositivo falló “antes”. Un resultado limpio de fsck solo dice que la estructura en disco es coherente en ese momento. Revisa SMART, errores I/O del kernel y logs de la plataforma.

4) ¿Cómo sé si fue una pérdida de energía versus un disco muriendo?

La pérdida de energía normalmente muestra apagado no limpio y necesidad de reproducción de journal, pero no timeouts/resets repetidos del dispositivo. Un disco muriendo muestra errores I/O, abortos, resets o contadores SMART en ascenso.

5) ¿Por qué veo esto dentro de un contenedor cuando el sistema host está bien?

Los contenedores usan frecuentemente OverlayFS. Si el upperdir del overlay está en un sistema de archivos que pasó a solo lectura, el contenedor verá comportamiento de solo lectura. Además, algunas imágenes montan rutas intencionadamente en solo lectura.

6) ¿Cuál es el primer comando fsck más seguro para ext4?

Empieza con una comprobación no destructiva en solo lectura: fsck.ext4 -fn /dev/DEVICE. Te indica si se necesitan reparaciones sin modificar nada. Luego decide cuándo y dónde ejecutar reparaciones reales.

7) ¿XFS hace el mismo comportamiento de “remontar ro”?

Mecanismo distinto, misma intención. XFS puede forzar el apagado del sistema de archivos ante ciertos errores; el resultado es funcionalmente similar: las escrituras fallan y el sistema debe repararse offline con xfs_repair.

8) ¿Mantengo el sistema activo para copiar datos o lo apago inmediatamente?

Si el dispositivo está activamente fallando (loops de timeouts/reset), minimiza la actividad y prioriza la evacuación. Si está estable pero el sistema de archivos es ro, a menudo puedes mantenerlo lo suficiente para recopilar logs y planear una reparación controlada.

9) ¿Y si la raíz está en solo lectura y no puedo iniciar sesión normalmente?

Usa acceso por consola y arranca en rescue/emergency. Si caes en initramfs aún puedes inspeccionar logs (a veces limitados) y ejecutar comprobaciones offline una vez el dispositivo sea visible.

10) Después de la recuperación, ¿qué debo monitorizar para detectar esto antes?

Como mínimo: patrones en logs del kernel por errores I/O y “remounting filesystem read-only”, contadores críticos SMART y latencia/tiempos de espera de almacenamiento. También alerta por sistemas de archivos cercanos a capacidad, especialmente /var.

Próximos pasos que puedes hacer hoy

Añade un hook de detección: alerta en mensajes del kernel que incluyan “Remounting filesystem read-only” y errores I/O de la capa de bloque.
Practica la ruta de recuperación: confirma que puedes arrancar en modo rescue y acceder a volúmenes encriptados/LVM con tus credenciales operativas reales.
Separa radios de explosión: considera montajes separados para /var, bases de datos y logs, dimensionados con margen realista.
Haz que la evacuación sea rutinaria: documenta cómo fallar o mover cargas cuando el almacenamiento de un host empiece a mentir.
Deja de confiar en “ya volvió” como resolución: tras cualquier remonte a ro, exige una nota de causa raíz: línea desencadenante del sistema de archivos, instantánea de salud del dispositivo y decisión de remediación.

El cambio a solo lectura es la forma en que el kernel dice: “No voy a ayudarte a destruir tus propios datos.” Hazle caso. Diagnostica el desencadenante, estabiliza el almacenamiento, repara offline cuando haga falta y solo entonces reanuda las escrituras normales.