Archivos del sistema corruptos vuelven a aparecer: la causa raíz (y cómo detenerlo)

Qué significa realmente la “corrupción recurrente”

La corrupción de un solo evento es molesta. La corrupción recurrente es diagnóstica. Si la misma clase de archivos sigue rompiéndose—binarios gestionados por paquetes, bibliotecas compartidas, archivos de configuración o archivos de diario—tu sistema está escribiendo datos malos repetidamente, perdiendo escrituras repetidamente o reproduciendo un estado dañado una y otra vez.

Dos patrones que deberías aprender a reconocer

Patrón A: “Lo reparo y vuelve a romperse.” Reinstalas glibc, restauras desde backup o vuelves a imagenar el host. Todo arranca, luego el mismo archivo se convierte en basura más tarde. Esto sugiere con fuerza un problema de integridad en la ruta de escritura: RAM, CPU, almacenamiento, controlador, cable, energía, firmware o un bug de kernel/controlador. El software también puede ser culpable, pero el hardware merece la primera interrogación.

Patrón B: “Siempre está mal al arrancar o desplegar.” La corrupción aparece justo después de un reinicio, tras un despliegue automatizado o después de una instantánea/reversión. Esto apunta a problemas de ordenación/flush, capas de caché, imágenes inestables o automatización aplicando repetidamente un artefacto malo. El almacenamiento aún puede estar implicado, pero el momento es una pista.

Qué es (y qué no es) la corrupción

La corrupción no siempre es un archivo lleno de bytes aleatorios. Puede ser:

• Un archivo truncado (común con pérdida de energía, falta de espacio o semánticas de flush defectuosas).
• Daño en metadatos (entradas de directorio erróneas, inodos apuntando a nonsense).
• Inconsistencia lógica (corrupción a nivel de aplicación, como fallo de checksum en una página de base de datos).
• Datos obsoletos (el sistema “escribió con éxito”, pero luego lee contenido antiguo).

Además: no toda “corrupción” es corrupción. A veces es una herramienta de automatización “arreglando” una configuración al estado equivocado, o un script postinstalación del paquete reescribiendo cosas en cada arranque. El truco es probarlo con evidencia, no con intuiciones.

Idea parafraseada de John Allspaw: “No arreglas incidentes regañando a la gente; arreglas el sistema que hizo que el resultado fuera probable.”

Y sí, he visto equipos culpar a los rayos cósmicos durante semanas cuando el problema real era un divisor de alimentación SATA flojo. El universo es grande, pero tu rack está más cerca.

Guía rápida de diagnóstico

Este es el orden que encuentra el cuello de botella rápidamente en producción real. No es perfecto. Es rápido.

Primero: decide si es reproducible y dónde se manifiesta

1. Confirma el síntoma: qué archivo(s) están corruptos, cuándo cambian y en qué hosts.
2. Revisa logs por problemas de I/O: mensajes del kernel, errores de sistema de archivos, reinicios de controlador.
3. Comprueba si la corrupción ocurre en lectura o en escritura: ¿fallan las sumas al leer datos antiguos, o solo después de escrituras nuevas?

Segundo: evalúa la pila de integridad de abajo hacia arriba

1. Salud del almacenamiento: SMART, errores de medio, estado de RAID/mdadm, resultados de scrub de ZFS/Btrfs.
2. Transporte/controlador: reinicios de enlace, logs de error NVMe, mensajes de firmware HBA.
3. Memoria: logs EDAC/MCE, memtest, contadores ECC.
4. Energía e historial de apagados: pérdida abrupta de energía, eventos de PSU, apagados sucios, logs de UPS si los tienes.

Tercero: elimina “es nuestra propia automatización”

1. Verificación de artefactos: ¿verifican firmas los paquetes? ¿coinciden las capas de contenedor con los digests esperados?
2. Desviación de gestión de configuración: ¿tienes un playbook que aplica el mismo archivo “malo” en cada ejecución?
3. Comportamiento de rollback/snapshot: ¿estás restaurando una instantánea conocida como mala?

Acciones para detener la hemorragia (hazlas temprano)

• Cuartena el host si está corrompiendo escrituras. No dejes que siga produciendo basura que parece válida.
• Remonta los sistemas de archivos sospechosos como solo lectura si puedes tolerarlo.
• Si usas RAID y sospechas de un disco, márcalo y reconstruye—después de recopilar evidencia.
• Si sospechas de RAM, deja de confiar en el nodo. La RAM mala puede corromper backups también.

Modos de fallo que hacen que la corrupción vuelva

1) La falacia “el sistema de archivos lo hizo”

Ext4, XFS, ZFS, Btrfs—ninguno es inmune a recibir datos malos. Un sistema de archivos puede detectar algunas clases de corrupción (especialmente con checksums), pero no puede corregir mágicamente lo que la CPU+RAM+controlador ya desfiguraron a menos que tengas redundancia e integridad de extremo a extremo.

Si sigues viendo corrupción después de “reparar el sistema de archivos”, probablemente reparaste síntomas de metadatos, no la causa.

2) Medio de almacenamiento inestable: el clásico aburrido

Los discos no siempre mueren con drama. A menudo se degradan. Verás sectores reasignados aumentando, errores incorrigibles o errores de media NVMe. A veces es un cable o backplane causando reinicios intermitentes de enlace, que bajo carga parecen “errores I/O aleatorios”.

La corrupción recurrente suele aparecer en archivos calientes: diarios, bases de datos de paquetes, bibliotecas compartidas y lo que escriba tu agente de monitorización cada minuto.

3) Orden de escritura y mentiras de caché (aka “dijo que escribió”)

La pila de almacenamiento está en capas: aplicación → libc → kernel page cache → filesystem → block layer → controlador → device cache → flash translation layer → medio real. Cada capa puede reclamar éxito temprano por rendimiento. Esto está bien hasta que una pérdida de energía o una ruta de flush defectuosa hace que esas escrituras “exitosas” desaparezcan o se reordenen.

La versión más maldita es un controlador o unidad que reconoce flushes pero no los persiste realmente. Puedes obtener patrones de corrupción consistentes y repetidos alrededor de apagados, reinicios o kernel panics.

4) RAM mala: el autor silencioso de tus archivos rotos

La RAM sin ECC puede voltear bits y nunca lo sabrás. La RAM ECC aún puede tener errores corregidos que predicen fallos no corregibles futuros. Si tus archivos del sistema cambian sin un evento de escritura claro, sospecha de la memoria. Si la base de datos del gestor de paquetes está “corrupta” en múltiples instalaciones nuevas en el mismo host, sospecha de la memoria aún más.

5) Bugs de firmware y drivers: la trampa de “todo está bien”

Las unidades NVMe modernas son computadoras con flash adjunto. HBAs y controladores RAID ejecutan firmware que puede estar equivocado de maneras creativas. Los drivers del kernel evolucionan. Un disco perfectamente sano puede producir corrupción cuando se empareja con una combinación problemática firmware+driver, especialmente bajo profundidad de cola, transiciones de gestión de energía o recuperación de errores.

6) Virtualización e instantáneas: viaje en el tiempo con consecuencias

En entornos virtuales, la corrupción puede ser lógica. Las instantáneas pueden usarse como muleta y luego revertirse accidentalmente. La provisión delgada puede alcanzar ENOSPC en el lado del hipervisor mientras el invitado sigue escribiendo hasta fallar. Las configuraciones de caché del host pueden violar las suposiciones del invitado. Pensarás “el sistema de archivos del invitado está corrupto” cuando el almacenamiento del host es la verdadera escena del crimen.

7) “Corrupción” causada por tu propia canalización

A veces el archivo está “corrupto” porque tu proceso de despliegue escribió la compilación equivocada, truncó un artefacto o reemplazó un binario por un archivo de texto (sí). Si el mismo archivo se rompe de la misma forma después de cada despliegue, probablemente no sea tu SSD. Es tu CI/CD, tu almacén de artefactos, tu gestión de configuración o tu proceso de creación de imágenes.

Broma #1: RAID no es una copia de seguridad. Es solo una forma muy confiada de perder datos dos veces más rápido si tienes mala suerte.

Tareas prácticas: comandos, salidas y decisiones

A continuación hay tareas prácticas que puedes ejecutar en un servidor Linux. Cada una incluye: el comando, lo que significa una salida típica y la decisión que tomas. El tema es consistente: recopilar evidencia y luego tomar acciones irreversibles.

Task 1: Identify exactly what changed (and when)

cr0x@server:~$ stat /usr/bin/sudo
  File: /usr/bin/sudo
  Size: 182000     Blocks: 360        IO Block: 4096   regular file
Device: 259,2 Inode: 131091      Links: 1
Access: 2026-02-05 10:11:44.000000000 +0000
Modify: 2026-02-05 09:58:12.000000000 +0000
Change: 2026-02-05 09:58:12.000000000 +0000
 Birth: 2025-12-01 03:14:55.000000000 +0000

Qué significa: Las marcas Modify/Change te dicen cuándo cambió el contenido o los metadatos. Si la corrupción aparece “después del reinicio”, pero Modify es horas antes, tu reinicio no fue la causa—solo cuando lo notaste.

Decisión: Correlaciona la hora Modify con despliegues, cron jobs, logrotate, actualizaciones de paquetes y reinicios. Si no hay un evento de escritura legítimo, sospecha del almacenamiento/RAM.

Task 2: Verify package-managed files (detect widespread corruption)

cr0x@server:~$ sudo debsums -s
/usr/bin/sudo
/lib/x86_64-linux-gnu/libc.so.6

Qué significa: Las rutas listadas difieren de las sumas de verificación esperadas por el paquete. Varias bibliotecas del núcleo fallando rara vez significa “alguien las editó”. Usualmente es corrupción.

Decisión: Si ves múltiples paquetes no relacionados fallando, deja de parchear archivos uno por uno. Ve directamente a comprobaciones de integridad (disco/RAM) y considera poner en cuarentena el host.

Task 3: Check kernel logs for I/O errors and resets

cr0x@server:~$ sudo dmesg -T | egrep -i "I/O error|buffer I/O|blk_update_request|reset|nvme|ata|scsi|EXT4-fs error|XFS|BTRFS"
[Wed Feb  5 09:55:03 2026] nvme nvme0: I/O 123 QID 6 timeout, aborting
[Wed Feb  5 09:55:03 2026] nvme nvme0: Abort status: 0x371
[Wed Feb  5 09:55:05 2026] EXT4-fs error (device dm-0): ext4_find_entry:1453: inode #262402: comm systemd: reading directory lblock 0

Qué significa: Timeouts y abortos indican que el dispositivo o la ruta se comportan mal. Los errores del sistema de archivos suelen ser consecuencias aguas abajo.

Decisión: Si ves reinicios/timeouts, trátalo como hardware/firmware/transporte hasta demostrar lo contrario. Planea una ventana de mantenimiento controlada; no “esperes a ver”.

Task 4: Inspect system journal for repeat offenders

cr0x@server:~$ sudo journalctl -b -p warning..alert --no-pager | head -n 20
Feb 05 09:55:06 server kernel: EXT4-fs error (device dm-0): ext4_journal_check_start:83: Detected aborted journal
Feb 05 09:55:06 server kernel: Buffer I/O error on dev dm-0, logical block 0, lost async page write

Qué significa: “Aborted journal” y “lost async page write” no son sutiles. Indican que el kernel no pudo completar escrituras de forma fiable.

Decisión: Reduce inmediatamente la actividad de escritura y captura diagnósticos de almacenamiento. Si este es un nodo de producción en una flota, vacíalo.

Task 5: Check filesystem health status (ext4 example)

cr0x@server:~$ sudo tune2fs -l /dev/mapper/vg0-root | egrep -i "Filesystem state|Errors behavior|Last checked|Last mount time|Mount count|Maximum mount count"
Filesystem state:         clean
Errors behavior:          Continue
Last mount time:          Wed Feb  5 09:54:58 2026
Last checked:             Sun Jan 12 02:00:01 2026
Mount count:              39
Maximum mount count:      40

Qué significa: “Errors behavior: Continue” significa que ext4 intentará seguir después de errores. Eso puede ser útil, y también puede esparcir daño por tu sistema de archivos.

Decisión: En sistemas donde la corrección importa más que la disponibilidad, considera establecer errors para remontar como solo lectura. Hazlo con intención y preparación operativa, no como ajuste de pánico.

Task 6: Run a read-only filesystem check (safe-ish)

cr0x@server:~$ sudo fsck.ext4 -fn /dev/mapper/vg0-root
e2fsck 1.46.5 (30-Dec-2021)
/dev/mapper/vg0-root: clean, 412351/6553600 files, 8123456/26214400 blocks

Qué significa: -n significa “sin cambios”, -f fuerza una comprobación. Clean es bueno; no absuelve al hardware, pero reduce la probabilidad de que el sistema de archivos sea el problema primario.

Decisión: Si reporta errores, programa downtime para una reparación offline y asume que problemas de I/O subyacentes podrían re-corromper el estado reparado.

Task 7: Check SMART for SATA/SAS disks

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

Qué significa: “PASSED” es marketing. Sectores pending/uncorrectable significan que la unidad tuvo problemas. Errores CRC suelen implicar cables/backplanes más que el propio medio.

Decisión: Reemplaza el disco si los sectores pending/uncorrectable persisten o aumentan. Si los errores CRC suben, recoloca/reemplaza el cable/backplane y observa si el contador deja de crecer.

Task 8: Check NVMe health and error log

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 41 C
available_spare                     : 100%
percentage_used                     : 12%
media_errors                        : 7
num_err_log_entries                 : 54

Qué significa: Errores de media y un conteo de logs de error creciente son señales rojas. Pueden preceder una falla obvia por semanas.

Decisión: Extrae entradas detalladas de error y planifica el reemplazo. NVMe tiende a fallar “bien hasta que no”, y la corrupción es un preludio común.

Task 9: Check RAID/mdadm status (software RAID)

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

unused devices: <none>

Qué significa: [UU] es saludable. Si ves [U_] o una reconstrucción, el array está degradado o recuperándose—momento propicio para que errores latentes de lectura aparezcan.

Decisión: Si está degradado, trata cualquier reporte de corrupción con seriedad: podrías estar leyendo a veces desde la “mitad mala”. Revisa SMART por disco y considera reemplazar el disco sospechoso antes de que provoque una falla en la reconstrucción.

Task 10: Validate LVM and device-mapper errors

cr0x@server:~$ sudo dmsetup status
vg0-root: 0 52428800 linear 
vg0-swap: 0 8388608 linear

Qué significa: Para mapeos lineales, el estado no mostrará mucho. Pero si usas dm-crypt o thin pools, el estado puede revelar fallos, falta de espacio o problemas de metadatos.

Decisión: Si la metadata del thin pool está estresada o casi llena, arregla eso antes de cualquier otra cosa. El agotamiento del thin pool puede imitar corrupción mediante errores I/O y escrituras parciales.

Task 11: Detect memory errors via EDAC/MCE (ECC systems)

cr0x@server:~$ sudo journalctl -k --no-pager | egrep -i "EDAC|MCE|Machine check|memory error" | tail -n 20
Feb 05 09:40:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0
Feb 05 09:40:12 server kernel: mce: [Hardware Error]: Machine check events logged

Qué significa: Errores corregidos (CE) son advertencias. Pueden devenir no corregibles (UE). Un flujo constante de CEs no está “bien”. Es tu servidor diciéndote educadamente que a veces te miente.

Decisión: Si ves CEs recurrentes, programa el reemplazo del DIMM. Si ves UEs o panics, saca el nodo inmediatamente.

Task 12: Do a targeted file integrity test with checksums

cr0x@server:~$ sudo sha256sum /usr/bin/sudo /lib/x86_64-linux-gnu/libc.so.6
c2b6d0b0a1e9a0d0f6c4b2f1e0d8a9f7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c2d1  /usr/bin/sudo
b4d1c2e3f4a5968778695a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4  /lib/x86_64-linux-gnu/libc.so.6

Qué significa: Estás creando una línea base para comparaciones posteriores. Si los hashes cambian sin actualizaciones legítimas, tienes pérdida de integridad.

Decisión: Revisa después de estrés o tras un reinicio. Si los hashes fluctúan, deja de confiar en la máquina y céntrate en hardware, firmware y energía.

Task 13: Stress I/O and watch for new kernel errors (controlled test)

cr0x@server:~$ sudo fio --name=verify --filename=/var/tmp/fio.dat --size=2G --rw=randwrite --bs=4k --ioengine=libaio --direct=1 --numjobs=1 --iodepth=32 --verify=crc32c --verify_fatal=1 --runtime=60 --time_based
verify: (groupid=0, jobs=1): err= 0: pid=22110: Wed Feb  5 10:05:12 2026
  write: IOPS=18.2k, BW=71.0MiB/s (74.5MB/s)(4262MiB/60001msec)
  lat (usec): min=45, max=21980, avg=172.1, stdev=311.4

Qué significa: Errores de verificación durante fio son extremadamente accionables. Si la herramienta reporta una discrepancia de verificación, algo por debajo del espacio de usuario está corrompiendo datos.

Decisión: Si la verificación falla, trátalo como un incidente de hardware. Si pasa pero en producción aún hay corrupción, sospecha de lógica en capas superiores (automatización, rollback, mal uso de la aplicación) o problemas intermitentes de hardware desencadenados por distintos estados de carga/energía.

Task 14: Check for out-of-space and inode exhaustion (the quiet corrupter)

cr0x@server:~$ df -h / /var /tmp
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/vg0-root    50G   49G  200M 100% /
/dev/mapper/vg0-var     80G   79G  300M 100% /var
tmpfs                  7.8G  1.2G  6.6G  16% /tmp

Qué significa: Ejecutar al 100% puede llevar a escrituras truncadas, renombres atómicos fallidos y actualizaciones de paquetes medio escritas. Eso parece corrupción desde la perspectiva de la aplicación.

Decisión: Si estás lleno, arregla el espacio primero. Luego vuelve a ejecutar la operación que “corrompió” archivos. Si el problema desaparece, no tenías un SSD embrujado—tenías disco lleno y optimismo.

Task 15: Confirm whether the host is suffering dirty shutdowns

cr0x@server:~$ last -x | head -n 12
reboot   system boot  5.15.0-94   Wed Feb  5 09:54   still running
shutdown system down  5.15.0-94   Tue Feb  4 22:10 - 22:10  (00:00)
reboot   system boot  5.15.0-94   Tue Feb  4 22:10 - 22:10  (00:00)
reboot   system boot  5.15.0-94   Tue Feb  4 17:31 - 22:10  (04:39)

Qué significa: Eventos “reboot” sin entradas de “shutdown” coincidentes pueden indicar crashes, pérdida de energía o reinicios forzados.

Decisión: Si ves apagados sucios frecuentes, trátalos como una fábrica de corrupción. Investiga energía, kernel panics, resets de watchdog y estabilidad del hipervisor.

Tres microhistorias corporativas desde el frente

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

La empresa: una SaaS mediana con una flota de hosts Linux “idénticos” y una rotación de on-call intensa. El síntoma: fallos esporádicos empezando con quejas del gestor de paquetes. Algunos nodos reportaron que bibliotecas compartidas tenían “tamaño inesperado” o fallaban la verificación de checksum. La primera suposición fue reconfortante: “es solo un mal deploy”.

Hicieron rollback. Los errores volvieron. Reimaginizaron. Mismo cuento, semana diferente. Alguien finalmente comparó los nodos fallidos y encontró una quieta común: todos estaban en el mismo rack, en el mismo switch top-of-rack y alimentados por la misma PDU. El almacenamiento era NVMe local, así que la red parecía irrelevante. Esa suposición—“la red no puede causar corrupción en discos locales”—fue la trampa.

El problema real eran eventos de energía sucios. Caídas breves no eran suficientes para reiniciar todos los servidores, pero sí para producir un comportamiento de brownout: controladores se reiniciaban a mitad de escritura, dispositivos desaparecían por milisegundos y el SO seguía funcionando mientras la ruta de almacenamiento tenía un mal día. Los nodos no siempre reiniciaban. Solo seguían, a veces reconociendo una escritura que nunca aterrizó realmente.

Una vez que correlacionaron los logs del kernel con el historial de eventos de la PDU, el patrón encajó: reinicios de almacenamiento dentro de unos segundos de cada bajón de energía. Los archivos “corruptos” eran exactamente los que esperarías que estuvieran calientes durante esas ventanas: logs, bases de datos de paquetes y estado de servicio frecuentemente actualizado.

La solución fue aburrida e inmediata: estabilizar la energía (reemplazar un módulo PDU defectuoso, mover la alimentación del rack, validar el comportamiento del UPS), luego reimagenar los hosts afectados. Y, crucialmente, cambiaron su runbook: cualquier host que muestre errores de sistema de archivos más reinicios de dispositivo se evacúa primero y se depura después. Esa política previno semanas de whack-a-mole.

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

Un equipo de una gran empresa quería builds más rápidos en su granja interna de compilación. Montaron un sistema de archivos compartido para artefactos y ajustaron configuraciones para exprimir rendimiento: writeback agresivo, comportamiento sync relajado en la capa de aplicación y una actitud general de “si es rápido, está bien”. Era rápido. Luego dejó de estar bien.

Los primeros signos fueron sutiles: errores ocasionales de “archivo de archivo corrupto”, fallos de tests que desaparecían al re-ejecutar y binarios que se bloqueaban solo en CI. Los ingenieros culparon a tests flakey (una tradición atemporal) y añadieron reintentos. Los reintentos “arreglaron” el síntoma escondiéndolo.

Meses después, tuvieron un fallo espectacular: un candidato de release construido con un artefacto de toolchain corrupto. Nada malicioso—solo bytes equivocados. La build completó, paquetes firmados, despliegue iniciado y solo entonces los servicios comenzaron a comportarse como si hubieran aprendido nuevas leyes de la física.

El postmortem mostró una reacción en cadena: el tuning de rendimiento aumentó la ventana donde los datos vivían en cachés sin persistencia duradera. Un conjunto de eventos de energía más alta carga de escritura creó escrituras parciales de artefactos. Como la pipeline carecía de verificación de extremo a extremo en el límite de artefactos, datos malos se propagaron como si fueran válidos.

La solución no fue “añadir más reintentos”. Fue restaurar semánticas correctas de durabilidad, añadir checksums de artefactos al publicar y al consumir, y condicionar releases a fallos de verificación. El rendimiento volvió, ligeramente menor. La fiabilidad volvió, enormemente mayor.

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

Un equipo pequeño de servicios financieros manejaba unos pocos nodos Linux críticos. Hardware no emocionante. No lo último. Su “arma secreta” era la disciplina: scrubs periódicos del sistema de archivos donde se soportaba, monitorización SMART con umbrales que disparaban reemplazo antes de la catástrofe, y comprobaciones semanales de integridad en una muestra de binarios del sistema.

Un viernes por la tarde sonó una alerta: errores de memoria corregidos aparecieron en un host que gestionaba procesamiento por lotes. El sistema seguía “saludable” y la carga era “no orientada al cliente”. La tentación fue ignorarlo hasta el lunes. No lo hicieron. Evacuaron el nodo y cambiaron el DIMM esa misma noche.

Cuando sacaron el DIMM, parecía como cualquier otro: inocente y silencioso. Pero los logs eran claros—las tasas de error estaban subiendo. Si hubieran esperado, el siguiente paso podrían haber sido errores no corregibles, kernel panics o peor: corrupción silenciosa de datos que hace que tus salidas sean incorrectas mientras el estado del trabajo dice “éxito”.

Reconstruyeron el nodo desde una imagen conocida buena, re-ejecutaron los trabajos por lotes y compararon salidas. Un trabajo tuvo resultados distintos. Ese fue el arma humeante: el sistema probablemente había estado produciendo datos incorrectos antes del reemplazo del DIMM. Porque tenían la práctica de mantener salidas de referencia y verificarlas, detectaron la discrepancia rápidamente.

Su práctica era aburrida: monitorizar, reemplazar temprano, verificar salidas y mantener imágenes gold. Les salvó de un escenario donde “todo parecía verde” mientras los números del negocio estaban silenciosamente errados.

Broma #2: Si alguna vez oyes “solo se corrompe a veces”, eso es simplemente “se corrompe” vistiendo una camisa más bonita.

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

1) “fsck lo arregló, así que hemos terminado”

Síntoma: Aparecen errores del sistema de archivos, ejecutas fsck, el sistema arranca y luego la corrupción regresa.

Causa raíz: Inestabilidad I/O subyacente (disco, NVMe, controlador, energía) continúa dañando datos.

Solución: Trata fsck como triaje. Extrae logs SMART/NVMe, revisa dmesg por reinicios y reemplaza componentes fallidos. Reimagen después de probar la estabilidad del hardware.

2) “SMART dice PASSED”

Síntoma: La corrupción persiste; SMART overall health muestra PASSED.

Causa raíz: “PASSED” de SMART no es predictivo; ignoraste las tendencias de atributos (sectores pending, errores CRC, errores de media).

Solución: Rastrea deltas de atributos SMART. Reemplaza discos en base al crecimiento de reallocated/pending/uncorrectable o errores de media NVMe—no en la única línea PASSED.

3) Corrupción después de cada reinicio

Síntoma: El sistema vuelve con paquetes rotos o archivos ilegibles después de ciclos de energía.

Causa raíz: Mentiras de cache de escritura, flush incompleto en apagado o pérdida abrupta de energía provocando reproducción del journal en un estado dañado.

Solución: Arregla la estabilidad de energía. Valida el comportamiento del write cache de la unidad y el firmware del controlador. Considera sistemas de archivos con checksums de extremo a extremo y redundancia cuando corresponda.

4) “Solo un archivo se corrompe siempre” (y lo sigues reemplazando)

Síntoma: El mismo config o binario se “corrompe” repetidamente, pero el disco parece bien.

Causa raíz: La automatización o un script de inicio lo reescribe constantemente (plantilla equivocada, truncación, escritura atómica fallida por ENOSPC).

Solución: Audita las ejecuciones de gestión de configuración y los scripts de inicio de la unidad. Confirma patrones de escritura atómica (escribir archivo temporal, fsync, rename) y revisa espacio/inodos.

5) “Las bases de datos están corruptas, debe ser la base de datos”

Síntoma: SQLite/Postgres/MySQL reporta fallos de checksum o páginas malas.

Causa raíz: Almacenamiento subyacente o corrupción de memoria, o eventos de disco lleno causando escrituras parciales.

Solución: Revisa integridad a nivel host (SMART/NVMe, logs de memoria), verifica configuraciones de durabilidad de la BD y confirma que no te quedas sin espacio bajo la base de datos.

6) Corrupción en múltiples hosts a la vez

Síntoma: Varios nodos muestran eventos similares de “archivo corrupto” en un día.

Causa raíz: Infraestructura compartida: una imagen mala, un artefacto defectuoso, un array de almacenamiento inestable o un evento de energía en un rack/zona.

Solución: Busca el radio de impacto compartido. Compara IDs de build, digests de imagen y ubicaciones físicas. Para de hacer rollouts hasta que puedas demostrar la integridad del artefacto.

7) “Añadiremos reintentos”

Síntoma: La build o despliegue a veces falla con mismatch de checksum; los reintentos tienen éxito.

Causa raíz: Estás ocultando una fuente de corrupción (almacén de artefactos, caché, transporte, disco) y convirtiéndola en riesgo silencioso.

Solución: Haz que las discrepancias de checksum sean fatales en los límites. Los reintentos están bien para errores de red transitorios, no para fallos de integridad.

Listas de verificación / plan paso a paso

Paso 1: Contener el daño

• Vacía el nodo del tráfico de producción o de los programadores de carga.
• Detén escrituras no esenciales (deshabilita agentes ruidosos, pausa jobs por lotes).
• Haz snapshot o imagen del disco si necesitas evidencia forense, pero no dejes que eso demore el reemplazo cuando los datos están en riesgo.

Paso 2: Demuestra si la corrupción está en curso

• Hash de un pequeño conjunto de binarios y bibliotecas estables; vuelve a comprobar después de estrés y tras un reinicio.
• Ejecuta una prueba I/O enfocada en integridad (como fio con verify) en una ventana controlada.
• Verifica paquetes en todo el sistema (debsums o verificación RPM) para ver el radio de impacto.

Paso 3: Recorre la pila desde hardware hacia arriba

• Medio de almacenamiento: logs SMART/NVMe, tasas de error, timeouts.
• Transporte: errores CRC, reinicios de enlace, logs HBA, comprobación de cables/backplane.
• Memoria: EDAC/MCE, memtest si puedes permitir downtime.
• Energía: frecuencia de apagados sucios, eventos UPS y PDU.

Paso 4: Arreglos con reemplazos y cambios de configuración que perduren

• Reemplaza discos sospechosos de forma proactiva. “Podría estar bien” no es una estrategia SRE.
• Reemplaza DIMMs si aparecen errores corregidos repetidamente.
• Actualiza firmware de NVMe/HBA cuando la evidencia apunte a timeouts/reinicios y tengas versiones conocidas buenas en tu entorno.
• Arregla inestabilidad de energía; no te limites a mejorar journaling y esperar lo mejor.

Paso 5: Reconstruye desde una fuente conocida buena y revalida

• Reimagen el host o reinstala el OS después de confirmar la estabilidad de hardware.
• Vuelve a ejecutar comprobaciones de integridad post-reconstrucción: verificación de paquetes, líneas base de hashes y una prueba corta de I/O con verify.
• Solo entonces vuelve a producción.

Política operativa que previene repeticiones

• Haz que las discrepancias de checksum y errores I/O en sistemas de archivos merezcan atención a nivel de página.
• Mantén un estado de “cuarentena” para nodos sospechosos de corromper escrituras.
• Rastrea deltas de atributos SMART/NVMe a lo largo del tiempo, no solo valores actuales.
• Valida artefactos en los límites de publicación y consumo con hashes.

Hechos interesantes y contexto histórico

• Los sistemas de archivos tempranos confiaban en el hardware. Muchos diseños clásicos asumían discos y controladores honestos; el checksum de extremo a extremo se volvió mainstream más tarde.
• El journaling redujo el tiempo de recuperación, no la verdad. Los sistemas de archivos con journaling (como ext3/ext4, XFS) ayudan a recuperar consistencia de metadatos tras crashes, pero no garantizan que tus datos no estuvieran mal antes de llegar al journal.
• La corrupción silenciosa de datos es anterior a los SSD. Flips de bits y escrituras mal dirigidas existían en discos giratorios también; los SSD solo añadieron más complejidad de firmware y capas de traducción.
• La memoria ECC no siempre fue estándar. Muchas flotas aún usan no-ECC por coste, y luego se sorprenden cuando sucede corrupción “imposible”.
• Los errores CRC suelen significar cables. Errores UDMA CRC crecientes se solucionan frecuentemente recolocando o reemplazando cables SATA/SAS o backplanes, no cambiando discos.
• Los checksums se volvieron una característica de almacenamiento, no solo de aplicaciones. Sistemas de archivos como ZFS y Btrfs popularizaron checksums integrados para detección (y con redundancia, corrección).
• El comportamiento del cache de escritura tiene una larga historia de mentiras. La industria ha encontrado repetidamente dispositivos que reconocen flushes incorrectamente, especialmente entre generaciones de firmware.
• “Funcionó en staging” es evidencia débil. La corrupción a menudo necesita calor, carga, profundidad de cola o condiciones de energía que staging nunca reproduce.

Preguntas frecuentes

1) ¿Puede un sistema de archivos “sanar” la corrupción recurrente por sí mismo?

No, a menos que tenga tanto detección como redundancia. Los checksums detectan; los espejos/paridad permiten corrección. Sin redundancia, el sistema de archivos solo puede quejarse, no arreglar.

2) Si reinstalo el OS y la corrupción vuelve, ¿cuál es la causa más probable?

Inestabilidad de hardware (RAM, medio de almacenamiento, controlador, energía) o un artefacto/imagen defectuosa repetida. Si una instalación fresca se corrompe de la misma manera en el mismo host, sospecha primero de RAM y almacenamiento.

3) ¿Puede ser simplemente “un apagado incorrecto”?

Un solo apagado sucio puede causar daño, sí. Pero si sigue ocurriendo, los apagados son también un síntoma: energía inestable, kernel panics, resets de watchdog o un problema del hipervisor.

4) ¿Cómo diferencio corrupción de disco de corrupción de RAM?

Los problemas de disco suelen producir errores I/O, timeouts, reinicios, advertencias SMART/NVMe y quejas del sistema de archivos. Los problemas de RAM pueden producir fallos extraños y generalizados: verificación de paquetes en archivos no relacionados, segfaults aleatorios, errores de descompresión e inconsistencias entre ejecuciones. Los logs ECC (EDAC/MCE) son la pista más rápida si los tienes.

5) ¿Por qué la corrupción suele golpear primero a bases de datos de paquetes y logs?

Porque están calientes: escrituras pequeñas frecuentes, muchos patrones fsync/rename y churn constante. Si tu ruta de almacenamiento falla, los archivos calientes reciben el primer golpe.

6) ¿Los SSDs son más o menos propensos a corromper datos que los HDDs?

Ninguno es “seguro” por defecto. Los SSDs tienen más complejidad de firmware y pueden fallar de forma abrupta; los HDDs pueden degradarse lentamente. Tu mejor defensa es monitorización, redundancia y verificación de integridad.

7) ¿Qué hago si solo una VM muestra corrupción pero el host parece bien?

Revisa salud del almacenamiento del hipervisor, provisión delgada y historial de snapshots/reversiones. Síntomas solo en el invitado aún pueden ser mentiras del almacenamiento del host o agotamiento de capacidad en la capa de virtualización.

8) ¿Debería cambiar de sistema de archivos para arreglar esto?

Cambiar el sistema de archivos puede ayudar si pasas a checksumming de extremo a extremo con redundancia (y la madurez operativa para ejecutar scrubs y manejar reemplazos). Pero cambiar a “otro sistema de journaling” no resolverá una RAM mala o energía inestable.

9) Si fio verify pasa, ¿estoy libre de sospechas?

No por completo. Significa que la corrupción no se reprodujo bajo esa prueba. Los problemas intermitentes pueden depender de temperatura, transiciones de energía o patrones de carga. Trata un pase como evidencia, no como absolución.

10) ¿Cuál es la decisión más rápida que puedes tomar en producción?

Si ves reinicios/timeouts de dispositivo en dmesg más errores de sistema de archivos: evacua el nodo y reemplaza hardware o muévelo fuera del dominio de rack/energía sospechoso. No negocies con la física.

Próximos pasos que realmente funcionan

Si los archivos del sistema corruptos vuelven a aparecer, deja de tratarlo como una reparación puntual. Trátalo como un incidente de integridad con condición de recurrencia.

1. Captura evidencia: errores de dmesg, logs SMART/NVMe, mensajes EDAC/MCE y salida de verificación de paquetes.
2. Cuartena: evacua el nodo para que no pueda producir más escrituras malas ni envenenar sistemas downstream.
3. Prueba la corrupción en curso: hashes base y una prueba I/O corta enfocada en verify.
4. Arregla la causa: reemplaza discos con atributos de error crecientes, reemplaza DIMMs con errores corregidos recurrentes, arregla la inestabilidad de energía y actualiza firmware cuando coincida con modos de fallo observados.
5. Reconstruye limpio: reimagen desde una fuente conocida buena y valida la integridad antes de volver al servicio.
6. Prevén repeticiones: aplica verificación de checksum en los límites de artefactos, trend de deltas SMART/NVMe y mantiene un runbook que priorice evacuar sobre negar.

La meta no es volverse paranoico. Es dejar de sorprenderse. La corrupción recurrente es tu sistema dándote una señal fiable. Atiende la pista, arregla la vía y permite que tus archivos vuelvan a ser aburridos.