Esta semana em cloud (07–13/set): o backup terminou — a recuperação, ninguém cronometrou

TL;DR — Um guia da CNCF mostrou, em três falhas reproduzíveis, que backup "Completed" pode não ter dado, que GitOps recria a aplicação vazia e que snapshots de volumes separados geram pagamentos sem pedido. O OCI Cache ganhou réplica entre regiões sem failover automático, por decisão de projeto; um caso de PostgreSQL mostrou lag de 60 segundos em horário ocioso; e o Karmada graduou na CNCF. A lição da semana: recuperação só existe se foi ensaiada e cronometrada.

A semana passada foi sobre sair de um lugar sem parar nada. Esta foi sobre o que acontece quando você não escolhe sair — quando a região cai, o volume corrompe ou alguém apaga o namespace errado.

Não houve um grande anúncio de disaster recovery. Houve cinco textos, de três organizações, que por caminhos diferentes chegaram à mesma conclusão desconfortável: quase todo mundo tem backup, e pouca gente sabe quanto tempo leva para voltar. A CNCF publicou um laboratório com três falhas reproduzíveis em Kubernetes. A Oracle lançou réplica entre regiões para o OCI Cache — sem failover automático, de propósito — e publicou um caso de PostgreSQL em que a réplica ficava um minuto atrás justamente quando ninguém estava olhando. O Google levou a GA um orquestrador de alta disponibilidade para AlloyDB Omni fora da nuvem. E o Karmada, que distribui aplicações e faz failover entre clusters, se tornou projeto graduado da CNCF.

Por que um backup "Completed" não prova nada?

Porque o status mede a operação, não o resultado. E o guia publicado na CNCF por Saiyam Pathak e Saloni Narang mostra isso com três cenários que qualquer time consegue reproduzir no próprio lab.

Cenário 1 — o backup que não levou os dados. Com Velero e snapshots CSI, um backup pode terminar como Completed sem que o conteúdo do volume tenha saído do cluster. A checagem que importou no laboratório foi olhar quanto o data mover realmente enviou ao object storage — 47.989.888 bytes, no caso — e, depois, restaurar o namespace inteiro e consultar o PostgreSQL para ver se as quatro linhas esperadas estavam lá. Status verde não é evidência; linha no banco é.

Cenário 2 — o GitOps que recriou tudo, vazio. O controlador GitOps reconstruiu a aplicação a partir dos manifestos sem nenhum erro. Só que o banco voltou sem dados, porque manifesto não carrega estado. A recuperação só se completou com a restauração explícita do backup — e foi cronometrada: quatro minutos na primeira execução, pouco menos de dois no ensaio repetido. A frase dos autores resume a separação que muita arquitetura esquece: "Git stores intent, and backups store state".

Cenário 3 — os snapshots que discordam entre si. Uma aplicação com pedidos num volume e pagamentos em outro teve os snapshots tirados individualmente, com cinco segundos de diferença. Restaurados, os dois volumes contavam histórias diferentes: 25 pagamentos sem pedido correspondente. A correção foi usar VolumeGroupSnapshot, que congela os volumes no mesmo ponto. Nenhuma ferramenta de backup acusaria erro ali — o dado estava íntegro em cada volume e inconsistente entre eles.

A recomendação final do guia cabe numa linha e deveria estar em todo runbook: restaure a aplicação completa num ambiente limpo, valide os dados contra um resultado conhecido e meça o tempo total com um relógio.

Quem aperta o botão de failover?

Essa é a pergunta que os lançamentos da semana responderam de formas diferentes — e a diferença é instrutiva.

A replicação entre regiões do OCI Cache mantém um cluster secundário warm em outra região, sincronizado de forma assíncrona por rede privada, com atraso projetado na faixa de poucos segundos. O detalhe de desenho é a ausência deliberada de failover automático. Se as duas regiões estão de pé, você faz um switchover planejado, e a documentação pede para parar as escritas antes. Se a primária caiu, converte o secundário em standalone e redireciona a aplicação. A justificativa é honesta: uma falha regional exige recuperar a stack inteira de forma coordenada, e promover só o cache pode piorar a situação.

Há letras miúdas que viram incidente se ninguém ler: os clusters precisam de pelo menos 8 GB por nó, reserved-memory-percentage de 35% ou mais e maxmemory-policy diferente de noeviction; só clusters não sharded são suportados; e a configuração e os usuários de ACL não são copiados para a região secundária. Quem promover o secundário sem ter replicado as ACLs vai descobrir, no pior momento, que a aplicação não autentica.

No outro extremo, o AlloyDB Omni RPM Orchestrator chegou a GA para rodar PostgreSQL compatível com alta disponibilidade em servidores Red Hat, fora da nuvem: replicação síncrona entre zonas, failover automático, Keepalived, PgBouncer e HAProxy na frente, um configuration store com três nós de etcd e point-in-time recovery automatizado para GCS ou storage compatível com S3. É o mesmo desenho que o ecossistema aberto já oferece com Patroni ou CloudNativePG — a novidade é o pacote empresarial pronto para quem não roda Kubernetes.

E o Karmada, graduado na CNCF nesta semana com mais de 1.214 contribuidores de 292 organizações, leva o raciocínio para a camada de aplicação: placement, propagação e failover de workloads entre clusters, nuvens e regiões, por política.

Camada	O que a semana trouxe	Failover automático?	O que ensaiar
Banco, dentro do site	AlloyDB Omni RPM Orchestrator (GA)	Sim, entre zonas, com replicação síncrona	O failover sob carga e o PITR restaurando um ponto conhecido
Cache, entre regiões	Replicação cross-region do OCI Cache	Não — promoção manual por runbook	A conversão para standalone e a recriação de ACLs e configuração
Banco, entre regiões	PostgreSQL com pglogical (caso Oracle)	Não — a promoção é desenho seu	O lag nos períodos de pouca escrita, não só no pico
Aplicação, entre clusters	Karmada (graduado na CNCF)	Disponível, por política	Se o estado acompanha a aplicação até o cluster de destino

A leitura da tabela é simples: dentro de um site, a automação já é madura; entre regiões, a decisão continua sendo humana. E decisão humana sem critério escrito e sem ensaio vira reunião de crise.

Seu plano de DR nunca foi cronometrado? A Nuvem Online desenha e ensaia a recuperação com você, do backup ao failover regional.

Replication lag é RPO — e depende de quando você escreve?

Depende, e o caso publicado por Mark Janzen, arquiteto da Oracle, é o melhor exemplo da semana.

Uma plataforma global de segurança queria réplicas de PostgreSQL próximas dos usuários na América do Norte, na Europa e na Ásia. A primeira tentativa, com a réplica warm standby gerenciada do OCI, funcionava bem durante o pico. Nos períodos quietos, uma alteração levava até 60 segundos para aparecer nas outras regiões. O motivo é mecânico: a replicação física envia segmentos de WAL, e com pouca escrita o segmento demora a encher — o serviço esperava o archive_timeout vencer. Reduzir o timeout resolveria o atraso ao custo de arquivar um arquivo de WAL de 16 MB a cada troca forçada, mesmo quase vazio.

A saída foi trocar de técnica: com pglogical, que faz replicação lógica, as mudanças passaram a chegar em 1 a 2 segundos. O próprio texto registra o limite: nem pglogical nem GoldenGate transformam PostgreSQL num banco com escrita consistente em qualquer região; escrita ativa em várias regiões exige particionar a propriedade dos dados por tenant, cliente ou região.

A lição vale para além do PostgreSQL. O seu RPO não é o número do fornecedor — é o atraso medido no seu padrão de escrita. Um sistema que escreve pouco de madrugada pode ter o pior RPO exatamente no horário em que o incidente tem mais chance de passar despercebido.

O que isso significa para quem opera infra no Brasil?

Três consequências práticas, em ordem de urgência.

1. Ensaio cronometrado vale mais que ferramenta nova. Nenhum dos três cenários da CNCF exige comprar nada — exige restaurar num ambiente limpo e olhar o dado. Para a maioria das empresas brasileiras, o primeiro exercício útil é escolher o serviço mais crítico, restaurá-lo do zero num cluster descartável e anotar o tempo. O número que sair dali é o RTO real, e costuma ser bem diferente do que está no documento de continuidade. Quem opera Kubernetes on-premises, sem o console do provedor para ajudar, sente isso primeiro — foi um dos pontos centrais do caso de Kubernetes on-premises em infraestrutura estatal.

2. O runbook precisa separar intenção, estado e o que não é replicado. Git recria a intenção; o backup devolve o estado; e sempre existe uma terceira lista — ACLs, configuração, segredos, DNS — que nenhum dos dois cobre sozinho, como mostra a letra miúda do OCI Cache. Um runbook bom tem as três seções, com a ordem de execução e quem é o dono de cada uma.

3. Lag de replicação precisa virar alerta, e a decisão de failover precisa de dono. Métricas como CrossRegionReplicationLag só protegem se alguém definir o limite e for acordado quando ele estourar — vale plugá-las na mesma stack de alertas do resto da operação, como descrevemos no guia de observabilidade self-hosted com LGTM. E há um ponto local: empresas que usam uma região fora do país como destino de DR estão, na prática, transferindo dados pessoais para o exterior, o que precisa estar coberto nas bases de transferência internacional da LGPD antes do dia em que o failover acontecer, não depois.

O que mais aconteceu na semana

Fora do fio da resiliência, cinco movimentos merecem nota:

O atacante ganhou agente. O Google Threat Intelligence publicou a nova edição do AI Threat Tracker: um ator foi do comprometimento de um recurso de nuvem a uma campanha de coleta de credenciais em massa em menos de seis horas; outro grupo, o UNC6780, comprometeu pacotes no PyPI, npm e Docker Hub publicando-os com atestações SLSA Build 3 válidas, extraiu tokens OIDC de runners do GitHub Actions e escondeu arquivos em diretórios como .claude/, .vscode/ e .cursor/. Servidores MCP legítimos também apareceram trojanizados. Atestação válida deixou de ser prova de pacote confiável.
kubectl com cliente público e PKCE. Um texto da CNCF defendeu que o acesso a clusters via provedor de identidade use cliente OIDC público com PKCE, e não cliente confidencial — um segredo distribuído para todas as máquinas que acessam o cluster deixa de ser segredo. Com kubelogin, redirect restrito a loopback e grupos mapeados para RBAC, o controle de acesso passa a morar no IdP. Conversa direta com o que já discutimos sobre IAM unificado sem lock-in.
O HTTPS que funciona fora e falha dentro do pod. A Oracle documentou um caso clássico no OKE com Envoy Gateway: TLS terminado no load balancer, backend em HTTP, e pods recebendo SSL wrong version number ao chamar o mesmo hostname. Com ipMode: VIP, o tráfego interno pula o load balancer. A correção é a annotation oci.oraclecloud.com/ingress-ip-mode: "proxy", aplicada na configuração do EnvoyProxy, não no Service gerado.
AWS abriu a próxima geração do sistema base. O Amazon Linux 2027 entrou em preview pública, com kernel 7.1 ou superior, e as instâncias R9g e R9gd com Graviton5 prometem até 25% mais desempenho de computação que a geração R8g e até 30% mais velocidade para bancos de dados. Na mesma leva, o Claude Fable 5.1 chegou ao Bedrock e o AWS Agent Registry ficou disponível em GA.
Spanner mudou onde o limite de mutation é contado. O teto de 80 mil mutation mods deixou de ser cumulativo por transação e passou a valer por statement DML. Transações podem agrupar mais operações sem split artificial — mas transação longa segura lock por mais tempo, e quem usa a Mutation API continua com o limite antigo.

Perguntas Frequentes

Se o meu backup termina com status Completed todo dia, eu estou protegido?
Não necessariamente. Completed diz que a operação de backup terminou, não que os dados do volume saíram do cluster nem que a aplicação volta funcionando. No laboratório publicado pela CNCF, a checagem útil foi outra: conferir os bytes que o data mover efetivamente enviou ao object storage e, depois, restaurar o namespace inteiro num ambiente limpo e consultar o banco para ver se as linhas esperadas estavam lá. Sem essa restauração de ponta a ponta, o backup é uma suposição com status verde.

Se tudo está em GitOps, preciso mesmo de backup?
Precisa, porque os dois guardam coisas diferentes. O repositório Git guarda a intenção — quais Deployments, Services e volumes devem existir. O backup guarda o estado — o que estava escrito dentro desses volumes. No cenário da CNCF, o controlador GitOps recriou a aplicação com perfeição, só que vazia; os dados só voltaram com a restauração explícita do backup. Um runbook de DR sério descreve as duas etapas, a ordem entre elas e quanto tempo cada uma leva.

Por que a Oracle não oferece failover automático na réplica entre regiões do OCI Cache?
Porque uma falha regional raramente derruba só o cache. A própria documentação argumenta que a recuperação exige coordenar a stack inteira — aplicação, rede, banco, cache e operação —, e promover o cache sozinho para outra região, com o banco ainda apontando para a região antiga, pode causar mais dano do que a queda. Por isso a promoção é manual: com as duas regiões de pé, faz-se um switchover planejado; com a primária fora, converte-se o secundário em standalone. O que isso exige de você é um runbook com critério de decisão e alguém autorizado a executá-lo.

Como sei qual é o RPO real da minha replicação de banco?
Medindo sob o seu padrão de escrita, e principalmente nos períodos quietos. No caso publicado pela Oracle, a réplica física de PostgreSQL ficava em dia durante o pico, mas chegava a 60 segundos de atraso quando havia pouca escrita, porque o segmento de WAL só era enviado quando enchia ou quando o archive_timeout vencia. Com replicação lógica via pglogical, o atraso caiu para 1 a 2 segundos. A métrica de lag precisa virar alerta com limite definido, e o teste de RPO precisa incluir a madrugada de domingo, não só o horário de pico.

Fontes: