Ingenieros de Facet corrigen un error de pérdida silenciosa de datos en el sistema de copias de seguridad SQLite multiinquilino

Facet, una plataforma para creadores construida con Go y SQLite, identificó y resolvió recientemente un error crítico en su mecanismo de restauración a un punto en el tiempo (PITR). El problema, descubierto en octubre de 2026, implicaba que el sistema seleccionaba incorrectamente instantáneas de base de datos obsoletas durante las operaciones de recuperación. Los ingenieros implementaron una solución de tres partes para garantizar que las restauraciones se basen en marcas de tiempo en lugar de simples contadores de secuencia, evitando así regresiones silenciosas de datos para los inquilinos.

Qué ocurrió

Facet opera como una plataforma multiinquilino donde cada creador recibe una base de datos SQLite aislada. Para ofrecer opciones de recuperación granulares sin costes prohibitivos, el equipo construyó un transportador de copias de seguridad personalizado integrado directamente en su proceso de aplicación. Este sistema sube segmentos inmutables de instantáneas y registros de escritura anticipada (WAL) al almacenamiento Cloudflare R2. Cada objeto incluye una cabecera firmada con un número de secuencia y un hash del objeto anterior, creando una cadena verificable de custodia para los datos de cada inquilino.

El equipo de ingeniería detectó recientemente que varios sitios de demostración apuntaban a cadenas de datos obsoletas después de ser migrados de un entorno de preproducción (staging) a producción. Los hosts de preproducción habían mantenido archivos de estado local con números de época altos, mientras que las nuevas instancias de producción comenzaban desde cero en la época uno. Dado que la lógica de restauración priorizaba el número de época más alto independientemente de cuándo se escribieron los datos, el sistema habría restaurado los sitios a su estado de finales de septiembre en lugar de la versión actual en vivo. Esto ocurrió a pesar de que todos los objetos individuales de copia de seguridad superaban las comprobaciones de integridad, ya que el error residía en la lógica de selección y no en la corrupción de datos.

Para resolver esto, el equipo desplegó tres cambios específicos en el entorno de producción. Primero, modificaron la asignación de épocas para comprobar el historial remoto antes de asignar nuevos números de secuencia, evitando que los archivos de estado local crearan cadenas conflictivas. Segundo, el planificador de restauración ahora selecciona épocas basándose en la relevancia temporal respecto al momento objetivo de la restauración, no solo en su altura numérica. Finalmente, el sistema ahora rechaza explícitamente la restauración si detecta una cronología invertida, obligando a los operadores a abordar líneas de tiempo ambiguas en lugar de adivinar.

Detalles clave

• El sistema de copias de seguridad cuesta aproximadamente $0.0034 por inquilino al mes mediante el uso de cargas impulsadas por cambios que omiten bases de datos inactivas.
• Cada objeto de copia de seguridad es inmutable y contiene un hash SHA-256 del objeto anterior, lo que permite la verificación sin necesidad de un índice central.
• El error hizo que el planificador de restauración seleccionara cadenas obsoletas con números de época más altos provenientes de entornos de preproducción anteriores.
• Las correcciones incluyen asignar épocas contra el historial remoto y rechazar restauraciones cuando la cronología está invertida.
• Las pruebas posteriores a la corrección mostraron que un sitio de demostración con 79 segmentos WAL se restauró correctamente en 2 minutos y 34 segundos.
• El sistema deshabilita el checkpointing automático de SQLite para los inquilinos enviados para evitar conflictos de escritura con el transportador interno.

Contexto

La restauración a un punto en el tiempo (PITR) permite a los administradores recuperar una base de datos a cualquier momento específico, en lugar de solo a la última copia de seguridad completa. En SQLite, esto suele implicar combinar una instantánea base con una serie de segmentos WAL que registran cada cambio realizado desde esa instantánea. El enfoque de Facet evita herramientas externas como Litestream ejecutando la lógica de copia de seguridad dentro del mismo proceso de Go que sirve la base de datos. Esto garantiza que el sistema de copias de seguridad sea consciente de los eventos del ciclo de vida del inquilino, como la hibernación o la migración, que los sidecars externos podrían pasar por alto.

El concepto de "época" en este contexto se refiere a un período distinto en la cadena de copias de seguridad. Las épocas se reinician cuando no se puede garantizar la continuidad, como después de una migración de host. Al encadenar estas épocas con hashes criptográficos, el sistema asegura que cualquier brecha o manipulación sea detectable. Sin embargo, gestionar estas épocas entre diferentes entornos requiere una coordinación cuidadosa para asegurar que los números más nuevos siempre correspondan a datos más recientes, una suposición que falló en el incidente reciente.

Por qué importa

Para equipos que ejecutan software autoalojado o gestionan arquitecturas multiinquilino, este incidente destaca los riesgos de depender del estado local para sistemas distribuidos. Cuando las aplicaciones se mueven entre hosts o entornos, los metadatos sobrantes pueden crear conflictos difíciles de detectar hasta que se intenta una restauración. La experiencia del equipo de Facet muestra que incluso las comprobaciones de integridad robustas sobre archivos individuales no pueden prevenir errores lógicos en cómo se ensamblan esos archivos durante la recuperación.

La eficiencia de costes de su modelo también ofrece una guía para empresas pequeñas y medianas. Al cobrar solo por las operaciones de escritura reales y omitir inquilinos inactivos, alcanzaron un precio que hace viable la PITR para todos los usuarios, no solo para clientes empresariales. Esto demuestra que las estrategias de copia de seguridad granulares no requieren necesariamente infraestructura costosa si la arquitectura del software se alinea con el modelo de precios del proveedor de almacenamiento.

Además, la decisión de fallar ruidosamente al encontrar datos ambiguos es una lección crucial en ingeniería de fiabilidad. Muchos sistemas podrían intentar adivinar la cadena correcta, sirviendo potencialmente datos corruptos u obsoletos sin alertar al usuario. La elección de Facet de bloquear la restauración y requerir intervención manual asegura que la integridad de los datos nunca se comprometa en aras de la disponibilidad.

Qué puedes hacer

• Audita tu lógica de selección de copias de seguridad para asegurarte de que prioriza las marcas de tiempo sobre los números de secuencia al resolver conflictos.
• Implementa mecanismos de carga impulsados por cambios para reducir los costes de almacenamiento de bases de datos inactivas en configuraciones multiinquilino.
• Verifica la integridad de las copias de seguridad comparando el recuento de filas de las tablas restauradas con las bases de datos en vivo durante simulacros regulares.
• Asegúrate de que los procesos de copia de seguridad sean conscientes de los eventos del ciclo de vida del inquilino, como las migraciones, para evitar la desincronización del estado.
• Configura los sistemas para rechazar restauraciones ambiguas en lugar de intentar adivinar la cadena de datos correcta.
• Almacena los metadatos de las copias de seguridad de forma remota en lugar de depender únicamente de archivos de estado local que pueden quedar obsoletos tras los movimientos.