Debian 13: Sistema de archivos montado como solo lectura tras errores — pasos de recuperación que minimizan el daño

octubre 7, 2025 • febrero 3, 2026 • Lectura: 31 min • Views: 7

¿Te fue útil?

Un minuto tu servicio funciona bien. Al siguiente minuto falla al escribir archivos PID, los logs dejan de avanzar y tu pipeline de despliegue empieza a gritar “Read-only file system.” El kernel no se volvió poético de la noche a la mañana; está protegiendo tus datos negándose a empeorar la situación.

Esta guía explica qué hacer a continuación en Debian 13 cuando un sistema de archivos pasa a solo lectura tras errores. No es el folklore de “ejecuta fsck y reza.” Son pasos reales para minimizar daños: diagnosticar el modo de fallo, preservar evidencia, elegir la vía de reparación menos destructiva y solo entonces volver a permitir escrituras en producción.

Qué significa realmente “montado como solo lectura” (y qué no significa)

En Debian 13 (y en Linux en general), que un sistema de archivos pase a solo lectura suele ser el kernel o el controlador del sistema de archivos decidiendo que seguir escribiendo arriesga convertir un problema recuperable en pérdida permanente. Piénsalo como un interruptor automático para la integridad de los metadatos.

Dos formas comunes de acabar aquí

Remontado automático como solo lectura: el sistema de archivos estaba montado como lectura/escritura, sufrió un error serio y el kernel lo remontó como solo lectura (ext4 hace esto con frecuencia). Verás logs como “Remounting filesystem read-only” o “Aborting journal.”
Montado solo lectura desde el inicio: problemas en el arranque, opciones de montaje explícitas ro, modo de emergencia de systemd o lógica de initramfs decidieron que es más seguro mantenerlo en solo lectura hasta repararlo.

Lo que no garantiza

Sólo porque está en solo lectura no significa que “los datos estén a salvo.” Significa “paramos para no empeorar las cosas.” Si el disco subyacente está fallando o tu RAID está degradado y aún acepta escrituras en lugares erróneos, puedes perder más datos incluso leyendo agresivamente (timeouts, resets, bugs del controlador, etc.).

Además: un montaje en solo lectura no impide todo tipo de cambios de estado. Algunos subsistemas aún pueden actualizar cosas fuera del sistema de archivos (caches de escritura del dispositivo, metadatos del RAID, tablas de firmware de la unidad). La mentalidad correcta es: preservar evidencia, minimizar escrituras y actuar de forma deliberada.

Hechos e historia: por qué Linux hace esto

Un poco de contexto te ayuda a tomar mejores decisiones a las 3 a.m. Aquí van hechos cortos y concretos que explican por qué tu caja Debian actúa “sobreprotectora.”

ext2 no tenía journaling. Antiguamente, la pérdida de energía significaba largos runs de fsck y posibilidad real de perder metadatos. Los sistemas de archivos con journaling (ext3/ext4) redujeron esto pero añadieron el concepto de “journal abort.”
ext3 popularizó el journaling en Linux. ext3 (principios de los 2000) introdujo journaling en la familia ext; ext4 mejoró asignación y escalabilidad pero mantuvo la válvula de seguridad de “abort journal y remount ro.”
XFS nació en el mundo UNIX de alto rendimiento. XFS se originó en SGI y tiene una visión estricta de la integridad de metadatos. Cuando detecta corrupción, con frecuencia fuerza el apagado para detener más daño.
Btrfs trata los checksums como ciudadanos de primera clase. Puede detectar corrupción silenciosa mediante checksums y, con redundancia, autorrepararse. Sin redundancia, los checksums principalmente te avisan de que estás en problemas.
El VFS del kernel intenta mantener el sistema vivo. Remontar un sistema de archivos como solo lectura suele ser menos disruptivo que provocar un panic del kernel o un crash duro del nodo.
Las caches de escritura del disco pueden mentir. Un disco puede reconocer una escritura antes de que esté en almacenamiento estable. La pérdida de energía más el comportamiento de caches es una receta clásica para problemas con el journal.
Los controladores RAID pueden “ayudar” de formas nocivas. Algunos firmwares de controladoras reintentan, remapean o reordenan operaciones, enmascarando problemas hasta que el sistema de archivos tropieza con resultados inconsistentes.
“Errors=remount-ro” es una política, no el destino final. Para ext4, la opción de montaje errors=remount-ro indica al kernel qué hacer ante ciertos errores. Puedes elegir panic o continuar, pero “continuar” es cómo se produce corrupción creativa.

Una frase para mantener la calma: La esperanza no es una estrategia. (idea parafraseada, común en círculos de operaciones)

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

Esta es la secuencia de “deja de adivinar.” El objetivo es identificar qué capa está fallando: metadatos del sistema de archivos, dispositivo de bloques, RAID/LVM o algo más arriba como quedarse sin espacio interpretado erróneamente como corrupción.

Primero: confirma ámbito e impacto (30–90 segundos)

¿Es solo un punto de montaje o son varios?
¿Está afectado el root o solo un volumen de datos?
¿Falla la aplicación porque no puede escribir, o porque el dispositivo está entrando en timeouts?

Segundo: lee la historia que cuenta el kernel (2–5 minutos)

Busca I/O error, Buffer I/O error, EXT4-fs error, XFS (dm-*) forced shutdown, reinicios NVMe, datos de sentido SCSI.
Decide si esto es un fallo de medio (hardware) o un fallo de metadatos/consistencia (nivel de sistema de archivos).

Tercero: decide si puedes permanecer en línea o debes detener escrituras ahora

Si ves reinicios repetidos del dispositivo, errores de medio o degradación de RAID: prioriza imagen/copia de seguridad y minimizar lecturas/escrituras.
Si es un aborto limpio del journal tras un apagado no controlado y el disco está sano: puedes planear una ventana de reparación controlada.

Regla: Si aún no sabes si el dispositivo de bloques es estable, no ejecutes herramientas de reparación destructivas. Una “reparación” en un disco que falla suele ser la vía rápida para convertir datos parciales en confeti.

Estabilizar al paciente: detener la hemorragia sin pánico

Cuando un sistema de archivos está en solo lectura, la tentación es remontarlo como lectura/escritura y seguir. Esa es una buena forma de aprender a qué huele la corrupción. Debes hacer lo contrario: reducir variables.

Prioridades de estabilización

Capturar evidencia: logs del kernel, estado de montajes, estado RAID/LVM, salud SMART/NVMe.
Detener escrituras innecesarias: detener servicios ruidosos, deshabilitar spam de logs, evitar “scripts de limpieza” que golpeen el disco.
Decidir un límite seguro para snapshot/backup: snapshot LVM, snapshot de VM, snapshot de array de almacenamiento o al menos una copia de archivos críticos.
Sólo entonces reparar: elige la herramienta adecuada para tu sistema de archivos y escenario.

Broma #1: El sistema de archivos pasó a solo lectura porque quiere más a tus datos que a tu uptime. Es el único subsistema en el servidor con límites saludables.

Tareas prácticas (comandos, significado de salida, decisiones)

A continuación hay tareas prácticas que puedes ejecutar en Debian 13. Cada una incluye: un comando, qué significa la salida típica y la decisión que debes tomar. Úsalas como lista de incidentes, no como buffet.

Task 1: Verificar qué está realmente montado como solo lectura

cr0x@server:~$ findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | sed -n '1,5p'
TARGET SOURCE        FSTYPE OPTIONS
/      /dev/sda2     ext4   rw,relatime,errors=remount-ro
/var   /dev/vg0/var  xfs    ro,relatime,attr2,inode64,logbufs=8,logbsize=32k
/home  /dev/sdb1     ext4   rw,relatime

Qué significa: /var está actualmente montado ro. Root sigue siendo rw, pero tiene errors=remount-ro por lo que también podría cambiar.

Decisión: Delimita el radio de impacto. Si solo un punto de datos está en ro, puedes mantener el sistema en línea mientras haces triage. Si root está en ro, prepárate para modo mantenimiento.

Task 2: Confirmar que el kernel lo remontó como solo lectura (y por qué)

cr0x@server:~$ journalctl -k -b --no-pager | tail -n 40
Dec 29 02:11:06 server kernel: XFS (dm-2): metadata I/O error in "xlog_iodone" at daddr 0x1a2c8 len 16 error 5
Dec 29 02:11:06 server kernel: XFS (dm-2): Log I/O Error Detected. Shutting down filesystem
Dec 29 02:11:06 server kernel: XFS (dm-2): Please unmount the filesystem and rectify the problem(s)
Dec 29 02:11:06 server kernel: XFS (dm-2): Corruption of in-memory data detected. Shutting down filesystem
Dec 29 02:11:06 server kernel: XFS (dm-2): Filesystem has been shut down due to log error (0x2).
Dec 29 02:11:07 server kernel: systemd-journald[301]: Failed to write entry (22 items, 812 bytes), ignoring: Read-only file system

Qué significa: XFS detectó un error de I/O en el log. Eso a menudo no es “XFS está roto,” es “la capa de bloques no entregó lecturas/escrituras consistentes.” Error 5 es EIO.

Decisión: Trátalo primero como posible inestabilidad de almacenamiento. No te apresures a ejecutar xfs_repair hasta que hayas comprobado los dispositivos subyacentes.

Task 3: Buscar errores y reinicios de dispositivo obvios

cr0x@server:~$ dmesg -T | egrep -i 'blk_update_request|I/O error|reset|nvme|medium error|critical medium|sense key' | tail -n 30
[Sun Dec 29 02:10:58 2025] nvme nvme0: I/O 112 QID 4 timeout, aborting
[Sun Dec 29 02:10:58 2025] nvme nvme0: Abort status: 0x371
[Sun Dec 29 02:10:59 2025] nvme nvme0: Resetting controller
[Sun Dec 29 02:11:06 2025] blk_update_request: I/O error, dev dm-2, sector 171720 write
[Sun Dec 29 02:11:06 2025] XFS (dm-2): Log I/O Error Detected. Shutting down filesystem

Qué significa: Timeouts NVMe y resets del controlador se correlacionan con el cierre del sistema de archivos.

Decisión: Asume problema en la ruta de hardware hasta que se demuestre lo contrario. Planifica copia/imaging primero y luego reparación.

Task 4: Mapear el punto de montaje afectado a la pila real de dispositivos de bloque

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,PKNAME
NAME           TYPE  SIZE FSTYPE MOUNTPOINTS PKNAME
sda            disk  1.8T                    -
sda2           part  1.8T ext4   /           sda
nvme0n1        disk  1.9T                    -
nvme0n1p1      part    1G vfat   /boot/efi   nvme0n1
nvme0n1p2      part  1.9T LVM2_member        nvme0n1
vg0-var        lvm   800G xfs    /var        -
vg0-data       lvm  1000G ext4   /data       -

Qué significa: /var es XFS en un LV de LVM respaldado por nvme0n1p2. Los errores de disco arriba son relevantes.

Decisión: Tu plan de reparación debe incluir comprobaciones de salud NVMe y posiblemente mover datos fuera de ese dispositivo.

Task 5: Comprobar salud de LVM y si puedes snapshot de forma segura

cr0x@server:~$ vgs; lvs -a -o +devices
  VG  #PV #LV #SN Attr   VSize VFree
  vg0   1   2   0 wz--n- 1.90t 120.00g
  LV   VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  var  vg0 -wi-ao---- 800.00g                                                     /dev/nvme0n1p2(0)
  data vg0 -wi-ao---- 1000.00g                                                    /dev/nvme0n1p2(204800)

Qué significa: Tienes 120G libres en el VG. Eso es espacio potencial para snapshot, pero los snapshots no son mágicos: en un dispositivo inestable, la actividad CoW puede empeorar la situación.

Decisión: Si el dispositivo es estable y necesitas un punto de reversión, haz snapshot. Si el disco está en timeouts, evita snapshots y haz backup/imagen externa en su lugar.

Task 6: Comprobar salud NVMe (dispositivos NVMe)

cr0x@server:~$ nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0x01
temperature                         : 49 C
available_spare                     : 96%
percentage_used                     : 21%
media_errors                        : 12
num_err_log_entries                 : 187
warning_temp_time                   : 0
critical_comp_time                  : 0

Qué significa: critical_warning 0x01 no es buena señal, y media_errors es un indicio claro. El controlador admite fallos en la capa NAND/media.

Decisión: Trata esto como fallo inminente del dispositivo. Prioriza copiar datos fuera. Las reparaciones pueden “funcionar” y aun así dejarte con un ladrillo con temporizador.

Task 7: Comprobar salud SMART (dispositivos SATA/SAS)

cr0x@server:~$ smartctl -a /dev/sda | egrep -i 'SMART overall|Reallocated_Sector|Current_Pending_Sector|Offline_Uncorrectable|CRC_Error_Count'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Qué significa: “PASSED” no es una garantía. Sectores pendientes/incorrectables indican que la unidad no pudo leer datos de forma fiable y no los ha remapeado.

Decisión: Si el sistema de archivos afectado vive aquí, planifica reemplazo y migración de datos. Si no, mantén la unidad en vigilancia.

Task 8: Confirmar espacio libre y agotamiento de inodos (sí, esto puede desencadenar cascadas)

cr0x@server:~$ df -hT /var; df -i /var
Filesystem          Type  Size  Used Avail Use% Mounted on
/dev/mapper/vg0-var xfs   800G  799G  1.2G 100% /var
Filesystem          Inodes  IUsed   IFree IUse% Mounted on
/dev/mapper/vg0-var       0      0       0     - /var

Qué significa: XFS no reporta cuentas de inodos como ext4, pero lo clave es el uso 100%. Los sistemas llenos desencadenan comportamientos extraños en aplicaciones y pueden exponer bugs latentes, aunque típicamente no fuerzan un remontado en solo lectura por sí solos.

Decisión: Si está lleno, aún necesitas liberar espacio después de estabilizar el dispositivo y verificar que no sea un escenario de error de I/O. No borres archivos al azar en un sistema potencialmente corrupto a menos que hayas decidido que es seguro escribir.

Task 9: Buscar degradación RAID (mdadm)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid10]
md0 : active raid1 sdb1[0] sdc1[1]
      976630336 blocks super 1.2 [2/2] [UU]

md1 : active raid10 sdd1[0] sde1[1] sdf1[2] sdg1[3]
      3906885632 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]
      [>....................]  recovery =  5.1% (100000000/1953442816) finish=240.0min speed=120000K/sec

Qué significa: md1 está degradado ([4/3]). Se está ejecutando la recuperación, lo cual es I/O intenso y puede amplificar problemas latentes de disco.

Decisión: Considera pausar la recuperación si está empeorando la situación y necesitas extraer datos primero. Eso depende del caso; no la pauses si estás a un disco de la pérdida total.

Task 10: Ver la visión de systemd (¿arrancaste en modo de emergencia porque fsck falló?)

cr0x@server:~$ systemctl --failed
  UNIT                      LOAD   ACTIVE SUB    DESCRIPTION
● systemd-fsck@dev-disk-by\x2duuid-1a2b.service loaded failed failed File System Check on /dev/disk/by-uuid/1a2b
● var.mount                 loaded failed failed /var

Qué significa: Una unidad fsck de arranque falló y el montaje falló. Debian puede entrar en modo de emergencia o seguir con montajes parciales según la configuración.

Decisión: No sigas reiniciando esperando que “se arregle solo.” Averigua por qué fsck falló: dispositivo equivocado, driver faltante, corrupción real o disco moribundo.

Task 11: Identificar qué proceso sigue intentando escribir (y fallando)

cr0x@server:~$ journalctl -b --no-pager | egrep -i 'Read-only file system|EROFS' | tail -n 20
Dec 29 02:11:07 server systemd[1]: Failed to start Rotate log files.
Dec 29 02:11:08 server nginx[1337]: open() "/var/log/nginx/access.log" failed (30: Read-only file system)
Dec 29 02:11:09 server postgres[2020]: could not write lock file "postmaster.pid": Read-only file system

Qué significa: Tus apps están golpeando escrituras. Eso puede aumentar ruido y confusión (reintentos, timeouts, fallos en cascada).

Decisión: Detén los servicios de alta churn de forma ordenada. La mejor reparación es la realizada en un sistema tranquilo.

Task 12: Si es ext4: inspeccionar estado del sistema de archivos sin escribir

cr0x@server:~$ tune2fs -l /dev/sda2 | egrep -i 'Filesystem state|Errors behavior|Last mount time|Last checked|Mount count'
Filesystem state:         clean with errors
Errors behavior:          Remount read-only
Last mount time:          Sun Dec 29 02:05:10 2025
Last checked:             Wed Nov  6 10:12:44 2025
Mount count:              31
Maximum mount count:      -1

Qué significa: ext4 piensa que está “clean with errors”, que básicamente es “el journal dice que pares de fingir.”

Decisión: Planifica un fsck offline (sistema de archivos desmontado). Si el disco subyacente parece poco sano, haz una imagen primero.

Task 13: Si es XFS: comprobar si el log necesita replay (chequeo de solo lectura)

cr0x@server:~$ xfs_repair -n /dev/mapper/vg0-var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed.
Mount the filesystem to replay the log, and unmount it before re-running xfs_repair.

Qué significa: XFS detectó transacciones pendientes en el log. Normalmente, el montaje reproducirá el log. Pero si el I/O del log fue el problema, el replay puede fallar o volver a provocar el cierre.

Decisión: Si el dispositivo es estable ahora, puedes intentar montar (posiblemente en solo lectura) para reproducir el log. Si no es estable, prioriza backup/imaging y luego considera xfs_repair sabiendo que puede descartar datos del log si se fuerza.

Task 14: Si es Btrfs: chequeo en solo lectura y estado de scrub

cr0x@server:~$ btrfs device stats /data
[/dev/sdb1].write_io_errs    0
[/dev/sdb1].read_io_errs     3
[/dev/sdb1].flush_io_errs    0
[/dev/sdb1].corruption_errs  1
[/dev/sdb1].generation_errs  0

Qué significa: Btrfs está viendo errores de lectura y corrupción. Con redundancia (RAID1/10) podría autorrepararse; sin ella, simplemente te dice “puedo detectar la pudrición, no curarla.”

Decisión: Si hay redundancia, ejecuta scrub y reemplaza el dispositivo malo. Si no hay redundancia, restaura desde backup o copia lo que puedas y luego reconstruye.

Task 15: Hacer un workaround seguro y mínimo para “tener logs reescribibles” (tmpfs)

cr0x@server:~$ mount -t tmpfs -o mode=0755,size=512M tmpfs /mnt/tmp-logs
cr0x@server:~$ systemctl stop nginx postgresql
cr0x@server:~$ ln -sfn /mnt/tmp-logs /var/log

Qué significa: Estás redirigiendo logs a RAM para mantener un nodo a trompicones para diagnóstico sin escribir en el sistema sospechoso. Es una cura temporal, no la solución.

Decisión: Úsalo solo si necesitas mantener servicios mínimos brevemente. Prefiere fallar sobre otro nodo si dispones de uno.

Task 16: Capturar una snapshot forense de logs y estado (bajo riesgo)

cr0x@server:~$ mkdir -p /root/ro-incident
cr0x@server:~$ journalctl -b --no-pager > /root/ro-incident/journal.txt
cr0x@server:~$ findmnt -a > /root/ro-incident/findmnt.txt
cr0x@server:~$ lsblk -f > /root/ro-incident/lsblk.txt

Qué significa: Guardaste la historia mientras está fresca. Si el siguiente reinicio cambia nombres de dispositivos o la máquina no vuelve, aún tienes pistas.

Decisión: Si el almacenamiento es inestable, copia este directorio fuera del host (scp a un bastión, adjunta al ticket, etc.).

Estrategias de reparación por sistema de archivos (ext4, XFS, Btrfs)

Los distintos sistemas de archivos tienen comportamientos de fallo diferentes. Usar el enfoque de reparación equivocado es la forma de transformar un incidente manejable en una restauración de varios días. Tu principio guía: repara offline siempre que sea posible, y nunca repares en un dispositivo que no confíes.

ext4: aborto del journal y “errors=remount-ro”

ext4 suele remontar como solo lectura después de detectar un error lo suficientemente serio para abortar el journal. A menudo se dispara por errores de I/O, a veces por bugs, y ocasionalmente por “tu disco devolvió basura.” ext4 es conservador. Escúchalo.

Ruta preferida para ext4

Confirma que la pila de dispositivos es estable (SMART/NVMe, dmesg, estado RAID).
Programa downtime o arranca en modo rescue para que el sistema de archivos objetivo esté desmontado.
Ejecuta primero un chequeo no destructivo (fsck sin arreglos automáticos si quieres visibilidad).
Ejecuta una pasada de reparación y luego vuelve a comprobar.

cr0x@server:~$ umount /dev/sda2
umount: /: target is busy.

Significado: No puedes desmontar root mientras corre. Usa un boot de rescue, shell de initramfs o adjunta el volumen a otro host.

cr0x@server:~$ fsck.ext4 -f -n /dev/sda2
e2fsck 1.47.2 (1-Jan-2025)
/dev/sda2: clean, 812345/122101760 files, 44444444/488378368 blocks

Significado: “clean” es buena señal. Si reporta errores en modo -n, tienes una decisión: reparar ahora, o imagear primero si el hardware es sospechoso.

cr0x@server:~$ fsck.ext4 -f -y /dev/sda2
e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
Inode 1234567 has illegal block(s).  Clear? yes
Pass 2: Checking directory structure
Entry 'tmp' in /var/tmp (98765) has deleted/unused inode 1234567.  Clear? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****

Significado: Se realizaron reparaciones. Ahora debes ejecutar fsck una segunda vez hasta que reporte limpio, porque las correcciones de la primera pasada pueden descubrir más.

Decisión: Si sigue encontrando nuevos problemas en cada ejecución, para y reevalúa el hardware. Los sistemas de archivos no suelen “generar” errores infinitos en medios estables.

XFS: cierre forzado y problemas de log

XFS no ejecuta fsck en tiempo de montaje como lo hacen los ext. Su journal (log) es integral, y XFS es intolerante con errores de I/O en el log. Eso es bueno para la corrección, molesto para el uptime.

Ruta preferida para XFS

Arregla primero la ruta de almacenamiento: cables, resets de controlador, NVMe fallando, RAID degradado, multipath inestable.
Intenta un desmontaje limpio si es posible. Si está ocupado y ya cerrado, detén servicios y desmonta.
Intenta montar para reproducir el log (si es seguro). Si el montaje falla, pasa a reparación.
Ejecuta xfs_repair. Considera zeroear el log solo como último recurso.

cr0x@server:~$ fuser -vm /var
                     USER        PID ACCESS COMMAND
/var:                root      1022 f....  rsyslogd
                     postgres   2020 f....  postgres
                     root      1337 f....  nginx

Significado: Estos procesos mantienen el punto de montaje ocupado.

Decisión: Deténlos. Si no puedes, no estás haciendo “reparación”, estás haciendo “investigación de corrupción no planificada”.

cr0x@server:~$ systemctl stop rsyslog nginx postgresql
cr0x@server:~$ umount /var
cr0x@server:~$ xfs_repair /dev/mapper/vg0-var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
Phase 3 - for each AG...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify and correct link counts...
done

Significado: La reparación tuvo éxito. Eso no significa que el almacenamiento sea sano. Significa que XFS pudo construir metadatos consistentes con lo que ve.

Decisión: Remonta y valida datos de aplicación. Si persisten errores de I/O, migra inmediatamente.

Sobre xfs_repair -L: Puede limpiar el log (“zero log”). Esto puede descartar cambios metadata recientes. Podría ser aceptable en un volumen cache; es catastrófico en un volumen de base de datos. Usa solo si aceptas pérdida de datos.

Btrfs: modo solo lectura, checksums, scrub y la regla de “no reparar a la ligera”

Btrfs es potente, pero tiene aristas. La más relevante operativa: btrfs check --repair no es una herramienta rutinaria. En muchos entornos, la acción preferida es: montar en solo lectura, copiar los datos y reconstruir.

Ruta preferida para Btrfs

Montar en solo lectura si no está ya.
Si hay redundancia, ejecutar scrub para sanar.
Reemplazar dispositivos defectuosos y luego volver a scrubear.
Si no hay redundancia y existe corrupción: copiar los datos críticos y recrear el sistema de archivos.

cr0x@server:~$ mount -o ro,subvolid=5 /dev/sdb1 /mnt
cr0x@server:~$ btrfs scrub start -Bd /mnt
scrub started on /mnt, fsid 1b2c3d4e-....
Starting scrub on devid 1
Scrub device /dev/sdb1 (id 1) done
Scrub started:    Sun Dec 29 02:20:01 2025
Status:           finished
Duration:         0:10:12
Total to scrub:   900.00GiB
Error summary:    read=3, csum=1, verify=0, super=0, malloc=0, uncorrectable=1

Significado: Hay al menos un error no corregible. Sin una copia espejada, Btrfs no puede recuperar la verdad perdida.

Decisión: Si este volumen importa, restaura desde backup o copia lo que puedas y reconstruye. “Seguir funcionando” es un incidente en cámara lenta.

Cuando no es el sistema de archivos: almacenamiento, RAID y causas a nivel kernel

Los sistemas de archivos suelen llevarse la culpa porque son el mensajero. En realidad, “solo lectura tras errores” con frecuencia es un fallo en la capa de bloques: timeouts, resets, errores de medio o dispositivos virtuales mal comportados.

Modos de fallo que comúnmente se hacen pasar por corrupción del sistema de archivos

Problemas de firmware/controlador NVMe: resets periódicos bajo carga, bugs de APST/estados de energía, estrangulamiento térmico que causa timeouts.
Problemas de enlace SATA/SAS: errores CRC, cables/backplanes inestables, rarezas de expanders. Los errores CRC son una bendición: gritan “problema de transporte”.
Estrés por reconstrucción RAID: la reconstrucción amplifica lecturas; discos débiles fallan durante la reconstrucción; el sistema de archivos recibe lecturas parciales y entra en pánico.
Snapshots LVM thin-provisioned: el snapshot se llena, el dispositivo devuelve errores de I/O y los sistemas de archivos se protegen.
Problemas de almacenamiento en virtualización: flaps de iSCSI, stalls del servidor NFS, picos de latencia del hipervisor. El invitado ve EIO; el sistema de archivos se rinde y pasa a solo lectura.

Reglas rápidas y con opinión

Si ves EIO en dmesg, asume hardware hasta que se demuestre lo contrario. Los sistemas de archivos no inventan EIO por diversión.
Si ves una sola necesidad limpia de replay de journal tras pérdida de energía, asume software hasta que se pruebe lo contrario. Pero aun así comprueba SMART/NVMe. Es un seguro barato.
Si el dispositivo subyacente es inestable, tu “reparación” debe empezar copiando datos fuera. Las herramientas de reparación no son herramientas de backup.

Tres mini-historias corporativas desde las trincheras

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

Tenían una pequeña flota de servidores Debian ejecutando un pipeline analítico con alto volumen de escrituras. Un nodo empezó a remontar /var como solo lectura aproximadamente una vez por semana. El patrón del on-call siempre era el mismo: reiniciar, vuelve, todos siguen.

La suposición era simple: “es solo ext4 actuando raro tras un apagado no limpio.” Hubo un evento de energía un mes antes, y esa historia quedó. A las personas les encanta una narrativa ordenada, sobre todo si es conveniente.

Durante una semana más ocupada, el mismo nodo pasó a solo lectura en medio del ingest. Esta vez, tiró abajo un servicio crítico: el pipeline no podía escribir archivos de spool y las tormentas de reintentos se multiplicaron. Alguien hizo lo que se hace bajo presión: remontó en modo lectura/escritura para “sobrevivir la noche.” Funcionó una hora y luego el sistema de archivos dejó de montarse por completo.

La postmortem fue aburrida y dolorosa. La causa raíz real eran resets intermitentes del controlador NVMe bajo colas sostenidas. El log de salud de la unidad había mostrado errores de media durante semanas, pero nadie lo revisaba porque “SMART siempre dice PASSED.”

Lo que cambió su práctica no fue una herramienta elegante. Fue un pequeño ítem en la checklist: si ves un remontado en solo lectura, siempre comprueba errores del dispositivo y métricas de salud antes de tocar la reparación del sistema de archivos. Dejaron de tratar al kernel como melodramático. La disponibilidad mejoró; sorpresa, también la pérdida de datos.

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

Otro equipo quería límites de reparación rápidos para servicios stateful, así que apostaron fuerte por snapshots LVM. La idea era elegante: snapshot del LV, ejecutar operaciones riesgosas, revertir si hacía falta. Funcionó bien en staging.

Entonces un nodo de producción sufrió un problema de almacenamiento transitorio. El sistema de archivos empezó a lanzar errores y pasó a solo lectura. El on-call siguió el runbook: “crear snapshot antes de reparar.” La creación del snapshot tuvo éxito, pero el espacio libre era escaso.

Con el sistema de archivos ya alterado, la amplificación CoW del snapshot hizo que el disco trabajara más. Las escrituras se acumularon, la latencia subió y el snapshot se llenó rápidamente. Una vez lleno, el snapshot thin convirtió efectivamente futuras escrituras en errores desde la capa de bloques.

El equipo acabó con un problema en dos capas: el error original del sistema de archivos más un cambio en el comportamiento del dispositivo causado por la exhaustión del snapshot. Las aplicaciones vieron EIO y fallaron de formas que parecían corrupción de datos. Su “mecanismo de seguridad” se convirtió en multiplicador de fallos.

La solución no fue “nunca snapshots.” Fue “usar snapshots deliberadamente.” Añadieron un requisito mínimo de espacio libre, monitorización y una regla estricta: si el disco ya está inestable, no añadas complejidad CoW. Imagen externa o failover.

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

Una organización grande ejecutaba nodos Debian como parte de un sistema transaccional. Nada exótico: ext4 en la mayoría de volúmenes, XFS para logs de gran tamaño y append. Su equipo SRE era molesta y consistentemente cuidadoso con dos cosas: checks programados de sistemas de archivos en ventanas de mantenimiento y restauraciones ensayadas.

Una mañana, una actualización del kernel más una desafortunada interrupción eléctrica hizo que un subconjunto de nodos arrancara con sistemas de archivos marcados como sucios. En dos nodos, ext4 abortó el journal y remontó root como solo lectura durante el arranque temprano. La primera respuesta de los equipos de apps fue “simplemente remonta rw.”

El SRE on-call no hizo heroísmos. Siguió el plan aburrido: arrancar en modo rescue, ejecutar fsck offline, validar montajes y luego levantar servicios en orden controlado. Mientras tanto, desviaron tráfico a nodos sanos.

Porque los backups y las restauraciones estaban ensayados, también conocían la salida: si fsck parecía sospechoso o la salud del disco era dudosa, limpiarían y restaurarían en lugar de improvisar. Esa opción cambia la psicología de la respuesta: dejas de apostar.

Volvieron dentro de su SLA interno, y la reunión post-incidente fue casi decepcionantemente tranquila. La lección no fue “somos genios.” Fue “la higiene operativa aburrida convierte el drama en una checklist.”

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

Esta sección es deliberadamente específica. No necesitas consejos más genéricos. Necesitas un emparejamiento de patrones correcto.

1) Síntoma: “Remounting filesystem read-only” tras un pico de escrituras

Causa raíz: aborto del journal de ext4 por errores de I/O subyacentes o timeouts; a veces causado por una ruta de almacenamiento inestable.

Solución: Revisa dmesg/journal por EIO y resets de dispositivos. Ejecuta comprobaciones SMART/NVMe. Si el hardware parece limpio, haz fsck offline. Si no, imagen/migra primero.

2) Síntoma: XFS muestra “Log I/O Error Detected. Shutting down filesystem”

Causa raíz: El almacenamiento no completó confiablemente escrituras/lecturas del log. Podría ser fallo de dispositivo, resets del controlador o problemas en la capa dm.

Solución: Estabiliza la ruta de hardware (reemplaza dispositivo, arregla multipath, pausa rebuild si hace falta). Luego desmonta y ejecuta xfs_repair. Evita -L a menos que aceptes perder transacciones metadata recientes.

3) Síntoma: Btrfs pasa a solo lectura y scrub reporta “uncorrectable”

Causa raíz: Corrupción detectada sin copias redundantes para sanar (o demasiadas fallas).

Solución: Copia lo que puedas, restaura desde backup, reconstruye el sistema de archivos. Si hay redundancia, reemplaza el dispositivo malo y vuelve a scrubear para sanar.

4) Síntoma: el sistema arranca en modo de emergencia; unidades de montaje fallaron

Causa raíz: fsck falló, dispositivo ausente, UUID incorrecto o corrupción real. A veces causado por renombrado de dispositivo tras cambios en RAID/HBA.

Solución: Usa systemctl --failed y journalctl -xb. Verifica UUIDs en /etc/fstab mediante blkid. Repara offline. No entres en bucle de reinicios.

5) Síntoma: sistema de archivos en solo lectura pero el disco parece “bien” y no aparece EIO

Causa raíz: Opciones de montaje (explicit ro), lógica de remount de systemd o una bandera de error previa que no se limpió.

Solución: Revisa findmnt opciones, /etc/fstab y tune2fs -l para el estado ext4. Si el sistema de archivos piensa que tiene errores, haz fsck offline aun cuando el dispositivo parezca estable.

6) Síntoma: tras un fsck “exitoso”, el sistema de archivos vuelve a pasar a solo lectura rápidamente

Causa raíz: El dispositivo subyacente sigue arrojando errores; fsck trató el síntoma, no la enfermedad.

Solución: Vuelve a comprobar SMART/NVMe y logs del kernel después de la reparación. Reemplaza medios sospechosos. Verifica cables/backplane. Si está virtualizado, revisa latencia y estabilidad del host.

7) Síntoma: existe un snapshot LVM thin; de repente aparecen errores de I/O y el FS se cierra

Causa raíz: El snapshot o thin pool se quedó sin espacio; la capa dm devuelve errores; el sistema de archivos se protege.

Solución: Revisa Data%/Meta% de lvs. Extiende el thin pool o elimina snapshot. Luego repara el sistema de archivos si es necesario. Añade monitorización y umbrales.

Listas de verificación / plan paso a paso

Checklist A: Cuando ves por primera vez “Read-only file system” en producción

Detén nuevas escrituras: drena tráfico, pausa jobs por lotes, detén servicios chatos.
Registra estado: guarda logs del kernel, opciones de montaje, topología de dispositivos (journalctl, findmnt, lsblk).
Confirma alcance: qué punto(s) de montaje están ro y qué apps dependen de ellos.
Revisa salud del dispositivo: SMART/NVMe, dmesg por resets/timeouts, estado RAID.
Elige un límite de seguridad: snapshot si es estable, backup/imagen si es inestable.

Checklist B: Plan de reparación controlada (minimizar daño)

Llega a un entorno offline: boot de rescue, shell de initramfs o adjunta el volumen a otro host.
Valida que vas a reparar el dispositivo correcto: mapea mount → LV → PV → disco. Confirma UUID.
Ejecuta un chequeo solo lectura primero donde esté soportado (fsck -n, xfs_repair -n).
Ejecuta la reparación con la herramienta adecuada (fsck.ext4, xfs_repair).
Vuelve a ejecutar la comprobación hasta que esté limpio.
Monta primero en solo lectura y valida datos clave (archivos DB, configuraciones, estado de aplicaciones).
Monta en lectura/escritura, inicia servicios en orden y vigila logs por nuevos errores de I/O.
Monitorización post-recuperación: conteos de error, latencia, estado de rebuild RAID, resets NVMe.

Checklist C: Si el hardware parece malo (plan “salva los datos, no el sistema de archivos”)

Detén servicios para reducir churn y timeouts.
Montar en solo lectura si es posible, copia primero datos críticos (configs, volcados de BD si es seguro, directorios clave).
Imagea el dispositivo de bloque si necesitas recuperación forense (y tienes dónde guardarlo).
Reemplaza el dispositivo, reconstruye RAID/LVM, recrea el sistema de archivos.
Restaura desde backup o desde los datos copiados.

Broma #2: Si tu primer paso de recuperación es “force remount rw”, felicidades—has inventado un nuevo benchmark de destrucción de datos.

Prevención que realmente funciona (y lo que es solo apariencia)

La prevención no es un sermón. Son controles aburridos que mantienen el “remontado en solo lectura” como un incidente aislado en lugar de un repetidor.

Qué funciona

Monitorización de salud de dispositivos en la que confíes: logs de error NVMe, atributos SMART relevantes (pending/uncorrectable/CRC) y alertas por resets/timeouts en logs del kernel.
Higiene RAID: monitoriza degradación, estado de reconstrucción y tasas de error. Las reconstrucciones son cuando los discos débiles confiesan.
Gestión de capacidad: los sistemas llenos no suelen causar remontado en solo lectura directamente, pero provocan errores operativos y thrash de aplicaciones durante incidentes.
Backups restaurables: prueba restauraciones regularmente. La capacidad de reconstruir limpiamente es el mejor antídoto contra reparaciones riesgosas.
Ventanas de mantenimiento para checks de sistema de archivos: especialmente para ext si no ejecutas checks periódicos basados en tiempo.
Diseño de servicios consciente de escrituras: apps que fallan con gracia cuando el almacenamiento es solo lectura (limpian errores, dejan de escribir, degradan funciones) reducen daño colateral.

Qué no funciona (o funciona solo en presentaciones)

Asumir que el journaling significa “sin corrupción.” El journaling ayuda la consistencia de metadatos; no hace confiable al hardware.
Confiar en “SMART PASSED.” Es un estado grueso, no una garantía. Las partes interesantes están en atributos y logs.
Reparar en línea. Algunas herramientas lo permiten, pero el perfil de riesgo es malo. Reparar offline es más lento y más seguro.
Ignorar logs de error de almacenamiento porque “el sistema de archivos es el problema.” Así reemplazas el componente equivocado y repites el incidente.

Preguntas frecuentes

1) ¿Por qué Linux remonta un sistema de archivos como solo lectura en vez de bloquearse?

Porque seguir escribiendo tras errores de metadatos puede causar corrupción en cascada. Remontarlo en solo lectura mantiene el sistema mayormente funcional mientras evita más daño.

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

Puedes, y a veces “funciona” brevemente. Si el error original fue inestabilidad de I/O o aborto de journal, probablemente empeorarás la corrupción. Remonta rw solo después de diagnosticar y corregir la causa subyacente.

3) ¿Cuál es la acción más rápida y segura cuando esto pasa en un servidor de base de datos?

Detén la base de datos de forma ordenada, captura logs y confirma si la capa de almacenamiento está arrojando errores. Si el disco es inestable, prioriza copiar archivos de datos o restaurar desde backups en lugar de maniobras de reparación de sistema de archivos.

4) ext4 dice “clean with errors.” ¿Es contradictorio?

Significa que el sistema de archivos está limpiamente desmontado o parece consistente, pero se registraron errores (a menudo por aborto de journal o inconsistencias detectadas). Trátalo como “necesita fsck offline.”

5) XFS dice montar para reproducir el log, pero montar provocó el cierre antes. ¿Y ahora?

Arregla primero la ruta de almacenamiento. Si no puedes estabilizar el almacenamiento, el replay puede seguir fallando. Tras lograr estabilidad, intenta montar (posiblemente en solo lectura) para el replay, luego desmonta y ejecuta xfs_repair. Usa xfs_repair -L solo si aceptas perder metadata reciente.

6) Para Btrfs, ¿debo ejecutar `btrfs check --repair`?

No por defecto. Prefiere scrub (si está montado) y reemplazo de dispositivos cuando haya redundancia. Si hay corrupción no corregible y no hay redundancia, copia y reconstruye. Usa repair solo si entiendes el riesgo y tienes backups.

7) ¿Un montaje en solo lectura significa que mi disco está fallando?

No siempre. Puede ser una respuesta limpia a un apagado no controlado o un bug puntual. Pero remontados repetidos en solo lectura, mensajes EIO, timeouts, resets, sectores pendientes o errores media NVMe apuntan fuertemente a problemas de hardware.

8) ¿Debería reiniciar inmediatamente para “arreglarlo”?

No. Reiniciar puede destruir evidencia y hacer la recuperación más difícil si el dispositivo empeora. Captura logs y evalúa la salud del disco primero. Reinicia solo como parte de un plan de reparación controlado.

9) Si solo `/var` está en solo lectura, ¿puedo seguir sirviendo tráfico?

Tal vez, brevemente, dependiendo de lo que viva en /var (logs, spool, bases). Si las aplicaciones lo necesitan para estado, ya estás roto. Si son principalmente logs, podrías mantenerte con logging en tmpfs mientras haces failover y reparas correctamente.

10) ¿Cómo sé si fsck causará pérdida de datos?

Cualquier herramienta de reparación puede eliminar o dejar huérfanas estructuras corruptas. Ejecuta primero un chequeo de solo lectura (fsck -n) para ver qué quiere cambiar. Si el disco es sospechoso, imagea primero para tener una vía de recuperación.

Conclusión: pasos siguientes que puedes ejecutar

Cuando Debian 13 monta un sistema de archivos como solo lectura tras errores, el kernel te está dando una oportunidad para recuperar limpiamente. No la desperdicies forzando escrituras y convirtiendo un fallo en un hobby forense.

Haz esto a continuación:

Ejecuta el guion de diagnóstico rápido: confirma alcance, lee logs del kernel, revisa salud del almacenamiento.
Estabiliza: detén servicios que escriben y captura evidencia.
Crea un límite de seguridad: haz snapshot solo si el almacenamiento es estable; si no, haz backup/imagen primero.
Repara offline con la herramienta correcta para tu sistema de archivos y luego valida.
Tras la recuperación, trata eventos repetidos de solo lectura como incidentes de la ruta de hardware hasta que se demuestre lo contrario.