Estratégia de backup: como criar uma que realmente proteja sua empresa

De acordo com o Relatório Kaseya sobre a Situação dos MSPs de 2026, 50% dos MSPs relataram um crescimento ano a ano na receita proveniente de serviços de BCDR, tornando essa área a segunda com maior crescimento, atrás apenas da cibersegurança. Baixe o relatório completo aqui.

Ter um software de backup instalado e ter uma estratégia de backup não são a mesma coisa. Essa diferença é extremamente importante quando algo dá errado.

Uma estratégia de backup é uma abordagem definida e documentada para proteger os dados, determinando o que deve ser copiado, com que frequência, onde as cópias são armazenadas, por quanto tempo são mantidas e com que rapidez a recuperação deve ocorrer. Sem ela, o backup se torna uma série de decisões pontuais tomadas de forma isolada, abrangendo alguns sistemas, mas não outros, atendendo a alguns requisitos de recuperação, mas não a todos, e gerando uma falsa sensação de segurança que só se revela quando se tenta a recuperação sob pressão.

Este guia explica como elaborar uma estratégia de backup abrangente, alinhada aos requisitos de recuperação dos negócios e resistente às ameaças específicas que visam a infraestrutura de backup.

Comece pelos requisitos de recuperação, não pela tecnologia de backup

A maioria das organizações inicia as discussões sobre backup falando de tecnologia: qual software, qual dispositivo, qual serviço em nuvem. O ponto de partida correto é a questão comercial: como deve ser a recuperação?

Dois indicadores definem os requisitos de recuperação:

Objetivo de Tempo de Recuperação (RTO), o tempo máximo que um sistema ou serviço pode ficar inoperante antes que o impacto se torne inaceitável. Um RTO de quatro horas significa que a equipe de TI tem quatro horas a partir do momento da falha para restaurar o serviço. Os RTOs devem ser definidos por sistema com base no impacto comercial do tempo de inatividade, e não como um único valor para todo o ambiente.

Objetivo de Ponto de Recuperação (RPO), a quantidade máxima de perda de dados aceitável, medida em tempo. Um RPO de 24 horas significa que a organização aceita perder até 24 horas de dados. Um RPO de uma hora significa que o backup deve ser feito pelo menos a cada hora para os sistemas abrangidos.

Uma vez definidos o RTO e o RPO para cada camada do sistema, a escolha da tecnologia de backup passa a ser uma questão de quais soluções podem atender a esses requisitos. Um sistema com um RTO de quatro horas precisa de capacidade de recuperação instantânea ou quase instantânea, backup baseado em imagem com recuperação de virtualização ou um dispositivo de BCDR capaz de inicializar o sistema protegido na nuvem em questão de minutos. Um sistema com um RTO de 24 horas pode utilizar backup convencional de arquivos com backups completos diários.

Essa sequência evita o erro comum de escolher ferramentas de backup com base no custo ou na familiaridade, para depois descobrir, no momento de um incidente, que a recuperação leva muito mais tempo do que a empresa pode suportar.

Classificação de dados e sistemas por prioridade de recuperação

Nem todos os sistemas exigem o mesmo investimento em velocidade, frequência e retenção de backup. A classificação dos sistemas por prioridade de recuperação permite que o investimento em backup seja direcionado de forma adequada:

Nível 1, Missão crítica. Sistemas cuja falha interrompe imediatamente as operações comerciais: principais aplicativos de negócios, bancos de dados, controladores de domínio, sistemas ERP e processamento de pagamentos. O Nível 1 exige os menores valores de RTO e RPO, normalmente inferiores a uma hora. Tecnologia: backup baseado em imagem com virtualização local, dispositivo de BCDR com continuidade na nuvem e CDP para bancos de dados de maior criticidade.

Nível 2, Importância operacional. Sistemas cuja falha prejudica significativamente as operações, mas não as interrompe imediatamente: servidores de e-mail, servidores de arquivos, aplicativos de negócios secundários. O Nível 2 pode aceitar RTOs (tempo de recuperação) ligeiramente mais longos (normalmente algumas horas) e RPOs (ponto de recuperação) (normalmente de algumas horas a um dia).

Nível 3, Padrão. Terminais, ambientes de desenvolvimento, aplicativos não críticos. O Nível 3 permite backups diários com tempos de recuperação de vários dias. Tecnologia: backup diário de arquivos/imagens, cópias exclusivamente na nuvem, retenção padrão.

Essa estrutura de níveis não se resume apenas à gestão de custos; trata-se de garantir que os sistemas mais críticos tenham a capacidade de recuperação de que a empresa realmente necessita e que o investimento em tecnologias de recuperação mais caras seja concentrado onde ele agrega maior valor.

Escolhendo a arquitetura de backup adequada

A combinação de dispositivo local + nuvem é a arquitetura mais resiliente para organizações com uma infraestrutura local significativa. O dispositivo oferece backup local para uma recuperação rápida em casos comuns de falha; a cópia na nuvem fornece o backup externo e isolado, capaz de resistir a eventos que afetam o local e a ataques de ransomware direcionados ao armazenamento local. O Datto SIRIS dessa arquitetura: um dispositivo Linux reforçado com capacidade de virtualização local para recuperação rápida no local e replicação automatizada na nuvem para proteção externa.

O backup com prioridade na nuvem é ideal para organizações com infraestrutura predominantemente na nuvem ou SaaS, ou para aquelas que não possuem data centers locais. Os backups são enviados diretamente para o armazenamento na nuvem, com o armazenamento de objetos imutáveis garantindo proteção contra ransomware. A recuperação pode ser feita de nuvem para nuvem ou de nuvem para o ambiente local.

O backup híbrido atende a organizações com múltiplos ambientes, que possuem cargas de trabalho tanto no local quanto na nuvem. Normalmente, são necessárias ferramentas diferentes para cada ambiente: uma solução baseada em appliance para o ambiente local, backup nativo da nuvem para a infraestrutura em nuvem e backup SaaS para aplicativos SaaS. O requisito fundamental é um gerenciamento centralizado que ofereça visibilidade de todos os ambientes de backup a partir de um único console.

A arquitetura voltada para BCDR prioriza a velocidade de recuperação em detrimento da eficiência de custos do backup. Os dispositivos de BCDR podem virtualizar os sistemas protegidos localmente em questão de minutos após uma falha, mantendo as operações comerciais enquanto a recuperação para o hardware primário ocorre em segundo plano. Essa arquitetura é adequada para sistemas de Nível 1 com requisitos de RTO inferiores a quatro horas.

Políticas de retenção: por quanto tempo guardar cada tipo de documento

A política de retenção é uma das decisões mais importantes do ponto de vista estratégico no que diz respeito ao backup e uma das menos cuidadosamente consideradas. Duas forças opostas determinam o prazo de retenção:

O tempo de permanência do ransomware justifica uma retenção mais longa. Os ataques modernos de ransomware geralmente envolvem semanas ou meses de reconhecimento antes que a carga destrutiva seja lançada. Se a retenção de backups de uma organização for de 30 dias e o invasor tiver obtido acesso 45 dias antes de lançar o ransomware, todas as cópias de backup podem estar dentro do período de comprometimento, contendo potencialmente arquivos criptografados ou infectados. As organizações precisam de uma retenção que se estenda bem além do tempo máximo de permanência esperado para garantir que haja pontos de restauração limpos disponíveis.

O custo de armazenamento justifica um período de retenção mais curto. Um período de retenção mais longo implica um maior consumo de espaço de armazenamento.

A resolução consiste em uma política de retenção em níveis:

• Backups recentes (últimos 7 a 30 dias): intervalos frequentes, alta granularidade, acesso rápido
• Backups mensais: mantidos por 12 meses
• Backups anuais: mantidos por 3 a 7 anos (de acordo com os requisitos de conformidade)

As obrigações de conformidade também determinam os prazos mínimos de retenção. A HIPAA exige o backup dos dados abrangidos com um período de retenção adequado. O GDPR impõe limites à retenção de dados que devem ser equilibrados com os requisitos de retenção dos backups. Regulamentações específicas de cada setor (serviços financeiros, saúde, governo) frequentemente especificam prazos mínimos de retenção para fins de auditoria e retenção legal.

Cópias de backup imutáveis, que não podem ser modificadas nem excluídas durante o período de retenção definido, oferecem proteção tanto contra ransomware quanto contra exclusões acidentais, garantindo que os pontos de restauração históricos permaneçam disponíveis independentemente do que ocorra no ambiente principal.

Segurança de backup: protegendo o caminho de recuperação

A infraestrutura de backup tornou-se um dos principais alvos de ataques. Mais de 90% dos ataques de ransomware têm como alvo os backups; os invasores sabem que uma organização com backups intactos não precisará pagar resgate, portanto, eliminar as opções de recuperação faz parte da estratégia de ataque.

A segurança do backup requer:

Isolamento da rede de produção. Os sistemas de backup acessíveis por meio de compartilhamentos de arquivos SMB padrão ou credenciais de domínio podem ser atingidos por ransomware que tenha comprometido contas do domínio. A infraestrutura de backup deve utilizar credenciais distintas, segmentos de rede separados e, idealmente, armazenamento baseado em dispositivos ou exclusivamente na nuvem, que não apresente uma superfície de ataque do sistema de arquivos padrão do Windows.

Armazenamento imutável. O armazenamento de objetos com configuração WORM (Write Once Read Many) ou imutabilidade fornecida pelo fornecedor impede que as cópias de backup sejam modificadas ou excluídas, mesmo por ransomware com credenciais administrativas.

Criptografia. Os dados de backup devem ser criptografados tanto em trânsito quanto em repouso. Isso protege contra o roubo de dados de repositórios de backup, que se tornou cada vez mais um objetivo secundário de ataques, juntamente com a instalação de ransomware.

Controles de acesso e autenticação multifatorial (MFA). As consolas de gerenciamento de backups devem exigir autenticação multifatorial (MFA) e acesso baseado em funções. As credenciais para gerenciar backups devem ser distintas das credenciais utilizadas no ambiente de produção.

Verificação contra ransomware. As plataformas de backup que verificam se há malware nas cópias de backup antes de finalizá-las garantem que os pontos de restauração estejam livres de malware, evitando que a recuperação a partir do backup restaure o ransomware junto com os dados.

Testes e verificação: a parte mais importante que ninguém faz

Um backup que nunca foi testado é uma mera suposição. O hardware pode falhar. As configurações mudam. As atualizações de software podem comprometer a compatibilidade. A tarefa de backup que foi concluída com sucesso no mês passado pode não produzir uma imagem restaurável hoje.

Os testes de backup devem incluir:

Testes regulares de restauração. Restaure arquivos específicos, bancos de dados ou sistemas inteiros a partir do backup em uma programação definida: mensalmente para sistemas críticos e trimestralmente para os demais. Documente o que foi restaurado, de qual backup e quanto tempo levou.

Testes completos de recuperação de desastres. Pelo menos uma vez por ano, simule um cenário de falha total: restaure o ambiente de produção a partir do backup em um ambiente de teste, verifique se as aplicações funcionam corretamente e compare o RTO real com a meta. Este é o único teste que confirma se a estratégia de backup oferece o desempenho de recuperação exigido pela empresa.

Verificação automatizada de backups. As plataformas modernas de backup podem testar automaticamente a capacidade de recuperação após cada tarefa de backup, inicializando uma instância virtualizada do sistema copiado e verificando se ela é inicializada corretamente. Isso proporciona confiança contínua sem a sobrecarga de testes manuais. O recurso de verificação por captura de tela da Datto faz exatamente isso, capturando automaticamente uma imagem de tela de cada sistema copiado após o backup para verificar se ele é inicializado sem problemas.

A prática de realizar testes regulares frequentemente revela problemas antes que eles se transformem em descobertas durante incidentes, como escopo de backup inadequado, lacunas na retenção ou tecnologia incapaz de cumprir o RTO exigido.

Estratégia de backup para MSPs

Para os MSPs, a estratégia de backup situa-se na interseção entre a proteção do cliente e a prestação de serviços:

Base padrão com personalização por cliente. Defina uma arquitetura de backup e uma política de retenção padrão que se apliquem a todos os clientes por padrão, com variações documentadas por cliente nos casos em que os requisitos específicos de cada um diferirem. Essa abordagem é mais escalável e mais auditável do que criar soluções personalizadas para cada cliente individualmente.

Documentação de RTO/RPO por cliente. Os contratos com os clientes devem documentar os objetivos de recuperação com os quais o MSP se compromete, e a configuração do backup deve ser verificada para garantir o cumprimento desses compromissos. Um RTO não documentado gera responsabilidade civil quando a recuperação demora mais do que o cliente esperava.

Monitoramento e geração de relatórios de backup. O status das tarefas de backup em todos os ambientes dos clientes deve ser monitorado, com alertas automáticos em caso de falhas. Os relatórios de backup destinados aos clientes, que demonstram a cobertura de proteção e as taxas de sucesso das tarefas, são tanto uma ferramenta de prestação de serviços quanto de retenção.

O backup como um serviço comercializável. Muitos clientes de pequenas e médias empresas (PMEs) não estão devidamente protegidos e, ou não sabem disso, ou não compreendem o que significa uma proteção abrangente. Os MSPs que conseguirem explicar a diferença entre o que um cliente possui e o que ele precisa, em termos comerciais, utilizando a linguagem de RTO/RPO e o argumento do custo do tempo de inatividade, podem aumentar a receita proveniente do backup a partir das relações já estabelecidas com os clientes.

Descubra por que os MSPs precisam de resiliência cibernética agora

Pontos principais

• Comece pelos requisitos de recuperação (RTO e RPO por camada do sistema), e não pela tecnologia; a solução de backup adequada é aquela que consegue atender a esses requisitos a um custo aceitável.
  
• A classificação dos sistemas por prioridade de recuperação concentra o investimento nos sistemas em que uma recuperação rápida é realmente necessária, em vez de aplicar a mesma abordagem a todos os casos.
  
• O ransomware transformou a segurança dos backups em uma preocupação prioritária: backups imutáveis e isolados, com credenciais separadas, são agora requisitos fundamentais, e não apenas medidas opcionais de fortalecimento da segurança.
  
• A realização regular de testes de restauração é o elemento mais negligenciado e mais crítico de qualquer estratégia de backup; backups não testados geram uma falsa sensação de segurança que falha no pior momento possível.