Backup local ou em nuvem: qual protege sua empresa?

Quase toda empresa tem algum backup. Um disco externo que alguém leva para casa às sextas, um NAS no rack do escritório, uma rotina do provedor de nuvem que "deve estar ligada". A pergunta só fica séria no dia em que o servidor não liga, um funcionário apaga a pasta errada ou a tela amanhece com um pedido de resgate.

Nesse dia, a dúvida "backup local ou em nuvem?" se revela mal formulada. O que importa é outra coisa: quanto tempo a empresa aguenta parada, quanto trabalho ela aceita perder e de qual desastre ela está se protegendo. Cada tipo de backup responde bem a uma parte dessas perguntas e mal a outra.

Este texto compara os dois caminhos, mostra onde cada um falha e como combiná-los.

Resposta curta: decida pelo tempo aceitável para voltar (RTO), pela perda de dados aceitável (RPO) e pelo cenário de desastre. Backup local restaura rápido, mas cai junto com o prédio, com o roubo do equipamento ou com o ransomware que alcança a rede. Backup em nuvem sobrevive ao desastre físico, mas depende do link e de restauração testada. Para a maioria das empresas, a resposta é usar os dois pela regra 3-2-1, com pelo menos uma cópia imutável.

Backup local: NAS, disco externo e servidor de backup

Backup local é a cópia que fica fisicamente perto do dado original: no mesmo prédio, muitas vezes na mesma rede.

Disco externo. O ponto de partida de muita empresa pequena. É simples e barato de começar, mas depende de alguém lembrar de conectar, trocar e guardar. Quando o disco fica sempre ligado ao computador, ele é atingido pelo mesmo problema que atingir a máquina.

NAS (armazenamento em rede). Um equipamento dedicado, com vários discos e algum nível de redundância entre eles, que recebe cópias automáticas de servidores e estações. Resolve a parte da disciplina, porque a rotina roda sozinha. Mas redundância de disco não é backup: ela protege contra a falha de um disco, não contra exclusão, corrupção ou criptografia dos arquivos.

Servidor de backup com software dedicado. Em ambientes maiores, um servidor roda um software de backup que copia máquinas virtuais, bancos de dados e arquivos, guarda versões e gerencia a retenção. É o caminho mais robusto, e o que exige mais administração.

O ponto forte do backup local é a velocidade de restauração. Os dados estão a poucos metros, na rede interna, e voltar um banco de dados inteiro costuma ser questão de tempo de cópia, não de banda de internet.

O ponto fraco é o destino compartilhado. Incêndio, alagamento, furto, pico de energia ou um ataque que se espalha pela rede atingem o servidor e o backup ao mesmo tempo.

Backup em nuvem: armazenamento de objetos, snapshots e serviços de backup

"Backup em nuvem" também cobre coisas bem diferentes, e vale separar.

Armazenamento de objetos. Serviços de armazenamento dos grandes provedores, pensados para guardar arquivos em grande volume com alta durabilidade. Costumam oferecer classes de armazenamento mais baratas para dado pouco acessado e mecanismos de retenção e bloqueio contra alteração. É um destino excelente para cópias externas, inclusive do backup local.

Snapshots. Fotografias do disco de uma máquina virtual ou de um banco gerenciado em um momento. São rápidos de criar e de restaurar, mas atenção: muitas vezes ficam na mesma conta e na mesma região do recurso original. Se a conta for comprometida ou alguém apagar o ambiente, os snapshots podem ir junto. Snapshot é ótimo como primeira linha, não como única cópia.

Serviços de backup gerenciado. Produtos que orquestram cópias de servidores, bancos, estações e até de aplicativos SaaS, com agendamento, retenção e console centralizado. Há opções dos próprios provedores de nuvem e de fornecedores especializados. Os recursos variam bastante e mudam com o tempo, então confirme com o fornecedor o que está incluído, como funciona a restauração e onde os dados ficam guardados.

O ponto forte da nuvem é sobreviver ao desastre físico. O escritório pode pegar fogo e a cópia continua lá.

Os pontos fracos são dois. Primeiro, o link: enviar o primeiro backup completo e, principalmente, trazer de volta muitos dados de uma vez depende da internet da empresa. Restaurar um servidor inteiro pela nuvem pode levar muito mais tempo do que parece na planilha. Segundo, a falsa sensação de segurança: dado em nuvem não significa dado com backup. Um sistema SaaS ou um servidor na nuvem sem política de cópia pode perder dados do mesmo jeito. Se a empresa está migrando o servidor local para a nuvem, a política de backup precisa ser redesenhada junto, não presumida.

RTO e RPO: as duas perguntas que definem a escolha

Antes de escolher equipamento ou serviço, responda duas perguntas para cada sistema importante.

RTO (Recovery Time Objective): quanto tempo a empresa aguenta sem esse sistema? Se o faturamento parar, quantas horas até virar prejuízo sério? Se for o arquivo de projetos antigos, talvez dias sejam aceitáveis.

RPO (Recovery Point Objective): quanto trabalho a empresa aceita perder? Backup noturno com queda no fim da tarde significa perder o dia inteiro de lançamentos.

Essas respostas mudam a escolha:

• RTO curto pede cópia perto. Restaurar rápido quase sempre significa ter uma cópia local ou um ambiente de nuvem pronto para subir, não baixar tudo pela internet.
• RPO curto pede cópia frequente. Backup noturno não atende quem não aceita perder mais que poucos minutos. Aí entram cópias incrementais frequentes, replicação ou backup contínuo de banco.
• Sistemas diferentes merecem metas diferentes. Tratar tudo como crítico encarece e complica. Tratar tudo como "backup semanal está bom" é arriscar o que importa.

Se a empresa precisa que o sistema praticamente não pare, backup não basta: o assunto passa a ser alta disponibilidade, com redundância e failover. Backup é para voltar depois do problema; alta disponibilidade é para o problema nem ser percebido. As duas coisas se complementam e entram num plano de recuperação de desastres que define quem faz o quê quando algo dá errado.

Ransomware e cópia imutável: o que mudou na regra do jogo

O ransomware mudou o cenário, porque o atacante não quer só criptografar os arquivos: ele procura os backups primeiro.

Se o NAS está montado como unidade de rede no servidor, ele é criptografado junto. Se a ferramenta de backup usa a mesma senha de administrador do domínio, o atacante entra nela e apaga as cópias. Se o backup em nuvem é acessado com credenciais guardadas no servidor comprometido, ele também pode ser alcançado.

Por isso a pergunta deixou de ser "tenho backup?" e passou a ser "tenho uma cópia que o atacante não consegue apagar nem alterar?". Há dois jeitos de responder:

• Cópia imutável. Armazenamento configurado para que os dados não possam ser alterados nem apagados durante um período de retenção, nem pelo administrador. Vários serviços de armazenamento de objetos e produtos de backup oferecem esse tipo de bloqueio; confirme com o fornecedor como ele funciona e quem pode desativá-lo.
• Cópia isolada (offline ou air gap). Mídia ou ambiente desconectado da rede de produção, como discos em rodízio guardados fora ou um destino acessível só por credenciais separadas e com acesso restrito.

Junto com isso vêm cuidados de acesso: credenciais do backup diferentes das do domínio, autenticação em dois fatores no console, contas com o mínimo de permissão e alerta quando alguém tenta apagar cópias. O tema completo está em como proteger a empresa de ransomware, mas o resumo é direto: sem cópia imutável ou isolada, o backup pode ser a primeira coisa a desaparecer.

Teste de restauração: o backup que nunca foi restaurado não existe

A rotina de backup reporta "concluído com sucesso" todos os dias. Isso diz que um arquivo foi gravado. Não diz que dá para voltar o sistema a partir dele.

Os problemas típicos só aparecem na hora de restaurar: o backup do banco foi feito com o banco em uso e está inconsistente; faltou incluir uma pasta de configuração; a senha de criptografia do backup estava só na cabeça de quem saiu da empresa; a restauração funciona, mas leva o triplo do RTO combinado.

Um teste de restauração honesto tem algumas características:

• Restaura em ambiente separado, sem tocar na produção.
• Sobe o sistema e verifica os dados, não só confere se os arquivos existem. Alguém da área abre o sistema e confirma que os lançamentos recentes estão lá.
• Mede o tempo, do início da restauração até o sistema utilizável, e compara com o RTO.
• Tem periodicidade e registro: data, quem fez, o que foi restaurado, quanto levou e o que deu errado.
• Testa a cópia externa também, inclusive o cenário de trazer os dados da nuvem pelo link real da empresa.

Melhor descobrir o problema num dia calmo.

Backup e LGPD: a cópia também é dado pessoal

Um ponto que costuma ficar de fora da conversa: o backup carrega os mesmos dados pessoais do sistema original, como cadastros de clientes, folha de pagamento e prontuários. A LGPD exige medidas de segurança adequadas para proteger esses dados, e isso vale para a cópia tanto quanto para a produção. Na prática, alguns cuidados resolvem a maior parte do problema:

• Criptografia do backup, em trânsito e armazenado, com a chave guardada em lugar separado e conhecida por mais de uma pessoa.
• Acesso restrito ao console e às mídias, com registro de quem restaurou o quê. Um disco externo sem criptografia esquecido no carro é um incidente de segurança.
• Retenção definida, porque guardar versões para sempre aumenta custo e exposição. A política de backup precisa conversar com a de retenção e descarte de dados pessoais.
• Localização conhecida: saber em qual região e com qual fornecedor a cópia em nuvem está guardada. O tema de dados na nuvem no Brasil e LGPD detalha quando isso importa.

Tabela comparativa: backup local x nuvem x híbrido

Quando escolher cada um (e por que a resposta costuma ser os dois)

A regra 3-2-1 organiza a decisão: três cópias dos dados, em dois tipos de mídia ou armazenamento diferentes, com uma delas fora do local. Uma extensão bastante difundida, às vezes chamada de 3-2-1-1-0, acrescenta que pelo menos uma cópia deve ser imutável ou isolada e que as restaurações testadas não podem apresentar erros. Na prática, isso quase sempre significa local e nuvem juntos.

Sinais de que o backup local deve ser a primeira linha

• O RTO de algum sistema é curto e o volume de dados é grande, então baixar tudo pela internet não caberia no prazo.
• Há servidores ou bancos rodando dentro da empresa.
• Os pedidos de restauração mais frequentes são de arquivo apagado ou versão anterior de documento.
• O link de internet é limitado ou instável.

Sinais de que a nuvem deve ser a cópia principal ou suficiente

• Os sistemas já rodam em nuvem ou em SaaS, e não há servidor relevante no escritório.
• A empresa é pequena, sem estrutura para cuidar de equipamento e rodízio de mídia.
• O principal risco é físico: escritório compartilhado, área sujeita a alagamento, histórico de furto.
• Um serviço de backup gerenciado de mercado atende o que a empresa tem. Nesse caso, não há motivo para construir nada: configure bem, ative a imutabilidade, separe credenciais e teste.

Sinais de que o híbrido é obrigatório

• Existe pelo menos um sistema cuja parada para o faturamento, a produção ou o atendimento.
• A empresa guarda dados que ela é obrigada a manter por prazo legal.
• Um ataque de ransomware hoje deixaria a empresa sem cópia confiável.
• Ninguém sabe dizer quando foi o último teste de restauração.

Uma observação justa: para muitas empresas, a solução certa é inteiramente feita com produtos de mercado, sem uma linha de código próprio. Um NAS bem configurado, um software de backup consolidado e um destino em nuvem com bloqueio contra alteração resolvem a maior parte dos casos. O trabalho de engenharia está em definir RTO e RPO, desenhar a política, cuidar dos acessos e testar. Software sob medida só entra quando há algo específico, como um sistema próprio que precisa de exportação consistente do banco ou uma rotina de verificação automática de integridade que nenhuma ferramenta pronta cobre bem.

Perguntas frequentes

Com que frequência a empresa deve fazer backup?

Depende do RPO de cada sistema, ou seja, de quanto trabalho a empresa aceita perder. Para faturamento ou banco de dados com muitos lançamentos ao longo do dia, backup noturno costuma ser pouco, e entram cópias incrementais frequentes ou replicação. Para arquivos pouco alterados, uma cópia diária geralmente basta, desde que a restauração seja testada.

RAID ou redundância de disco substitui o backup?

Não. A redundância de disco, comum em NAS e servidores, protege apenas contra a falha física de um disco. Ela não protege contra exclusão acidental, corrupção de arquivos ou criptografia por ransomware, porque a alteração vale para todos os discos ao mesmo tempo. O backup guarda versões anteriores em outro lugar, e é isso que permite voltar.

Snapshot da nuvem é suficiente como backup?

Não como única cópia. O snapshot é rápido de criar e de restaurar, mas muitas vezes fica na mesma conta e na mesma região do recurso original. Se a conta for comprometida ou o ambiente for apagado, os snapshots podem ir junto. O ideal é usar o snapshot como primeira linha e manter outra cópia separada e imutável.

O que é backup imutável?

Backup imutável é a cópia gravada em um armazenamento configurado para que os dados não possam ser alterados nem apagados durante um período de retenção, nem pelo administrador. Ele existe para resistir ao ransomware, que procura e apaga os backups antes de criptografar a empresa. Confirme com o fornecedor como o bloqueio funciona e quem pode desativá-lo.

Como saber se o backup da empresa realmente funciona?

Só um teste de restauração mostra se o backup funciona. O aviso de "concluído com sucesso" indica apenas que um arquivo foi gravado. Um teste honesto restaura em ambiente separado, sobe o sistema, pede a alguém da área que confira os lançamentos recentes, mede o tempo em relação ao RTO e fica registrado com data e responsável.

Como a Pervian Tech ajuda a decidir e a desenhar a política de backup

Começamos por um diagnóstico inicial gratuito: levantamos quais sistemas existem, onde estão os dados, como o backup é feito hoje e quando foi a última restauração de verdade. A partir disso, definimos com a empresa RTO e RPO por sistema, em linguagem de negócio, não de TI.

Com essas metas, desenhamos a política: o que vai para cópia local, o que vai para a nuvem, qual cópia é imutável, quem tem acesso a quê, a retenção de cada tipo de dado e o roteiro de teste de restauração. Quando um produto de backup de mercado atende, é isso que recomendamos. Quando há sistemas próprios ou integrações que pedem automação específica, desenvolvemos essa parte sob medida dentro do trabalho de cloud e DevOps.

O investimento é definido sob consulta, depois do diagnóstico, porque depende do número de sistemas, do volume de dados e das metas de recuperação. Para outros temas de infraestrutura, veja os textos de cloud e infraestrutura. Se você não tem certeza de que conseguiria restaurar seus sistemas amanhã, fale com a gente.