Chaque seconde de votre base de données, restaurable.

Une minute, du début à la restauration.

De vraies commandes et la vraie console sur un catalogue de démonstration : listez chaque base, voyez ce qui a changé pendant la nuit, restaurez-la dans un bac à sable.

0:58 · avec son · 2,7 Mo

La console

Vue d'ensembleUne baseUn diff

La 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  -

Sortie du serveur de démonstration du dépôt : go run ./hack/demo, puis pointez la CLI ou un navigateur dessus.

Restaurez n'importe où, sans toucher à la production.

Une restauration est une ressource Kubernetes comme une autre. Demandez un instant ou un identifiant de sauvegarde et choisissez la destination. Keeper planifie la sauvegarde de base et les modifications à rejouer, puis exécute vos vérifications avant de déclarer la restauration réussie.

Assez léger pour qu'on l'oublie.

Keeper est un unique binaire Go. Le contrôleur et l'API ne font que planifier et lire ; les données transitent par des Jobs de courte durée qui s'arrêtent une fois terminés, donc rien de lourd ne reste dans votre cluster entre deux sauvegardes.

Working set rapporté par le kubelet dans le cluster de test k3d (12 bases) après les suites de bout en bout et de chaos ; le CPU au repos se compte en quelques millicœurs. Chaque base avec restauration à un instant fait aussi tourner un streamer, environ 70 Mio pendant qu'il diffuse.

Sachez ce qui a changé entre deux versions.

Chaque sauvegarde porte un inventaire de ses tables, lignes et tailles. Chaque segment de modifications porte un résumé de ce qu'il a fait. Avant de restaurer quoi que ce soit, vous voyez quelle version contenait encore les lignes perdues.

• Diffs entre deux sauvegardes quelconques. Changements de schéma, nombre de lignes et taille par table.
• Résumés de modifications par segment WAL ou binlog. Insertions, mises à jour, suppressions et DDL par table : un TRUNCATE à 22:48 se retrouve facilement.
• Aperçus masqués. Des lignes d'exemple avec les colonnes que vous indiquez masquées, lisibles avec une clé de catalogue qui ne peut pas déchiffrer les données.

Conçu pour la nuit où tout dérape.

Les données passent par des Jobs, jamais par le contrôleur.

Le contrôleur ne fait que planifier. Movers et streamers transportent les octets dans un seul pipeline en flux jusqu'à votre bucket, et le restorer les ramène.

Bien plus qu'un dump nocturne dans un bucket.

De zéro à restaurable.

1. Installez le chart

   Les CRD, le contrôleur, l'API et la console, le RBAC, les alertes et le tableau de bord.

   Copier

   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. Indiquez un bucket et vos clés

   N'importe quel stockage compatible S3. Générez une clé age avec age-keygen et gardez-en une copie hors ligne.

   Copier

   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…]   # clé publique uniquement ; la clé privée reste hors ligne

3. Déclarez une cible à côté de la base

   Créez les utilisateurs en lecture seule avec le SQL de docs/sql/, puis commitez la cible dans git.

   Copier

   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             # complète chaque nuit, fenêtre de 7 jours
     credentials:
       secretRef: { name: keeper-backup-postgres }
       replicationSecretRef: { name: keeper-repl-postgres }

4. Restaurez quelque chose, exprès

   La première sauvegarde complète démarre toute seule. Essayez ensuite ce dont vous espérez ne jamais avoir besoin.

   Copier

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

Le guide complet, chaque champ des CRD et l'API REST sont dans la documentation (en anglais).