Fallo de respaldo debido a duplicados de GIF en Discourse

Cómo un archivo GIF provocó el fallo de una copia de seguridad en Discourse

Durante una copia de seguridad de uno de los foros en la plataforma Discourse, ocurrió un incidente anómalo: el mismo archivo GIF de 1.6 MB se duplicó 246.173 veces. Esto hizo que el tamaño de la copia de seguridad se inflara en 377 GB, corrompió el sistema de archivos de Linux y provocó el fallo completo del proceso de copia de seguridad. El problema no se debió a un error en el código, sino a la arquitectura de seguridad de la plataforma y a las limitaciones del sistema de archivos ext4.

Por qué un archivo se convirtió en cientos de miles de copias

Discourse utiliza un mecanismo de "carga segura" en el que cada vez que un archivo se mueve entre diferentes contextos (por ejemplo, de un mensaje privado a una publicación pública), el sistema crea una nueva copia con un hash SHA1 único. Aunque el contenido del archivo sea idéntico, la plataforma lo trata como un objeto separado. Esto es necesario para aplicar políticas de seguridad y evitar accesos no autorizados a archivos multimedia.

En el caso de un GIF popular —Rachel bailando de la serie de TV Friends—, los usuarios lo insertaron repetidamente en varios temas, comentarios y mensajes privados. Cada uso en un nuevo contexto generaba una nueva entrada en la base de datos y un nuevo archivo en disco, a pesar de que el contenido binario fuera exactamente el mismo.

Primer intento de optimización: Hard Links

El equipo de Discourse desarrolló una solución basada en agrupar archivos por hash de contenido durante la copia de seguridad. Para cada grupo de duplicados, se conservaba solo una copia física, reemplazando el resto por hard links a ella. Este enfoque redujo drásticamente los tamaños de las copias de seguridad y funcionó bien en la mayoría de las instancias.

Sin embargo, las pruebas en un foro de un cliente grande revelaron que el sistema de archivos ext4 impone un límite: un máximo de unas 65.000 hard links por inode. Con 246.173 duplicados, al alcanzarse el límite, el sistema empezó a crear nuevas copias físicas —no como duplicados, sino como archivos independientes—. Al final, en lugar de una copia, había ~181.000 archivos adicionales, lo que solo resolvió el problema parcialmente.

Solución final: Conmutación dinámica entre enlaces y copias

La nueva solución tiene en cuenta las limitaciones del sistema de archivos y funciona de manera universal:

• El sistema empieza creando hard links, como antes.
• Cuando recibe un error EMLINK ("Demasiados enlaces") del kernel de Linux, el proceso cambia a copiar archivos localmente.
• La nueva copia se convierte en la "principal" para los enlaces posteriores, y el ciclo se repite al alcanzar el siguiente límite.

Este enfoque no requiere ajustes en el sistema de archivos, es compatible con cualquier SO conforme a POSIX y reduce eficazmente los tamaños de las copias de seguridad incluso con cantidades extremas de duplicados.

Ejemplo de lógica de procesamiento (simplificado):

if hard_link_fails_with_emlink?
  create_new_physical_copy
  reset_link_counter
end

Lecciones clave

• Seguridad vs. Eficiencia: Las decisiones arquitectónicas para el aislamiento de contextos pueden llevar a efectos secundarios inesperados a gran escala.
• Los límites de los sistemas de archivos son reales: Incluso límites de bajo nivel como 65K hard links por inode en ext4 pueden interrumpir aplicaciones de alto nivel.
• Las soluciones universales son mejores: Los algoritmos adaptativos que responden a errores del SO son más fiables que las optimizaciones estáticas para condiciones ideales.
• El contenido popular genera carga: Los archivos multimedia usados con frecuencia (emojis, reacciones, memes) se convierten en devoradores ocultos de recursos.
• La prueba con datos de producción es crítica: Solo los escenarios de uso reales revelan estos casos límite.

Lecciones para desarrolladores de sistemas distribuidos

El incidente de Discourse pone de relieve un dilema clásico: equilibrar la seguridad de los datos con la eficiencia de almacenamiento. Al diseñar sistemas que manejan contenido generado por usuarios, considera:

• Desduplicación a nivel de aplicación antes de escribir en disco.
• Monitoreo de métricas relacionadas con conteos de archivos y duplicados.
• Degradación elegante al alcanzar límites del sistema.

Aunque el problema surgió del uso masivo de un GIF, sus raíces están en compensaciones arquitectónicas. La solución encontrada por el equipo de Discourse puede servir de ejemplo para otros proyectos que enfrenten desafíos similares.

— Editorial Team