Cada segundo do seu banco de dados, restaurável.

Um minuto, do início à restauração.

Comandos reais e o console real sobre um catálogo de demonstração: liste cada banco, veja o que mudou durante a noite e restaure em um sandbox.

0:58 · com som · 2,7 MB

O console

Visão geralUm bancoUm diff

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

Saída do servidor de demonstração do repositório: go run ./hack/demo e aponte a CLI ou um navegador para ele.

Restaure onde quiser, sem tocar na produção.

Uma restauração é um recurso do Kubernetes como qualquer outro. Peça um horário ou um ID de backup e escolha o destino. O Keeper planeja o backup base e as alterações a reaplicar, e roda suas verificações antes de considerar a restauração bem-sucedida.

Leve a ponto de você esquecer que está lá.

O Keeper é um único binário Go. O controlador e a API apenas agendam e leem; os dados trafegam em Jobs de vida curta que terminam ao concluir, então entre um backup e outro nada pesado fica no seu cluster.

Working set informado pelo kubelet no cluster de testes k3d (12 bancos) após as suítes end-to-end e de caos; a CPU em repouso fica em poucos milicores. Cada banco com restauração pontual também roda um streamer, cerca de 70 MiB durante o streaming.

Saiba o que mudou entre duas versões.

Cada backup traz um inventário das tabelas, linhas e tamanhos. Cada segmento de alterações traz um resumo do que fez. Assim, antes de restaurar qualquer coisa, você vê qual versão ainda tinha as linhas perdidas.

• Diffs entre quaisquer dois backups. Mudanças de esquema, contagem de linhas e tamanho por tabela.
• Resumo de alterações por segmento WAL ou binlog. Inserções, atualizações, exclusões e DDL por tabela, para achar fácil um TRUNCATE às 22:48.
• Prévias mascaradas. Linhas de amostra com as colunas que você indicar mascaradas, legíveis com uma chave de catálogo que não descriptografa os dados.

Feito para a noite em que algo dá errado.

Os dados trafegam em Jobs, nunca no controlador.

O controlador apenas agenda. Movers e streamers levam os bytes por um único pipeline em streaming direto para o seu bucket, e o restorer os traz de volta.

Mais do que um dump noturno em um bucket.

Do zero ao restaurável.

1. Instale o chart

   CRDs, o controlador, a API e o console, RBAC, alertas e o dashboard.

   Copiar

   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. Aponte para um bucket e suas chaves

   Qualquer armazenamento compatível com S3. Gere uma chave age com age-keygen e guarde uma cópia offline.

   Copiar

   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…]   # só a chave pública; a privada fica offline

3. Declare um alvo ao lado do banco

   Crie os usuários somente leitura com o SQL de docs/sql/ e faça commit do alvo no git.

   Copiar

   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             # completos toda noite, janela de 7 dias
     credentials:
       secretRef: { name: keeper-backup-postgres }
       replicationSecretRef: { name: keeper-repl-postgres }

4. Restaure algo, de propósito

   O primeiro backup completo começa sozinho. Depois teste aquilo que você espera nunca precisar.

   Copiar

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

O guia completo, cada campo dos CRDs e a API REST estão na documentação (em inglês).