Casos

Casos: o desenho por trás de cada recuperação

Clientes anonimizados por confidencialidade. Cada caso indica se é uma operação que executamos ou um cenário representativo — a distinção está no card, porque misturar as duas coisas é o que transforma caso em propaganda.

Leitura

Como ler estes casos

Operação real

Operação real: executada por nós. O cliente está anonimizado por acordo de confidencialidade, e os números são medidos.

Cenário representativo

Cenário representativo: construído a partir de arquiteturas que operamos, com metas típicas de projeto. Não é resultado de cliente e está marcado como tal em todo lugar onde aparece.

Arquitetura

Dois níveis, sempre

Toda arquitetura aqui tem duas cópias com propósitos diferentes. O nível 1 resolve o incidente comum com velocidade; o nível 2 existe para o dia em que a conta do cliente inteira estiver comprometida. Quem tem só o nível 1 descobre a diferença no pior momento possível.

Nuvem do clienteProduçãoNível 1cópia localsem egressRestauração rápidaSe a conta do cliente for comprometida,produção e nível 1 caem juntos.É por isso que existe o nível 2.Conta e credencialseparadasFora da nuvem do clienteNível 2 — cópia imutávelWORM · retenção travadaoutro provedor, outra contaQuem tomou a conta de origemnão tem credencial aqui.Nem apaga, nem cifra, nem lê.só escreve
O nível 1 é rápido porque está perto: restaura sem egress e sem depender de banda externa. O nível 2 é seguro porque está longe, em conta e credencial que a produção não administra. Um resolve o incidente da terça-feira; o outro decide se a empresa sobrevive ao pior dia.
Operação realOperação multi-cloud

600 servidores protegidos em OCI e AWS, com o menor custo total do desenho

Porte
600 servidores · bancos de dados e arquivos · duas nuvens
Stack
Oracle Cloud (OCI)AWSLinuxWindowsBancos relacionaisArquivos
O problema

Parque grande e heterogêneo espalhado por duas nuvens, com bancos de dados, servidores de aplicação e volumes de arquivo. A exigência era dupla e normalmente conflitante: reduzir o custo total de proteção e, ao mesmo tempo, garantir que nenhuma exclusão — de um invasor com credencial de administrador ou de um operador distraído — pudesse destruir a cópia.

Nível 1 — na nuvem do cliente

Cópia dentro da própria tenancy do cliente, em OCI e em AWS. Restauração rápida, sem custo de egress e sem depender de banda externa — resolve o caso comum: arquivo apagado, tabela corrompida, servidor que precisa voltar hoje.

Nível 2 — fora da nuvem do cliente

Cópia fora da nuvem de origem, em conta e credencial separadas, com retenção travada por política. A conta que roda a produção não tem permissão para apagar essa cópia. Quem toma a conta de origem não alcança o nível 2 — nem para apagar, nem para cifrar, nem para ler.

600
Servidores sob gestão
bancos, aplicação e arquivos
OCI + AWS
Nuvens
cópia cruzada entre elas
Incremental
Transferência
só o bloco alterado sai
AES-256
Em repouso
com compressão antes de cifrar
O que decide o resultado

A economia veio de três decisões combinadas, não de negociar preço de GB. Primeiro, backup incremental permanente: depois da carga inicial, só o bloco alterado trafega, o que derruba tanto o volume armazenado quanto a janela. Segundo, compressão aplicada antes da criptografia — a ordem importa, porque dado cifrado não comprime. Terceiro, camadas de retenção: o que precisa voltar hoje fica em acesso imediato, o que existe para auditoria desce para arquivamento. A proteção contra exclusão é estrutural, não uma configuração que alguém pode reverter sozinho: a imutabilidade vive numa conta que a produção não administra.

Cenário representativoServiços financeiros

RPO de minutos em cluster PostgreSQL, com cinco anos de retenção para o regulador

Porte
Cluster PostgreSQL · 3,5 TB · transações contínuas
Stack
PostgreSQLWAL streamingPITRKubernetes
O problema

Instituição que não pode perder transação confirmada e ainda precisa provar ao regulador que consegue reconstituir qualquer instante dos últimos cinco anos. Backup noturno não atende nenhuma das duas exigências: perde o dia inteiro de transações e não permite voltar a um ponto específico.

Nível 1 — na nuvem do cliente

WAL streaming contínuo para réplica quente na mesma nuvem, com PITR de granularidade de segundo. É o que sustenta o RPO de minutos e permite voltar exatamente ao instante anterior a um erro de aplicação.

Nível 2 — fora da nuvem do cliente

Backup full semanal mais cadeia de WAL arquivada fora da nuvem de origem, com retenção imutável de cinco anos. Atende a exigência regulatória e sobrevive ao cenário em que a conta de produção é comprometida.

< 5 min
RPO alvo
meta típica de projeto
1 a 4 h
RTO alvo
meta típica de projeto
5 anos
Retenção
imutável, para auditoria
PITR
Granularidade
qualquer instante da série
O que decide o resultado

O ponto delicado desse desenho não é o backup, é a cadeia de WAL: se um único segmento se perde, a recuperação para naquele ponto e todo o resto da série vira arquivo inútil. Por isso o teste mensal aqui não restaura só o full — ele reconstrói a partir de um instante sorteado dentro do período, o que é a única forma de provar que a cadeia está íntegra de ponta a ponta.

Cenário representativoIndústria

O ransomware chegou ao administrador do domínio — e a cópia sobreviveu

Porte
SQL Server Always On · 40 servidores · chão de fábrica em turno contínuo
Stack
SQL ServerAlways OnWindows ServerLog shipping
O problema

O cenário que mais destrói empresa não é o ransomware que cifra os servidores: é o que espera semanas, obtém credencial de administrador, apaga o backup e só então cifra a produção. Contra esse ataque, cópia que o administrador consegue apagar não é backup — é a segunda vítima.

Nível 1 — na nuvem do cliente

Full semanal, diferencial diário e log shipping a cada quinze minutos, dentro da nuvem do cliente. Cobre falha de hardware, corrupção de base e erro humano — a maioria dos incidentes reais.

Nível 2 — fora da nuvem do cliente

Cópia em conta separada com imutabilidade WORM e exclusão sujeita a aprovação de duas pessoas. A credencial de domínio comprometida não tem alcance nenhum sobre esse destino. Detecção de anomalia alerta quando o padrão de alteração sugere criptografia em massa.

15 min
RPO alvo
meta típica de projeto
WORM
Retenção travada
não apagável por administrador
2 pessoas
Exclusão de política
aprovação dupla
Ativo
Alerta de anomalia
padrão de cifragem em massa
O que decide o resultado

A pergunta que separa um plano que funciona de um que só parece funcionar é simples: quem consegue apagar a última cópia? Se a resposta incluir qualquer credencial que também exista na produção, o plano tem um ponto único de falha que nenhum volume de backup compensa. Nesse desenho, a resposta é ninguém sozinho — nem o cliente, nem nós.

Cenário representativoSaúde

Dado sensível com residência nacional e chave sob custódia do cliente

Porte
MongoDB sharded · 12 TB de imagem e prontuário
Stack
MongoDBReplica setShardingArmazenamento de objeto
O problema

Prontuário e imagem médica são dado pessoal sensível pela LGPD. A instituição precisava de residência em território nacional, de garantia de que o fornecedor de backup não conseguiria ler o conteúdo, e de retenção longa sem que o custo crescesse na mesma proporção do acervo.

Nível 1 — na nuvem do cliente

Snapshot consistente por shard mais oplog tailing, em região brasileira, dentro da nuvem da instituição. Restauração de coleção ou de shard isolado sem tocar o restante do cluster.

Nível 2 — fora da nuvem do cliente

Cópia imutável fora da nuvem de origem, também em território nacional, cifrada com chave gerenciada pelo próprio cliente no KMS dele. Revogar o acesso é ação unilateral da instituição — a partir dela, nenhuma cópia nova é legível por nós.

Brasil
Residência
declarada em contrato
BYOK
Custódia da chave
KMS do próprio cliente
Nenhuma
Leitura pelo fornecedor
sem a chave do cliente
3
Camadas de retenção
quente, morna e arquivo
O que decide o resultado

BYOK muda a natureza da relação e é por isso que vale o trabalho extra de configurar. Sem ele, a instituição precisa confiar que o fornecedor não vai ler o prontuário — uma promessa. Com ele, a instituição não precisa confiar: a leitura é tecnicamente impossível sem uma chave que nunca sai do controle dela. Promessa e impossibilidade não são a mesma garantia.

Cenário representativoSaaS · startup em crescimento

Acervo dobrando ao ano sem que a conta de backup dobre junto

Porte
MySQL Galera · 800 GB crescendo ~8% ao mês
Stack
MySQLGalera ClusterXtraBackupBinlog
O problema

Startup com dado crescendo mais rápido que a receita, guardando tudo em camada de acesso imediato porque nunca houve tempo de desenhar retenção. A conta de armazenamento crescia de forma composta e o time de engenharia gastava dias por trimestre cuidando de backup em vez de produto.

Nível 1 — na nuvem do cliente

XtraBackup com incremental diário e binlog contínuo, na própria nuvem. Restauração de nó do cluster sem parar os demais, e PITR para o erro de migração que aparece em produto que muda rápido.

Nível 2 — fora da nuvem do cliente

Cópia semanal fora da nuvem de origem, imutável, com política de ciclo de vida que desce automaticamente para arquivamento após o período de acesso frequente.

40 a 60%
Redução de custo alvo
meta típica ao aplicar camadas
Zero
Operação do time
gestão passa a ser nossa
2 a 4×
Ganho por compressão
varia com o tipo de dado
Trimestral
Revisão de política
acompanha o crescimento
O que decide o resultado

A economia quase nunca está no preço do gigabyte — está em parar de guardar tudo na camada mais cara pelo prazo mais longo. Retenção é decisão de negócio disfarçada de configuração técnica: quanto tempo cada tipo de dado precisa voltar em segundos, e a partir de quando voltar em horas é aceitável. Respondida essa pergunta, a conta cai sozinha.

Cenário representativoVarejo e e-commerce

Backup que não disputa recurso com a operação no pico de venda

Porte
PostgreSQL + arquivos de mídia · 2 TB · pico sazonal de 12×
Stack
PostgreSQLSnapshot de volumeArmazenamento de objetoCDN
O problema

Operação que fatura concentrado em poucos dias do ano não tem janela de manutenção nesses dias. O backup precisava deixar de competir por I/O e banda justamente quando cada segundo de latência custa conversão — sem que isso significasse ficar desprotegido no período de maior risco.

Nível 1 — na nuvem do cliente

Snapshot no nível do volume, que não disputa I/O com o banco, mais WAL contínuo para granularidade fina. Durante o pico, a cadência aumenta e o custo do full é adiado, não a proteção.

Nível 2 — fora da nuvem do cliente

Envio para fora da nuvem de origem em janela deslocada, com limite de banda configurado, e retenção imutável do período de pico por prazo estendido — é o intervalo em que uma perda de dado tem o maior custo de reconstituição.

Desprezível
Impacto em produção
snapshot fora do caminho de I/O
Aumentada
Cadência no pico
sem full na janela crítica
Estendida
Retenção do pico
o período mais caro de reconstituir
Limitada
Banda
teto configurado no envio
O que decide o resultado

Backup que degrada a produção acaba desligado — em geral por alguém apressado, na véspera do dia mais importante do ano, e ninguém religa depois. Por isso o desenho aqui trata a janela como restrição de primeira ordem, no mesmo nível do RPO. Proteção que o time tem motivo para desligar não é proteção.

Seu cenário se parece com algum destes?

O diagnóstico começa exatamente onde estes casos começaram: medindo volume, topologia e quanto tempo sua empresa aguenta parada.

Solicitar diagnóstico gratuito

Seu último backup foi restaurado com sucesso?

Se a resposta demorar mais de cinco segundos, vale uma conversa. Avaliamos seu cenário atual — bancos, volumes, janela e retenção — e devolvemos um diagnóstico com RTO e RPO estimados. Sem compromisso.

Infraestrutura em data centers certificados

AWS·Azure·Google Cloud·Oracle Cloud·Nuvem soberana BR