Disaster recovery as a service (DRaaS), ou recuperação de desastres como serviço, é um serviço em nuvem em que um provedor mantém cópias atualizadas dos servidores e dados da empresa e permite ligá-las no ambiente dele quando o seu para, por pane, ransomware ou incêndio. Em vez de manter um segundo data center, a empresa paga pelo serviço e volta a operar em minutos ou horas, conforme o que contratar.
Como o DRaaS funciona na prática
Um software instalado nos servidores, ou na camada de virtualização, copia os dados para a nuvem do provedor. A primeira cópia é completa; depois disso, só as alterações são enviadas, de forma contínua ou em intervalos definidos. O provedor guarda vários pontos de recuperação, e isso permite voltar a um momento anterior ao problema, não apenas à última versão.
O serviço gira em torno de quatro etapas:
- Replicação: o envio constante das mudanças, que mantém a cópia em dia sem interromper o trabalho de ninguém.
- Failover: quando o ambiente principal cai, as máquinas replicadas são ligadas na nuvem do provedor, na ordem prevista no plano, e passam a atender os usuários.
- Failback: resolvido o problema, os dados alterados durante a crise voltam para o ambiente principal, que reassume a operação.
- Testes: bons serviços permitem ligar as réplicas numa rede isolada, sem afetar a produção, para conferir se tudo sobe como esperado.
Depois do failover, os sistemas continuam os mesmos, só que rodando em outro lugar. Por isso o plano precisa prever como os funcionários chegam até eles: mudança de endereços e DNS, links de internet e, em muitos casos, uma VPN corporativa com vários acessos simultâneos. O vídeo abaixo, em inglês, resume o funcionamento do serviço.
RPO e RTO: as duas metas que definem o serviço
Toda contratação de DRaaS começa por duas perguntas. A primeira é quanto dado a empresa aceita perder, o RPO (recovery point objective): um RPO de 15 minutos significa que, no pior caso, se perdem os últimos 15 minutos de lançamentos. A segunda é quanto tempo ela aguenta parada, o RTO (recovery time objective): um RTO de quatro horas significa que o sistema precisa estar de volta em até quatro horas.
As metas não precisam ser iguais para tudo. Um ERP que fatura, um e-commerce ou um banco de dados de atendimento pedem RPO e RTO curtos; um servidor de arquivos antigos ou uma intranet aguentam mais. Quanto menores os números, mais caro o serviço, porque exigem replicação contínua e recursos prontos para ligar. O jeito prático de decidir é estimar, para cada sistema, quanto custa uma hora parada em vendas perdidas, equipe sem trabalhar, multas contratuais e desgaste com clientes, e comparar com o preço de cada nível de proteção.
DRaaS não substitui o backup
Os dois serviços se completam, mas resolvem problemas diferentes:
| Aspecto | Backup (BaaS) | DRaaS |
|---|---|---|
| Objetivo | Recuperar dados: arquivos, bancos, e-mails | Recuperar a operação: servidores inteiros rodando |
| Guarda por quanto tempo | Semanas, meses ou anos | Janela mais curta de pontos de recuperação, em geral de dias a poucas semanas |
| Tempo para voltar | Horas ou dias para restaurar sistemas inteiros, porque é preciso ter onde restaurar | Minutos ou horas, porque a infraestrutura já está pronta |
| Melhor contra | Arquivo apagado, dado corrompido, exigência de guardar histórico | Pane geral, perda do local, indisponibilidade prolongada |
Um ponto que pega muitas empresas de surpresa é o ransomware. A replicação copia tudo, inclusive arquivos criptografados por um ataque; por isso o DRaaS precisa oferecer pontos de recuperação de antes da invasão, e a empresa deve manter um backup separado, com pelo menos uma cópia imutável ou desconectada da rede. A velha regra 3-2-1 continua valendo: três cópias dos dados, em dois tipos de armazenamento, com uma delas fora da empresa.
Modelos de contratação e como a cobrança costuma funcionar
Há três formas principais de contratar o serviço:
- Autosserviço: a própria equipe de TI usa as ferramentas de uma nuvem pública, configura a replicação, escreve o plano e executa os testes. Sai mais barato, mas exige gente qualificada.
- Assistido: o provedor ajuda a desenhar e testar o plano, e a empresa continua responsável pela operação.
- Gerenciado: o provedor cuida da replicação, do monitoramento, dos testes e da execução do failover. É o que costuma fazer mais sentido para empresas sem equipe de TI dedicada.
Nas nuvens públicas, os serviços mais conhecidos são o AWS Elastic Disaster Recovery, da Amazon Web Services (AWS), o Azure Site Recovery, da Microsoft, e as ferramentas de backup e recuperação do Google Cloud. As três têm região de data center no estado de São Paulo, o que ajuda quem prefere manter os dados no Brasil. Muitos provedores gerenciados, inclusive nacionais, montam o serviço sobre softwares como Veeam, Zerto e Acronis, cobram em reais e dão suporte em português.
Na maioria das propostas, a conta combina três itens: uma taxa por servidor ou máquina virtual protegida, o armazenamento das réplicas e o processamento consumido quando o ambiente é ligado, em testes ou numa recuperação real. Peça a simulação dos três, porque um failover que dure vários dias pode custar bem mais que a mensalidade. Se a empresa ainda está decidindo onde manter os próprios sistemas, a comparação entre nuvem híbrida e nuvem pública para empresas ajuda a enxergar onde a recuperação de desastres se encaixa.
Como implantar em sete passos
- Faça o inventário. Liste servidores, sistemas, bancos de dados, serviços de rede (como DNS e Active Directory), links de internet e licenças, e anote o que depende do quê.
- Defina as metas. Classifique os sistemas por impacto no negócio e estabeleça RPO e RTO para cada grupo.
- Escolha o modelo e o provedor, com base nos critérios da próxima seção.
- Faça a carga inicial. A primeira cópia pode levar dias, conforme o volume de dados e a velocidade do link. Alguns provedores aceitam essa carga por disco físico.
- Escreva o plano de recuperação. Ele diz quem pode declarar o desastre, a ordem em que as máquinas sobem (primeiro os serviços de rede, depois os bancos de dados e só então as aplicações), como os usuários acessam o ambiente, quem aciona o provedor e como clientes e fornecedores serão avisados.
- Teste de verdade. Faça um failover de teste em rede isolada, meça se as metas foram cumpridas e corrija o que falhou. Repita pelo menos uma vez por ano e sempre que o ambiente mudar muito.
- Planeje a volta. Combine como e quando os dados alterados durante a crise retornam ao ambiente principal, para o failback não virar um segundo incidente.
O que perguntar ao provedor antes de assinar
- Quais RPO e RTO estão no contrato, com acordo de nível de serviço (SLA), e o que acontece se não forem cumpridos?
- Em que país e em qual data center ficam as réplicas, e quem tem acesso a elas?
- O serviço é compatível com o que a empresa usa hoje: servidores físicos, VMware, Hyper-V ou outra nuvem?
- Quantos testes por ano estão incluídos e quanto custa cada teste extra?
- Quantos pontos de recuperação ficam guardados, por quanto tempo, e há proteção contra ransomware, como cópias imutáveis e autenticação em dois fatores no painel?
- O suporte funciona 24 horas, em português? Quem executa o failover numa madrugada de domingo?
- Como os dados são devolvidos se a empresa trocar de fornecedor?
Se as réplicas contêm dados pessoais de clientes ou funcionários, o provedor vai tratá-los em nome da empresa, e o contrato precisa prever segurança, sigilo, aviso em caso de incidente e exclusão dos dados ao fim do serviço. Réplicas guardadas fora do Brasil também seguem as regras da LGPD para transferência internacional. O guia sobre adequação à LGPD em lojas virtuais traz os cuidados principais; na dúvida, envolva o jurídico ou o encarregado de dados da empresa.
Quando o DRaaS vale a pena e quando não é prioridade
O serviço faz mais sentido para empresas com servidores próprios rodando sistemas críticos, como ERP, banco de dados, sistemas de produção ou de atendimento, e para quem tem clientes ou contratos que exigem continuidade. Nesses casos, o custo de horas paradas costuma superar com folga a mensalidade.
Já uma empresa que roda quase tudo em serviços on-line, como e-mail, ERP e CRM na nuvem, tem outra prioridade: fazer backup dos dados desses serviços, ter um segundo link de internet e saber como trabalhar se um deles sair do ar, porque a recuperação da infraestrutura em si fica a cargo de cada fornecedor. E um escritório pequeno, com um único servidor de arquivos, pode estar bem atendido por um backup em nuvem com restauração testada.
O primeiro passo não depende de fornecedor: liste seus sistemas, estime quanto custa cada hora parada e defina o RPO e o RTO de cada um. Com esses números em mãos, fica fácil comparar propostas de DRaaS e cobrar do provedor, com testes periódicos, aquilo que foi prometido.
