Austin IT Support

Seu backup rodou ontem à noite. Ele restauraria de verdade?

Jorge Velasquez14 de agosto de 20265 min de leitura
Seu backup rodou ontem à noite. Ele restauraria de verdade?

Em algum ponto da sua rede, ontem à noite um trabalho de backup terminou e acendeu uma luz de status em verde. Esse tique verde vale muito menos do que a maioria dos donos de empresa imagina. Ele confirma uma única coisa: que o trabalho rodou. Não diz nada sobre se os arquivos podem ser lidos, se o sistema inteiro pode ser reconstruído, nem se você conseguiria mesmo reabrir na segunda-feira caso um servidor morresse no fim de semana.

O único backup que serve é aquele do qual você já restaurou de propósito, antes de precisar dele. Um backup que você nunca testou não é uma rede de segurança. É uma esperança, e esperança não é um plano de recuperação quando estão em jogo a folha de pagamento, os registros dos seus clientes e os sistemas em que a sua equipe entra toda manhã.

Um tique verde não é uma recuperação

O software de backup é feito para reportar sucesso. Ele avisa que o trabalho foi concluído, que os arquivos foram copiados, que o horário foi cumprido. O que quase nunca avisa é se essa cópia voltaria à vida em hardware real, no tempo que a sua empresa realmente pode ficar parada.

Há uma distância enorme entre "o backup rodou" e "já estamos abertos de novo". Restaurar significa subir os sistemas na ordem certa, reconectar as peças que conversam entre si e fazer isso sob pressão enquanto o telefone toca e os clientes esperam. Um tique não mede nada disso. A única medida honesta é uma restauração que você viu acontecer.

A falha silenciosa que ninguém percebe

A falha de backup mais perigosa é a silenciosa. Um trabalho começa a dar erros, ou para de cobrir sem avisar um servidor novo que alguém acrescentou na primavera. Ele manda um alerta para uma caixa de entrada que ninguém lê, ou para um funcionário que saiu no ano passado. O painel, num relance, continua verde. As semanas passam e a empresa opera totalmente desprotegida sem que uma única pessoa saiba.

Então chega o dia: um disco que falha, um golpe de ransomware, uma pasta apagada. Alguém abre o backup pela primeira vez em meses e descobre que a última cópia boa é de antes de o problema começar, ou que ele nunca esteve rodando de verdade. Isso não é raro. É a forma mais comum de "nós temos backups" virar uma perda total, e acontece justamente porque ninguém estava vigiando os alertas.

RPO e RTO, em palavras simples

Duas perguntas simples decidem o que o seu backup realmente precisa fazer. Você não precisa das siglas para tocar uma empresa, mas entendê-las muda todas as conversas que você terá sobre recuperação.

  • RPO — quantos dados você pode perder? O Objetivo de Ponto de Recuperação é a idade da sua cópia boa mais recente. Se você faz backup uma vez por noite e o servidor falha às 16h, você perdeu um dia inteiro de trabalho: cada nota, pedido e e-mail desde o backup de ontem à noite. Se perder um dia doeria, os seus backups precisam rodar com mais frequência do que uma vez por dia.
  • RTO — em quanto tempo você precisa voltar? O Objetivo de Tempo de Recuperação é quanto a empresa consegue sobreviver com os sistemas parados antes de o custo ficar sério. Uma hora? Um dia inteiro? Três dias? A resposta honesta define tudo: onde os backups ficam, como são estruturados e quanto você deveria estar pagando pela recuperação.

A maioria dos donos nunca ouviu essas duas perguntas diretamente. Responda-as e você saberá na hora se o que está pagando corresponde ao que a sua empresa realmente tolera.

Como é um teste de restauração de verdade

Um teste de verdade não é dar uma olhada num painel. É trazer de propósito um backup de volta à vida, confirmar que os dados estão íntegros e utilizáveis, verificar que ele voltou dentro da sua janela de RTO e anotar o que aconteceu. Bem-feito, ele responde à única pergunta que importa: se fosse a emergência de verdade, estaríamos abertos a tempo?

Nós rodamos esses testes de restauração todo mês e documentamos cada um, para que a recuperação seja uma rotina ensaiada e sem graça, e não uma aposta de estreia durante a pior semana do seu ano. A documentação importa tanto quanto o próprio teste. Ela comprova que o backup funcionou numa data específica, mostra exatamente quanto tempo a recuperação levou e transforma o "acho que estamos cobertos" em "aqui está o registro que prova".

Um backup que o ransomware alcança já era

Aqui está a armadilha que pega as empresas que fizeram quase tudo certo. Se o seu backup fica num disco ou num servidor que a rede infectada consegue alcançar, o ransomware criptografa o backup junto com todo o resto. Os ataques modernos caçam os backups primeiro, de propósito, porque uma empresa que não consegue restaurar é uma empresa que paga.

Por isso um backup seguro precisa estar ao alcance para a recuperação, mas fora do alcance de um ataque: cópias guardadas fora do local e isoladas, e ao menos uma cópia que não possa ser alterada nem apagada mesmo com acesso total à sua rede. Se um único acesso comprometido consegue varrer ao mesmo tempo os seus sistemas em produção e os seus backups, você não tem um backup. Você tem duas cópias do mesmo problema.

Pontos-chave

  • Um tique verde prova que um trabalho rodou. Só uma restauração documentada prova que a sua empresa consegue mesmo reabrir.
  • Defina primeiro o seu RPO e o seu RTO — quantos dados você pode perder e em quanto tempo precisa voltar — e depois garanta que o que você paga corresponde a essas respostas.
  • Teste as restaurações todo mês e mantenha ao menos uma cópia do backup fora do local e intocável, para que um invasor que chegue à sua rede não chegue à sua recuperação.

Não tem certeza de que os seus backups sobreviveriam a uma emergência real? Jorge e a equipe rodam testes de restauração documentados todo mês para empresas de Austin, para que a recuperação seja comprovada, não presumida. Conheça os nossos serviços de Backup e recuperação de dados ou agende uma consulta gratuita.

Compartilhe este conteúdo: