Política de backup: a regra 3-2-1 e o que precisa estar documentado

📚 Continue aprendendo sobre este tema:

O erro que quase toda empresa comete: confundir backup com restauração

Quando perguntamos a um diretor se a empresa tem backup, a resposta é quase sempre sim. Quando perguntamos qual foi a última vez que alguém restaurou um arquivo de verdade a partir dessa cópia, o silêncio é comum.

Backup é a atividade de copiar. Restauração é a atividade de trazer de volta. A empresa contrata a primeira e depende da segunda. E há uma lista longa de motivos pelos quais uma cópia aparentemente saudável não volta:

A rotina rodava, mas havia meses deixara de incluir a pasta que mais importa.
A cópia existe, mas está no mesmo servidor que falhou.
A cópia está íntegra, mas ninguém sabe a senha do repositório porque quem sabia saiu da empresa.
A restauração funciona, mas leva dois dias, e a operação não sobrevive a dois dias parada.
O backup foi criptografado junto com o resto durante um ataque de ransomware, porque estava acessível pela mesma rede e com a mesma credencial.

Esse último item mudou o desenho de backup nos últimos anos. Quem ataca sabe que a cópia é o que impede o pagamento do resgate, então a cópia virou o primeiro alvo. Nosso plano prático contra ransomware detalha o restante das camadas, mas o resumo é direto: se o invasor consegue apagar seu backup com as credenciais que ele roubou, você não tem backup.

A regra 3-2-1, traduzida

A regra é simples de dizer e cheia de detalhe na execução.

Elemento	O que significa	Que falha ele cobre
3 cópias	O dado em produção mais duas cópias independentes	Exclusão acidental, corrupção de arquivo, erro de usuário
2 mídias diferentes	As cópias não moram no mesmo tipo de dispositivo nem no mesmo sistema	Falha de hardware, defeito de lote, problema no próprio sistema de armazenamento
1 fora do local	Uma cópia em outro endereço físico ou em nuvem	Incêndio, alagamento, furto, indisponibilidade do escritório

Duas variações apareceram com o tempo e valem a pena para empresa que depende de sistema crítico. A primeira acrescenta uma cópia isolada, sem acesso pela rede de produção. A segunda acrescenta a exigência de zero erro na verificação, ou seja, a cópia precisa ser testada, não só existir. Na prática, para uma média empresa usuária de ERP, o desenho mínimo defensável hoje é: cópia local rápida para restaurar arquivo do dia a dia, cópia em nuvem ou em outro endereço para desastre, e pelo menos uma versão que não possa ser apagada nem por quem tem privilégio de administrador.

Cópia imutável, em linguagem de negócio

Cópia imutável é aquela que, uma vez gravada, não pode ser alterada nem excluída até o fim de um prazo definido. Nem pelo administrador, nem por quem roubar a senha dele, nem por engano.

Ela custa mais, porque ocupa espaço que você não consegue liberar antes do prazo. E é exatamente por isso que funciona. Se a sua empresa opera com dado que não pode ser perdido, como base do ERP, contabilidade e contratos, essa é a linha do orçamento que você não corta.

RPO e RTO: os dois números que a diretoria precisa definir

Esses dois termos parecem técnicos, mas são decisões de negócio. Quem responde não é o técnico, é quem responde pelo prejuízo.

RPO, ponto de recuperação: quanto de trabalho a empresa aceita perder. É medido em tempo. Se o RPO é de 24 horas, você aceita perder até um dia de lançamentos.
RTO, tempo de recuperação: quanto tempo a empresa aceita ficar parada até voltar a operar. Também é medido em tempo.

Um exemplo aritmético deixa claro. Suponha que o backup do ERP rode uma vez por dia, às 22 horas, e o servidor falhe às 16 horas do dia seguinte. A última cópia boa é a das 22 horas do dia anterior, então se perdeu tudo o que foi lançado entre 22 horas e 16 horas, ou seja, 18 horas de trabalho. Se a empresa não aceita perder 18 horas de lançamento fiscal, o RPO real dela não é de 24 horas, e a frequência do backup precisa mudar. Não adianta escrever no papel um RPO de 1 hora e manter rotina diária: a política vira ficção.

A mesma lógica vale para o RTO. Restaurar uma base grande a partir de uma cópia em nuvem leva o tempo que a conexão permitir. Se o RTO prometido é de 4 horas e a cópia demora mais que isso só para descer, a promessa não se sustenta. É por isso que a cópia local existe: ela atende o RTO curto, enquanto a cópia externa atende o desastre.

Como chegar a esses números sem chute

Liste os sistemas por criticidade, não por tamanho. ERP, e-mail, sistema fiscal e pasta de contratos costumam liderar.
Para cada um, pergunte à área dona: se isso sumir agora, o que a empresa deixa de fazer, e a partir de quantas horas o prejuízo vira grave?
Escreva o RPO e o RTO desejados por sistema.
Compare com o que a infraestrutura atual entrega de fato. A diferença entre os dois é o seu projeto, com custo e prazo.
Leve essa diferença para a diretoria decidir: ou se investe para fechar a lacuna, ou se aceita formalmente o risco, por escrito.

Esse último passo é o que separa governança de boa intenção. Risco aceito por escrito, com nome e data, é gestão. Risco ignorado é surpresa esperando acontecer. O mesmo raciocínio aparece no nosso material sobre implantar governança de TI em 90 dias.

Teste de restauração: a única prova que vale

Relatório verde de backup prova que a cópia rodou. Só o teste de restauração prova que a cópia serve. Estabeleça uma rotina com três níveis:

Teste pontual, frequente: restaurar um arquivo ou uma caixa de e-mail escolhida ao acaso. É rápido e pega o erro mais comum, que é escopo incompleto.
Teste de sistema, periódico: restaurar uma base ou um servidor inteiro em ambiente separado, e abrir o sistema para ver se ele sobe mesmo.
Simulação de desastre, planejada: exercitar o cenário em que o ambiente principal não existe mais, cronometrando quanto tempo se leva até a operação voltar.

Cada teste precisa gerar registro: data, quem executou, o que foi restaurado, quanto tempo levou, o que falhou. Esse registro é o que você mostra ao auditor, ao cliente que exige comprovação e à seguradora. E é também o que permite comparar o RTO prometido com o RTO medido.

O que a política de backup precisa ter por escrito

Uma política de backup útil cabe em poucas páginas e responde, sem ambiguidade, aos itens abaixo:

Escopo. Quais sistemas, bases, pastas e serviços em nuvem estão cobertos, e quais estão explicitamente fora.
Frequência. De quanto em quanto tempo cada item é copiado.
Retenção. Por quanto tempo cada cópia é guardada, e quando ela é descartada.
Localização. Onde mora cada cópia, incluindo a de fora do local.
Imutabilidade. Quais cópias não podem ser apagadas antes do prazo, e por qual mecanismo.
RPO e RTO por sistema. Os números aprovados pela diretoria.
Responsáveis. Quem executa, quem confere o resultado diário, quem responde quando falha.
Rotina de teste. Tipo de teste, periodicidade e formato do registro.
Procedimento de restauração. Passo a passo escrito, para que qualquer pessoa capacitada consiga executar sob pressão.
Credenciais e acesso. Onde ficam as senhas do repositório e quem tem acesso, com um caminho válido caso o responsável esteja indisponível.
Dado pessoal. Como a política trata a LGPD, incluindo o que acontece com um pedido de exclusão quando o dado também está no backup.
Revisão. Com que periodicidade o documento é revisado e por quem.

Repare no item 11. Ele é ignorado com frequência e aparece nas auditorias. Backup e direito de eliminação convivem, mas a política precisa dizer como: normalmente registrando o pedido, aplicando a exclusão na base viva e documentando que a cópia histórica será descartada no fim do prazo de retenção, sem ser reintroduzida em produção.

Erros comuns que a política previne

Backup rodando com a mesma credencial de administrador usada no dia a dia.
Repositório de cópia acessível por toda a rede, sem isolamento.
Alerta de falha indo para uma caixa de e-mail que ninguém lê.
Servidor novo que entra em produção e nunca é incluído na rotina.
Sistema em nuvem tratado como se já viesse com backup completo, sem verificar o que a plataforma realmente cobre.
Retenção infinita por falta de decisão, inflando custo sem ganho.

O quarto item merece atenção especial em ambientes que crescem. Todo servidor novo precisa entrar na rotina de backup no mesmo dia em que entra em produção, e isso funciona melhor quando existe uma rotina formal de gestão de servidores, com checklist de entrada em operação.

Perguntas frequentes

Backup em nuvem sozinho já atende a regra 3-2-1?

Depende de como está montado. Se existe o dado em produção, uma cópia local e uma cópia em nuvem, você tem três cópias, dois ambientes distintos e uma fora do local, o que atende ao espírito da regra. O que não atende é ter apenas o dado em produção e uma única cópia na nuvem: nesse caso você tem duas cópias, e qualquer problema na segunda deixa você sem alternativa.

Com que frequência devo testar a restauração?

O teste rápido de um arquivo deve ser rotina frequente e sempre registrada. O teste de sistema completo, com a base subindo em ambiente separado, precisa de periodicidade definida na política e cadência maior. A regra prática é: nenhum sistema crítico deve passar um ciclo longo sem que alguém tenha comprovado, na prática, que ele volta.

Se o e-mail e os arquivos estão no Microsoft 365, ainda preciso de backup?

Sim. A plataforma garante a disponibilidade do serviço, o que é diferente de proteger contra exclusão acidental, saída de funcionário ou necessidade de recuperar uma versão antiga muito tempo depois. Trate a retenção nativa como um recurso útil e o backup como uma camada separada, com escopo e responsável definidos na sua política.

Como a BS IT Solutions ajuda

A BS IT Solutions monta a política de backup junto com a diretoria, define RPO e RTO sistema a sistema, implanta o desenho de cópias com camada imutável, coloca o monitoramento das rotinas dentro do nosso NOC 24x7 e executa os testes de restauração com registro formal para auditoria. O objetivo é simples: quando o pior dia acontecer, a resposta já estar escrita e testada.

Fale com um especialista da BS IT Solutions e faça uma revisão honesta do que a sua empresa consegue restaurar hoje, e em quanto tempo.