A recuperação de desastres terceirizada para empresas deixou de ser um luxo restrito a bancos e grandes corporações. Com a migração de sistemas críticos para a nuvem e a pressão crescente de reguladores e clientes por disponibilidade contínua, decisores de TI passaram a avaliar o DRaaS como peça de infraestrutura estratégica — não como apólice de seguro guardada na gaveta. A pergunta que chega às mesas de CTOs raramente é "vale a pena?", mas sim "como contratar sem criar dependência, sem estourar o orçamento e sem descobrir na hora do incidente que o plano não funciona?".
Este texto responde a essa pergunta na prática. Em vez de repetir definições genéricas, ele detalha o que um provedor realmente assume e o que continua sendo responsabilidade da sua equipe, como ler cláusulas de SLA e multas, o que a LGPD exige em termos de soberania de dados e quais custos costumam escapar do orçamento — tráfego de replicação, testes de failover, licenças no ambiente de contingência. Também compara cenários de contratação, aponta erros que fazem o DRaaS falhar justamente durante o desastre e propõe um roteiro de implantação para os primeiros 90 dias.
Se a sua operação processa dados sensíveis ou transações financeiras, a leitura serve como checklist de decisão — e não como promessa de imunidade a falhas.
O que é recuperação de desastres terceirizada (DRaaS)
Recuperação de desastres terceirizada — ou Disaster Recovery as a Service (DRaaS) — consiste na contratação de um provedor externo para replicar cargas de trabalho críticas em uma infraestrutura de contingência e orquestrar a retomada da operação quando o ambiente principal falha. Em vez de manter um segundo datacenter próprio, a empresa paga pelo uso de recursos de computação, armazenamento e rede do fornecedor, acionados sob demanda ou em regime de standby contínuo.
O modelo ganhou escala com a maturidade das nuvens públicas. Plataformas como Microsoft Azure permitem que máquinas virtuais, bancos de dados e aplicações inteiras sejam replicados para regiões distintas, com automação de failover que reduz a dependência de intervenção manual. Para companhias que operam transações sensíveis — como ambientes financeiros com processamento de Pix —, a diferença entre minutos e horas de indisponibilidade tem impacto direto em receita, obrigação regulatória e reputação.
DRaaS não é sinônimo de backup. O backup gerenciado preserva cópias para restauração de dados, mas não entrega infraestrutura pronta para assumir a operação. A recuperação de desastres terceirizada vai além: mantém réplicas orquestradas, procedimentos de acionamento e metas de retomada definidas em contrato.
Como funciona a recuperação de desastres terceirizada na prática
O funcionamento do DRaaS parte de um inventário técnico das cargas que precisam ser protegidas. Servidores, bancos de dados, aplicações e serviços de rede são classificados por criticidade, e cada um recebe uma política de replicação específica. O provedor instala agentes ou conectores no ambiente de origem — seja on-premise, em nuvem ou híbrido — e passa a copiar blocos de dados alterados para o ambiente de destino em intervalos definidos.
Quando um incidente é declarado, o provedor executa um runbook previamente validado: provisiona os recursos no ambiente de contingência, redireciona o tráfego e entrega um ambiente operacional à equipe do cliente. O processo pode ser acionado manualmente por um gestor autorizado ou de forma automatizada, conforme o desenho contratado e a criticidade do serviço.
Replicação contínua, failover e failback
A replicação contínua usa captura de alterações em nível de bloco para enviar ao destino apenas o que mudou desde a última sincronização. Isso permite RPOs (Recovery Point Objectives) na casa de segundos ou poucos minutos, sem sobrecarregar o link de dados. Em cargas com baixa taxa de mudança, a replicação quase em tempo real é viável mesmo em conexões corporativas comuns.
Failover é o ato de chavear a operação para o ambiente de contingência. No Azure, por exemplo, o Azure Site Recovery orquestra o processo: derruba a réplica, aplica as últimas alterações e publica os endpoints substitutos. Failback é o caminho inverso — devolver a carga ao ambiente original após a correção da causa raiz — e costuma ser a etapa mais negligenciada nos testes, justamente porque exige sincronização reversa e validação de integridade antes do corte definitivo.
O que fica com o provedor e o que continua com a sua equipe
A divisão de responsabilidades varia conforme o modelo contratado, mas há um padrão de mercado. O provedor assume a infraestrutura de contingência, a ferramenta de replicação, o monitoramento da sincronização, a execução do failover e a manutenção do ambiente de destino. Em contratos gerenciados, ele também assume a atualização dos runbooks e a realização de testes periódicos.
O cliente permanece responsável por decisões que nenhum fornecedor consegue tomar por ele:
- Definir quais cargas entram no escopo do DRaaS e em que ordem de prioridade
- Manter o inventário de dependências entre sistemas atualizado
- Indicar quem tem autoridade para declarar desastre e acionar o failover
- Validar se o ambiente recuperado atende aos requisitos de negócio
- Garantir que licenças de software sejam válidas no ambiente de contingência
Ignorar essa divisão é uma das causas mais comuns de expectativa frustrada. O provedor entrega infraestrutura e orquestração; a definição do que é crítico e do que constitui retomada aceitável é decisão de negócio, não técnica.
RTO e RPO: os números que definem o contrato
RTO (Recovery Time Objective) é o tempo máximo aceitável entre a declaração do incidente e a disponibilidade do serviço recuperado. RPO (Recovery Point Objective) é a quantidade máxima de dados que a empresa tolera perder, medida em tempo — um RPO de 15 minutos significa que, no pior cenário, até 15 minutos de transações podem ser perdidos.
Esses dois números orientam toda a arquitetura do DRaaS. Cargas com RTO de 4 horas aceitam provisionamento sob demanda, que custa menos. Cargas com RTO de 15 minutos exigem réplicas quentes já provisionadas e sincronizadas, com custo mensal substancialmente maior. O mesmo vale para RPO: replicação síncrona entre regiões do Azure encarece a operação em relação à replicação assíncrona com janelas de 1 hora.
Para ambientes financeiros que processam Pix, o RPO tende a ser agressivo. Uma transação liquidada que se perde na replicação gera conciliação manual, risco de duplicidade e potencial questionamento regulatório. Por isso, bancos e fintechs costumam especificar RPO próximo de zero para os sistemas de autorização e liquidação, enquanto sistemas de backoffice aceitam janelas maiores.
- RTO/RPO subestimados geram contrato caro e complexidade desnecessária
- RTO/RPO superestimados geram plano que não atende ao negócio no incidente real
- Metas diferentes por carga reduzem custo sem sacrificar a criticidade
- RTO e RPO precisam constar no SLA com penalidade associada
Modelos de contratação: autoatendimento, assistido e gerenciado
O DRaaS se divide em três modelos principais, com graus crescentes de delegação. No autoatendimento, o cliente contrata a infraestrutura e a ferramenta de replicação, mas configura, monitora e executa tudo internamente — o provedor é essencialmente um fornecedor de nuvem. O modelo é mais barato, porém exige equipe com domínio profundo de orquestração de failover.
No modelo assistido, o provedor configura a replicação, entrega os runbooks e fica disponível para apoiar o failover, mas o acionamento e a operação do ambiente recuperado ficam com o cliente. É um meio-termo comum em empresas que já têm time de infraestrutura, mas não querem construir a camada de DR do zero.
No modelo gerenciado, o provedor opera o DR de ponta a ponta: monitora a replicação 24/7, executa testes programados, atualiza runbooks e conduz o failover quando acionado. É o formato que mais se aproxima do que decisores de TI esperam ao buscar "recuperação de desastres terceirizada para empresas" — transferência operacional com SLA formal. O custo é o mais alto dos três, mas elimina a dependência de conhecimento interno escasso.
O que exigir de um provedor de DRaaS
A seleção de provedor não pode se limitar a comparar preço de assinatura. O contrato de DRaaS concentra riscos jurídicos, técnicos e operacionais que só aparecem quando o desastre acontece — e é exatamente nesse momento que a margem para renegociar desaparece. Três blocos de exigências merecem atenção antes da assinatura.
SLA, multas e responsabilidade compartilhada
O SLA de um contrato de DRaaS precisa definir, no mínimo: tempo máximo para iniciar o failover após o acionamento, tempo para disponibilizar o ambiente recuperado, disponibilidade mensal da infraestrutura de replicação e janela de manutenção programada. Sem esses parâmetros, o provedor pode alegar "melhor esforço" — expressão que não protege o cliente em incidente real.
Multas precisam ter lastro financeiro proporcional ao prejuízo. Um crédito de 5% sobre a mensalidade por falha de failover é irrisório diante de horas de indisponibilidade em um ambiente que processa Pix. O ideal é escalonar a compensação conforme o tempo de atraso e associar o descumprimento reiterado à possibilidade de rescisão sem penalidade.
A cláusula de responsabilidade compartilhada deve espelhar a divisão prática descrita anteriormente. O provedor responde pela infraestrutura e pela orquestração; o cliente responde pelas definições de negócio, pelos dados e pelas aplicações. Documentar isso evita a disputa clássica pós-incidente em que cada parte atribui a falha à outra.
Segurança, isolamento de dados e conformidade com LGPD
O ambiente de contingência é uma cópia do ambiente produtivo — e carrega os mesmos dados sensíveis. Exija criptografia em trânsito e em repouso, isolamento lógico entre tenants, autenticação multifator para acesso ao console de DR e trilha de auditoria de todas as ações administrativas. Para cargas financeiras, verifique se o provedor suporta controles adicionais como backup imutável para impedir que réplicas sejam alteradas ou excluídas por atacantes.
A LGPD impõe deveres específicos ao operador — figura que o provedor de DRaaS ocupa. O contrato precisa prever cláusulas de tratamento de dados pessoais, instruções documentadas, obrigação de comunicar incidentes e comprovação de medidas de segurança. A localização dos dados também importa: replicar para região fora do Brasil não é proibido pela LGPD, mas exige avaliação de transferência internacional e pode colidir com políticas internas de soberania de dados.
Para empresas do setor financeiro, ainda há sobreposição com regulação do Banco Central. A Resolução CMN nº 4.893/2021 e normas posteriores tratam de continuidade de negócios e gestão de incidentes cibernéticos — e o DRaaS precisa estar alinhado a esses requisitos, não apenas à LGPD. Um provedor sem familiaridade com esse arcabouço tende a entregar contrato genérico que não resiste a uma auditoria regulatória.
Portabilidade e plano de saída do provedor
Aprisionamento tecnológico é risco concreto em DRaaS. Se o provedor usa ferramenta proprietária de replicação, migrar para outro fornecedor pode exigir reconstruir todo o ambiente de contingência do zero. Exija clareza sobre formatos de exportação, prazos de transição e propriedade dos runbooks e scripts de automação desenvolvidos durante o contrato.
O plano de saída deve prever um período de transição assistida em que o provedor mantém a replicação ativa enquanto o cliente migra para a nova solução. Também é razoável exigir que, ao término do contrato, os dados residuais no ambiente do provedor sejam eliminados com comprovação formal, em linha com boas práticas de gestão do ciclo de vida de dados.
Quanto custa terceirizar a recuperação de desastres
O custo de DRaaS é composto por camadas que nem sempre aparecem na proposta comercial inicial. A assinatura mensal cobre a infraestrutura de contingência e a ferramenta de replicação, mas tráfego de dados, testes de failover e horas de suporte em incidente costumam ser cobrados à parte. Entender a composição total evita surpresas no primeiro trimestre de contrato.
Custos de assinatura, tráfego de dados e testes
A assinatura varia conforme o número de servidores protegidos, o volume de dados replicados e o modelo contratado. O valor exato depende de arquitetura, região de destino e criticidade.
O tráfego de dados é a variável mais subestimada. Replicação contínua gera volume constante de saída de dados do ambiente de origem, e provedores de nuvem cobram por gigabyte trafegado. Em cargas com alta taxa de mudança — bancos de dados transacionais, por exemplo —, o custo de egresso pode igualar ou superar a assinatura. Testes de failover também consomem recursos: cada simulação provisiona o ambiente de contingência, gera tráfego e exige horas de acompanhamento técnico.
Comparação com manter um site de recuperação próprio
Um site de recuperação próprio exige, no mínimo: um segundo datacenter ou sala segura, hardware redundante, licenças de software em dobro, link dedicado entre os sites, equipe para operar o ambiente de contingência e procedimentos testados. O custo fixo existe mesmo quando nenhum desastre ocorre — e é exatamente essa ociosidade que o DRaaS elimina.
Em compensação, o site próprio oferece controle total sobre a infraestrutura e ausência de dependência de terceiros em momento crítico. Para empresas com requisitos regulatórios extremos ou que já possuem datacenter secundário subutilizado, manter o DR interno pode ser financeiramente racional. A decisão passa por comparar o custo total de propriedade em um horizonte de 3 a 5 anos, incluindo depreciação, energia, equipe e testes — não apenas o investimento inicial.
- DRaaS converte capex em opex e reduz ociosidade de hardware de contingência
- Site próprio exige investimento contínuo mesmo sem incidentes
- Testes de failover em site próprio consomem horas internas de equipe sênior
- DRaaS permite escalar a proteção conforme o parque cresce, sem compra antecipada
Erros que fazem o DRaaS falhar na hora do desastre
Contratar DRaaS não garante recuperação. A maioria das falhas em incidentes reais não vem de defeito na infraestrutura do provedor, mas de decisões e omissões do lado do cliente que se acumulam silenciosamente. O primeiro erro clássico é nunca testar o failover completo — apenas validar que a replicação está sincronizando. Réplica sincronizada não significa ambiente funcional: dependências de DNS, certificados digitais, integrações entre sistemas e configurações de rede só se revelam quando o ambiente de contingência é efetivamente ligado.
O segundo erro é proteger tudo com a mesma prioridade. Sem classificação de criticidade, o orçamento se dilui em cargas de baixo impacto enquanto sistemas essenciais recebem RTO insuficiente. O resultado é um plano que parece abrangente no papel e falha exatamente onde o negócio mais precisa.
O terceiro erro é tratar o DRaaS como projeto de infraestrutura, não como processo contínuo. Aplicações mudam, servidores são adicionados, integrações são refeitas — e o runbook envelhece. Um plano de recuperação desatualizado é tão perigoso quanto a ausência de plano, porque gera confiança falsa. O mesmo raciocínio se aplica ao teste de restore de backup: sem validação periódica, não há evidência de que a recuperação funciona.
- Nunca testar failover completo, apenas sincronização de réplica
- Proteger cargas sem classificar criticidade de negócio
- Manter runbook desatualizado após mudanças em aplicações
- Não treinar a equipe que vai operar o ambiente recuperado
- Ignorar dependências externas como DNS, certificados e APIs de terceiros
Como escolher e implantar o DRaaS na sua empresa
A implantação de DRaaS segue uma sequência que começa no inventário e termina na operação assistida. Pular etapas — especialmente a definição de RTO/RPO por carga e o teste piloto — é a receita mais rápida para um contrato caro que não protege o que deveria. Empresas que já operam ambientes híbridos com Azure e on-premise têm vantagem: a integração com ferramentas de replicação nativas reduz a complexidade da camada de contingência, como detalhado no guia de backup em ambientes híbridos.
Perguntas para fazer ao fornecedor antes de assinar
As respostas a estas perguntas revelam mais sobre o provedor do que qualquer apresentação comercial:
- Qual é o RTO e o RPO contratualmente garantidos para cada carga do escopo?
- O failover é testado com que frequência e quem paga pelos testes?
- Onde os dados replicados ficam armazenados e sob qual jurisdição?
- Qual é o procedimento exato para acionar o DR em um incidente real?
- Quem atende o chamado de failover fora do horário comercial?
- Como funciona o failback e quanto tempo ele costuma levar?
- O que acontece com os dados ao final do contrato?
- Existe histórico de incidentes em que o DR foi acionado com sucesso?
A recusa em responder qualquer uma dessas perguntas com precisão é, por si só, um critério de eliminação. Provedores sérios de DRaaS operam com runbooks documentados e métricas históricas; a vagueza nessa etapa tende a se repetir durante o incidente.
Primeiros 90 dias após a contratação
Os primeiros 90 dias definem se o DRaaS será um ativo de continuidade ou uma despesa mensal com falsa sensação de segurança. O inventário técnico completo e a definição formal de criticidade por carga devem contar com participação das áreas de negócio — não apenas da TI. É nessa etapa que RTO e RPO são validados contra expectativas reais.
A configuração da replicação e a elaboração dos runbooks iniciais concentram a etapa seguinte. Cada carga protegida precisa de documentação de dependências, ordem de inicialização, validação de integridade e critério de sucesso do failover. Para cargas críticas, o runbook deve incluir contatos de acionamento, matriz de comunicação e procedimento de retorno.
O primeiro teste completo de failover deve ser executado em janela controlada, com a participação das equipes que operariam o ambiente em incidente real, e cada falha encontrada deve ser registrada. O resultado desse teste alimenta a revisão do runbook e o plano de correção. A partir daí, a rotina entra em ciclo contínuo: testes programados, atualização de runbook a cada mudança relevante e revisão contratual anual — incluindo a verificação de que o provedor continua alinhado aos requisitos de segurança e conformidade que motivaram a contratação.
