Estratégia de backup: como elaborar 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 crescimento da receita em relação ao ano anterior nos serviços de BCDR, tornando essa área a segunda que mais cresce, 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 precisa ocorrer. Sem ela, o backup se torna uma série de decisões pontuais tomadas de forma independente, abrangendo alguns sistemas, mas não outros, atendendo a alguns requisitos de recuperação, mas não a todos, e proporcionando uma falsa sensação de segurança que só se revela quando se tenta a recuperação sob pressão.
Este guia aborda como elaborar uma estratégia de backup que seja abrangente, alinhada aos requisitos de recuperação dos negócios e resiliente contra as ameaças específicas que visam a infraestrutura de backup.
Elabore uma estratégia de backup adaptada à era do ransomware
O Datto BCDR oferece suporte à arquitetura 3-2-1-1-0, dispositivo de backup local, cópia imutável na nuvem e verificação automatizada, proporcionando aos MSPs e às equipes de TI um caminho de recuperação resiliente e resistente a ransomware.
Comece pelos requisitos de recuperação, e não pela tecnologia de backup
A maioria das organizações inicia as discussões sobre backup falando de tecnologia: qual software, qual equipamento, qual serviço em nuvem. O ponto de partida correto é a questão de negócios: 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 fora do ar 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 valor único para todo o ambiente.
Objetivo de Ponto de Recuperação (RPO), a quantidade máxima de perda de dados considerada aceitável, medida em tempo. Um RPO de 24 horas significa que a organização aceita a perda de até 24 horas de dados. Um RPO de uma hora significa que o backup deve ser realizado 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 por virtualização ou um dispositivo 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 selecionar ferramentas de backup com base no custo ou na familiaridade e, em seguida, descobrir, no momento de um incidente, que a recuperação leva muito mais tempo do que a empresa pode tolerar.
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: aplicativos essenciais ao negócio, 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 BCDR com continuidade na nuvem e CDP para bancos de dados de maior criticidade.
Nível 2, Importância para os negócios. Sistemas cuja falha prejudica significativamente as operações, mas não as interrompe imediatamente: servidores de e-mail, servidores de arquivos, aplicativos secundários de negócios. O Nível 2 pode aceitar RTOs um pouco mais longos (normalmente algumas horas) e RPOs (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 pode aceitar backup diário 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 mais valor.
Escolhendo a arquitetura de backup adequada
O dispositivo local + nuvem é a arquitetura mais resiliente para organizações com uma infraestrutura local significativa. O dispositivo oferece backup local para 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 todo o local e a ataques de ransomware direcionados ao armazenamento local. O Datto SIRIS é um exemplo 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 isolamento contra ransomware. A recuperação é 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 é o gerenciamento centralizado, que oferece 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 custo do backup. Os dispositivos de BCDR podem virtualizar os sistemas protegidos localmente em questão de minutos após a ocorrência de 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 manter 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 implantada. Se a retenção de backups de uma organização for de 30 dias e o invasor tiver estabelecido acesso 45 dias antes de implantar o ransomware, todas as cópias de backup podem estar dentro da janela de comprometimento, contendo potencialmente arquivos criptografados ou infectados. As organizações precisam estender a retenção bem além do tempo máximo de permanência esperado para garantir que pontos de restauração limpos estejam disponíveis.
O custo de armazenamento justifica um período de retenção mais curto. Um período de retenção mais longo significa 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 limitações à retenção de dados que devem ser equilibradas 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 primário.
Segurança do 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. Sistemas de backup acessíveis por meio de compartilhamentos de arquivos SMB padrão ou credenciais de domínio podem ser alcançados 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). Os consoles 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 as cópias de backup em busca de malware 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 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 (DR). 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 os aplicativos funcionam corretamente e compare o RTO real com a meta. Esse é o único teste que valida se a estratégia de backup oferece o desempenho de recuperação exigido pela empresa.
Verificação automatizada de backup. 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 captura 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 tornem descobertas no momento de um incidente, como escopo de backup incorreto, 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 padronizada 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 abordagens personalizadas para cada cliente de forma independente.
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 leva mais tempo 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.
Backup como um serviço comercializável. Muitos clientes de pequenas e médias empresas (PMEs) estão protegidos de forma inadequada 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 terminologia de RTO/RPO e o argumento do custo do tempo de inatividade, podem aumentar a receita com serviços de backup a partir dos relacionamentos já estabelecidos 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 conseguir 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 de primeira ordem: backups imutáveis e isolados, com credenciais separadas, são agora requisitos fundamentais, e não apenas medidas opcionais de fortalecimento da segurança.
- Os testes regulares de restauração sã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.
