Jede Sekunde Ihrer Datenbank, wieder­herstell­bar.

Eine Minute, vom Start bis zur Wiederherstellung.

Echte Befehle und die echte Konsole auf einem Demo-Katalog: alle Datenbanken auflisten, sehen, was sich über Nacht geändert hat, und in eine Sandbox zurückholen.

0:58 · mit Ton · 2,7 MB

Die Konsole

ÜbersichtEine DatenbankEin Diff

Die CLI

$ keeper targets
TARGET              ENGINE    ORG/PROJECT/ENV      LAST FULL             PITR WINDOW                                  STORED    HEALTH
analytics/events    postgres  acme/data/staging    2026-10-07 02:11:47Z  -                                            19.1GiB   ok
auth/users          postgres  acme/platform/prod   2026-10-07 02:11:06Z  2026-09-23 02:11:06Z → 2026-10-07 18:50:52Z  1.5GiB    ok
billing/invoices    mysql     acme/billing/prod    2026-10-07 02:09:03Z  2026-09-23 02:09:03Z → 2026-10-07 18:50:52Z  6.7GiB    ok
billing/ledger      postgres  acme/billing/prod    2026-10-07 02:08:22Z  2026-09-23 02:08:22Z → 2026-10-07 18:50:52Z  14.3GiB   ok
maps/geo            postgres  acme/maps/prod       2026-10-07 02:10:25Z  2026-09-23 02:10:25Z → 2026-10-07 18:50:52Z  23.3GiB   ok
shop-dev/orders-db  postgres  acme/shop/dev        2026-10-07 02:12:28Z  -                                            17.4MiB   ok
shop/catalog-db     postgres  acme/shop/prod       2026-10-07 02:07:41Z  2026-09-23 02:07:41Z → 2026-10-07 18:50:52Z  731.0MiB  ok
shop/orders-db      postgres  acme/shop/prod       2026-10-07 02:07:00Z  2026-09-23 02:07:00Z → 2026-10-07 18:50:52Z  9.6GiB    ok
web/wordpress       mysql     acme/marketing/prod  2026-10-07 02:09:44Z  2026-09-23 02:09:44Z → 2026-10-07 18:50:52Z  607.4MiB  ok

$ keeper diff 20261006T020700Z-bd79 20261007T020700Z-6da5
from  20261006T020700Z-bd79 (2026-10-06 02:07:00Z)
to    20261007T020700Z-6da5 (2026-10-07 02:07:00Z)

20261007 applied (was 20261006)
column orders.gift_note added
table audit_log +158,175 rows (+2%)
table order_items +62,923 rows (+1%)
table orders +15,655 rows (+1%)
table coupons −3,120 rows (−100%)
table customers +531 rows (+1%)

14 segments in between:
  00000001000000A100000000  18:51:32–19:20:32 · 800 commits · audit_log +3348 / ~1116 / −83 · order_items +1327 / ~442 / −33 · orders +330 / ~110 / −8 · customers +11 / ~3 / −0
  00000001000000A100000001  19:21:32–19:50:32 · 813 commits · audit_log +3352 / ~1116 / −83 · order_items +1328 / ~442 / −33 · orders +330 / ~110 / −8 · customers +13 / ~3 / −0
  00000001000000A100000002  19:51:32–20:20:32 · 826 commits · audit_log +3356 / ~1116 / −83 · order_items +1329 / ~442 / −33 · orders +330 / ~110 / −8 · customers +15 / ~3 / −0

$ keeper restore shop/orders-db --at 20261006T020700Z-bd79 --ttl 6h --reason "coupons truncated"
restore orders-db-sandbox-60414a15fc created (sandbox from 20261006T020700Z-bd79, 0 segments)
restore  shop/orders-db-sandbox-60414a15fc

$ keeper sandbox list
NAME      ENGINE    SOURCE            OWNER               PHASE         EXPIRES               IN-CLUSTER
sbx-7f3a  postgres  shop/orders-db    maria@acme.example  Ready         2026-10-08 00:37:32Z  keeper-sbx-sbx-7f3a.keeper-sandboxes.svc:5432
sbx-c210  mysql     billing/invoices  dev@acme.example    Provisioning  -

Ausgabe des Demo-Servers im Repository: go run ./hack/demo, dann die CLI oder einen Browser darauf richten.

Überall wiederherstellen, ohne die Produktion anzufassen.

Eine Wiederherstellung ist eine Kubernetes-Ressource wie jede andere. Geben Sie eine Zeit oder eine Backup-ID an und wählen Sie das Ziel. Keeper plant das Basis-Backup und die einzuspielenden Änderungen und führt Ihre Prüfungen aus, bevor die Wiederherstellung als erfolgreich gilt.

So leicht, dass man es vergisst.

Keeper ist ein einziges Go-Binary. Controller und API planen und lesen nur; Daten bewegen sich in kurzlebigen Jobs, die nach getaner Arbeit enden. Zwischen den Backups bleibt nichts Schweres im Cluster.

Working Set laut Kubelet im k3d-Testcluster (12 Datenbanken) nach End-to-End- und Chaos-Suite; die CPU im Ruhezustand liegt bei wenigen Millicores. Jede Datenbank mit Point-in-Time-Wiederherstellung betreibt zusätzlich einen Streamer, etwa 70 MiB während des Streamens.

Wissen, was sich zwischen zwei Versionen geändert hat.

Jedes Backup trägt ein Inventar seiner Tabellen, Zeilen und Größen. Jedes Änderungssegment trägt eine Zusammenfassung dessen, was es getan hat. So sehen Sie vor jeder Wiederherstellung, welche Version die verlorenen Zeilen noch hatte.

• Diffs zwischen beliebigen zwei Backups. Schemaänderungen, Zeilenzahlen und Größe je Tabelle.
• Änderungsübersicht je WAL- oder Binlog-Segment. Inserts, Updates, Deletes und DDL je Tabelle, damit ein TRUNCATE um 22:48 leicht zu finden ist.
• Maskierte Vorschauen. Beispielzeilen mit maskierten Spalten Ihrer Wahl, lesbar mit einem Katalogschlüssel, der die Daten selbst nicht entschlüsseln kann.

Gebaut für die Nacht, in der etwas schiefgeht.

Daten bewegen sich in Jobs, nie im Controller.

Der Controller plant nur. Mover und Streamer tragen die Bytes durch eine einzige Streaming-Pipeline direkt in Ihren Bucket, und der Restorer holt sie zurück.

Mehr als ein nächtlicher Dump im Bucket.

Von null auf wieder­herstell­bar.

1. Chart installieren

   CRDs, Controller, API und Konsole, RBAC, Alerts und das Dashboard.

   Kopieren

   helm install keeper charts/keeper -n keeper-system --create-namespace \
     --set image.repository=registry.example.com/keeper/keeper --set image.tag=v0.1.0 \
     --set 'targetNamespaces={team-a}'

2. Bucket und Schlüssel angeben

   Jeder S3-kompatible Speicher. Erzeugen Sie einen age-Schlüssel mit age-keygen und bewahren Sie eine Offline-Kopie auf.

   Kopieren

   apiVersion: keeper.republic.global/v1alpha1
   kind: BackupStore
   metadata: { name: main }
   spec:
     s3:
       endpoint: https://s3.example.com
       region: us-east-1
       bucket: db-backups
       credentialsSecret: { namespace: keeper-system, name: keeper-s3 }
     encryption:
       ageRecipients: [age1…]   # nur der öffentliche Schlüssel; der private bleibt offline

3. Ein Ziel neben der Datenbank deklarieren

   Legen Sie die schreibgeschützten Benutzer mit dem SQL aus docs/sql/ an und committen Sie das Ziel in Git.

   Kopieren

   apiVersion: keeper.republic.global/v1alpha1
   kind: BackupTarget
   metadata: { name: app, namespace: team-a }
   spec:
     engine: postgres
     endpoint: { host: postgres, port: 5432 }
     databases: [app]
     policy: prod             # nächtliche Vollsicherung, 7-Tage-Fenster
     credentials:
       secretRef: { name: keeper-backup-postgres }
       replicationSecretRef: { name: keeper-repl-postgres }

4. Etwas zurückholen, mit Absicht

   Die erste Vollsicherung startet von selbst. Probieren Sie dann aus, was Sie hoffentlich nie brauchen.

   Kopieren

   keeper targets
   keeper restore team-a/app --at 2026-10-07T09:41:27Z --wait
   keeper query <sandbox> -e "select count(*) from orders"

Die vollständige Anleitung, jedes CRD-Feld und die REST-API stehen in der Dokumentation (auf Englisch).