Velero na Prática: Backup e Restore de Clusters Kubernetes Sem Pânico

Há uma frase que soa tranquilizadora e é perigosamente incompleta: "não preciso de backup do cluster, meus manifests estão todos no Git". A intenção é boa — infraestrutura como código é o caminho certo —, mas ela ignora quanta coisa vive no cluster e nunca passou pelo seu repositório. Secrets gerados dinamicamente, PersistentVolumeClaims com dados de verdade, objetos criados por operators, CRDs e seus custom resources, ConfigMaps editados na correria de um incidente, o estado de aplicações com dados. Se o cluster morrer, "aplicar os manifests de novo" recria a casca, mas não traz de volta o recheio.

Um cluster Kubernetes é, na prática, duas coisas que precisam ser protegidas de formas diferentes. Existe o estado declarativo — todos os objetos que vivem na API do Kubernetes, o desenho do que deveria estar rodando — e existem os dados — o que está gravado nos volumes persistentes, o banco, os arquivos, o que a aplicação escreveu. Perder qualquer um dos dois é um desastre, e a estratégia para proteger cada um é distinta. É exatamente essa dupla proteção que o Velero oferece.

Neste guia você vai entender o que o Velero faz por baixo dos panos: como ele faz backup dos objetos da API e como lida com os volumes, a diferença entre snapshot nativo e cópia de arquivos, para que serve o agendamento e a retenção, o papel dos hooks na consistência de bancos, e — talvez o mais importante — por que um backup que nunca foi testado num restore real não é um backup, é uma esperança.

O que se perde quando um cluster morre

Vale ser concreto sobre o que está em jogo, porque a confiança excessiva no Git nasce de subestimar isso. Muitos objetos que sustentam a operação nunca foram versionados por ninguém: Secrets de credenciais criados por um operator, tokens, certificados emitidos pelo cert-manager, custom resources que operators mantêm, ajustes feitos com kubectl edit durante uma madrugada e nunca portados de volta para o repositório. Há também o problema da ordem e das dependências: recriar tudo do zero na sequência certa, com os CRDs instalados antes dos recursos que dependem deles, é um quebra-cabeça que ninguém quer montar sob pressão.

E há um cenário muito mais comum que o "cluster inteiro pegou fogo": o erro humano. Um kubectl delete namespace no contexto errado apaga aplicação, configuração e dados de um golpe. Uma atualização que dá errado. Um operator que reconcilia para um estado indesejado. Nesses casos, você não quer reconstruir o mundo — quer voltar no tempo para minutos atrás, restaurando exatamente aquele namespace como ele estava. É para isso que o Velero existe.

A arquitetura do Velero

O Velero tem duas partes simples de entender. Há um servidor que roda dentro do cluster, como um Deployment, e uma CLI que você usa para disparar e inspecionar operações. O servidor é quem faz o trabalho: quando você pede um backup, ele conversa com a API do Kubernetes, coleta os recursos e os envia para um armazenamento externo.

Esse armazenamento externo é configurado através de uma BackupStorageLocation, que aponta para um bucket de object storage — S3, GCS, Azure Blob ou compatíveis. É ali que cada backup vira um conjunto de arquivos (essencialmente tarballs com os objetos serializados). Manter os backups fora do cluster é fundamental: se eles vivessem dentro do próprio cluster que estão protegendo, morreriam junto com ele. Para os volumes, há também a VolumeSnapshotLocation, que define onde e como os snapshots de disco são criados. Essa separação — objetos num lugar, snapshots de volume em outro — reflete exatamente a dualidade entre estado declarativo e dados.

Backup de objetos: o estado declarativo

O backup dos objetos da API é a parte mais direta. O Velero varre a API do Kubernetes, serializa os recursos e os guarda no bucket. O que o torna útil é a capacidade de filtrar: você pode fazer backup do cluster inteiro, ou só de namespaces específicos, ou só de recursos com determinado label, ou excluir certos tipos. Isso permite estratégias precisas — um backup diário completo, backups frequentes só dos namespaces críticos, backups pontuais antes de uma operação arriscada.

No restore, o Velero lê aquele backup do bucket e recria os objetos na API, respeitando dependências e permitindo remapeamentos. Como os objetos são o desenho declarativo, restaurá-los faz o cluster reconstruir o que estava descrito — os Deployments voltam a criar pods, os Services voltam a existir, os custom resources voltam e seus operators voltam a agir sobre eles. Esse é o mecanismo por trás tanto do disaster recovery quanto da migração entre clusters.

Backup de volumes: onde estão os dados

Objetos são o desenho; os dados estão nos volumes. E aqui o Velero oferece duas abordagens com trade-offs claros. A primeira são os snapshots nativos do provedor de armazenamento, hoje feitos via a integração com os CSI snapshots. Nesse modelo, o Velero pede ao provedor de nuvem um snapshot do disco subjacente ao PersistentVolume — uma operação rápida, no nível do bloco, feita pela infraestrutura de storage. É eficiente e veloz, mas os snapshots ficam atrelados à região e ao provedor: um snapshot de disco da AWS não se restaura num cluster do Google, o que limita a portabilidade.

A segunda abordagem é o File System Backup (historicamente baseado em Restic, e mais recentemente em Kopia), que copia os dados arquivo a arquivo para dentro do mesmo bucket dos objetos. É mais lento que um snapshot de bloco e consome mais recursos durante o backup, mas ganha em portabilidade: como os dados viram arquivos comuns no object storage, você pode restaurá-los em outro provedor, outra região, outro tipo de storage. A escolha entre os dois é a clássica troca entre velocidade e independência: snapshots para recuperação rápida no mesmo ambiente; cópia de arquivos quando migrar entre ambientes é o objetivo.

Casos de uso, agendamento e hooks

O Velero cobre um espectro amplo de necessidades. Ele é a base do disaster recovery, restaurando um cluster funcional a partir do bucket. É a ferramenta de migração — mover cargas entre clusters, entre regiões ou entre provedores, especialmente com o File System Backup pela portabilidade. Serve para clonar ambientes, criando uma cópia de produção para teste. E é a rede de proteção contra o erro humano, permitindo desfazer um delete acidental restaurando só o namespace afetado.

Para que backup seja disciplina e não boa vontade, o Velero traz o recurso Schedule, que dispara backups em horários definidos por expressão cron — diário, de hora em hora, o que fizer sentido. Cada backup carrega um TTL que define sua retenção: passado o prazo, o Velero expira o backup e libera o espaço no bucket, evitando crescimento infinito. Você combina backups completos periódicos com backups seletivos mais frequentes dos namespaces que mudam mais.

Um ponto sutil e crucial é a consistência de aplicações com estado, sobretudo bancos de dados. Tirar um snapshot de um volume enquanto o banco escreve pode capturar um estado inconsistente, meio-a-meio, que não restaura direito. Para isso existem os hooks: comandos que o Velero executa dentro do pod antes e depois do backup. Um hook de pré-backup pode dar o comando para o banco fazer flush e congelar as escritas (quiesce), e o hook de pós-backup libera de novo. Assim o snapshot captura um instante coerente. Sem hook, backup de banco é um jogo de sorte.

Restore, e a regra que ninguém deveria ignorar

O restore do Velero é flexível. Você pode restaurar tudo, ou seletivamente por namespace e tipo. Pode remapear namespaces, restaurando um backup de producao dentro de staging para inspecionar. Pode fazer restauração parcial, trazendo só o que precisa. Essa flexibilidade é o que torna o Velero útil no dia a dia, e não só na tragédia total.

Mas existe uma regra que supera todas as outras em importância: um backup que nunca foi restaurado não é um backup, é uma suposição. Backups falham silenciosamente por dezenas de motivos — um recurso que não foi capturado, um CRD que precisava ser restaurado primeiro, um snapshot atrelado a uma região que já não existe, um hook que não rodou e deixou o banco inconsistente. A única forma de saber se o seu backup funciona é executar um restore de verdade, periodicamente, num cluster de teste, e verificar que a aplicação sobe e os dados estão íntegros. Um exercício de restore agendado é o que transforma a promessa do Velero em confiança real.

Armadilhas comuns

Alguns tropeços aparecem com frequência. A ordem de restauração de CRDs importa: se um custom resource é restaurado antes do CRD que o define, o restore falha; o Velero lida bem com isso na maioria dos casos, mas cenários complexos com operators exigem atenção. Os Secrets vão para o bucket em texto (base64, que não é criptografia) — habilite criptografia no object storage e controle o acesso ao bucket com rigor, porque ele contém as chaves do reino. Os snapshots nativos são presos a região e provedor, então não conte com eles para migração entre nuvens; use File System Backup para isso. A consistência de bancos depende de hooks, então não presuma que um snapshot de volume de banco está correto sem eles. E o RBAC do Velero precisa ser suficiente para ler todos os recursos que você quer proteger — um Velero com permissão parcial faz backups silenciosamente incompletos.

Por onde começar

Comece configurando uma BackupStorageLocation apontando para um bucket em uma região ou conta diferente da do cluster — a separação física importa no dia do desastre. Habilite criptografia no bucket e restrinja o acesso a ele. Em seguida, crie um Schedule com backup diário dos namespaces críticos e um TTL de retenção sensato, e adicione hooks de quiesce para qualquer banco ou aplicação com estado, para garantir consistência.

Escolha a estratégia de volume conforme seu objetivo: snapshots CSI para recuperação rápida no mesmo ambiente, File System Backup se portabilidade entre provedores ou regiões for importante. E, acima de tudo, agende um exercício de restore recorrente num cluster de teste — restaure um namespace, confirme que a aplicação sobe e que os dados estão lá. O Velero é uma excelente apólice de seguro, mas seguro só vale se você já testou o acionamento antes de precisar dele de verdade.