Em 10 de setembro de 2026, a CNCF publicou orientações baseadas em três cenários de falha reproduzíveis, com o objetivo de testar a recuperação de desastres de aplicações Kubernetes com estado, em vez de simplesmente verificar se o backup terminou com o status Completed. Os experimentos, que podem ser executados em um laptop a partir de um repositório de laboratório, utilizaram uma aplicação PostgreSQL com conteúdo conhecido composto por quatro linhas, permitindo verificar o resultado real da restauração em vez de depender de indicadores gerais de status.
O material foi preparado por Saiyam Pathak e Saloni Narang, ambos embaixadores da CNCF. Seu escopo limita-se à restauração do estado das aplicações dentro do Kubernetes; não aborda estruturas de conformidade, comparação de produtos, restauração da infraestrutura subjacente da nuvem ou do data center. Ferramentas como Velero e as interfaces CSI Snapshot aparecem como implementações de referência para os cenários, enquanto os padrões de falha aplicam-se a ferramentas que desempenham as mesmas funções.
Um backup concluído não prova a capacidade de restauração
No primeiro cenário, os componentes do backup do Kubernetes foram separados em definições de recursos no formato YAML e dados de volumes persistentes. O laboratório utilizou o Velero com um mecanismo de transferência de dados para um armazenamento de objetos compatível com S3 fora dos dois clusters. A inspeção dos objetos DataUpload mostrou que 47.989.888 bytes de dados do volume foram efetivamente transferidos para o armazenamento externo.
Após a exclusão do namespace, incluindo o PVC, a restauração recuperou as mesmas quatro linhas em cerca de dois minutos. Contudo, a CNCF alerta que proteger os dados do volume não torna automaticamente o backup do banco de dados consistente do ponto de vista da aplicação; as aplicações podem precisar de operações de flush ou quiesce. A restauração em uma infraestrutura diferente também pode exigir o alinhamento da StorageClass e outras transformações que a equipe deve projetar e testar.
Mais importante, as ferramentas de backup restauram recursos em um cluster já existente e não criam nós, rede, balanceadores de carga ou DNS. Portanto, o plano de recuperação deve definir claramente o ambiente que receberá o backup, atribuindo a restauração do Kubernetes à infraestrutura como código ou à Cluster API quando necessário.
O Git restaura a intenção, não o estado armazenado
No segundo cenário, o cluster de produção foi desligado, enquanto o cluster de recuperação já existia e continha um controlador GitOps conectado a um repositório Git e uma ferramenta de backup conectada ao armazenamento compartilhado. A sincronização da aplicação foi bem-sucedida, o StatefulSet estava em execução e o painel mostrava um status saudável, mas a consulta ao banco de dados retornou o erro: relation "attendees" does not exist.
A causa não era uma falha no Kubernetes ou no GitOps. O repositório continha apenas as definições; por isso, o controlador recriou o StatefulSet, o Service e um novo volume de armazenamento vazio. Na prática, o Git armazena o estado declarado ou a intenção da equipe, enquanto os backups armazenam os dados reais; nenhum dos dois, isoladamente, consegue restaurar a aplicação inteira.
O método de recuperação usado no laboratório envolveu remover a aplicação vazia criada pela sincronização, restaurar a aplicação com seus volumes a partir do armazenamento de backups e, por fim, comparar os dados com o conteúdo esperado. O intervalo entre a interrupção da produção e a disponibilização de dados verificados foi de quatro minutos no experimento ao vivo e pouco menos de dois minutos na repetição do teste. A CNCF esclarece que esses números abrangem apenas a parte automatizada e não incluem a detecção do incidente, a tomada de decisão, o redirecionamento do tráfego e o retorno ao ambiente original.
Snapshots individuais podem produzir um ponto de recuperação que nunca existiu
O terceiro cenário testou uma aplicação que utiliza dois volumes de armazenamento interdependentes: um para pedidos e outro para pagamentos. O laboratório gravava pares correspondentes cinco vezes por segundo, com a condição de que cada pagamento tivesse um pedido correspondente. Ao serem obtidos dois snapshots separados com intervalo de cinco segundos, cada snapshot parecia pronto e íntegro individualmente, mas a restauração revelou que o último pedido registrado era 108352, contra 108377 pagamentos, ou seja, 25 pagamentos sem pedidos correspondentes.
O resultado demonstra que o sucesso de cada operação individual de armazenamento não garante a consistência de uma aplicação que utiliza vários volumes; juntos, os dois snapshots podem descrever um momento que nunca existiu de fato. O material observa que a diferença pode aumentar em produção quando a ferramenta de backup percorre um grande número de PVCs um após o outro.
O VolumeGroupSnapshot, que alcançou o status GA no Kubernetes 1.36, oferece um mecanismo para identificar volumes com uma única etiqueta e solicitar um ponto de recuperação consistente por meio do CSI. No experimento coordenado, o último número de pedidos e pagamentos coincidiu em 109169, e a verificação da relação entre eles foi bem-sucedida. Contudo, o suporte depende do driver; o suporte a VolumeSnapshots comuns não comprova o suporte a snapshots de grupos, e a maioria dos principais drivers de nuvem examinados para o laboratório ainda não os implementava até meados de 2026. Além disso, os CRDs, o recurso de snapshots e os complementos relacionados devem ser ativados explicitamente.
O que um teste de recuperação deve medir?
- Restaurar uma aplicação completa em um destino limpo que nunca a tenha executado, e não apenas excluir um Pod e observar sua recriação.
- Verificar os dados e o caminho de acesso do usuário usando conteúdo esperado, em vez de se limitar ao status dos recursos ou às cores dos painéis.
- Medir todo o processo com um cronômetro, reconhecendo que o tempo real de recuperação inclui detecção, decisão, redirecionamento do tráfego e, possivelmente, o retorno ao ambiente original.
- Usar dois domínios de falha independentes, como um cluster de produção e um cluster de recuperação, mantendo o armazenamento de backups fora de ambos.
Leitura editorial: uma lacuna entre as ferramentas e a sequência de recuperação
A mudança prática destacada por esses experimentos é transferir o critério de sucesso de “o backup foi concluído” para “os dados corretos retornaram e estão acessíveis”. A limitação mais ampla é que o Kubernetes básico não define um contrato comum para coordenar dados, aplicação, cluster, tráfego e identidade, nem fornece um recurso padrão duradouro que descreva a unidade completa de recuperação da aplicação e suas dependências externas. Portanto, os limites entre GitOps, backups, infraestrutura e o caminho do usuário continuam sendo responsabilidade da equipe, mesmo quando existem ferramentas maduras para cada camada. A CNCF menciona que a iniciativa Cloud Native Business Continuity, da CNCF TAG Operational Resilience, busca reunir contribuições sobre a análise das lacunas do ecossistema, orientações de recuperação e arquiteturas de referência.