Les ingénieurs de Facet corrigent un bug de perte silencieuse de données dans le système de sauvegarde SQLite multi-tenant

Facet, une plateforme pour créateurs construite sur Go et SQLite, a récemment identifié et résolu un bug critique dans son mécanisme de restauration à un instant donné. Le problème, découvert en octobre 2026, concernait la sélection incorrecte d'instantanés de base de données obsolètes par le système lors des opérations de récupération. Les ingénieurs ont implémenté une correction en trois parties pour garantir que les restaurations s'appuient sur les horodatages plutôt que sur de simples compteurs de séquence, évitant ainsi une régression silencieuse des données pour les locataires.

Ce qui s'est passé

Facet fonctionne comme une plateforme multi-tenant où chaque créateur reçoit une base de données SQLite isolée. Pour offrir des options de récupération granulaires sans coûts prohibitifs, l'équipe a développé un expéditeur de sauvegarde personnalisé intégré directement dans leur processus applicatif. Ce système téléverse des segments immuables d'instantanés et de journal pré-écriture (WAL) vers le stockage Cloudflare R2. Chaque objet inclut un en-tête signé avec un numéro de séquence et un hachage de l'objet précédent, créant une chaîne de garde vérifiable pour les données de chaque locataire.

L'équipe d'ingénierie a récemment détecté que plusieurs sites de démonstration pointaient vers des chaînes de données obsolètes après avoir été migrés d'un environnement de préproduction vers la production. Les hôtes de préproduction avaient maintenu des fichiers d'état locaux avec des numéros d'époque élevés, tandis que les nouvelles instances de production repartaient à zéro à l'époque un. Comme la logique de restauration priorisait le numéro d'époque le plus élevé indépendamment du moment où les données avaient été écrites, le système aurait restauré les sites à leur état de fin septembre au lieu de la version actuelle en ligne. Cela s'est produit bien que tous les objets individuels de sauvegarde aient réussi les contrôles d'intégrité, car l'erreur résidait dans la logique de sélection plutôt que dans une corruption des données.

Pour résoudre ce problème, l'équipe a déployé trois modifications spécifiques dans l'environnement de production. Premièrement, ils ont modifié l'allocation des époques pour vérifier l'historique distant avant d'assigner de nouveaux numéros de séquence, empêchant les fichiers d'état locaux de créer des chaînes conflictuelles. Deuxièmement, le planificateur de restauration sélectionne désormais les époques en fonction de leur pertinence temporelle par rapport à l'heure de restauration cible, et non plus seulement selon leur valeur numérique. Enfin, le système refuse explicitement de restaurer s'il détecte une chronologie inversée, obligeant les opérateurs à traiter les chronologies ambiguës plutôt que de deviner.

Détails clés

• Le système de sauvegarde coûte environ 0,0034 $ par locataire et par mois grâce à des téléversements pilotés par les changements qui ignorent les bases de données inactives.
• Chaque objet de sauvegarde est immuable et contient un hachage SHA-256 de l'objet précédent, permettant la vérification sans index central.
• Le bug a poussé le planificateur de restauration à sélectionner des chaînes obsolètes avec des numéros d'époque plus élevés provenant d'environnements de préproduction précédents.
• Les corrections incluent l'allocation des époques contre l'historique distant et le refus des restaurations lorsque la chronologie est inversée.
• Les tests post-correction ont montré qu'un site de démonstration avec 79 segments WAL a été restauré avec succès en 2 minutes et 34 secondes.
• Le système désactive le checkpointing automatique de SQLite pour les locataires servis afin d'éviter les conflits d'écriture avec l'expéditeur interne.

Contexte

La restauration à un instant donné (PITR) permet aux administrateurs de récupérer une base de données à un moment précis, plutôt que simplement depuis la dernière sauvegarde complète. Dans SQLite, cela implique généralement de combiner un instantané de base avec une série de segments WAL qui enregistrent chaque modification effectuée depuis cet instantané. L'approche de Facet évite les outils externes comme Litestream en exécutant la logique de sauvegarde dans le même processus Go qui sert la base de données. Cela garantit que le système de sauvegarde est conscient des événements du cycle de vie des locataires tels que la mise en veille ou la migration, que les sidecars externes pourraient manquer.

Le concept d'« époque » dans ce contexte fait référence à une période distincte dans la chaîne de sauvegarde. Les époques sont réinitialisées lorsque la continuité ne peut pas être garantie, par exemple après une migration d'hôte. En chaînant ces époques avec des hachages cryptographiques, le système garantit que tout écart ou toute falsification est détectable. Cependant, la gestion de ces époques à travers différents environnements nécessite une coordination minutieuse pour s'assurer que les numéros plus élevés correspondent toujours à des données plus récentes, une hypothèse qui a échoué lors de l'incident récent.

Pourquoi c'est important

Pour les équipes exécutant des logiciels auto-hébergés ou gérant des architectures multi-locataires, cet incident met en évidence les risques liés à la dépendance à l'état local pour les systèmes distribués. Lorsque les applications se déplacent entre hôtes ou environnements, les métadonnées résiduelles peuvent créer des conflits difficiles à détecter jusqu'à ce qu'une restauration soit tentée. L'expérience de l'équipe Facet montre que même des contrôles d'intégrité robustes sur des fichiers individuels ne peuvent pas prévenir les erreurs logiques dans la façon dont ces fichiers sont assemblés lors de la récupération.

L'efficacité économique de leur modèle offre également un plan directeur pour les petites et moyennes entreprises. En facturant uniquement les opérations d'écriture réelles et en ignorant les locataires inactifs, ils ont atteint un prix qui rend la PITR viable pour chaque utilisateur, et pas seulement pour les clients entreprise. Cela démontre que les stratégies de sauvegarde granulaires ne nécessitent pas nécessairement une infrastructure coûteuse si l'architecture logicielle s'aligne sur le modèle de tarification du fournisseur de stockage.

De plus, la décision d'échouer bruyamment lors de la rencontre de données ambiguës est une leçon cruciale en ingénierie de fiabilité. De nombreux systèmes pourraient tenter de deviner la chaîne correcte, servant potentiellement des données corrompues ou obsolètes sans alerter l'utilisateur. Le choix de Facet de bloquer la restauration et d'exiger une intervention manuelle garantit que l'intégrité des données n'est jamais compromise au profit de la disponibilité.

Ce que vous pouvez faire

• Auditez votre logique de sélection de sauvegarde pour vous assurer qu'elle priorise les horodatages sur les numéros de séquence lors de la résolution des conflits.
• Implémentez des mécanismes de téléversement pilotés par les changements pour réduire les coûts de stockage des bases de données inactives dans les configurations multi-locataires.
• Vérifiez l'intégrité des sauvegardes en comparant le nombre de lignes des tables restaurées avec les bases de données actives lors d'exercices réguliers.
• Assurez-vous que les processus de sauvegarde sont conscients des événements du cycle de vie des locataires comme les migrations pour éviter la désynchronisation de l'état.
• Configurez les systèmes pour refuser les restaurations ambiguës plutôt que de tenter de deviner la chaîne de données correcte.
• Stockez les métadonnées de sauvegarde à distance plutôt que de compter uniquement sur des fichiers d'état locaux qui peuvent devenir obsolètes.