Benchmark de Recuperação de Desastres: Acronis vs Comet vs MSP360
Comparamos o Acronis Cyber Protect Cloud, o Comet Backup e o 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 com a mesma carga de trabalho determinística, um serviço web, uma base de dados de 10.000 linhas e 50 ficheiros, e depois recuperou toda a máquina para um servidor separado após um desastre ao estilo ransomware ter encriptado os dados.
Resultados do benchmark de recuperação de desastres
Produto | Pontuação ponderada | Tempo de restauro | Deteção de failover | Integrações de 3ª parte | Motor de DR |
|---|---|---|---|---|---|
90 | 73 s (Win) / 108 s (Linux) | Automatizada (captura de ecrã por IA) | 6 de 7 destinos | ✓ | |
Comet | 40 | ~15-25 min (Linux) | Nenhuma | 5 de 7 destinos | ✗ |
MSP360 | 20 | ~15-25 min (Win) | Restrita ao Hyper-V | 6 de 7 destinos | ✗ |
O que significa cada coluna:
- Pontuação ponderada: o total da grelha nas sete dimensões, reportado para referência; o benchmark avalia cada dimensão individualmente.
- Tempo de restauro: o tempo de recuperação ponta a ponta (RTO), desde a declaração do failover até o serviço recuperado responder a uma sonda externa.
- Deteção de failover: se o produto consegue executar um failover de teste e confirmar que a máquina recuperada arrancou, desde uma verificação automatizada por captura de ecrã até absolutamente nada.
- Integrações de 3ª parte: quantos dos sete destinos de recuperação (nuvem do fornecedor, AWS, Azure, Google Cloud, hipervisor local, cross-region, cross-cloud) o produto consegue alcançar na recuperação.
- Motor de DR: se o produto orquestra o failover (servidor de recuperação e runbook) ou apenas restaura um backup manualmente.
Consulte a metodologia completa do benchmark de recuperação de desastres para a grelha de pontuação e o protocolo de temporização T0-T6.
As principais conclusões:
- Acronis recuperou o servidor encriptado em 73 segundos no Windows e cerca de 108 segundos no Linux com um único clique no runbook. A carga de trabalho arrancou num servidor novo dentro da nuvem do fornecedor, recebeu um IP público automaticamente e voltou byte a byte exatamente limpo.
- Comet e MSP360 não têm motor de failover. A recuperação é um restauro manual para VM que demorou dezenas de minutos e exigiu um operador em cada passo: provisionar um destino, escrever a imagem de disco, reconfigurar a rede, reiniciar.
- Os três produziram uma recuperação byte a byte exata. O manifesto SHA-256 dos 50 ficheiros e a soma de verificação da base de dados corresponderam à linha de base pré-desastre em todos os casos, portanto a diferença está na velocidade e no esforço do operador, não na integridade dos dados.
Produtos de recuperação de desastres avaliados
Acronis Cyber Protect Cloud
Acronis é o único produto no teste com um motor de failover de recuperação de desastres como serviço. 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. Ganha a sua pontuação na automação, velocidade de recuperação e alcance de destinos, e o seu principal limite é o failback baseado em agente.
Profundidade da automação de failover
Os runbooks orquestram o failover através de passos ordenados, ações paralelas dentro de um passo, verificações de conclusão por ping e porta, barreiras de aprovação manual e runbooks aninhados. O painel de conformidade monitoriza os alvos de RPO, dispositivos elegíveis e quota de pontos de computação. Nenhum outro produto no teste codifica a recuperação em vez de a deixar a cargo de um operador.
Capacidade de failover de teste
O failover de teste não disruptivo arranca o servidor de recuperação numa rede isolada, e o Failover de Teste Automatizado valida um arranque agendado com uma verificação de captura de ecrã por IA. Funcionou em ambos os sentidos, dando um veredito de falha verdadeiro num servidor Linux que ficou bloqueado na recuperação do journal e um sucesso verdadeiro num arranque limpo do Windows.
RTO ponta a ponta
73 segundos no Windows, cerca de 108 segundos no Linux (94 e 121 em dois exercícios). Um clique no runbook levanta o servidor de recuperação, atribui um IP público e serve a aplicação recuperada. O estado recuperado foi byte a byte exato face à linha de base pré-desastre.
RPO
A recuperação utilizou um backup com três a quatro minutos de idade, dentro do limiar de conformidade de RPO. O limiar é configurável de 15 minutos a 14 dias.
Failback e reproteção
Failback delta em quatro fases (planeamento, transferência de dados, comutação, validação) com o servidor na nuvem a permanecer ativo durante a transferência. O regresso ao hardware original requer suporte de arranque e uma reproteção manual.
Conectividade e flexibilidade de rede
O modo apenas nuvem não necessita de appliance VPN. OpenVPN site-to-site, IPsec multi-site, VPN ponto-a-site, IP público por servidor e DNS personalizado estão todos disponíveis. Não existe reencaminhamento automático de registo A de DNS público integrado.
Alcance de destinos de DR
Seis de sete destinos. Um site de DR gerido na nuvem Acronis ou Azure, Instant Restore para VMware e Hyper-V locais, recuperação para hardware físico dissimilar e uma migração documentada de restauro para EC2 para uma conta AWS própria do cliente. O failover orquestrado propriamente dito é executado na nuvem Acronis ou Azure, portanto o EC2 é alcançado por restauro manual em vez de failover automatizado. Apenas o Google Compute Engine não tem caminho documentado.
Uma nota de fiabilidade surgiu dos exercícios. A recuperação limpa e byte a byte exata foi comprovada duas vezes, no primeiro exercício (um RTO de 94 segundos com uma verificação de integridade aprovada) e no failover de teste não disruptivo. O segundo exercício revelou duas armadilhas de ponto de recuperação, nenhuma delas culpa do motor de recuperação. Um ponto capturado enquanto a origem estava a meio de um reset arrancou para um estado de recuperação de journal bloqueado e teve de ser refeito. Parar esse failover auto-retomou o backup da origem, que capturou a origem ainda encriptada, portanto a repetição arrancou a tempo mas caiu nesse ponto encriptado mais recente. O servidor de recuperação não é melhor do que o ponto de recuperação que está por trás dele, portanto 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 ganhou os seus pontos no caminho de restauro manual para VM e na amplitude de destinos de restauro. O seu restauro de imagem de disco funciona. No benchmark, trouxe de volta um servidor Ubuntu atingido por ransomware, byte a byte exato e acessível externamente, num novo anfitrião.
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 ponta a ponta. O próprio guia de recuperação de desastres do Comet não descreve um failover de carga de trabalho; cobre a proteção da própria consola do Comet com replicação e o re-registo de um agente novo após a perda de um dispositivo cliente.
Capacidade de failover de teste
Nenhuma. A opção "Simular apenas restauro" do assistente de restauro é uma simulação que não arranca uma máquina, portanto não há failover de teste para pontuar.
RTO ponta a ponta
A escrita da imagem de disco para o disco de um servidor novo demorou cerca de dois minutos, mas o procedimento completo (arranque de recuperação, instalação do agente, restauro para dispositivo físico, reescrita de rede, reinicialização) decorreu entre 15 a 25 minutos. O servidor recuperado coincidiu com a soma de verificação pré-desastre e serviu a sua aplicação num novo IP.
RPO
Backups de imagem de disco agendados com incrementais, sem proteção contínua de dados. O primeiro backup do volume raiz ativo preencheu o armazenamento diferencial e precisou que a carga de trabalho fosse colocada em quiescência para uma imagem limpa.
Failback e reproteção
O failback é o mesmo restauro manual ao contrário, 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 o MAC correspondente da origem, que reescrevemos manualmente para o endereço do anfitrião de recuperação antes de conseguir ficar online.
Alcance de destinos de DR
Bare metal, Hyper-V, VMware vSphere e Proxmox nativamente; AWS e Azure através de exportação VMDK e VHDX. Uma ressalva surgiu aqui: um restauro para imagem de ficheiro expande para o tamanho total do disco, portanto o disco de origem do mesmo tamanho não pode conter o ficheiro intermédio, o que forçou o caminho de restauro bare metal.
MSP360 Managed Backup
O MSP360 é um produto de backup cuja recuperação de desastres é um restauro manual para VM, e cuja recuperação funciona no Windows, não no Linux. No Windows igualou a classe de recuperação do Comet e arrancou um servidor restaurado em hardware separado. A sua pontuação cross-OS é baixa porque o seu agente Linux não tem backup de imagem, portanto metade do benchmark (recuperação Linux) pontua zero. As sub-pontuações abaixo são para Windows; o total cross-OS é a média dos números do Windows com um zero no Linux.
Profundidade da automação de failover
Sem motor, sem runbook, sem servidor de recuperação. As designações "DRaaS" e "Cloud DR" nas suas páginas de produto resumem-se a um restauro manual para VM.
Capacidade de failover de teste
A funcionalidade Executar Verificação de Restauro arranca a imagem como uma máquina virtual Hyper-V e verifica um início de sessão bem-sucedido, o que é mais do que uma simulação, mas precisa de Hyper-V local (ausente nos anfitriões de teste na nuvem) e valida um backup em vez de fazer failover para um site de recuperação.
RTO ponta a ponta
Restaurámos uma imagem de disco completo com conversão GPT para BIOS/MBR, escrevemo-la para um servidor na nuvem separado, arrancámos o Windows no novo anfitrião e alcançámos uma sonda de saúde externa byte a byte exata e limpa. O motor de restauro produziu a imagem inicializável em cinco a seis minutos; o resto foi mover a imagem, arrancá-la e uma correção manual de rede. Ponta a ponta, o restauro bare-metal para VM foi um procedimento manual de várias etapas de 15 a 25 minutos, a mesma classe da recuperação Linux do Comet. Um restauro mais simples no local apenas dos dados encriptados, com o servidor ainda em execução, demorou cerca de 10 minutos.
RPO
Backups de imagem agendados com incrementais de monitorização de blocos alterados, sem proteção contínua de dados.
Failback e reproteção
Restauro completo manual de volta para a origem, sem sincronização delta, sem reproteção automatizada.
Conectividade e flexibilidade de rede
Sem rede de DR. O servidor restaurado arrancou com o IP estático da máquina de origem e ficou inacessível até definirmos o endereço correto através da consola out-of-band.
Alcance de destinos de DR
Disco físico, Hyper-V, VMware vSphere e VirtualBox, mais as três nuvens públicas através de opções nativas do assistente de restauro: Restaurar para Amazon EC2, Restaurar para VM do Azure e Restaurar para Instância Google Cloud (a exportação de imagem para AWS VM Import é a alternativa indireta). O restauro nativo para Google Cloud faz do MSP360 o único produto no teste que alcança o Google Compute Engine, portanto em contagem bruta de destinos empata com a Acronis e supera o Comet. Falta-lhe apenas a nuvem de DR gerida pelo fornecedor, que não tem nenhuma. A conversão GPT para BIOS/MBR que fez o restauro bare metal arrancar num anfitrião BIOS é uma peça útil da amplitude.
A lacuna do Linux é a limitação decisiva. O agente Linux do MSP360 faz apenas backup ao nível de ficheiros, sem imagem de disco, portanto não há imagem de sistema inicializável e não há restauro para 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 funcionalidades
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 para a sua própria nuvem, Azure, anfitriões VMware e Hyper-V locais, e para o AWS EC2 de um cliente através de uma migração documentada de restauro para EC2, faltando apenas o Google Compute Engine. O MSP360 não tem nuvem gerida mas suporta as três nuvens públicas nativamente (o seu assistente de restauro oferece Restaurar para EC2, VM do Azure e Instância Google Cloud), tornando-o o único produto aqui que suporta o Google Compute Engine.
O Comet alcança AWS e Azure exportando um VMDK ou VHDX e importando-o, sem nuvem gerida e sem caminho para Google Cloud. A Acronis e o MSP360 alcançam cada um seis dos sete tipos de destino e o Comet cinco. Nenhum inclui uma integração integrada de failover de DNS de terceiros, como um reencaminhamento automático de registo ao estilo Cloudflare; a Acronis fornece DNS personalizado e modos VPN, e nos produtos manuais, a rede da máquina recuperada é configurada manualmente.
Rede e failback
Conclusões dos testes de recuperação de desastres
Reconfiguração de rede após um restauro manual
Em ambos os produtos manuais, o servidor recuperado arrancou com o IP estático da máquina de origem, não com o do anfitrião de recuperação, e ficou inacessível na rede até um operador o corrigir. O endereço reside dentro da imagem de disco, portanto viaja com o restauro. No Comet (Linux) reescrevemos a configuração do netplan no ambiente de recuperação; no MSP360 (Windows) iniciámos sessão no servidor arrancado através da consola da nuvem e definimos o IP estático manualmente. Um DRaaS trata disto como parte do failover; um restauro manual não.
Qualidade do ponto de recuperação e fiabilidade do failover
O RTO de negócio ponta a ponta mediu 94 segundos no primeiro exercício de failover Linux, contra um ponto de recuperação com cerca de 3 minutos de idade. O failover do Windows devolveu 73 segundos em duas execuções com variância zero. O Exercício 1 e o failover de teste não disruptivo passaram cada um uma verificação de integridade T6 byte a byte exata, sem ransomware transportado para o sistema recuperado.
Os dois itens que surgiram no segundo exercício Linux foram um ponto de recuperação capturado a meio de um reset que arrancou para um bloqueio de recuperação de journal e um backup da origem auto-retomado que colocou um ponto ainda encriptado na repetição, ambas falhas de ponto de recuperação e operacionais e não do motor de recuperação. O Failover de Teste Automatizado da Acronis detetou independentemente a mesma condição de recuperação de journal num teste não disruptivo e devolveu um veredito de Falha, um passo de validação ausente no Comet e no MSP360, que ambos pontuaram 0 em failover de teste.
Conversão UEFI para BIOS no restauro
O anfitrião de recuperação do MSP360 arrancou em modo BIOS enquanto a origem era UEFI/GPT. O restauro do MSP360 inclui uma opção "Converter GPT para BIOS/MBR" que reconstrói o layout das partições e a configuração de arranque para o destino BIOS, o que permite que o Windows restaurado arranque em firmware dissimilar. Sem essa conversão, o disco não teria sido inicializável no anfitrião de recuperação. O caminho de restauro para ficheiro do Comet encontrou uma barreira mecânica diferente: a imagem expande para o tamanho total do disco, portanto 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. A recuperação de desastres é o processo orquestrado de colocar uma carga de trabalho novamente em serviço em infraestrutura diferente após a original ser perdida, medido pela rapidez com que o serviço regressa (RTO) e quantos dados são perdidos (RPO).
O benchmark mostra a diferença. Os três produtos produziram um backup correto e um restauro byte a byte exato. Um dos três, a Acronis, transformou esse backup num serviço em execução num servidor novo com um clique em 73 segundos. Os outros dois restauraram os mesmos dados corretamente mas deixaram o failover, o arranque e a rede a cargo de um humano, razão pela qual a sua recuperação demorou dezenas de minutos e as 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 aloja o ambiente de recuperação e orquestra o failover, para que o cliente recupere para uma infraestrutura gerida sem a construir. A Acronis encaixa nesta definição. Um servidor de recuperação arranca na sua nuvem a partir de um runbook.
O Comet, o MSP360 e produtos de backup semelhantes usam rótulos de recuperação de desastres nas suas páginas de marketing, o MSP360 chegando ao ponto de usar "DRaaS" e "Cloud DR", para descrever uma coisa diferente, um restauro manual de uma imagem de disco para uma máquina virtual ou instância na 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 leia "DRaaS" deve verificar se o produto inclui um motor de failover (um servidor de recuperação, um runbook, um failover de teste) ou se "DR" é a funcionalidade de restauro do produto de backup sob um rótulo de marketing.
Adicionar como fonte preferencialMetodologia do benchmark de recuperação de desastres
O benchmark mede a recuperação de desastres, não o débito de backup, portanto cada produto executou o mesmo ciclo de vida de recuperação, instalando o agente, capturando uma imagem limpa de um servidor ativo, desencadeando um desastre nesse servidor, recuperando-o para uma máquina separada e verificando o estado recuperado contra uma linha de base conhecida. As temporizações de backup de imagem são reportadas como tempo decorrido, não como débito.
Ambiente de teste
As origens foram dois servidores na nuvem, um Windows Server 2022 e um Ubuntu 24.04, cada um VPS na nuvem com um disco de 75 GB. Os destinos de recuperação foram servidores na 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 foi um pequeno serviço web que respondia /health com HTTP 200, uma tabela de base de dados de 10.000 linhas com uma soma de verificação fixa conhecida, 50 ficheiros 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 regressou?" é uma verificação de sim ou não, não um juízo de valor.
Protocolo de desastre e recuperação
O desastre foi uma simulação de ransomware controlada e reversível, não malware real. Em T0 codificou em base64 os ficheiros da carga de trabalho para The disaster was a controlled, reversible ransomware simulation, not real malware. At T0 it base64-encoded the workload files into .locked copies and deleted the originals, overwrote each database row with an ENCRYPTED_BY_RANSOMWARE_SIM marker, and dropped a ransom note. The operating system stayed up by design, and the data was corrupted, so the recovery could be driven from the vendor's recovery point rather than from a crashed host.
A recuperação seguiu um protocolo de marcas temporais fixo:
- 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 restauro manual para os outros).
- T3, a VM recuperada atinge o início de sessão.
- T4, a aplicação responde (porta aberta, saúde 200).
- T5, o serviço recuperado está 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 da base de dados contra a linha de base e confirmando que não permanecem ficheiros
.lockedou nota de resgate.
Os tempos provêm de duas fontes, não de um cronómetro. A consola do fornecedor fornece T1 a T4 (o registo de atividades ou tarefas), e uma sonda externa de uma máquina separada fornece T5.
Os tempos de recuperação são reportados com precisões diferentes propositadamente. A Acronis recupera com uma única ação automatizada de runbook, portanto o seu tempo ponta a ponta é uma janela limpa e repetível; executou dois exercícios de failover consecutivos e a tabela reporta a média. As recuperações de restauro manual para VM (Comet e MSP360) são procedimentos de várias etapas onde o operador provisiona um destino, restaura a imagem e reconfigura a rede manualmente, portanto o tempo ponta a ponta depende do operador e é reportado como um intervalo em vez de um valor único. As partes apenas da máquina dessas recuperações são precisas (a escrita da imagem de disco do Comet demorou cerca de dois minutos, e o motor de restauro do MSP360 produziu a imagem inicializável em cinco a seis minutos), mas o procedimento completo está limitado pelo 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 ponta a ponta 20%, o RPO 10%, o failback e reproteção 10%, a conectividade e flexibilidade de rede 10% e o alcance de destinos de DR 20%. Cada dimensão é reportada separadamente; o total ponderado é um valor informativo arredondado para a dezena mais próxima.
Windows e Linux são pontuados como sub-pontuações separadas e calculados em média. Um produto que não suporta recuperação de desastres num sistema operativo pontua zero nessa sub-pontuação, com a lacuna citada como uma conclusão em vez de deixada em branco, razão pela qual a recuperação apenas Windows do MSP360 faz uma média de aproximadamente metade da sua sub-pontuação Windows.
As capacidades que um produto não tem são pontuadas por ausência e citadas (por exemplo, a falta de um motor de failover no Comet e no MSP360 define as suas dimensões de automação e failover de teste como zero). "Por ausência" significa que a funcionalidade não existe, confirmado contra o produto, em vez de uma dimensão deixada por testar.
Pontuações por categoria
As pontuações são a média das sub-pontuações Windows e Linux. A Acronis e o Comet suportam recuperação de desastres em ambos os sistemas operativos, portanto a sua média é igual à sua pontuação por SO. O MSP360 suporta recuperação baseada em imagem no Windows, não no Linux, portanto a sua sub-pontuação Linux é 0 e cada dimensão é reduzida a metade.
A diferença entre a Acronis e os outros dois concentra-se em três dimensões: automação de failover (DR1), failover de teste (DR2) e conectividade (DR6). Estas são as dimensões que um motor de DRaaS genuíno fornece e um produto de backup não fornece. Estas três colunas sozinhas representam 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 diferem: a Acronis carrega a sua nuvem gerida, AWS EC2 (migração documentada de restauro para EC2), Azure, hipervisores locais, cross-region e cross-cloud, faltando apenas o Google Compute Engine; o MSP360 não tem nuvem gerida mas alcança as três nuvens públicas nativamente, AWS, Azure e Google Compute Engine, mais hipervisores locais. O produto mais fraco em automação iguala assim o mais forte em alcance bruto, que é o ponto: a diferença que decide o benchmark é a automação, não a amplitude.
A coluna reduzida a metade do MSP360 é um artefacto da cobertura de sistemas operativos, não de uma recuperação Windows mais fraca. Apenas em Windows, o MSP360 pontua os mesmos 70 em RTO ponta a ponta que o Comet no Linux, porque ambos executam a mesma classe de restauro manual para VM. A média cross-OS cai para 21 porque o MSP360 não consegue fazer recuperação baseada em imagem no Linux de todo.
Limitações e âmbito
O lado da recuperação de desastres foi testado em máquinas virtuais na nuvem sem virtualização aninhada, portanto qualquer funcionalidade que precise de um hipervisor local (verificação de restauro Hyper-V do MSP360, alvos de replicação locais) foi avaliada a partir da documentação e da interface do produto em vez de executada. A dimensão de conectividade foi exercitada em modo apenas nuvem na prática; os modos VPN e IPsec foram avaliados a partir da consola e da documentação.
Leitura adicional
- Benchmark de software de backup: Acronis vs NinjaOne vs Comet vs MSP360
- Top 7 soluções de backup SaaS
- Backup do Google Workspace: 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}
}
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.