Backup na nuvem: o que a AWS não pode restaurar

Imagine abrir o painel do seu sistema numa segunda-feira e ler o seguinte aviso do seu provedor: parte dos seus dados não pode ser restaurada. Não "vai demorar". Não "estamos trabalhando nisso". Simplesmente não volta. Foi mais ou menos isso que a AWS comunicou a clientes depois que instalações no Oriente Médio foram atingidas por ataques iranianos, segundo o Wall Street Journal. É o tipo de notícia que faz todo mundo que depende de nuvem parar por um segundo e pensar: e se fosse comigo? A resposta depende inteiramente de como o seu backup na nuvem está montado hoje.

Vou ser direto: a maior parte das empresas que eu atendo não tem backup. Tem a sensação de backup. São coisas diferentes.

"Mas está na nuvem, não é seguro?"

Essa é a confusão mais cara que existe em tecnologia hoje.

A nuvem resolve um problema específico muito bem: ela tira de você a responsabilidade de comprar servidor, trocar HD queimado e pagar conta de ar-condicionado de sala técnica. Ela não tira de você a responsabilidade pelos seus dados. Todo grande provedor tem isso escrito em contrato, no que chamam de modelo de responsabilidade compartilhada. Eles cuidam da infraestrutura. Você cuida do que coloca dentro dela.

Traduzindo para o português de dono de empresa: se um data center vira pó, o provedor devolve o serviço. Os seus arquivos, só se você tiver mandado copiá-los para outro lugar antes.

E tem um detalhe técnico que engana muita gente. Quando você contrata um serviço na nuvem, escolhe uma "região", tipo São Paulo ou Norte da Virgínia. Dentro de uma região existem zonas de disponibilidade, que são prédios diferentes. A maioria dos sistemas é configurada para sobreviver à queda de um prédio. Quase nenhum é configurado para sobreviver à perda de uma região inteira. E é exatamente esse cenário, o regional, que aparece em guerra, desastre natural, incêndio grande ou bloqueio jurídico.

Isso não é hipótese, já aconteceu várias vezes

Guerra parece distante. Então vamos de exemplos mais domésticos.

Em março de 2021, a OVH, maior provedora de nuvem da Europa, teve um data center em Estrasburgo destruído por incêndio. Prédio inteiro. Milhares de clientes perderam dados de forma definitiva. Muitos descobriram naquele dia que o "backup" que pagavam estava no mesmo campus que pegou fogo. Empresas fecharam.

Em 2014, a Code Spaces, que hospedava código para outras empresas, sofreu um ataque. O invasor entrou no painel de administração da AWS e apagou os dados junto com os backups, porque backup e produção estavam na mesma conta, com as mesmas credenciais. A empresa anunciou o encerramento das operações em menos de 24 horas.

Em 2023, um provedor sul-coreano perdeu dados de clientes quando um ransomware criptografou produção e backups conectados. O padrão se repete: o backup existia, mas estava ao alcance do mesmo problema.

Backup que morre junto com o original nunca foi backup. Era só uma segunda cópia do risco.

O que você realmente precisa ter fora da nuvem do seu fornecedor

Existe uma regra antiga de TI, a 3-2-1, e ela envelheceu muito bem. Três cópias dos dados, em dois tipos de mídia ou plataformas diferentes, e uma delas fora do local principal.

Para um negócio pequeno ou médio que roda em SaaS, eu adapto assim:

• Uma cópia fora do fornecedor principal. Se seu sistema roda na AWS, a cópia de segurança não pode estar só na AWS. Pode ir para o Google Cloud, para um storage barato tipo Backblaze, ou até para um NAS no escritório.
• Uma cópia que o sistema de produção não consegue apagar. Credencial separada, conta separada, de preferência com bloqueio de exclusão por período (imutabilidade). Isso é o que te salva de ransomware e de funcionário irritado.
• Uma cópia em formato que você consegue ler sem o fornecedor. CSV, JSON, PDF, SQL. Se o backup do seu CRM só abre dentro do próprio CRM, e o CRM sumiu, você tem um arquivo bonito e inútil.

Esse terceiro ponto é o mais esquecido e o mais importante em SaaS. Você não está só na nuvem de infraestrutura. Está no Bling, no Omie, no RD Station, no Notion, no ClickUp, no WhatsApp Business. Cada um desses guarda pedaços do seu negócio. Cada um pode te bloquear por suspeita de fraude no cartão, encerrar um plano, ou simplesmente quebrar.

O teste que quase ninguém faz

Aqui vai a pergunta que eu faço em toda primeira reunião e que quase sempre trava a conversa: quando foi a última vez que você restaurou um backup?

Não "gerou". Não "conferiu se o arquivo existe". Restaurou de verdade, abriu, olhou os dados, e confirmou que estava tudo lá.

Backup não testado é uma crença religiosa. Eu já peguei rotina de exportação que rodava havia oito meses gerando arquivo de 0 KB, porque a senha da API tinha expirado e ninguém lia o e-mail de erro. Já peguei dump de banco de dados perfeito, completo, íntegro, mas que faltava a pasta de anexos: todos os contratos assinados em PDF, todas as fotos de produtos, nada disso estava no backup. O banco tinha o caminho dos arquivos. Os arquivos, não.

Faça isso uma vez por trimestre. Pegue o backup mais recente, restaure num ambiente separado, e tente responder a três perguntas simples:

1. Os dados dos últimos sete dias estão lá?
2. Os anexos e imagens abrem?
3. Quanto tempo isso levou, do zero até funcionando?

Essa terceira resposta é o seu tempo real de recuperação. Se for oito horas e seu negócio não aguenta duas, você não tem um problema de backup, tem um problema de arquitetura, e é melhor descobrir isso num teste do que numa crise.

Quanto tempo e quanto dado você aguenta perder

Duas perguntas resolvem 90% do planejamento, e nenhuma delas é técnica.

Quanto tempo o negócio aguenta parado? Uma hora? Um dia? Uma semana? Uma loja online parada por um dia perde vendas e recupera. Uma clínica sem prontuário por um dia cancela a agenda inteira e machuca a reputação.

Quanto dado o negócio aguenta perder? Se o backup roda toda madrugada e o problema acontece às 17h, você perde o dia inteiro de trabalho. Todo pedido, toda ligação registrada, todo atendimento. Para alguns negócios isso é aceitável. Para outros é inaceitável, e aí o backup precisa ser contínuo.

Responda essas duas com um número e o resto vira execução. Sem elas, qualquer solução que alguém te vender é chute com nota fiscal.

E sim, existe custo. Mas muito menos do que as pessoas imaginam. Guardar 500 GB em storage frio numa segunda nuvem custa algo entre 10 e 25 reais por mês. A automação que copia isso todo dia, testa e te avisa quando falha, é trabalho de configuração, não assinatura eterna. Compare com o valor de uma semana parada e a conta fecha sozinha.

O que fazer nesta semana

Você não precisa de um projeto de seis meses. Precisa de uma tarde.

Liste todos os sistemas onde seu negócio guarda algo que importa. Sistema de gestão, financeiro, CRM, e-mails, arquivos, site. Para cada um, escreva três coisas: onde estão os dados, se existe exportação automática, e quem tem acesso a essa exportação. Só montar essa tabela já costuma revelar dois ou três buracos que ninguém sabia que existiam.

Depois disso, escolha o sistema mais crítico e configure uma exportação diária para um lugar diferente do fornecedor original. Só um. Comece pelo que doeria mais perder.

A notícia da AWS é dramática porque envolve mísseis, mas o aprendizado é banal e vale para quem nunca vai chegar perto de uma zona de conflito. Toda dependência que você não consegue substituir é uma aposta de que nada vai dar errado. E dá, mais cedo ou mais tarde, geralmente numa sexta-feira à tarde.

Se você quer uma segunda opinião sobre onde estão os buracos no seu setup, me conte como funciona hoje. Em geral dá para resolver com automação simples, e sem trocar nada do que você já usa.

A AWS avisou clientes que parte dos dados simplesmente não volta. Não "vai demorar". Não volta.

A maior parte das empresas que eu atendo não tem backup. Tem a sensação de backup.

A nuvem cuida da infraestrutura. Seus dados continuam sendo responsabilidade sua, está no contrato.

E a pergunta que quase sempre trava a reunião: quando foi a última vez que você restaurou um backup de verdade? Não gerou. Restaurou, abriu e conferiu.

Já peguei rotina rodando havia oito meses gerando arquivo de 0 KB, porque a senha da API expirou e ninguém lia o e-mail de erro.

Backup que morre junto com o original nunca foi backup. Era só uma segunda cópia do risco.

Se quiser, me conte como está o seu setup hoje. Em geral dá para resolver com automação simples, sem trocar nada do que você já usa.

#backup #cloudcomputing #gestaoderiscos #tecnologia #pmes