Quem procura entender backup gerenciado por MSP: o que está incluído costuma estar no meio de uma comparação de propostas. Duas ou três fornecedores enviaram escopos diferentes, com nomes parecidos e preços distantes, e a pergunta que trava a decisão é simples: o que exatamente entra no contrato e o que fica de fora. A resposta raramente está no slide comercial — está na separação entre o que é proteção técnica e o que é operação contínua.
Essa distinção importa porque grande parte das surpresas em auditoria e em incidentes não vem de falha de software, e sim de escopo mal delimitado. Serviços de egress, retenção longa, cargas em SaaS legados e estações de trabalho são exemplos recorrentes de itens que o cliente presume cobertos e o fornecedor não inclui. Sem uma matriz clara de responsabilidades entre MSP, cliente e fabricante, a discussão só aparece quando já é tarde.
Este texto percorre o escopo típico de um serviço gerenciado de backup — ativos protegidos, retenção, frequência, testes de restauração e evidências de recuperabilidade — e mostra como auditar uma proposta antes de assinar, considerando também o impacto da LGPD e das exigências de retenção legal sobre o que precisa constar em contrato.
O que é backup gerenciado por MSP (e o que não é)
Backup gerenciado por MSP é um serviço contínuo em que um provedor terceirizado assume a responsabilidade operacional pela execução, monitoramento e recuperação das cópias de segurança de uma empresa. Diferente de um projeto pontual de implementação — em que o fornecedor configura o software, entrega o ambiente e sai —, o modelo gerenciado mantém um ciclo permanente de verificação, correção de falhas e validação de restauração. O contrato define metas de recuperação (RPO e RTO), janelas de execução e entregáveis periódicos, como relatórios de backup e evidências de teste.
O que não é backup gerenciado: não se trata de armazenamento avulso em nuvem, não é uma licença de software de backup comprada e operada internamente pelo time de TI, e não é um serviço de disaster recovery completo. Em um DRaaS, o provedor mantém um ambiente de contingência pronto para assumir a operação em caso de incidente — servidores, rede e aplicações. No backup gerenciado, o objeto do contrato é a cópia de dados e a capacidade de restaurá-la. A recuperação de um ambiente inteiro pode existir como objetivo de projeto, mas a operação contínua de failover pertence a outro escopo contratual.
Para empresas que operam ambientes híbridos — parte on-premise, parte em Azure —, a contratação de um MSP com gestão de ambiente híbrido on-premise e Azure permite unificar políticas de proteção em uma única camada de governança. Isso evita o cenário comum de dois regimes de backup desconectados: um para servidores locais, outro para workloads em nuvem, cada um com retenção e testes diferentes.
O que está incluído no serviço: escopo técnico
O escopo técnico descreve o que é protegido e como tecnicamente isso acontece. É a parte da proposta que mais varia entre fornecedores e a que mais gera surpresa desagradável quando um incidente acontece e se descobre que determinado servidor, banco ou aplicação não estava coberto. Separar esse escopo do operacional — tratado na próxima seção — é o primeiro filtro para comparar propostas de forma justa.
Agentes, workloads e ambientes protegidos
O contrato precisa listar nominalmente quais ativos entram na cobertura. Servidores físicos Windows e Linux, máquinas virtuais em VMware ou Hyper-V, bancos de dados SQL Server, Oracle ou PostgreSQL, aplicações SaaS com retenção própria e estações de trabalho críticas são categorias distintas, cada uma com agente ou método de captura específico. Um backup de máquina virtual inteira não garante consistência de banco de dados: para SQL Server, por exemplo, é necessário integração com VSS ou agente nativo que congele transações no momento da cópia.
Ambientes Microsoft 365 merecem atenção separada. Exchange Online, SharePoint, OneDrive e Teams não possuem backup nativo no sentido tradicional — a Microsoft garante disponibilidade e redundância, mas não retenção histórica recuperável contra exclusão acidental, ransomware ou saída de funcionário. O serviço gerenciado precisa declarar explicitamente se inclui proteção dessas cargas via API do Microsoft 365, qual a granularidade de restauração (mensagem individual, site, caixa postal inteira) e qual a retenção aplicada.
- Servidores físicos e virtuais: agente por máquina ou integração hypervisor
- Bancos de dados: consistência transacional via VSS ou agente nativo
- Microsoft 365: Exchange, SharePoint, OneDrive e Teams via API
- Azure: snapshots de VM, discos gerenciados e cofres de recuperação
- Estações críticas: laptops de diretores ou máquinas com dados locais sensíveis
Infraestrutura, storage e retenção
A infraestrutura de destino define onde as cópias residem e com qual nível de isolamento. O padrão recomendado é a regra 3-2-1: três cópias dos dados, em dois tipos de mídia diferentes, com uma cópia fora do site principal. No contexto gerenciado, isso costuma se traduzir em um repositório local para restaurações rápidas e uma cópia em nuvem (Azure Blob, S3 ou storage do próprio provedor) para sobrevivência a incidentes físicos no datacenter do cliente.
Retenção é um dos pontos mais sensíveis do contrato, especialmente para empresas sob a LGPD ou regulação setorial financeira. A lei brasileira não estipula prazo único de guarda — cada finalidade de tratamento define seu período. Um contrato de backup gerenciado precisa permitir políticas de retenção diferentes por classe de dado: logs de transação por 30 dias, bases contábeis por 5 anos, registros de consentimento pelo tempo da relação. Retenção única e genérica para todo o ambiente é sinal de escopo mal desenhado.
- Repositório local: restauração rápida para falhas de baixa severidade
- Cópia em nuvem: isolamento geográfico contra incidente físico no site
- Retenção por política: prazos distintos conforme classe de dado e norma aplicável
- Criptografia em trânsito e em repouso: chaves sob gestão definida em contrato
- Capacidade contratada: volume protegido versus volume real consumido
Frequência, janelas e cópias imutáveis
Frequência de backup não é sinônimo de qualidade de proteção. O que importa é o RPO — recovery point objective, ou quantos dados a empresa aceita perder. Um RPO de 1 hora exige backup incremental horário, não apenas diário. O contrato precisa expressar RPO por workload: banco de dados transacional de um ambiente Pix, por exemplo, demanda RPO muito menor que um servidor de arquivos departamental.
Cópias imutáveis são a defesa mais efetiva contra ransomware que tenta criptografar ou apagar os próprios backups. A imutabilidade — recurso presente em soluções como Acronis e em storages compatíveis com object lock — impede que qualquer credencial, inclusive de administrador, altere ou exclua a cópia antes do prazo definido. O serviço gerenciado deve declarar se a imutabilidade está ativa, em quais repositórios e por quanto tempo, pois ela também impede exclusão antecipada por solicitação do cliente — uma consequência operacional que precisa estar clara.
O que está incluído no serviço: escopo operacional
O escopo operacional responde a quem faz o quê, com que frequência e com qual evidência. É aqui que propostas baratas se revelam incompletas: o software pode estar instalado e configurado, mas ninguém olha se o backup rodou, ninguém testa se a restauração funciona e ninguém responde quando o alerta dispara às 3h da manhã. Um backup sem operação é uma promessa, não uma proteção.
Monitoramento, alertas e tratamento de falhas
O serviço gerenciado precisa incluir monitoramento ativo de cada job de backup, com alerta automático em caso de falha, atraso ou ausência de execução. O MSP deve ter um processo definido de tratamento: primeira tentativa de reexecução automática, diagnóstico da causa, abertura de chamado e comunicação ao cliente quando a falha persistir. O simples envio de um e-mail diário com o resultado dos jobs não é monitoramento gerenciado — é relatório automático.
O tratamento de falhas inclui ainda a correção de inconsistências silenciosas: backups que terminam com warning, snapshots que não consolidam, repositórios com espaço insuficiente, jobs que passam a demorar mais que a janela. Esse trabalho contínuo de higiene é o que diferencia um serviço gerenciado de um software licenciado. O conceito se conecta diretamente ao monitoramento proativo de TI, que antecipa degradação antes que ela vire incidente.
- Verificação diária de todos os jobs, com alerta imediato em falha
- Reexecução automática e diagnóstico de causa raiz
- Tratamento de warnings e degradação de performance
- Gestão de capacidade dos repositórios antes do esgotamento
- Comunicação proativa ao cliente em falhas recorrentes
Testes de restauração e evidências de recuperabilidade
Backup que nunca foi restaurado é backup que não se sabe se funciona. O contrato gerenciado precisa incluir testes periódicos de restauração — mensais, trimestrais ou conforme criticidade — com escopo definido: restauração de arquivo individual, de banco de dados, de máquina virtual completa. Cada teste deve gerar um relatório de evidência com data, ativo testado, tempo decorrido e resultado.
Esse relatório é o entregável mais negligenciado do mercado e o mais valioso para auditoria. Em um ambiente regulado, a evidência de recuperabilidade é o documento que demonstra ao comitê de riscos, ao auditor externo ou ao regulador que a estratégia de continuidade não existe apenas no papel. Sem esse artefato, a empresa não consegue comprovar que testa seus backups — e, em incidente real, descobre a falha no pior momento possível.
Suporte, SLA e matriz de responsabilidade (RACI)
O SLA do backup gerenciado precisa ir além do tempo de resposta a chamados. Ele deve cobrir: disponibilidade do serviço de backup, prazo para início de restauração após solicitação, prazo para conclusão de restaurações padrão e janela de atendimento (8x5, 24x7, com ou sem plantão). O RTO — recovery time objective — é a meta de tempo para restaurar o dado após a autorização, e precisa estar expresso por criticidade de workload.
A matriz RACI distribui responsabilidades entre quatro papéis: MSP (quem opera o backup), cliente (quem autoriza restaurações, fornece acesso e valida dados), fabricante de software (quem corrige bugs e fornece suporte de produto) e, quando aplicável, provedor de nuvem (quem garante disponibilidade do storage). Exemplo típico de lacuna: o MSP opera o backup, mas a licença do software está em nome do cliente — se o fabricante exige um chamado de suporte, quem abre? O contrato precisa responder. Para aprofundar os parâmetros de acordo de nível de serviço, vale consultar o que cobrar no SLA de um contrato de MSP.
- R: quem executa a ação (MSP executa o backup, cliente autoriza a restauração)
- C: quem é consultado antes da decisão (compliance valida restauração de dado sensível)
- I: quem é informado do resultado (diretoria recebe relatório mensal)
- Papel do fabricante: bugs, patches e limites técnicos do software
- Papel do provedor de nuvem: disponibilidade e durabilidade do storage
O que costuma ficar de fora do contrato
Tão importante quanto saber o que está incluído é identificar o que o contrato padrão não cobre — e que muitas empresas assumem estar coberto. A omissão mais comum é o egress de dados: a taxa cobrada pelo provedor de nuvem para transferir dados para fora do storage quando o cliente decide trocar de fornecedor ou restaurar grandes volumes.
Outros itens frequentemente fora do escopo padrão:
- Retenção de longo prazo (acima de 90 dias ou arquivamento de anos)
- Backup de SaaS legados e sistemas não listados na proposta
- Estações de trabalho da massa de colaboradores (apenas máquinas críticas)
- Restauração de ambiente completo em site alternativo (isso é DR, não backup)
- Recuperação de dados de sistemas descontinuados ou fora do inventário contratado
- Backup de ambientes de desenvolvimento, homologação e sandbox
- Atendimento a solicitações de restauração fora da janela contratada
Dados em SaaS legados merecem atenção especial. Sistemas antigos de ERP, CRM on-premise legado ou aplicações customizadas que não estão no inventário do contrato simplesmente não geram backup — e a descoberta só acontece quando alguém precisa restaurar. O inventário de ativos protegidos é um anexo vivo do contrato: cada servidor novo, cada banco criado, cada tenant adicionado precisa passar por um processo formal de inclusão na cobertura.
Backup gerenciado, BaaS e DRaaS: onde termina um e começa o outro
Os três termos se confundem nas propostas comerciais, mas representam escopos contratuais distintos. Backup gerenciado é o serviço operacional sobre uma solução de backup — o MSP configura, opera, monitora e testa as cópias. BaaS (Backup as a Service) é o modelo de consumo em que a infraestrutura de backup e o storage são fornecidos como serviço, geralmente com cobrança por volume protegido ou por workload. DRaaS (Disaster Recovery as a Service) é a manutenção de um ambiente de contingência pronto para assumir a operação em caso de desastre.
Na prática, um contrato de backup gerenciado pode usar BaaS como plataforma — o MSP opera um BaaS de terceiro ou próprio. Mas BaaS puro, sem a camada de gestão, é apenas infraestrutura: alguém ainda precisa configurar políticas, validar restaurações e responder a falhas. Já o DRaaS responde a uma pergunta que o backup não responde: em quanto tempo a empresa volta a operar, e não apenas em quanto tempo o dado é restaurado. São camadas complementares, não concorrentes.
- Backup gerenciado: operação contínua da solução de backup
- BaaS: infraestrutura e storage de backup como serviço
- DRaaS: ambiente de contingência para continuidade operacional
- RPO pertence ao backup; RTO de ambiente pertence ao DR
- Um contrato pode combinar os três, com escopos e SLAs separados
Para ambientes financeiros e de pagamentos instantâneos, a fronteira entre backup e DR é crítica. Um incidente em um sistema que processa transações Pix exige retomada em minutos — não apenas restauração de dados em horas. O backup gerenciado garante que os dados existam e possam ser recuperados; o DRaaS garante que haja um ambiente para recebê-los. Contratar um sem dimensionar o outro cria uma proteção incompleta.
Como ler a proposta do MSP: itens que precisam estar por escrito
Uma proposta de backup gerenciado que cabe em duas páginas provavelmente omite mais do que esclarece. Os itens abaixo precisam estar explicitamente escritos — não em conversa, não em e-mail, não em "padrão de mercado":
- Inventário nominal dos ativos protegidos, com versão e criticidade
- RPO e RTO por workload ou classe de serviço
- Retenção por política, com prazos e regra de expurgo
- Localização física e jurídica do storage (país, região, provedor)
- Imutabilidade: ativa, em quais repositórios, por quanto tempo
- Criptografia: algoritmo, gestão de chaves, quem detém acesso
- Frequência e escopo dos testes de restauração, com relatório de evidência
- SLA de restauração: prazo para início, prazo para conclusão, janela de atendimento
- Política de egress e custos de saída de dados
- Processo de inclusão e exclusão de ativos no escopo
- Matriz RACI com papéis de MSP, cliente, fabricante e provedor de nuvem
- Cláusulas de rescisão: devolução de dados, prazo, formato e custo
A cláusula de rescisão é um capítulo à parte. Quando o contrato termina, como os dados são devolvidos? Em que formato? Em quanto tempo? Quem paga o egress? Sem isso definido, a empresa fica refém do fornecedor no momento mais delicado da relação. Um MSP sério trata a saída do cliente com o mesmo profissionalismo da entrada — e coloca isso no contrato desde o primeiro dia.
A LGPD adiciona uma camada obrigatória a essa leitura. O MSP é operador dos dados pessoais contidos nos backups; o cliente é o controlador. O contrato precisa prever obrigações do operador: confidencialidade, finalidade limitada à prestação do serviço, cooperação em incidentes de segurança e eliminação segura dos dados ao fim do contrato. A ausência dessa cláusula transfere risco jurídico para o cliente sem que ele perceba. Para ambientes com dados sensíveis, a certificação ISO 27001 do MSP é um atalho de due diligence que reduz o esforço de auditoria do fornecedor.
Perguntas para fazer ao MSP antes de assinar
As perguntas abaixo funcionam como um roteiro de due diligence técnica. Se o vendedor não souber responder na hora, peça que volte com a resposta por escrito — a incapacidade de responder já é uma resposta.
- Qual foi a última vez que vocês restauraram um backup de um cliente em produção?
- O teste de restauração cobre banco de dados com consistência transacional ou apenas arquivos?
- Quem detém as chaves de criptografia do backup — o MSP, o cliente ou o provedor de nuvem?
- Se o storage em nuvem ficar indisponível, existe cópia em outro provedor ou região?
- Qual o custo total de egress se eu precisar baixar todos os meus dados amanhã?
- Como vocês comprovam que o backup de Microsoft 365 está funcionando?
- Em caso de falha recorrente no backup, qual o processo de escalonamento interno?
- Se eu rescindir o contrato, em quanto tempo e em que formato recebo meus dados?
- O contrato cobre backup de ambientes que eu criar depois da assinatura?
- Qual o RTO realista para restaurar um servidor de 2 TB em um incidente de ransomware?
A pergunta sobre ransomware é a mais reveladora. Um incidente real de ransomware não é uma restauração pontual: é um processo de contenção, investigação, limpeza e restauração em massa. O MSP precisa descrever como o backup gerenciado se integra à resposta a incidentes — não prometendo eliminação total do risco, mas demonstrando que as cópias imutáveis, o isolamento do repositório e os testes periódicos reduzem materialmente o impacto. A conexão com um SOC para monitoramento de segurança complementa a estratégia: backup protege contra perda de dados, mas não substitui detecção de intrusão.
Modelos de cobrança: por usuário, por workload ou por volume protegido
Existem três modelos predominantes de precificação, cada um com distorções próprias. Por usuário é comum em propostas que empacotam backup de Microsoft 365 e endpoints: paga-se um valor mensal por colaborador coberto. O risco é pagar por usuários que não geram dados relevantes e subdimensionar servidores, que concentram o volume real.
Por workload precifica por unidade protegida: cada servidor, cada banco de dados, cada tenant Microsoft 365, cada máquina virtual. É o modelo mais previsível para ambientes estáveis, mas exige disciplina de inventário — cada workload novo adicionado fora do contrato gera cobrança extra ou, pior, fica desprotegido. Por volume protegido precifica por terabyte efetivamente armazenado após deduplicação e compressão. É o modelo mais alinhado ao custo real do provedor, porém o menos previsível para o cliente, pois o crescimento de dados altera a fatura mensal.
- Por usuário: previsível, indicado para Microsoft 365 e endpoints
- Por workload: estável, indicado para servidores e bancos de dados
- Por volume: alinhado ao custo real, exige governança de crescimento
- Modelos híbridos: combinam workload para servidores e volume para nuvem
- Taxas adicionais: egress, retenção estendida, restauração prioritária
A escolha do modelo deve considerar a dinâmica de crescimento da empresa. Um ambiente que dobra de dados a cada 18 meses — comum em setores com telemetria, logs e transações digitais — pode tornar o modelo por volume imprevisível. Já uma empresa com quadro de funcionários estável e poucos servidores pode se beneficiar da simplicidade do modelo por usuário. O contrato ideal explicita o modelo, a unidade de medida, o gatilho de reajuste e o processo de revisão periódica do volume contratado.
A decisão final sobre backup gerenciado por MSP não é técnica — é de governança. O que está em jogo é a capacidade da empresa de comprovar, em qualquer momento, que seus dados críticos existem em cópia íntegra, testada e recuperável dentro de um prazo conhecido. Um contrato bem desenhado transforma essa capacidade em evidência documental. Um contrato mal desenhado transforma a confiança no fornecedor em aposta. A diferença está nos detalhes que este artigo mapeou: inventário nominal, RPO e RTO por workload, imutabilidade, testes com relatório, matriz RACI, cláusula de egress e processo de rescisão. Quem domina esses itens não compra promessa — compra proteção operacional verificável.
