Pular para conteúdo

Restaurar com o Tenax

Toda restauração é um recurso Restore. O console, a CLI e a API criam um. As restaurações nunca gravam em um banco existente, a menos que você peça no lugar e digite o nome do alvo. Escolha o modo:

Necessidade Modo Papel
Olhar os dados, conferir uma correção, gerar um relatório sandbox (padrão) operator
Recuperar uma tabela ou algumas linhas sandbox, depois copie o que precisar operator
Uma cópia ao lado da produção (nome de banco novo) new restorer
Um arquivo de dump para alguém fora do cluster download (URL pré-assinada, 1 h) restorer
Voltar o alvo inteiro no tempo no lugar (depois de um backup de segurança) restorer-admin

1. Encontrar o ponto

tenax targets                                   # PITR windows and last backups
tenax backups team/app                          # versions (ids, times, sizes, verified, pinned)
tenax changes team/app --since 6h               # what changed when: per-table counts and DDL per segment
tenax diff <backup-a> <backup-b>                # schema and row changes between two versions

No console, abra o alvo e depois Alterações. Cada linha de segmento tem os links "sandbox before" e "sandbox after", que preenchem o horário.

Com PITR, qualquer segundo dentro de uma janela serve (UTC, RFC3339): --at 2026-01-02T03:04:05Z. Sem PITR, escolha um ID de backup: --at 20260102T020000Z-1a2b3c. Se o horário não puder ser restaurado, o Tenax diz o motivo e mostra as janelas.

2. Restaurar em um sandbox (seguro, o padrão)

tenax restore team/app --at 2026-01-02T03:04:05Z --ttl 6h --wait
tenax sandbox show <sandbox>                    # connection info, expiry
tenax query <sandbox> -e "select count(*) from orders where created_at > now() - interval '1 day'"
tenax query <sandbox> -e "select * from orders where id = 42" -o csv > order42.csv
  • O sandbox recebe o próprio namespace tenax-sbx-<name>, credenciais aleatórias e um TTL (padrão 24 h; estenda com tenax sandbox extend <sandbox> --by 24h, até o máximo da política).
  • O console de consultas é somente leitura por padrão, com timeout de 30 s e limite de 1.000 linhas. Colunas que batem com os padrões de mask do alvo são mascaradas. Toda consulta é auditada.
  • De outro pod: dê a ele o label tenax.run/sandbox-client: <sandbox> e conecte-se ao endereço interno do cluster que sandbox show mostra.
  • De um notebook, quando o sandbox foi criado com --expose: tenax sandbox connect <sandbox> --port 15432. Isso abre o túnel pelo Cloudflare Access e mostra a string de conexão.
  • tenax sandbox delete <sandbox> ao terminar. Sandboxes expirados são excluídos automaticamente.

3. Restaurar em um banco novo

tenax restore team/app --at 2026-01-02T03:04:05Z --to new \
  --host postgres.team.svc --database app_restored --credentials-secret tenax-admin --wait

Primeiro o Tenax restaura em um sandbox de staging, executa as checagens e depois copia o resultado para o banco novo com um dump e carga lógicos (ADR 0007). Ele nunca sobrescreve um banco existente. O secret de admin (prefixo tenax-) fica no namespace do alvo e precisa de CREATE DATABASE.

4. Download

tenax restore team/app --at <backup-id> --to download --wait

--wait mostra uma URL pré-assinada para um dump descriptografado e recomprimido. Ela vale por 1 hora. A URL é um segredo: compartilhe-a como tal.

5. No lugar (último recurso)

tenax restore team/app --at 2026-01-02T03:04:05Z --to in-place --confirm app --credentials-secret tenax-admin --wait
  1. Pare primeiro quem escreve no banco. O Tenax não para aplicações. Reduza a escala delas ou coloque-as em modo de manutenção.
  2. O Tenax faz um backup de segurança do estado atual (motivo safety). Pular esse passo exige --skip-safety-backup.
  3. Ele restaura em um sandbox de staging, confere o resultado e depois substitui os bancos do alvo.
  4. Inicie as aplicações de novo e confira-as.

Se algo der errado, o backup de segurança é uma versão normal do alvo: restaure-o da mesma forma.

Sem a CLI

O recurso Restore é a API:

apiVersion: tenax.run/v1alpha1
kind: Restore
metadata: { name: app-incident-42, namespace: team }
spec:
  target: app
  source: { time: "2026-01-02T03:04:05Z" }     # or backupID: ..., or latest: true
  destination:
    mode: sandbox
    sandbox: { ttl: 6h }

kubectl -n team get restore app-incident-42 -w mostra o progresso: plan, fetching base, replaying, checking, Succeeded.

Quando o próprio Tenax está fora do ar

O store é a fonte da verdade, e o formato de backup é simples: - manifest.json lista cada objeto com o tamanho e o SHA-256 dele. - Os objetos são comprimidos com zstd e criptografados com age: age -d -i key.txt obj.zst.age | zstd -d. - Os backups físicos do Postgres são streams tar do pg_basebackup mais segmentos de WAL. - Os backups lógicos do Postgres são arquivos pg_dump -Fc, um por banco. - Os backups do MySQL são a saída do mysqldump mais arquivos de binlog.

Depois que um cluster é perdido ou recriado

A recuperação é automática. O Tenax não mantém banco de dados próprio: o store guarda todos os backups (e é a única cópia que importa), o Git guarda o BackupStore, as políticas e os alvos (GitOps), e as identidades age são secrets que você restaura como qualquer outro. Instale o Tenax no novo cluster com o mesmo store e as mesmas identidades e aplique os mesmos alvos. Então:

  1. O controlador verifica cada store ao iniciar (BackupStore.status.lastImportTime). Para cada alvo, ele recria os objetos Backup dos keepBackupObjects backups mais recentes (padrão 20), incluindo os fixados. Nada é gravado no store. Os backups mais antigos continuam no store, sob a retenção, e no catálogo do console.
  2. Restaurações, janelas PITR e o console funcionam como antes. O streamer inicia uma nova cadeia a partir de um backup completo novo.

A importação também roda quando os alvos mudam e a cada controller.autoImport.interval (1 h). Desative-a com controller.autoImport.enabled: false. tenax catalog import [--dry-run] faz o mesmo manualmente, usando o seu kubeconfig.