Existe uma crença circulando nas empresas que migraram para a nuvem: a de que, junto dos servidores, foi embora também a responsabilidade de proteger a informação. Se o e-mail vive no Microsoft 365 e os arquivos no Google Workspace, alguém muito maior e mais competente estaria cuidando de tudo. A realidade dos incidentes desmonta essa premissa: um levantamento global da Veeam apontou que 74% das empresas já sofreram perda de dados em ambientes SaaS, e essa confusão figura entre os pontos cegos mais caros da TI corporativa.

A regra do jogo, aliás, está escrita nos próprios contratos. O termo de serviço da Microsoft afirma que todos os serviços online estão sujeitos a interrupções, que a empresa não se responsabiliza por perdas decorrentes delas e recomenda, com todas as letras, que o cliente faça backup regular do conteúdo usando aplicativos e serviços de terceiros. Em outras palavras, o backup SaaS não é um excesso de zelo de quem desconfia da nuvem: é a orientação formal de quem a opera, registrada em contrato e ignorada na prática pela maior parte dos clientes.

O que o modelo de responsabilidade compartilhada realmente diz

O modelo de responsabilidade compartilhada estabelece uma divisão simples: o provedor responde pela infraestrutura e pela disponibilidade do serviço, e o cliente responde pelos próprios dados. A Microsoft garante que datacenters, rede e aplicações estejam de pé, com redundância geográfica e mecanismos de tolerância a falhas que nenhuma empresa reproduziria sozinha. O que ela não garante é a existência de uma cópia recuperável da planilha que um colaborador apagou, da caixa de correio de um funcionário desligado ou dos arquivos cifrados por um ransomware que se propagou pela sincronização.

A distinção parece sutil, mas separa dois problemas de natureza diferente. Disponibilidade trata de manter o serviço acessível agora; proteção de dados trata de conseguir voltar no tempo. A replicação que o provedor faz entre datacenters serve ao primeiro objetivo e trabalha contra o segundo: por desenho, ela copia tudo imediatamente, inclusive a exclusão indevida e o arquivo corrompido. Se o dado errado se espalha com a mesma eficiência do dado certo, redundância não é backup.

Há ainda a camada regulatória. A LGPD exige que a empresa garanta a integridade e a disponibilidade dos dados pessoais que trata, e auditorias e disputas judiciais cobram a capacidade de recuperar informações de períodos específicos. Nenhuma dessas obrigações se cumpre com os recursos nativos de retenção, e a responsabilidade perante o titular do dado e o regulador permanece integralmente com a empresa contratante, não com o provedor da plataforma.

Isso não se limita ao ecossistema da Microsoft. O Google Workspace adota divisão equivalente de responsabilidades, e o mesmo vale para plataformas SaaS de CRM, ERP e atendimento que concentram dados igualmente críticos. Na medida em que a empresa distribui informação estratégica por dezenas de serviços contratados, a superfície de perda potencial cresce na mesma proporção, e o backup SaaS deixa de ser um item da lista do Microsoft 365 para virar uma disciplina transversal de proteção de dados, com inventário próprio de quais plataformas guardam o quê e qual o impacto de perder cada uma delas.

Por que a retenção nativa não substitui o backup SaaS

A retenção nativa não substitui o backup SaaS porque foi desenhada para conveniência de curto prazo, não para recuperação de desastres. No Microsoft 365, um item apagado percorre lixeiras com prazos que somam cerca de 93 dias; depois disso, a exclusão é definitiva e irreversível. Quando a licença de um ex-colaborador é cancelada, a caixa de correio associada é eliminada em cerca de 30 dias, levando junto e-mails, contatos e calendários que podem conter informações comerciais relevantes. São janelas curtas para erros que, na vida real, costumam ser descobertos meses depois.

O versionamento de arquivos tampouco resolve os casos graves. Em um incidente de ransomware, a sincronização do OneDrive ou de ferramentas equivalentes replica os arquivos cifrados para a nuvem em minutos, sobrescrevendo as versões saudáveis. Restaurar manualmente, arquivo por arquivo, milhares de documentos a partir do histórico de versões é impraticável dentro de qualquer prazo aceitável de retomada. Sem uma cópia íntegra e independente, a empresa fica refém da extorsão ou do retrabalho.

Há ainda o fator humano interno, que as estatísticas de incidentes teimam em destacar. Exclusões acidentais respondem por parcela expressiva das perdas em nuvem, e exclusões intencionais, como a de um colaborador em conflito com a empresa às vésperas do desligamento, acontecem com mais frequência do que os relatórios públicos sugerem. Nos dois casos, o dano costuma ser descoberto fora da janela de retenção nativa, quando a lixeira já fez seu trabalho de limpeza. Um backup SaaS com retenção longa transforma esse tipo de episódio de crise irreversível em chamado de rotina, resolvido em minutos com a restauração do ponto anterior ao dano.

Existe, por fim, o risco que ninguém gosta de contemplar: a falha do próprio provedor ou da conta. Indisponibilidades prolongadas de grandes plataformas deixaram de ser hipótese, e um comprometimento administrativo do ambiente, no qual o invasor obtém privilégios de administrador, alcança também as lixeiras e as políticas de retenção. O backup SaaS rompe essa dependência circular ao manter a cópia dos dados fora do alcance das credenciais e da infraestrutura que protege.

O que uma estratégia de backup SaaS precisa ter

O primeiro requisito de um backup SaaS sério é a independência: a cópia deve residir em infraestrutura separada da plataforma de origem, sob credenciais distintas, de modo que nenhum incidente, erro ou invasor alcance o dado de produção e a salvaguarda ao mesmo tempo. É a tradução, para o mundo SaaS, do princípio clássico de manter cópias em meios e locais diferentes que sustenta toda boa política de proteção de dados. Soluções que armazenam o backup SaaS dentro da mesma nuvem e da mesma conta que protegem oferecem conforto, não segurança, porque compartilham o destino daquilo que deveriam socorrer.

O segundo requisito é a imutabilidade, tema que já aprofundamos no artigo sobre backup imutável. A cópia precisa ser protegida contra alteração e exclusão durante o período de retenção, inclusive por administradores, porque os ataques modernos procuram destruir os backups antes de cifrar a produção. Sem essa trava, o backup SaaS vira apenas mais um alvo.

O terceiro requisito é a granularidade da restauração com prazos definidos. Recuperar um único e-mail de dois anos atrás, uma pasta inteira do SharePoint na versão de ontem ou a caixa completa de um usuário desligado são necessidades diferentes, e a ferramenta deve atender a todas sem reconstruções heroicas. Objetivos claros de tempo e de ponto de recuperação, conhecidos pelas siglas RTO (Recovery Time Objective) e RPO (Recovery Point Objective), transformam a expectativa de “voltar rápido” em compromisso mensurável, e a cobertura deve abranger o conjunto do ecossistema, de e-mail e arquivos a equipes de colaboração e diretórios de identidade. Definir esses objetivos junto às áreas de negócio, e não apenas dentro da TI, evita a descoberta tardia de que o prazo tecnicamente possível é inaceitável para a operação.

Por último, exercícios periódicos de recuperação, com situações que vão do arquivo individual à perda completa de um serviço, validam prazos, expõem lacunas de cobertura e treinam a equipe para o dia em que a restauração acontecer sob pressão, com a operação parada e a diretoria perguntando de hora em hora. A rotina de backup SaaS também precisa de vigilância própria: jobs que falham por semanas são uma das causas mais comuns de surpresa amarga na hora da restauração, e o monitoramento diário do sucesso das cópias custa uma fração do prejuízo que evita.

A nuvem mudou o lugar do dado, não o dono do risco

A adoção de plataformas SaaS retirou das empresas o trabalho de operar servidores, mas não retirou a obrigação de responder pelos dados que vivem nelas, e os contratos dos provedores dizem isso com clareza para quem se dispõe a ler. A pergunta de maturidade deixou de ser “nossos dados estão na nuvem?” e passou a ser “se o dado da nuvem sumir hoje, em quanto tempo ele volta?”.

A boa notícia é que fechar essa lacuna está entre os movimentos de melhor relação entre custo e risco de toda a agenda de proteção. Diferentemente de projetos longos de transformação, implantar um backup SaaS é questão de semanas: mapear as plataformas críticas, definir retenção por tipo de dado, ativar as cópias automáticas e agendar o primeiro teste de restauração. O investimento é previsível e modesto diante do custo de uma perda definitiva, que combina interrupção operacional, exposição regulatória e o desgaste de explicar a clientes que a informação deles não volta mais.

A Solo Iron responde a essa pergunta com o Iron Business Continuity, que estrutura estratégias de backup SaaS e de continuidade de negócios com cópias independentes e imutáveis, retenção alinhada às exigências regulatórias e testes regulares de restauração para os principais ecossistemas de produtividade do mercado. Vale encerrar com o teste que todo gestor pode fazer ainda hoje: escolha um arquivo importante apagado há seis meses e peça a recuperação. O resultado desse pedido diz mais sobre sua resiliência do que qualquer política escrita.