Zum Inhalt

Schnellstart

Damit bringen Sie eine Postgres-Datenbank, die bereits in Ihrem Cluster läuft, in etwa zehn Minuten von keinem Backup zu einer getesteten Wiederherstellung. Sie brauchen kubectl- und helm-Zugriff auf den Cluster, einen S3-kompatiblen Bucket mit Zugangsdaten und age auf Ihrem Rechner.

Kein Cluster zur Hand?

Probieren Sie Konsole und CLI zuerst mit einem Demo-Server aus: ein Befehl, kein Kubernetes, keine Datenbank.

1. Tenax installieren

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 listet die Namespaces, deren Datenbanken Tenax sichert; Tenax erhält dort eine Role, um die tenax-*-Secrets mit Zugangsdaten zu lesen, und sonst nichts. examplePolicies legt die gemeinsamen Policies prod, dev und critical an. Jeder Wert ist unter Helm-Werte beschrieben.

2. Schlüssel und Bucket

Erzeugen Sie das Schlüsselpaar, das jedes Backup verschlüsselt. Bewahren Sie eine Offline-Kopie von tenax-backups.key auf: Ohne sie lässt sich kein Backup wiederherstellen.

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, dann kubectl get backupstores: main wird Ready, sobald Tenax den Bucket erreicht und die Schlüssel sich einlesen lassen.

3. Der Datenbankbenutzer

Tenax verbindet sich mit einem einzigen Benutzer, tenax. Legen Sie ihn mit dem SQL aus Datenbankbenutzer an und speichern Sie sein Passwort neben der Datenbank:

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

Für die Wiederherstellung auf jede Sekunde erlauben Sie ihm außerdem die Replikation: Fügen Sie host replication tenax all scram-sha-256 zu pg_hba.conf hinzu und laden Sie die Konfiguration neu. Das geht auch später. Bis dahin erstellt Tenax logische Backups, und seine Condition Replication sagt, was hinzuzufügen ist.

4. Das Ziel deklarieren

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

Innerhalb einer Minute startet Tenax einen Streamer für das Ziel und erstellt von selbst die erste Vollsicherung (Grund chain-restart). Darf der Benutzer noch nicht replizieren, zeigt das Ziel stattdessen Replication=False mit der Lösung, und Backups bleiben logisch, bis Sie sie anwenden:

kubectl -n team-a get backuptargets,backups

5. Wiederherstellen, mit Absicht

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"

Die Wiederherstellung führt Ihre Checks aus, bevor sie Erfolg meldet. Die Sandbox löscht sich selbst, wenn ihre TTL abläuft. Als Nächstes: