Aller au contenu

Démarrage rapide

Ce guide fait passer une base Postgres qui tourne déjà dans votre cluster de zéro sauvegarde à une restauration testée, en une dizaine de minutes. Il vous faut un accès kubectl et helm au cluster, un bucket compatible S3 avec ses identifiants, et age sur votre machine.

Pas de cluster sous la main ?

Essayez d'abord la console et la CLI sur un serveur de démonstration : une commande, ni Kubernetes ni base de données.

1. Installer Tenax

helm install tenax oci://registry.example.com/helm/tenax --version 0.1.0 \
  -n tenax-system --create-namespace \
  --set image.repository=registry.example.com/tenax/tenax --set image.tag=v0.1.0 \
  --set 'targetNamespaces={team-a}' \
  --set examplePolicies.enabled=true --set examplePolicies.store=main

targetNamespaces liste les namespaces dont Tenax sauvegarde les bases ; Tenax y reçoit un Role pour lire les secrets d'identifiants tenax-*, et rien d'autre. examplePolicies crée les politiques partagées prod, dev et critical. Chaque valeur est décrite dans Valeurs Helm.

2. Les clés et le bucket

Générez la paire de clés qui chiffre chaque sauvegarde. Conservez une copie hors ligne de tenax-backups.key : sans elle, aucune sauvegarde ne peut être restaurée.

age-keygen -o tenax-backups.key        # prints "Public key: age1…"
kubectl -n tenax-system create secret generic tenax-age-identity \
  --from-literal=identity="$(grep AGE-SECRET-KEY tenax-backups.key)"
kubectl -n tenax-system create secret generic tenax-s3 \
  --from-literal=accessKeyId=AKIA… --from-literal=secretAccessKey=…
store.yaml
apiVersion: tenax.run/v1alpha1
kind: BackupStore
metadata:
  name: main
spec:
  s3:
    endpoint: https://s3.us-east-1.amazonaws.com
    region: us-east-1
    bucket: db-backups
    credentialsSecret: { namespace: tenax-system, name: tenax-s3 }
  encryption:
    ageRecipients: [age1qxyz…]                        # the public key from age-keygen
    identitySecret: { namespace: tenax-system, name: tenax-age-identity }

kubectl apply -f store.yaml, puis kubectl get backupstores : main passe à Ready dès que Tenax atteint le bucket et que les clés sont lues correctement.

3. L'utilisateur de base de données

Tenax se connecte avec un seul utilisateur, tenax. Créez-le avec le SQL de Utilisateurs de base de données, puis stockez son mot de passe à côté de la base :

kubectl -n team-a create secret generic tenax-postgres --from-literal=username=tenax --from-literal=password=…

Pour restaurer à n'importe quelle seconde, autorisez-le aussi à répliquer : ajoutez host replication tenax all scram-sha-256 à pg_hba.conf et rechargez. Vous pouvez le faire plus tard. D'ici là, Tenax prend des sauvegardes logiques et sa condition Replication indique quoi ajouter.

4. Déclarer la cible

target.yaml
apiVersion: tenax.run/v1alpha1
kind: BackupTarget
metadata:
  name: app
  namespace: team-a
  labels:
    tenax.run/org: acme
    tenax.run/project: shop
    tenax.run/env: prod
spec:
  engine: postgres
  endpoint: { host: postgres, port: 5432 }
  databases: [app]
  policy: prod                 # nightly fulls, 7-day point-in-time window
  credentials:
    secretRef: { name: tenax-postgres }
  checks:
    - name: orders-not-empty
      database: app
      sql: select count(*) > 0 from orders

En moins d'une minute, Tenax démarre un streamer pour la cible et prend de lui-même la première sauvegarde complète (raison chain-restart). Si l'utilisateur ne peut pas encore répliquer, la cible affiche à la place Replication=False avec le correctif, et les sauvegardes restent logiques jusqu'à ce que vous l'appliquiez :

kubectl -n team-a get backuptargets,backups

5. Restaurer, volontairement

tenax login --server https://tenax.example.com     # or TENAX_SERVER + port-forward, see Console, CLI and access
tenax targets
tenax restore team-a/app --at "$(date -u -d '-10 min' +%FT%TZ)" --wait
tenax query <sandbox> -e "select count(*) from orders"

La restauration exécute vos contrôles avant d'annoncer sa réussite. Le bac à sable se supprime de lui-même à l'expiration de son TTL. Ensuite :