Benchmark de recuperação de desastres: Acronis vs Comet vs MSP360

Fizemos benchmark de Acronis Cyber Protect Cloud, Comet Backup e MSP360 Managed Backup em recuperação de desastres. Cada fornecedor criou uma imagem de um Windows Server 2022 ativo e de um servidor Ubuntu 24.04 ativo executando a mesma carga de trabalho determinística, um serviço web, um banco de dados de 10.000 linhas e 50 arquivos, e depois recuperou a máquina inteira em um servidor separado após um desastre no estilo ransomware ter criptografado os dados.

Resultados do benchmark de recuperação de desastres

O que cada coluna significa:

• Pontuação ponderada: o total da rubrica nas sete dimensões, informado para referência; o benchmark pontua cada dimensão isoladamente.
• Tempo para restaurar: o tempo de recuperação de ponta a ponta (RTO), desde a declaração do failover até o serviço recuperado responder a uma sonda externa.
• Detecção de failover: se o produto consegue executar um failover de teste e confirmar que a máquina recuperada inicializou, desde uma verificação automatizada por captura de tela até não fazer nada.
• 3rd-party integrações: quantos dos sete destinos de recuperação (nuvem do fornecedor, AWS, Azure, Google Cloud, hipervisor local, cross-region, cross-cloud) o produto consegue recuperar.
• Motor de DR: se o produto orquestra o failover (um servidor de recuperação e runbook) ou apenas restaura um backup manualmente.

Consulte a metodologia do benchmark de recuperação de desastres para a rubrica de pontuação e o protocolo de tempos T0-T6.

Os principais insights:

• Acronis recuperou o servidor criptografado em 73 segundos no Windows e em cerca de 108 segundos no Linux com um único clique no runbook. A carga de trabalho inicializou em um novo servidor dentro da nuvem do fornecedor, recebeu um IP público automaticamente e voltou limpa e idêntica byte a byte.
• Comet e MSP360 não têm motor de failover. A recuperação é um restore-to-VM manual que levou dezenas de minutos e exigiu um operador em cada etapa: provisionar um destino, gravar a imagem de disco, reconfigurar a rede, reiniciar.
• Os três produziram uma recuperação idêntica byte a byte. O manifesto dos 50 arquivos SHA-256 e a soma de verificação do banco de dados corresponderam à linha de base pré-desastre em todos os casos, então a diferença está na velocidade e no esforço do operador, não na integridade dos dados.

Produtos de recuperação de desastres testados

Acronis Cyber Protect Cloud

Acronis é o único produto no teste com um motor de failover de recuperação de desastres como serviço. Ele executa um servidor de recuperação na nuvem da Acronis, faz failover a partir de um runbook e valida o resultado com failover de teste automatizado. Ele ganha sua pontuação em automação, velocidade de recuperação e alcance de destinos, e seu principal teto é o failback baseado em agente.

Profundidade da automação de failover

Os runbooks orquestram o failover por meio de etapas ordenadas, ações paralelas dentro de uma etapa, verificações de conclusão por ping e porta, portões de aprovação manual e runbooks aninhados. O painel de conformidade monitora metas de RPO, dispositivos elegíveis e cota de pontos de computação. Nenhum outro produto no teste codifica a recuperação em vez de deixá-la para um operador.

Capacidade de failover de teste

O failover de teste não disruptivo inicializa o servidor de recuperação em uma rede isolada, e o Automated Test Failover valida uma inicialização agendada com uma verificação de captura de tela por IA. Funcionou nos dois sentidos, dando um veredito real de falha em um servidor Linux travado na recuperação do journal e um sucesso real em uma inicialização limpa do Windows.

RTO de ponta a ponta

73 segundos no Windows, cerca de 108 segundos no Linux (94 e 121 em dois testes). Um clique no runbook sobe o servidor de recuperação, atribui um IP público e serve a aplicação recuperada. O estado recuperado era idêntico byte a byte à linha de base pré-desastre.

RPO

A recuperação usou um backup de três a quatro minutos, dentro do limite de conformidade de RPO. O limite é configurável de 15 minutos a 14 dias.

Failback e reproteção

Failback delta de quatro fases (planejamento, transferência de dados, comutação, validação) com o servidor em nuvem permanecendo ativo durante a transferência. Retornar ao hardware original exige mídia inicializável e uma reproteção manual.

Conectividade e flexibilidade de rede

O modo somente nuvem dispensa appliance de VPN. OpenVPN site-to-site, IPsec multi-site, VPN point-to-site, IP público por servidor e DNS personalizado estão disponíveis. Não há redirecionamento integrado de registro A de DNS público.

Alcance de destinos de DR

Seis de sete destinos. Um site de DR gerenciado no Acronis Cloud ou no Azure, Instant Restore para VMware e Hyper-V locais, recuperação para hardware físico dissimilar e uma migração documentada de restore-to-EC2 para a conta AWS do cliente. O failover orquestrado em si é executado no Acronis Cloud ou no Azure, portanto o EC2 é alcançado por restauração manual e não por failover automatizado. Apenas o Google Compute Engine não tem caminho documentado.

Uma observação de confiabilidade surgiu dos testes. A recuperação limpa e idêntica byte a byte foi comprovada duas vezes, no primeiro teste (um RTO de 94 segundos com verificação de integridade aprovada) e no failover de teste não disruptivo. O segundo teste revelou duas pegadinhas de ponto de recuperação, nenhuma falha do motor de recuperação. Um ponto capturado enquanto a origem estava no meio de um reset inicializou em um estado de recuperação de journal travado e teve de ser refeito. Parar esse failover auto-retomou o backup de origem, que capturou a origem ainda criptografada, então a nova tentativa inicializou no tempo certo, mas caiu naquele ponto criptografado mais recente. O servidor de recuperação não é melhor do que o ponto de recuperação por trás dele, então pausar o backup durante um incidente e fazer failover a partir de um ponto reconhecidamente limpo é a sequência mais segura.

Comet Backup

O Comet é um produto de backup sem motor de recuperação de desastres. Pontuou 0 em automação de failover e failover de teste, porque não tem nenhum dos dois, e conquistou pontos no caminho manual de restore-to-VM e na amplitude dos destinos de restauração. A restauração de imagem de disco funciona. No benchmark, ele trouxe de volta um servidor Ubuntu atingido por ransomware, idêntico byte a byte e acessível externamente, em um novo host.

Profundidade da automação de failover

Nenhuma. Sem servidor de recuperação, sem runbook, sem failover de um clique. A recuperação é um procedimento manual de ponta a ponta. O próprio guia de recuperação de desastres do Comet não descreve um failover de carga de trabalho; ele aborda a proteção do console do Comet com replicação e o re-registro de um novo agente após a perda de um dispositivo cliente.

Capacidade de failover de teste

Nenhuma. A opção “Simulate restore only” do assistente de restauração é um ensaio que não inicializa uma máquina, portanto não há failover de teste a pontuar.

RTO de ponta a ponta

A gravação da imagem de disco no disco de um novo servidor levou cerca de dois minutos, mas o procedimento completo (boot de resgate, instalação do agente, restauração para dispositivo físico, reconfiguração de rede, reinicialização) levou de 15 a 25 minutos. O servidor recuperado correspondia à soma de verificação pré-desastre e serviu sua aplicação em um novo IP.

RPO

Backups agendados de imagem de disco com incrementais, sem proteção contínua de dados. O primeiro backup do volume raiz ao vivo encheu o armazenamento diferencial e exigiu que a carga de trabalho fosse quiescida para uma imagem limpa.

Failback e reproteção

O failback é a mesma restauração manual invertida, sem sincronização delta e sem reproteção automatizada.

Conectividade e flexibilidade de rede

Sem rede de DR. A máquina restaurada carregava o netplan estático com MAC correspondente ao da origem, que reescrevemos manualmente para o endereço do host de recuperação antes de funcionar.

Alcance de destinos de DR

Bare metal, Hyper-V, VMware vSphere e Proxmox nativamente; AWS e Azure via exportação de VMDK e VHDX. Uma ressalva surgiu aqui: uma imagem de restore-to-file infla para o tamanho total do disco, então o disco de origem do mesmo tamanho não pode conter o arquivo intermediário, o que forçou o caminho de restauração bare metal.

MSP360 Managed Backup

O MSP360 é um produto de backup cuja recuperação de desastres é um restore-to-VM manual e cuja recuperação funciona no Windows, não no Linux. No Windows, ele igualou a classe de recuperação do Comet e inicializou um servidor restaurado em hardware separado. Sua pontuação entre sistemas operacionais é baixa porque o agente Linux não tem backup de imagem, então metade do benchmark (recuperação Linux) pontua zero. As subpontuações abaixo são para Windows; o total entre sistemas operacionais é a média dos números do Windows com um zero do Linux.

Profundidade da automação de failover

Sem motor, sem runbook, sem servidor de recuperação. O “DRaaS” e o “Cloud DR” em suas páginas de produto se resumem a um restore-to-VM manual.

Capacidade de failover de teste

O recurso Run Restore Verification inicializa a imagem como uma máquina virtual Hyper-V e verifica um logon bem-sucedido, o que é mais do que um ensaio, mas exige Hyper-V local (ausente nos hosts de teste em nuvem) e valida um backup em vez de fazer failover para um site de recuperação.

RTO de ponta a ponta

Restauramos uma imagem de disco completo com conversão GPT para BIOS/MBR, gravamos em um servidor em nuvem separado, inicializamos o Windows no novo host e alcançamos uma sonda de saúde externa limpa e idêntica byte a byte. O motor de restauração produziu a imagem inicializável em cinco a seis minutos; o resto foi mover a imagem, inicializá-la e uma correção manual de rede. De ponta a ponta, o restore-to-VM bare-metal foi um procedimento manual de múltiplas etapas de 15 a 25 minutos, a mesma classe da recuperação Linux do Comet. Uma restauração in-place mais simples apenas dos dados criptografados, com o servidor ainda em execução, levou cerca de 10 minutos.

RPO

Backups de imagem agendados com incrementais por changed-block tracking, sem proteção contínua de dados.

Failback e reproteção

Restauração completa manual de volta à origem, sem sincronização delta e sem reproteção automatizada.

Conectividade e flexibilidade de rede

Sem rede de DR. O servidor restaurado inicializou com o IP estático da máquina de origem e ficou inacessível até definirmos o endereço correto pelo console out-of-band.

Alcance de destinos de DR

Disco físico, Hyper-V, VMware vSphere e VirtualBox, além das três nuvens públicas por meio das opções nativas do assistente de restauração: Restore to Amazon EC2, Restore to Azure VM e Restore to Google Cloud Instance (a exportação de imagem para AWS VM Import é o fallback indireto). A restauração nativa do Google Cloud torna o MSP360 o único produto no teste que alcança o Google Compute Engine, portanto, na contagem bruta de destinos, ele empata com a Acronis e supera o Comet. Só não tem a nuvem de DR gerenciada pelo fornecedor, que ele não possui. A conversão GPT para BIOS/MBR que fez a restauração bare-metal inicializar em um host BIOS é uma parte útil da amplitude.

A lacuna no Linux é a limitação decisiva. O agente Linux do MSP360 faz backup apenas em nível de arquivo, sem imagem de disco, portanto não há imagem de sistema inicializável nem restore-to-VM no Linux. Para um MSP com qualquer frota Linux, a recuperação de desastres com MSP360 cobre apenas metade do parque.

Comparação de recursos

Failover e orquestração

Integrações de terceiros e destinos de recuperação

O alcance de recuperação é próximo entre os três, mas composto de forma diferente. A Acronis recupera na própria nuvem, no Azure, em hosts VMware e Hyper-V locais e no AWS EC2 de um cliente por meio de uma migração documentada de restore-to-EC2, ficando devendo apenas o Google Compute Engine. O MSP360 não tem nuvem gerenciada, mas suporta nativamente as três nuvens públicas (o assistente de restauração oferece Restore to EC2, Azure VM e Google Cloud Instance), o que o torna o único produto aqui que suporta Google Compute Engine.

O Comet alcança AWS e Azure exportando um VMDK ou VHDX e importando-o, sem nuvem gerenciada e sem caminho para o Google Cloud. A Acronis e o MSP360 chegam, cada um, a seis dos sete tipos de destino, e o Comet a cinco. Nenhum deles traz uma integração integrada de failover de DNS de terceiros, como o redirecionamento automático de registro no estilo Cloudflare; a Acronis oferece DNS personalizado e modos de VPN, e nos produtos manuais a rede da máquina recuperada é configurada manualmente.

Rede e failback

Descobertas dos testes de recuperação de desastres

Reconfiguração de rede após uma restauração manual

Nos dois produtos manuais, o servidor recuperado inicializou com o IP estático da máquina de origem, não o do host de recuperação, e ficou inacessível na rede até um operador corrigir. O endereço vive dentro da imagem de disco, então viaja com a restauração. No Comet (Linux), reescrevemos a configuração do netplan no ambiente de resgate; no MSP360 (Windows), entramos no servidor inicializado pelo console em nuvem e definimos o IP estático manualmente. Um DRaaS trata isso como parte do failover; uma restauração manual não.

Qualidade do ponto de recuperação e confiabilidade do failover

O RTO de negócio de ponta a ponta mediu 94 segundos no primeiro teste de failover Linux, contra um ponto de recuperação de cerca de 3 minutos. O failover do Windows retornou 73 segundos em duas execuções com zero variação. O Teste 1 e o failover de teste não disruptivo passaram cada um por uma verificação de integridade T6 idêntica byte a byte, sem ransomware levado para o sistema recuperado.

Os dois itens que apareceram no segundo teste Linux foram um ponto de recuperação capturado no meio do reset que inicializou em um travamento de recuperação do journal e um backup de origem auto-retomado que colocou um ponto ainda criptografado na nova tentativa, ambos falhas de ponto de recuperação e operacionais, e não do motor de recuperação. O Automated Test Failover da Acronis detectou de forma independente a mesma condição de recuperação do journal em um teste não disruptivo e retornou um veredito de Falha, uma etapa de validação ausente no Comet e no MSP360, que pontuaram 0 em failover de teste.

Conversão de UEFI para BIOS na restauração

O host de recuperação do MSP360 inicializou em modo BIOS enquanto a origem era UEFI/GPT. A restauração do MSP360 inclui uma opção “Convert GPT to BIOS/MBR” que reconstrói o layout de partições e a configuração de boot para o destino BIOS, o que permite que o Windows restaurado inicialize em firmware diferente. Sem essa conversão, o disco não teria sido inicializável no host de recuperação. O caminho de restore-to-file do Comet esbarrou em outro limite mecânico: a imagem infla para o tamanho total do disco, então o caminho bare-metal para o disco de destino foi o único que coube.

Backup versus recuperação de desastres

Um backup é uma cópia de dados que pode ser restaurada. Recuperação de desastres é o processo orquestrado de colocar uma carga de trabalho de volta em serviço em uma infraestrutura diferente após a original ser perdida, medido pela rapidez com que o serviço retorna (RTO) e pela quantidade de dados perdidos (RPO).

O benchmark mostra a diferença. Os três produtos produziram um backup correto e uma restauração idêntica byte a byte. Um dos três, a Acronis, transformou esse backup em um serviço em execução em um novo servidor com um clique em 73 segundos. Os outros dois restauraram os mesmos dados corretamente, mas deixaram o failover, a inicialização e a rede para um humano, razão pela qual a recuperação deles levou dezenas de minutos e suas dimensões de automação pontuaram zero. Um produto pode ser uma excelente ferramenta de backup e ainda assim não ser uma ferramenta de recuperação de desastres.

O que significa recuperação de desastres como serviço (DRaaS)?

Recuperação de desastres como serviço significa que o fornecedor hospeda o ambiente de recuperação e orquestra o failover, para que o cliente recupere em uma infraestrutura gerenciada sem precisar construí-la. A Acronis se encaixa nessa definição. Um servidor de recuperação inicializa em sua nuvem a partir de um runbook.

Comet, MSP360 e produtos de backup semelhantes usam rótulos de recuperação de desastres em suas páginas de marketing, com o MSP360 indo até “DRaaS” e “Cloud DR”, para descrever uma coisa diferente: uma restauração manual de uma imagem de disco para uma máquina virtual ou instância em nuvem que o cliente provisiona e opera. A capacidade é real e a lista de destinos é ampla, mas a orquestração é o operador. Um comprador que lê “DRaaS” deve verificar se o produto vem com um motor de failover (servidor de recuperação, runbook, failover de teste) ou se “DR” é o recurso de restauração do produto de backup sob um rótulo de marketing.

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.

Adicionar como fonte preferencial

Metodologia do benchmark de recuperação de desastres

O benchmark mede recuperação de desastres, não throughput de backup, então cada produto executou o mesmo ciclo de recuperação: instalar o agente, capturar uma imagem limpa de um servidor ativo, desencadear um desastre nesse servidor, recuperá-lo em uma máquina separada e verificar o estado recuperado em relação a uma linha de base conhecida. Os tempos de backup de imagem são relatados como tempo decorrido, não throughput.

Ambiente de teste

As origens foram dois servidores em nuvem, um Windows Server 2022 e um Ubuntu 24.04, cada um VPS em nuvem com disco de 75 GB. Os destinos de recuperação foram servidores em nuvem separados da mesma classe (e, para a Acronis, a própria nuvem do fornecedor).

Cada origem executou uma carga de trabalho determinística para que a recuperação pudesse ser verificada byte a byte. A carga de trabalho era um pequeno serviço web respondendo /health com HTTP 200, uma tabela de banco de dados com 10.000 linhas e soma de verificação fixa conhecida, 50 arquivos determinísticos e um manifesto de linha de base SHA-256 de todos eles. Como a carga de trabalho é idêntica em cada execução, “o estado exato pré-desastre voltou?” é uma verificação de sim ou não, não uma questão de julgamento.

Protocolo de desastre e recuperação

O desastre foi uma simulação de ransomware controlada e reversível, não malware real. No T0, ele codificou os arquivos da carga de trabalho em base64 em O desastre foi uma simulação de ransomware controlada e reversível, não malware real. No T0, ele codificou os arquivos da carga de trabalho em base64 em cópias .locked e excluiu os originais, sobrescreveu cada linha do banco de dados com um marcador ENCRYPTED_BY_RANSOMWARE_SIM e deixou uma nota de resgate. O sistema operacional permaneceu ativo por design, e os dados foram corrompidos, para que a recuperação pudesse ser conduzida a partir do ponto de recuperação do fornecedor, e não de um host travado.

A recuperação seguiu um protocolo fixo de carimbos de data/hora:

• T0, desastre declarado (o relógio começa aqui).
• T1, o operador aciona o failover (um clique no runbook para a Acronis, a primeira ação de restauração manual para os outros).
• T3, a VM recuperada chega ao login.
• T4, a aplicação responde (porta aberta, health 200).
• T5, o serviço recuperado é acessível a partir de um cliente externo, que é o RTO de negócio principal: RTO = T5 – T1.
• T6, a integridade dos dados é confirmada recalculando o manifesto SHA-256 e a soma de verificação do banco de dados em relação à linha de base e confirmando que não restam arquivos .locked nem nota de resgate.

Os tempos vêm de duas fontes, não de um cronômetro. O console do fornecedor fornece T1 a T4 (o log de atividades ou de tarefas), e uma sonda externa de uma máquina separada fornece T5.

Os tempos de recuperação são relatados com precisões diferentes de propósito. A Acronis recupera com uma única ação de runbook automatizada, então seu tempo de ponta a ponta é uma janela limpa e repetível; ela executou dois testes de failover consecutivos e a tabela relata a média. As recuperações manuais de restore-to-VM (Comet e MSP360) são procedimentos de múltiplas etapas em que o operador provisiona um destino, restaura a imagem e reconfigura a rede manualmente, portanto o tempo de ponta a ponta depende do operador e é relatado como uma faixa, não como um número único. As partes apenas de máquina dessas recuperações são precisas (a gravação da imagem de disco do Comet levou cerca de dois minutos, e o motor de restauração do MSP360 produziu a imagem inicializável em cinco a seis minutos), mas o procedimento completo está limitado ao operador.

Metodologia de pontuação

Sete dimensões são pontuadas de 0 a 100 e ponderadas. A profundidade da automação de failover vale 20%, a capacidade de failover de teste 10%, o RTO de ponta a ponta 20%, o RPO 10%, o failback e a reproteção 10%, a conectividade e a flexibilidade de rede 10% e o alcance de destinos de DR 20%. Cada dimensão é relatada separadamente; o total ponderado é um valor informativo arredondado para a dezena mais próxima.

Windows e Linux são pontuados como subpontuações separadas e calculados pela média. Um produto que não suporta recuperação de desastres em um sistema operacional pontua zero nessa subpontuação, com a lacuna citada como uma descoberta em vez de ficar em branco, razão pela qual a recuperação apenas no Windows do MSP360 fica em média com cerca de metade da subpontuação do Windows.

Recursos que um produto não tem são pontuados por ausência e citados (por exemplo, a falta de um motor de failover no Comet e no MSP360 zera as dimensões de automação e failover de teste). “Por ausência” significa que o recurso não existe, confirmado no produto, em vez de uma dimensão não testada.

Pontuações por categoria

As pontuações são a média das subpontuações de Windows e Linux. Acronis e Comet suportam recuperação de desastres nos dois sistemas operacionais, então a média deles é igual à pontuação por sistema operacional. O MSP360 suporta recuperação baseada em imagem no Windows, não no Linux, então a subpontuação Linux é 0 e cada dimensão é reduzida à metade.

A diferença entre a Acronis e os outros dois se concentra em três dimensões: automação de failover (DR1), failover de teste (DR2) e conectividade (DR6). São as dimensões que um motor de DRaaS genuíno oferece e um produto de backup não oferece. Somente essas três colunas respondem por 38 pontos da vantagem da Acronis sobre o Comet.

O alcance de destinos não é onde os produtos se diferenciam. A Acronis e o MSP360 alcançam, cada um, seis dos sete tipos de destino, e o Comet cinco, mas os conjuntos são diferentes: a Acronis tem sua nuvem gerenciada, AWS EC2 (migração documentada de restore-to-EC2), Azure, hipervisores locais, cross-region e cross-cloud, faltando apenas o Google Compute Engine; o MSP360 não tem nuvem gerenciada, mas alcança nativamente as três nuvens públicas, AWS, Azure e Google Compute Engine, além de hipervisores locais. O produto mais fraco em automação iguala, assim, o mais forte em alcance bruto, e esse é o ponto: a diferença que decide o benchmark é automação, não amplitude.

A coluna reduzida à metade do MSP360 é um artefato da cobertura de sistemas operacionais, não de uma recuperação Windows mais fraca. Apenas no Windows, o MSP360 marca os mesmos 70 no RTO de ponta a ponta que o Comet no Linux, porque ambos executam a mesma classe de restore-to-VM manual. A média entre sistemas operacionais cai para 21 porque o MSP360 não consegue fazer recuperação baseada em imagem no Linux.

Limitações e escopo

O lado da recuperação de desastres foi testado em máquinas virtuais em nuvem sem virtualização aninhada, portanto qualquer recurso que exija um hipervisor local (a verificação de restauração do Hyper-V do MSP360, alvos de replicação locais) foi avaliado pela documentação e pela interface do produto, e não executado. A dimensão de conectividade foi exercitada de forma prática no modo somente nuvem; os modos de VPN e IPsec foram avaliados pelo console e pela documentação.

Leitura adicional

• Benchmark de software de backup: Acronis vs NinjaOne vs Comet vs MSP360
• Top 7 SaaS soluções de backup
• Google Workspace backup: NinjaOne vs Acronis vs CloudAlly

Cite esta pesquisa

Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Benchmark de recuperação de desastres: Acronis vs Comet vs MSP360}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/disaster-recovery-solutions}},
  note   = {AIMultiple. Acessado em 4 Agosto 2026}
}

Ekrem Sarı

Pesquisador de IA

Siga-nos

Ekrem é Pesquisador de IA e Cientista de Dados na AIMultiple. Ele projeta e executa benchmarks práticos para sistemas de IA e LLM.

Ver perfil completo

Seja o primeiro a comentar

Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.

Nome

Endereço de email

Comentário

0/450

Postar comentário