>_ DevTrendsfr

Langue

Accueil

Langages

Sections

Frontend Backend Mobile DevOps AI / ML GameDev Blockchain Embarqué Sécurité
Go

Comment sauvegarder SQLite vers S3 à la volée sans perdre de données

Vous adorez SQLite pour sa simplicité ? Lancez un VPS vierge, déployez un petit service, déposez un fichier de base de données à côté, et tout fonctionne avec un temps de réponse instantané. Pas de conteneurs Docker supplémentaires avec PostgreSQL, pas de gestion d'utilisateurs ni de configuration des droits d'accès. Magnifique.

Les problèmes commencent lorsque le serveur plante de manière inattendue ou que le fournisseur « accidentellement » supprime votre disque. Si vous faisiez des sauvegardes une fois par jour via cron, vous perdiez une journée de données utilisateur et de commandes. Si vous avez tenté de copier le fichier de base de données avec une simple cp pendant que des écritures étaient en cours, vous vous êtes retrouvé avec un fichier corrompu qu'SQLite refuse même d'ouvrir.

Le créateur de la base de données clé-valeur bien connue BoltDB, Ben Johnson, a rencontré exactement ce dilemme et a créé Litestream. C'est un petit outil en Go qui résout le problème de sauvegarde SQLite une bonne fois pour toutes.

Ce que fait Litestream et pourquoi vous en avez besoin

Litestream s'exécute en tant que processus d'arrière-plan sur le même serveur que votre application. Son rôle est de diffuser en continu les modifications de votre base de données SQLite locale vers un stockage distant. Il peut s'agir d'un cloud compatible S3, de Yandex Object Storage, de MinIO, ou simplement d'un dossier sur un autre disque monté.

Vous obtenez ainsi un système de récupération après sinistre prêt à l'emploi. Si votre VPS part en fumée, vous lancez une nouvelle instance, exécutez une seule commande de restauration, et la base de données récupère jusqu'à la dernière transaction avant le crash.

La principale caractéristique de l'outil est sa fiabilité. Il interagit avec la base de données strictement via l'API C officielle de SQLite, et non en lisant aveuglément des octets bruts du disque. Cela garantit que les phases d'écriture ne se chevauchent pas avec la compression ou les points de contrôle du journal, et que la base de données ne se transforme pas en fichier corrompu.

Comment fonctionne la réplication en interne

Pour comprendre comment cela fonctionne, rappelons le mode WAL (Write-Ahead Logging) de SQLite.

Par défaut, SQLite écrit les modifications directement dans le fichier principal .db. En mode WAL, toutes les nouvelles transactions vont d'abord dans un journal séparé avec l'extension -wal. Périodiquement, ces modifications sont vidées dans le fichier principal. Cette approche accélère les écritures et ne bloque pas les lectures.

Litestream utilise ce mécanisme :

  1. Il bascule la base de données en mode WAL.
  2. Il surveille l'apparition de nouvelles pages dans le fichier WAL.
  3. Il copie ces modifications et les envoie par petits segments vers S3.
  4. Il contrôle le processus de point de contrôle afin qu'SQLite ne vide pas le WAL prématurément avant que les données n'aient été téléchargées vers le cloud.

Le délai d'envoi des données vers S3 n'est que de quelques secondes. En cas de panne du serveur, vous perdez au maximum les données des dernières secondes.

Configuration et exemple d'utilisation

Vous pouvez démarrer la réplication en quelques minutes. Il suffit de télécharger le binaire ou d'utiliser une image Docker prête à l'emploi.

D'abord, créons le fichier de configuration litestream.yml :

dbs:
  - path: /var/lib/my-app/production.db
    replicas:
      - url: s3://my-backup-bucket/production.db

Les paramètres de connexion à S3 comme les clés d'accès et le point de terminaison sont généralement transmis via les variables d'environnement standard : AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY.

Le processus est démarré avec une simple commande :

litestream replicate -config /etc/litestream.yml

Souvent, Litestream est exécuté dans le même conteneur Docker que l'application principale, en utilisant un orchestrateur de processus léger comme entrypoint.sh ou supervisord.

Si le serveur a planté et que vous devez déployer la base de données vers un nouvel emplacement, vous exécutez la commande de restauration avant de démarrer l'application :

litestream restore -o /var/lib/my-app/production.db s3://my-backup-bucket/production.db

L'utilitaire récupérera le dernier dump de base depuis le bucket, téléchargera tous les segments WAL manquants par-dessus, assemblera un fichier de base de données complet et le placera au chemin spécifié.

Limitations et pièges

L'outil semble très attrayant, mais Litestream a un périmètre clair et ses propres limitations.

Premièrement, l'utilitaire nécessite que le mode WAL soit activé. Si votre application ou une bibliothèque de pilote de base de données spécifique est incompatible avec celui-ci, rien ne fonctionnera.

Deuxièmement, c'est un outil de récupération après sinistre, pas pour la mise à l'échelle horizontale en lecture. Vous ne pouvez pas utiliser Litestream pour lancer cinq copies du service sur différents serveurs lisant tous simultanément la même base de données répliquée. Pour les scénarios distribués avec plusieurs nœuds, vous feriez mieux de regarder LiteFS de la même équipe ou des projets comme rqlite.

Troisièmement, si vous avez une base de données énorme de plusieurs centaines de gigaoctets avec des écritures lourdes constantes, les coûts de trafic S3 et de requêtes API peuvent être une surprise désagréable. L'outil est conçu pour des charges de travail légères à moyennes.

Qui trouvera ce projet utile

Litestream élimine le besoin de configurer des bases de données lourdes lorsqu'il n'y a pas de véritable besoin pour elles. C'est un excellent choix pour :

  • Les bots Telegram et les API REST en Go, Python ou Node.js avec une seule instance d'application.
  • Les projets sur des frameworks comme PocketBase ou Directus fonctionnant au-dessus de SQLite.
  • Les services auto-hébergés personnels fonctionnant sur des VPS bon marché.
  • Les microservices avec cache local ou isolation des données clients.

Si vous hésitiez à déplacer un projet personnel vers SQLite mais que la peur de perdre votre disque vous retenait, essayez d'ajouter Litestream. La configuration prend une demi-heure, mais vous dormirez l'esprit tranquille.

Projets similaires