Fonctionnement de Tenax

Tenax est un opérateur Kubernetes. Vous déclarez où vont les sauvegardes, à quelle fréquence et pour combien de temps, et quelles bases ; Tenax s'occupe du reste.

flowchart LR
  subgraph Declared["Declared in git"]
    S[BackupStore<br/>bucket + keys]
    P[BackupPolicy<br/>schedule, retention, window]
    T[BackupTarget<br/>one database]
  end
  subgraph Created["Created by Tenax or by you"]
    B[Backup<br/>one full backup]
    R[Restore<br/>to a sandbox, new DB, download, in place]
    X[Sandbox<br/>a throwaway database]
  end
  T --> P --> S
  T -. schedule .-> B
  R -. sandbox .-> X

Ressource	Portée	Qui la crée	Ce que c'est
BackupStore	cluster	vous	Un bucket S3, ses identifiants et les destinataires age vers lesquels chaque objet est chiffré.
BackupPolicy	namespace	vous (ou les préréglages du chart)	Planning, fenêtre de restauration à un instant donné, niveaux de rétention, limites, protection de charge, vérification, compression.
BackupTarget	namespace, à côté de la base	vous	Un serveur de base de données : moteur, endpoint, identifiants, politique, contrôles, masques.
Backup	namespace de la cible	Tenax (planning, sauvegarde immédiate, redémarrage de chaîne)	Une exécution de sauvegarde complète. Seules les plus récentes sont conservées en tant qu'objets ; S3 les garde toutes.
Restore	namespace de la cible	vous, la console ou la CLI	Un plan, d'un instant ou d'un identifiant de sauvegarde vers une destination.
Sandbox	cluster	un Restore vers un bac à sable	Une base privée avec un TTL, des identifiants et une console de requêtes.

Le chemin des données

flowchart LR
  db[(Postgres / MySQL)] -->|pg_basebackup, pg_dump, mysqldump| mover[mover Job]
  db -->|WAL receiver, mysqlbinlog| streamer[streamer]
  mover --> pipe[zstd → age → SHA-256 → parallel multipart]
  streamer --> pipe
  pipe --> s3[(S3 bucket<br/>manifest.json written last)]
  s3 --> restorer[restorer Job<br/>verify → decrypt → replay → checks]
  restorer --> dest[sandbox · new database · in place · download]

• Le contrôleur ne fait que planifier. Les transferts et les restaurations sont des Jobs ; chaque cible avec restauration à un instant donné a un Deployment de streamer. Les octets ne passent jamais par le contrôleur ni par l'API.
• Rien ne se bloque. Ni montages, ni iSCSI, ni FUSE, ni périphériques bloc ; les bases ne sont jointes que par le réseau. Chaque appel d'E/S a une échéance, chaque flux un chien de garde de progression, et les outils enfants tournent dans leur propre groupe de processus pour être tués avec lui.
• Crash-only. N'importe quel pod peut être tué à tout moment. L'état vit dans les CRD et dans S3, et une sauvegarde n'existe qu'une fois son manifeste écrit en dernier : une sauvegarde à moitié écrite n'est jamais prise pour une sauvegarde complète.

Le catalogue et la console

Au démarrage, tenax-api liste les manifestes de chaque store et tient un index en mémoire : cibles, sauvegardes, segments de modifications et fenêtres de restauration. Les inventaires et les aperçus masqués sont chiffrés vers une clé catalogue supplémentaire, qui peut les lire mais ne peut pas déchiffrer les dumps ni le WAL (ADR 0009). Le cache est jetable ; S3 est la source de vérité.