Sauvegarder et restaurer une instance Keyright auto-hébergée

Un serveur de licences gagne son pain en étant présent à l’instant exact où un client active. Cela rend ses données précieuses : perdez l’enregistrement de qui est sous licence, quels sièges sont réclamés et combien de crédits restent, et vous n’êtes pas seulement en panne — vous avez perdu la vérité dont dépendent les installations de vos clients. La sauvegarde et la reprise après sinistre de Keyright auto-hébergé méritent donc la même conception délibérée que celle que vous avez donnée à la haute disponibilité. La bonne nouvelle, c’est que la même architecture qui facilite la HA rend la DR simple elle aussi.

À retenir : Keyright auto-hébergé est une application sans état dont tout l’état vit dans votre PostgreSQL ; la DR se résume donc à la sauvegarde/restauration de Postgres plus la protection de deux secrets que vous générez. Sauvegardez la base pour tout votre état ; sauvegardez votre KEYRIGHT_KEK et votre KEYRIGHT_SIGNING_KEY séparément et de façon sécurisée — car sans la KEK, les clés de signature chiffrées de la base ne peuvent pas être récupérées.

Ce qu’il faut réellement sauvegarder

Keyright a exactement deux pièces mobiles : une application sans état et votre base de données. Ce découpage est toute l’histoire de la sauvegarde.

L’application est l’image ghcr.io/delta1-labs/keyright — un service ASP.NET Core sur le port 8080, sans base de données à l’intérieur. Elle ne conserve aucun état entre les requêtes. Il n’y a donc rien dans le conteneur applicatif à sauvegarder : il est reconstruit depuis l’image publiée plus votre configuration et vos variables d’environnement. Si un nœud, une VM ou un cluster entier disparaît, vous redéployez la même image et elle revient à l’identique. Traitez la couche applicative comme du bétail, pas comme des animaux de compagnie.

Tout ce qui compte vit dans PostgreSQL. Licences, activations et sièges, soldes de crédits et leur grand livre, journal d’audit, état des webhooks et des notifications, votre configuration de locataire et de produits — et les clés de signature, stockées chiffrées au repos. Vous pointez l’application vers elle avec la chaîne de connexion KEYRIGHT_DB et elle crée et migre son propre schéma. Comme tout l’état durable se concentre dans une seule base, sauvegarder Keyright revient à sauvegarder cette base. Pas d’état de fichiers dispersé, pas de cache de vérité local au nœud, rien sur un disque quelque part qu’une sauvegarde Postgres manquerait.

Les deux secrets qu’une sauvegarde de la base ne contient pas

Voici la partie qui piège les gens, et le point le plus important de cet article. Deux secrets sont les vôtres — vous les générez, Keyright ne les voit jamais — et ils ne sont pas reconstructibles depuis une sauvegarde de la base :

• KEYRIGHT_KEK — une clé de chiffrement des clés de 32 octets en base64. Elle chiffre vos clés de signature au repos, ce qui est précisément pourquoi ces clés peuvent résider en toute sécurité dans la base. Le revers : sans la KEK, les clés de signature chiffrées de votre base ne peuvent pas être récupérées. Un snapshot parfait de la base plus une KEK perdue équivaut à une instance qui ne peut plus déchiffrer ses propres clés de signature — elle peut restaurer chaque ligne et rester incapable de signer un seul bail avec la clé d’origine. Chaque client qui a épinglé la clé publique correspondante rejetterait alors les nouveaux baux.
• KEYRIGHT_SIGNING_KEY — la clé privée RSA PKCS#8 en base64 qui signe les baux hors ligne et les blocs de crédit isolés (air-gapped), et dont la moitié publique est intégrée par les applications de vos clients. Si vous la définissez explicitement (recommandé), elle fait partie de votre configuration, pas quelque chose que vous pouvez régénérer sans ré-épingler des clés publiques dans chaque client distribué.

La règle, donc, tout droit tirée de la référence de configuration : sauvegardez la KEK et la clé de signature séparément de la base et de façon sécurisée — dans un gestionnaire de secrets avec sa propre sauvegarde, un coffre hors ligne, là où votre organisation conserve les secrets de niveau racine. Jamais dans la base que vous protégez, jamais dans l’image, jamais dans le contrôle de version. Une sauvegarde de la base et la KEK sont les deux moitiés d’une seule sauvegarde récupérable ; conservez-les à des endroits différents, mais conservez-les toutes les deux.

Sauvegarder la base de données

Tout est dans PostgreSQL, utilisez donc l’outillage Postgres standard. Pour la plupart des déploiements, un dump logique planifié est l’approche correcte la plus simple :

pg_dump --format=custom --no-owner \
  "host=db.internal.example.com port=5432 dbname=keyright user=keyright_app sslmode=require" \
  --file "keyright-$(date +%F).dump"

Le format custom se restaure proprement avec pg_restore et compresse bien. Exécutez-le sur une minuterie (cron, un job sidecar, votre planificateur géré), copiez chaque dump hors machine vers un stockage objet, et appliquez une politique de rétention. Vérifiez que le fichier n’est pas vide et qu’il est restaurable — une sauvegarde non testée est un espoir, pas un plan.

Pour une instance plus grande, ou un RPO plus serré, ajoutez des sauvegardes physiques avec récupération à un instant précis (PITR). Prenez une sauvegarde de base et archivez le WAL pour pouvoir avancer jusqu’à n’importe quel moment :

pg_basebackup --pgdata=/backup/base --format=tar --gzip \
  --wal-method=stream --checkpoint=fast

Avec l’archivage du WAL configuré, le PITR vous permet de récupérer jusqu’à un horodatage choisi — inestimable si une migration défectueuse ou une erreur d’opérateur doit être annulée à la seconde près avant qu’elle ne survienne.

Si vous exploitez un Postgres géré — ce que, pour tout ce qui dépasse l’évaluation, vous devriez faire, avec une topologie primaire-plus-secondaire — appuyez-vous sur ses snapshots automatiques et sa rétention de sauvegardes. Un snapshot quotidien (ou plus fréquent) plus la fenêtre de PITR du fournisseur vous donne généralement un meilleur RPO que des dumps artisanaux, et la restauration est une opération de console ou de CLI. Dans tous les cas, le principe est le même : la base est l’endroit où vit chaque octet d’état, c’est donc dans sa protection que vous investissez. Ne vous reposez pas sur le Postgres d’évaluation intégré que proposent les kits — il sert à essayer Keyright sur un ordinateur portable, pas à la DR en production.

RPO et RTO pour un serveur de licences

Pensez explicitement aux deux chiffres, car un serveur de licences a un profil de défaillance inhabituellement indulgent.

Votre RPO (quelle quantité de données vous pouvez vous permettre de perdre) est fixé par votre cadence de sauvegarde. Un pg_dump nocturne risque de perdre jusqu’à une journée d’activations, de dépenses de crédits et d’enregistrements d’audit ; l’archivage continu du WAL ou des snapshots gérés fréquents réduisent cela à des minutes. Choisissez la cadence en fonction de la quantité d’historique d’activations et de grand livre que vous êtes prêt à rejouer ou à perdre.

Votre RTO (combien de temps prend la récupération) est l’endroit où l’architecture paie. Comme les clients mettent en cache un bail signé et valident hors ligne entre les activations, une panne ne bloque personne à l’instant où elle commence — leurs fenêtres de grâce l’absorbent. Vous courez contre la fenêtre de grâce client la plus longue, pas contre un chronomètre à chaque lancement d’application. Cela transforme « restaurer une base et redéployer un conteneur sans état » d’une course frénétique à la seconde en une opération mesurée que vous pouvez réussir. (Et si vous exploitez aussi la HA multinœud, les défaillances de routine ne deviennent jamais un événement de reprise.)

L’exercice de restauration

Entraînez-vous avant d’en avoir besoin. Une restauration comporte quatre étapes :

1. Restaurez la base. Depuis un dump logique, dans une base fraîche et vide :

   pg_restore --no-owner --clean --if-exists \
     --dbname="host=db.internal.example.com port=5432 dbname=keyright user=keyright_app sslmode=require" \
     keyright-2026-11-04.dump

   Depuis un snapshot géré ou un PITR, restaurez au point voulu via votre fournisseur et notez la nouvelle chaîne de connexion.

2. Redéployez l’application sans état pointée vers la base restaurée via KEYRIGHT_DB. Fournissez les mêmes KEYRIGHT_KEK et KEYRIGHT_SIGNING_KEY depuis votre sauvegarde de secrets séparée — c’est le moment où la KEK gagne son pain, en déchiffrant les clés de signature que la restauration a ramenées. Les migrations s’appliquent automatiquement au démarrage, il n’y a donc aucun SQL manuel.

3. Installez la clé d’auto-licence. Keyright est fail-closed : il a besoin d’une clé d’auto-licence (ou d’essai) valide pour servir le moindre trafic. Définissez KEYRIGHT_SELF_LICENSE (la même clé s’exécute sur chaque nœud) et démarrez l’application. Sans elle, chaque requête renvoie 402, aussi propre que fût la restauration de la base.

4. Vérifiez. Deux contrôles confirment une bonne restauration :

   • GET /health/ready renvoie 200 — l’application est en service et a atteint la base restaurée (elle renvoie 503 tant que Postgres est injoignable).
   • GET /admin/self-license indique votre édition et une phase active — l’auto-licence a pris et l’instance sert, elle n’est pas bloquée.

   Faites ensuite un test de fumée d’un /v1/validate réel contre une licence connue pour confirmer que la clé de signature restaurée produit toujours des baux que vos clients acceptent.

Si les quatre passent, vous êtes de retour sur le chemin d’activation avec votre état intact.

Intégrez-le à l’exploitation

Sauvegardez la base à une cadence qui correspond à votre RPO, conservez la KEK et la clé de signature là où vous ne les perdrez pas, et répétez la restauration pour que la première fois où vous l’exécutez ne soit pas pendant un incident. Le guide d’exploitation contient les détails de sauvegarde et de mise à jour, et comme Keyright est un seul produit dans les deux modes de déploiement, la même forme application-sans-état-plus-votre-base se maintient que vous exécutiez un nœud ou trois. Keyright auto-hébergé est facturé par déploiement entre Standard, Pro et Enterprise — voir les tarifs — mais la discipline de DR est la même à chaque niveau : protégez la base, protégez les deux secrets, et entraînez-vous à récupérer les deux.