Backup Kubernetes: Como Proteger Clusters e Workloads

Pontos-Chave deste Artigo

• 96% das organizações usam ou avaliam Kubernetes, segundo a pesquisa anual da CNCF — mas a maioria não tem backup adequado
• O etcd é o componente mais crítico: se corromper sem backup, o cluster inteiro é perdido
• Persistent volumes armazenam os dados reais (bancos de dados, arquivos) e precisam de snapshots + backup offsite
• Combinando Velero + Object Storage S3 + backup imutável, você cobre estado, config e dados com RPO de minutos

Por Que Backup de Kubernetes É Diferente

Kubernetes revolucionou a forma como empresas fazem deploy de aplicações. Containers sobem e descem em segundos. Pods são efêmeros por design. Scaling horizontal acontece automaticamente. Mas essa natureza dinâmica cria uma falsa sensação de resiliência.

Muitas equipes de DevOps assumem que, por o Kubernetes ser capaz de recriar pods automaticamente, os dados estão protegidos. Na prática, a situação é bem diferente. O Kubernetes garante disponibilidade de aplicação — não proteção de dados. Se um Deployment é deletado acidentalmente, o K8s não o recria. Se o etcd corrompe, o cluster inteiro para. Se um PersistentVolume com dados de produção é removido, os dados somem.

A diferença fundamental entre backup de infraestrutura tradicional e backup de Kubernetes é que o K8s distribui o estado em múltiplas camadas:

• Estado do cluster (etcd): armazena todas as definições de recursos — Deployments, Services, ConfigMaps, Secrets, CRDs, RBAC policies. É o "cérebro" do cluster.
• Estado dos dados (Persistent Volumes): armazena dados persistentes das aplicações — bancos de dados, arquivos de upload, caches, filas de mensagens.
• Estado da configuração (ConfigMaps/Secrets): variáveis de ambiente, chaves de API, certificados TLS, strings de conexão de banco.
• Estado da infraestrutura: definições de Ingress, Network Policies, Service Accounts, namespaces, Resource Quotas.

Fazer backup de apenas uma dessas camadas não é suficiente. Se você restaurar o etcd sem os persistent volumes, as aplicações voltam mas sem dados. Se restaurar os volumes sem o etcd, os dados existem mas nenhuma aplicação sabe como acessá-los. Backup de Kubernetes exige uma abordagem multi-camada.

Stateless vs Stateful: A Armadilha

Aplicações stateless (APIs, frontends, workers) podem ser recriadas a partir de imagens Docker e manifests YAML. O risco aqui é perder os manifests — se estiverem apenas no etcd e não em um repositório Git, um kubectl delete namespace acidental destrói tudo.

Aplicações stateful (bancos de dados, Kafka, Elasticsearch, Redis com persistência) são o cenário mais crítico. Os dados vivem em PersistentVolumeClaims (PVCs) vinculados a PersistentVolumes (PVs) provisionados pelo storage provider. Se o PV é destruído — por falha no storage, erro humano, ou ataque — os dados são perdidos permanentemente, a menos que haja um backup offsite seguindo a regra 3-2-1.

O Que Proteger no Cluster Kubernetes

Um plano de backup Kubernetes completo deve cobrir todos os componentes abaixo. A prioridade de cada um depende do seu RPO e RTO definidos no plano de disaster recovery.

Atenção especial para Secrets: por padrão, Secrets são armazenados em base64 (não criptografados) no etcd. O backup do etcd inclui todos os Secrets em texto claro. Isso significa que o backup do etcd precisa ser criptografado e armazenado com controle de acesso rigoroso. Considere usar um cofre externo (HashiCorp Vault, AWS Secrets Manager) e fazer backup dele separadamente.

Estratégias de Backup para Kubernetes

Não existe uma solução única para backup K8s. A estratégia ideal combina múltiplas abordagens, cada uma cobrindo uma camada diferente do cluster.

1. Snapshots do etcd

O etcd é um banco de dados key-value distribuído que armazena todo o estado do cluster Kubernetes. Sem o etcd, o cluster não sabe quais pods devem rodar, quais services existem, ou quais volumes estão provisionados.

A forma mais direta de fazer backup do etcd é com o comando etcdctl snapshot save, que gera um arquivo de snapshot consistente. Esse snapshot pode ser restaurado em um novo cluster com etcdctl snapshot restore.

• Frequência: a cada 1 hora para clusters de produção, ou contínuo com ferramentas como etcd-backup-operator
• Armazenamento: Object Storage S3 com versionamento habilitado e imutabilidade
• Retenção: mínimo 7 dias de snapshots horários, 30 dias de snapshots diários
• Teste: restaure o snapshot em um cluster de teste mensalmente para validar a integridade

Limitação importante: o snapshot do etcd captura o estado declarativo do cluster, não os dados das aplicações. Se o PostgreSQL roda em um PersistentVolume, o snapshot do etcd sabe que o PVC existe — mas não contém os dados do banco.

2. Velero (Backup de Recursos + Volumes)

Velero (anteriormente Heptio Ark) é a ferramenta open source mais adotada para backup de Kubernetes. Ele faz backup de recursos do cluster (Deployments, Services, ConfigMaps, etc.) e de persistent volumes simultaneamente.

• Backup de recursos: exporta definições de objetos Kubernetes como manifests JSON, armazenando em Object Storage (S3, GCS, Azure Blob)
• Backup de volumes: usa o Restic/Kopia integrado para copiar dados de PVs, ou CSI snapshots para volumes compatíveis
• Schedules: permite agendar backups periódicos com políticas de retenção automáticas (TTL)
• Filtros: backup seletivo por namespace, label selector, ou tipo de recurso

O Velero é especialmente forte para migração entre clusters e disaster recovery: você pode restaurar um cluster inteiro em outro provedor cloud a partir do backup.

3. CSI Snapshots (Nível de Storage)

O Container Storage Interface (CSI) padroniza operações de storage no Kubernetes. Com drivers CSI compatíveis, é possível criar snapshots de persistent volumes diretamente no nível do storage provider — sem overhead no nível de aplicação.

• Vantagens: rápidos (segundos), consistentes no nível de bloco, integrados ao Kubernetes API
• Limitações: snapshots ficam no mesmo storage — não protegem contra falha do provider
• Melhor prática: combine CSI snapshots (para recuperação rápida) com backup offsite via Velero ou DataBackup (para proteção contra desastres)

4. GitOps como Backup de Configuração

Se sua equipe pratica GitOps (ArgoCD, Flux), os manifests Kubernetes vivem em repositórios Git. Isso significa que toda a configuração do cluster é versionada, auditável e restaurável com um git checkout.

Entretanto, GitOps não substitui backup de dados. Manifests no Git cobrem o estado declarativo (Deployments, Services, ConfigMaps), mas não os dados em persistent volumes, o estado do etcd em runtime, Secrets criados manualmente (que não devem estar em Git por segurança), e CRDs instalados via Helm que podem não estar no repositório.

Recomendação: trate GitOps como uma camada de backup para configuração, mas mantenha snapshots de etcd e backup de persistent volumes como camadas independentes.

Ferramentas de Backup Kubernetes

O mercado oferece diversas soluções para backup de Kubernetes, desde projetos open source até plataformas enterprise. A escolha depende do tamanho do cluster, do nível de suporte necessário e da integração com sua infraestrutura existente de backup corporativo.

Velero: A Base Open Source

O Velero é o ponto de partida para a maioria das equipes. Instalação simples via Helm, integração com todos os cloud providers, e comunidade ativa. Limitações incluem a falta de GUI nativa (é 100% CLI), backup de volumes via Restic pode ser lento para grandes volumes, e o suporte a restauração granular (por exemplo, restaurar apenas um ConfigMap) exige filtros manuais.

Kasten K10: Enterprise com GUI

O Kasten K10, agora parte da Veeam, adiciona uma camada enterprise ao backup Kubernetes: GUI intuitiva, políticas de compliance, backup application-aware (entende a semântica de MySQL, PostgreSQL, MongoDB), e suporte comercial 24/7. A versão gratuita cobre clusters com até 5 nodes.

DataBackup: Proteção Gerenciada de Volumes

Para empresas que já usam a DataBackup para proteção de máquinas virtuais, bancos de dados e ambientes cloud, a extensão para Kubernetes é natural. O agente DataBackup protege os persistent volumes no nível de storage — os dados dentro dos PVCs são enviados para Object Storage com criptografia AES-256, deduplicação e imutabilidade configurável. O monitoramento 24/7 garante que falhas de backup sejam detectadas e tratadas antes de virarem problema.

A abordagem recomendada é combinar Velero (para estado do cluster e recursos) com DataBackup (para persistent volumes e dados de aplicação), criando uma solução de backup Kubernetes completa com gestão centralizada.

Melhores Práticas de Backup K8s

Backup de Kubernetes funcional exige disciplina operacional. As seguintes práticas são essenciais para garantir que seus backups realmente funcionem quando necessários.

1. Defina RPO e RTO por Workload

Nem todos os workloads precisam do mesmo nível de proteção. Um RPO de 1 hora pode ser aceitável para um serviço de relatórios, mas inaceitável para o banco de dados de transações. Classifique cada workload por criticidade e defina políticas de backup proporcionais.

2. Backup Imutável é Obrigatório

Ataques de ransomware contra clusters Kubernetes estão crescendo. Se o atacante compromete credenciais de admin do cluster, pode deletar backups armazenados em volumes acessíveis. Armazene backups em storage imutável com Object Lock — onde nem o administrador pode deletar antes do período de retenção expirar.

3. Siga a Regra 3-2-1

Aplique a regra 3-2-1 de backup ao Kubernetes: 3 cópias dos dados, em 2 tipos de mídia diferentes, com 1 cópia offsite. Na prática para K8s, isso significa: dados originais nos PVs do cluster, snapshots CSI no mesmo storage provider, e backup completo em Object Storage de outro provedor ou região.

4. Backup Multi-Região

Para disaster recovery real, os backups do cluster devem estar em uma região geográfica diferente da região de produção. Se seu cluster roda na AWS us-east-1, armazene backups na us-west-2 ou em outro provider. Isso protege contra falhas regionais do cloud provider — que, embora raras, acontecem.

5. Criptografe Backups em Repouso e em Trânsito

Backups do etcd contêm Secrets (senhas, chaves de API) em texto claro. Backups de persistent volumes podem conter dados sensíveis de clientes (PII, dados financeiros). Toda transferência deve usar TLS 1.3 e os backups armazenados devem ter criptografia AES-256 com chaves gerenciadas por KMS. A DataBackup aplica essa criptografia automaticamente em todos os planos.

6. Teste Restauração Regularmente

O backup que nunca foi testado é uma promessa, não uma garantia. Agende testes de restauração trimestrais em um cluster de staging: restaure o etcd, aplique os manifests, restaure os persistent volumes, e valide que as aplicações funcionam. Documente os tempos de recuperação reais e compare com o RTO definido.

7. Use Namespaces para Organizar Backups

Organize workloads em namespaces por criticidade e por política de backup. Por exemplo: production-critical (backup a cada hora), production-standard (backup diário), staging (backup semanal). Isso permite configurar schedules do Velero por namespace sem precisar listar cada recurso individualmente.

8. Monitore e Alerte sobre Falhas de Backup

Configure alertas no Prometheus/Grafana para falhas de backup do Velero e para snapshots de etcd que não executaram no horário esperado. Um backup que falha silenciosamente por semanas é pior do que não ter backup — porque cria a falsa confiança de que os dados estão protegidos. Com a DataBackup, o monitoramento 24/7 detecta e notifica falhas automaticamente.

9. Documente o Procedimento de Restauração

O backup é metade do trabalho. A outra metade é saber restaurar. Documente passo a passo os procedimentos de restauração para cada cenário: perda de etcd, perda de PV, perda de namespace, perda total do cluster. Inclua essa documentação no plano de disaster recovery.

10. Versione Seus Manifests com GitOps

Mesmo com backup de etcd, manter manifests em Git é uma camada extra de proteção. Se o backup do etcd falhar, você pode recriar o cluster a partir dos manifests do Git. Ferramentas como ArgoCD e Flux sincronizam automaticamente o estado do cluster com o repositório, garantindo que toda mudança é versionada e auditável.

Disaster Recovery para Kubernetes

Backup é a base, mas disaster recovery (DR) é o plano completo. Em Kubernetes, o DR precisa cobrir cenários que vão desde a perda de um único pod até a destruição total da infraestrutura.

Cenários de Falha e Procedimentos de Restauração

Estratégia Multi-Cluster para DR

Para workloads de alta criticidade, a melhor estratégia de DR é operar clusters em múltiplas regiões ou providers. Existem três abordagens:

• Active-Active: dois ou mais clusters recebem tráfego simultaneamente. Se um cai, o tráfego é redistribuído automaticamente. Exige sincronização de dados em tempo real entre clusters (complexo e custoso).
• Active-Passive: um cluster de produção e um cluster standby que recebe réplicas dos dados. Em caso de falha, o standby assume. Requer menos sincronização mas aumenta o RTO.
• Backup-Restore: apenas backups offsite, sem cluster standby. Em caso de desastre, um novo cluster é provisionado e restaurado a partir dos backups. O RTO é maior (horas, não minutos), mas o custo é significativamente menor.

A escolha depende do orçamento e do RTO aceitável. Para a maioria das PMEs, a abordagem Backup-Restore com Velero + DataBackup oferece o melhor equilíbrio entre custo e proteção. Para empresas com SLA de disponibilidade acima de 99,9%, Active-Passive é o mínimo recomendado.

Restauração Completa: Passo a Passo

Se você precisa restaurar um cluster Kubernetes completo (cenário de disaster recovery total), o procedimento é:

1. Provisionar infraestrutura: criar novos nodes (VMs ou bare-metal) com o SO base e o container runtime (containerd/CRI-O).
2. Instalar control plane: inicializar o cluster Kubernetes com kubeadm init ou ferramenta equivalente (kops, Rancher, EKS/AKS/GKE).
3. Restaurar etcd: aplicar o snapshot do etcd no novo cluster para recuperar todas as definições de recursos.
4. Restaurar PVs: recriar os persistent volumes e restaurar os dados a partir do backup offsite (DataBackup ou Velero com Restic).
5. Validar workloads: verificar que todos os pods estão rodando, services acessíveis, dados íntegros. Rodar testes de smoke em cada aplicação crítica.
6. Atualizar DNS/Load Balancer: redirecionar o tráfego para o novo cluster.

O tempo total de restauração depende diretamente de três fatores: tamanho do cluster, volume de dados nos PVs e velocidade de transferência do backup. Para um cluster típico de PME (10-50 pods, 500 GB de dados), a restauração completa leva entre 4 e 12 horas com backups bem organizados.

Próximos Passos

Proteger clusters Kubernetes exige uma abordagem multi-camada: etcd, persistent volumes, configurações e infraestrutura. Nenhuma ferramenta sozinha cobre tudo — a melhor estratégia combina GitOps (configuração), Velero (estado do cluster), e uma solução de backup gerenciada como a DataBackup (dados persistentes com criptografia, imutabilidade e monitoramento).

Se você está implementando ou revisando sua estratégia de backup Kubernetes, estes recursos podem ajudar:

• RTO e RPO: O Que São e Como Definir — entenda as métricas que definem sua política de backup
• Regra 3-2-1 de Backup — o framework fundamental aplicado a containers
• Snapshot vs Backup — diferenças críticas entre CSI snapshots e backup real
• Template de Disaster Recovery Plan — modelo pronto para documentar seu DR de Kubernetes
• Bare-Metal Recovery — como restaurar a infraestrutura base dos nodes do cluster
• Object Storage S3 para Backup — o destino ideal para backups Velero e DataBackup
• Soluções de Backup Corporativo — proteção completa para toda a infraestrutura
• Backup na Nuvem — como proteger workloads cloud-native

Quer avaliar a proteção dos seus clusters Kubernetes? A DataBackup oferece análise gratuita da sua infraestrutura de backup, incluindo ambientes containerizados. Fale com nossa equipe ou teste grátis por 14 dias.