Resumo
- A mudança da DRP Cloud México para a marca Ebunti é suportada pelo anúncio oficial, dados atuais de registro de rede e referências recentes de terceiros. O registro público, no entanto, deixa uma importante questão contratual: as páginas legais mais recentes da Ebunti usam “Ebunti México, S.A.P.I. de C.V.” enquanto os registros de rede, universidade e negócios continuam a identificar DRP CLOUD MEXICO SAPI DE CV.
- As evidências operacionais são mais substanciais do que um típico folheto de revendedor. A empresa controla um sistema autônomo mexicano e espaço de endereço, publica telemetria de serviço, mantém uma distinção atual de parceiro Veeam e expõe termos contratuais para infraestrutura, backup, recuperação e proteção Microsoft 365. Nenhum desses fatos, por si só, prova a localização dos dados do cliente, tempo de recuperação ou disponibilidade completa.
- O material público associado à ARTEM não estabelece que a ARTEM seja a DRP Cloud México, Ebunti, uma sucessora ou afiliada. A ARTEM identifica uma empresa diferente, enquanto uma entrada no diretório Odoo meramente identifica a DRP Cloud México como cliente do Odoo. O catálogo em nuvem da ARTEM e as capacidades Odoo não podem, portanto, ser atribuídos com segurança a esta entidade.
- Um comprador pode transformar a incerteza em uma vantagem de aquisição. O teste decisivo é uma prova baseada em contrato que cubra a contraparte legal, os locais de carga de trabalho e backup, os caminhos de rede, o desempenho de restauração e failover, a titularidade do suporte, o escopo de segurança, a escalada de preços e uma saída ensaiada — não uma lista de logotipos de produtos.
Às 2 da manhã, o nome na fatura se torna infraestrutura
Imagine a falha que importa. São 2 da manhã de um domingo. Um ataque de ransomware tornou as máquinas virtuais de produção de um cliente suspeitas, as réplicas mais recentes podem ter copiado o dano e a equipe financeira precisa do ambiente Odoo antes de segunda-feira. O cliente liga para o número em seu runbook. Um engenheiro de suporte solicita o identificador do serviço. O portal da nuvem tem um nome, a nota fiscal tem outro, o revendedor pode ser o dono do relacionamento comercial e uma plataforma de terceiros fornece a maquinaria de recuperação. Nesse momento, a arquitetura de marca deixa de ser uma preocupação de marketing.
Torna-se parte da arquitetura de recuperação.
Essa é a abertura certa para a DRP CLOUD MEXICO SAPI DE CV porque as evidências públicas apoiam a continuidade e também expõem uma lacuna que um comprador sério não deve ignorar. Em umanúncio oficial hospedado no antigo domínio da DRP México, a empresa disse que sua marca comercial se tornaria Ebunti. Apresentou a mudança como uma evolução do mesmo negócio, deu o endereço web da Ebunti e manteve DRP Cloud México SAPI de CV como nome para faturamento e contratos. O aviso também descreveu uma expansão além do México para Panamá e Colômbia. Essa é uma evidência incomumente útil: afirma tanto a ponte operacional quanto a distinção entre uma marca e a empresa por trás dela.
O registro de rede ao vivo fortalece a ponte.O registro da LACNIC para AS265618identifica DRP CLOUD MEXICO SAPI DE CV como titular, enquanto seu contato técnico atual usa um endereço@ebunti.come seu contato de abuso é nomeado para Ebunti. A alocação relacionada45.190.180.0/22carrega a mesma combinação. Isso não é meramente um logotipo antigo redirecionando para um novo site; dados de contato operacionais atuais ligam o nome legal da DRP ao nome operacional da Ebunti em um recurso real da internet. Um relatório de fevereiro de 2026 pela unidade de inovação da Universidad Politécnica de Chiapas descreve da mesma forma uma colaboração com“DRP Cloud México (EBUNTI)”. Juntas, essas fontes apoiam a conclusão de que a Ebunti é a continuação comercial da DRP Cloud México.
Elas não resolvem o quadro legal. Oacordo mestre atual da Ebunti, atualizado em janeiro de 2026, identifica a entidade contratante mexicana como “Ebunti México, S.A.P.I. de C.V.” Seuaviso de privacidade mexicano, atualizado em julho de 2026, usa esse nome e fornece RFC DCM170329Q19. Enquanto isso, os recursos LACNIC ainda nomeiam DRP CLOUD MEXICO SAPI DE CV, alista de convênios de 2025 da Universidade de Guadalajaraainda lista DRP Cloud México SAPI DE CV, e umaentrada de negócios Dunsguidemantém esse nome legal. Os endereços também diferem entre as páginas públicas: o acordo aponta para López Mateos Sur 7000, enquanto o aviso de privacidade aponta para um endereço na Avenida de las Américas.
Há várias explicações inocentes. A empresa pode ter completado uma mudança formal de nome; um documento pode estar desatualizado; um endereço pode ser um escritório operacional e o outro um endereço registrado ou de notificação. As fontes públicas inspecionadas não provam qual explicação está correta. A conclusão prudente é, portanto, mais estreita do que “apenas o logotipo mudou” ou “uma empresa totalmente nova assumiu”. A continuidade comercial e operacional é bem suportada.
A denominação corporativa exata atual, endereço de notificação, propriedade dos recursos de rede e responsabilidade por um contrato DRP existente devem ser verificados para cada compra.
Um arquivo de aquisição deve conter a constancia de situación fiscal atual, nome corporativo e RFC, o pedido assinado, a entidade mostrada nas faturas, a entidade nomeada como processadora de dados, a entidade que opera cada serviço de data center e um cronograma de subcontratados. Se o sistema autônomo e o espaço de endereço permanecerem registrados em DRP Cloud México enquanto a Ebunti México assina o pedido, o contrato deve declarar como o primeiro disponibiliza esses recursos para o segundo e quem é responsável por um incidente de roteamento ou abuso.
Se os nomes se referirem à mesma corporação renomeada, o cliente deve reter o documento que comprova a mudança. Essa papelada não é burocracia em torno da nuvem. É a primeira dependência na nuvem.
O atalho ARTEM falha no teste de identidade
O erro mais tentador ao pesquisar um amplo catálogo de nuvem local é juntar negócios porque seu vocabulário se sobrepõe. “DRP” também é uma abreviação comum para planejamento de recuperação de desastres. Serviços Odoo, backup, segurança cibernética, infraestrutura e linguagem de data center mexicano ocorrem em muitos provedores não relacionados. Um resultado de pesquisa pode, portanto, fazer dois catálogos parecerem um grupo operacional, mesmo quando não existe ponte corporativa.
O material público da ARTEM inspecionado para este artigo não passa nesse teste de ponte. Apágina sobreda ARTEM apresenta Arquitectos de Tecnología Mouan como a empresa por trás da marca, com sua própria história e equipe. Seu site tem usado um número de telefone diferente e presença na Cidade do México em relação ao material da Ebunti. Nenhum aviso corporativo, registro regulatório, anúncio de cliente, página de parceiro ou registro de rede autoritativo encontrado no conjunto de evidências congelado diz que a ARTEM adquiriu a DRP Cloud México, tornou-se Ebunti, opera para ela ou pertence ao mesmo grupo. Referências sobrepostas a nuvem, recuperação de desastres, segurança ou Odoo não são evidência de controle.
A liderança Odoo é ainda mais estreita. O diretório oficial de clientes da Odoo tem uma página intituladaDRP CLOUD MEXICO. A página prova que a Odoo listou a empresa como cliente. Não fornece narrativa de caso, escopo de implementação, status de parceiro, certificação, arquitetura de implantação ou compromisso de suporte. Não pode estabelecer que a DRP Cloud México implementa Odoo para outras empresas, hospeda Odoo de produção sob um serviço definido ou fornece as integrações exibidas pela ARTEM.
Isso importa porque uma carga de trabalho Odoo é um excelente teste de resiliência. Sua disponibilidade depende não apenas da capacidade da máquina virtual, mas também da consistência do PostgreSQL, sincronização do repositório de arquivos, trabalhos agendados, relays de e-mail, DNS, certificados, identidade, integrações de pagamento e impostos e um conjunto recuperável de módulos personalizados. Um provedor que pode restaurar um disco virtual não restaurou necessariamente o processo de negócios. A Ebunti pode ser capaz de fazer mais; a entrada pública do Odoo simplesmente não o prova.
Consequentemente, o catálogo da ARTEM é excluído da avaliação da DRP CLOUD MEXICO SAPI DE CV. Um comprador abordado sob ambos os nomes deve pedir ao vendedor que documente o relacionamento, identifique a entidade contratante e separe o trabalho subcontratado dos serviços operados pela Ebunti. Até que essa evidência exista, o limite seguro é claro: a ponte verificada DRP-Ebunti pode apoiar a diligência de aquisição; uma ponte ARTEM-DRP não pode.
O catálogo da Ebunti descreve componentes, ainda não um sistema operacional
O centro do catálogo público da Ebunti é coerente. Seusite atualagrupa Infraestrutura como Serviço, Backup como Serviço, Recuperação de Desastres como Serviço, Proteção Microsoft como Serviço e armazenamento compatível com S3. Seu acordo mestre define as mesmas famílias e adiciona serviços gerenciados. A ênfase é continuidade, não desenvolvimento de aplicativos de propósito geral: executar máquinas virtuais, copiar dados, preservar conteúdo do Microsoft 365, manter réplicas recuperáveis e ter alguém monitorando o resultado.
Esse centro é reforçado por evidências de fornecedores. A Veeam nomeou a Ebunti como suaparceira de nuvem e provedora de serviços do ano para a América Latina em 2024. Em entrevistas do setor, executivos da Ebunti descrevem o negócio como um fabricante de serviços para parceiros de canal, empacotando backup e recuperação baseados em Veeam com infraestrutura e suporte.A entrevista de 2024 da ITware Latamconecta explicitamente o antigo nome DRP México à Ebunti e descreve BaaS, DRaaS, S3, IaaS e proteção Microsoft.O relato da ITsellerapresenta um design semelhante liderado por parceiros. Essas são entrevistas que trazem afirmações da empresa, não medições independentes, mas a consistência e o reconhecimento da Veeam tornam a proposição operacional crível.
Um fluxo de trabalho plausível do cliente segue. O cliente ou seu revendedor define as cargas de trabalho protegidas. A conectividade transporta o tráfego de backup para um repositório do provedor ou destino de replicação. A VMware fornece parte da camada de virtualização; a Veeam fornece grande parte da política, movimentação, catálogo e maquinário de recuperação; a Ebunti fornece infraestrutura, capacidade, monitoramento, trabalho operacional e um caminho de suporte. Para Microsoft 365, o sistema protegido, autenticação e destinos de restauração são diferentes, mas a ideia comercial é semelhante.
O armazenamento S3 pode ser um destino ou serviço de aplicação. A cotação decide quais peças estão realmente presentes.
A própria documentação da Veeam mostra por que essa distinção importa. Aarquitetura Cloud Connectpermite que um provedor de serviços exponha seus próprios recursos de computação, armazenamento e rede para repositórios hospedados e replicação. OService Provider Consolesuporta monitoramento central e uma hierarquia de provedores, revendedores e empresas gerenciadas. Essas são capacidades úteis, mas a capacidade de uma plataforma não é uma declaração da implantação de um provedor. O comprador ainda precisa saber onde o servidor de gerenciamento está, qual parte detém privilégios administrativos, como os inquilinos são separados, se o repositório é imutável, para onde vão os backups de configuração, quais redes transportam tráfego de gerenciamento e como uma identidade de cliente comprometida é impedida de excluir a cópia de recuperação.
As histórias de sucesso públicas adicionam sinais de escala sem fechar essas lacunas. Ocaso de sucesso da Softtekda Ebunti chama a Ebunti de antiga DRP México e diz que sua proteção atinge 14.000 endpoints em 25 países. Inclui melhorias de desempenho e uma citação do cliente. É material publicado pelo provedor, não um relatório técnico auditado, portanto apoia a existência de um envolvimento substancial, não desempenho universal para outro cliente. Histórias nomeadas envolvendo Softtek, Sí Vale, Carnes Viba e outros parceiros mostram rotas para o mercado; não divulgam domínios de falha, períodos de retenção ou objetivos contratuais de recuperação.
A diferença entre um catálogo e um sistema operacional é a diferença entre substantivos e verbos. “Backup”, “recuperação”, “S3”, “segurança” e “suporte 24/7” são substantivos. Um sistema operacional diz quem detecta um trabalho com falha, quem liga para quem, como uma cópia imutável é selecionada, como a identidade é reconstruída, quanto tempo a restauração leva, quais verificações de aplicação determinam o sucesso e como o cliente sai com dados utilizáveis. A Ebunti tem infraestrutura visível e evidências de parceiros suficientes para justificar o teste desses verbos. O site sozinho não pode respondê-los.
AS265618 é evidência concreta – mas apenas para uma camada
A terceirização de nuvem frequentemente trata as reivindicações de rede como invisíveis. A DRP Cloud México oferece uma exceção: ela tem uma identidade de rede observável externamente. Os registros LACNIC atribuemAS265618a DRP CLOUD MEXICO SAPI DE CV, com status ativo e data de registro original em dezembro de 2019. O registro também registra a alocação 45.190.180.0/22. Os contatos operacionais atuais ligam esses recursos ao domínio Ebunti. Isso é uma evidência mais forte do que uma alegação genérica de “conectividade de classe mundial”.
Observadores de roteamento adicionam uma visão útil, embora não autoritativa, do perímetro.bgp.toolsmostra cinco prefixos IPv4 anunciados, incluindo os quatro /24 dentro da alocação LACNIC e uma rota 38.58.140.0/22. Identifica Alestra e Cogent entre os upstreams.A página AS265618 do IPinforelata da mesma forma cinco prefixos IPv4, nenhum prefixo IPv6 observado e uma autorização de origem de rota válida para a rota 38.58.140.0/22. Esses instantâneos podem mudar, e os coletores de roteamento não veem todas as conexões privadas, então eles são evidência de roteamento público, não um diagrama de rede completo.
O que o sistema autônomo prova? Ele prova que a empresa nomeada tem uma identidade de roteamento de internet durável e que contatos com a marca Ebunti a operam. Dá ao comprador algo concreto para monitorar: mudanças de origem, validação de rota, diversidade upstream e acessibilidade de prefixo. Pode permitir que o provedor controle a política de roteamento mais diretamente do que uma empresa que apenas aluga endereços atrás de uma operadora.
O que ele não prova? Ele não localiza uma carga de trabalho. Um rótulo de geolocalização IP não é um endereço de rack. Ele não mostra se dois upstreams entram em uma instalação através de dutos diversos, se os roteadores de borda compartilham energia, se a proteção contra negação de serviço distribuída está inline, se o tráfego de gerenciamento usa o mesmo caminho, se existem circuitos privados, ou se um site de recuperação de desastres tem conectividade independente. Ele não prova que um cliente receberá endereços portáteis. Ele não prova durabilidade de armazenamento ou disponibilidade de virtualização.
A ausência de um anúncio IPv6 observado também não estabelece que não existe IPv6 interno ou privado, mas é um assunto razoável para uma pergunta de roadmap.
Um comprador deve converter a evidência de rede em um teste ao vivo. Primeiro, liste cada prefixo de produção e recuperação e verifique a origem esperada. Pergunte sobre o status da autorização de origem de rota, processo de carta de autorização e regras de notificação para uma mudança de origem ou upstream. Segundo, trace caminhos dos principais escritórios do cliente, usuários remotos e parceiros de integração chave em vários horários do dia.
Terceiro, force a falha de conectividade acordada: desabilite o túnel ou circuito primário, meça a reconvergência, confirme que o monitoramento percebe o evento e verifique se as cargas de trabalho restauradas são alcançáveis através do caminho secundário. Quarto, distinga internet pública, conectividade privada, replicação e redes de gerenciamento. Um provedor pode ter duas operadoras de internet enquanto um cliente ainda tem um caminho de recuperação frágil.
A demarcação comercial importa tanto quanto a topologia. O SLA da Ebunti exclui falhas além de sua demarcação e muitas causas de terceiros. Se um revendedor fornece o circuito, um firewall de escritório termina o túnel e a Ebunti fornece a máquina virtual, uma única interrupção pode cair entre três filas de suporte. O pedido deve nomear o ponto de demarcação, parte responsável, fonte de evidência e relógio para cada camada. AS265618 é valioso precisamente porque torna uma porção dessa cadeia observável. Deve ser o começo da diligência, não o fim.
Soberania de dados mexicana é um mapa, não um endereço
A Ebunti comercializa infraestrutura no México e Panamá e fala com clientes que buscam serviço local. Isso pode ser valioso. A capacidade local pode reduzir a latência, simplificar visitas ao local e faturamento, manter o conhecimento operacional no mesmo fuso horário e dar ao cliente uma alternativa prática para exportar cada carga de trabalho para uma região distante. Mas “soberano” e “local” não são atributos binários conferidos por um escritório mexicano ou endereço IP. São propriedades de um fluxo de dados específico, arranjo legal e design de controle.
A primeira razão é visível no próprioaviso de privacidade mexicanoda Ebunti. Ele lista provedores de tecnologia incluindo Microsoft, Google, AWS, Veeam e Wasabi, bem como afiliadas da Ebunti na Colômbia, Panamá e Estados Unidos, entre possíveis destinatários ou processadores. Isso não é evidência de que o conteúdo da carga de trabalho do cliente é rotineiramente enviado a todos eles. Avisos de privacidade geralmente cobrem um amplo conjunto de processos de negócios, incluindo vendas, suporte, análise e administração. Isso mostra por que uma promessa genérica de que “os dados permanecem no México” deve ser decomposta.
Para cada serviço, o comprador precisa de uma matriz de localização. Onde estão os discos virtuais primários? Onde estão os blocos de backup, réplicas e cópias de arquivo? Onde estão as chaves de criptografia, bancos de dados do plano de gerenciamento, catálogos de trabalhos, métricas de monitoramento, anexos de tickets, gravações de suporte e logs de administradores? De quais países o pessoal privilegiado pode se conectar? Um fornecedor recebe pacotes de diagnóstico? Um revendedor vê metadados do inquilino? Se a replicação S3 está habilitada, a segunda localização física está no México ou em outro país?
Uma carga de trabalho pode permanecer em Guadalajara enquanto seus dados de suporte, serviço de identidade ou metadados de recuperação cruzam uma fronteira.
A lei de privacidade mexicana torna os controles e a transparência consequentes sem transformar toda carga de trabalho do setor privado em um mandato de localização universal. A atualLei Federal de Proteção de Dados Pessoais em Posse de Particulares, emitida em 2025 e subsequentemente alterada, exige que os responsáveis mantenham medidas de segurança administrativas, técnicas e físicas e notifiquem os titulares dos dados de violações materialmente significativas. Também regula transferências de dados e o aviso de privacidade. Os deveres exatos dependem dos papéis, dados e setor, então um comprador deve obter aconselhamento jurídico para suas circunstâncias, em vez de confiar em um slogan de nuvem. Opadrão de privacidade em nuvem NMX-I-27018 do Méxicooferece um ponto de referência adicional para proteção de dados pessoais em processamento em nuvem pública, mas a existência de um padrão não é evidência de que a Ebunti seja certificada nele.
A segunda razão é a concorrência. Grandes provedores globais agora oferecem regiões mexicanas. AAWS abriu sua região México Centralem janeiro de 2025 com três zonas de disponibilidade. A Microsoft anunciou a operação de suaregião de nuvem México Centralem 2024, e oGoogle Cloud abriu uma região em Querétarono final daquele ano. A substituição local não é mais uma escolha simples entre um provedor mexicano e uma região estrangeira a milhares de quilômetros de distância. É uma escolha entre capacidade física local, diferentes planos de controle, diferentes estruturas de suporte e diferente alavancagem contratual.
A potencial distinção da Ebunti não é, portanto, uma bandeira plantada sobre um servidor. É a possibilidade de combinar infraestrutura mexicana, uma rede local visível, continuidade centrada em Veeam, suporte operacional em espanhol e relacionamentos de canal em um serviço que uma PME pode realmente executar. Isso pode ser mais útil para uma empresa com três administradores do que um vasto catálogo de hiperescala. Também pode introduzir concentração: o mesmo provedor pode operar o ambiente de produção, repositório de backup, site de recuperação e suporte de primeira linha.
Uma falha de controle ou disputa comercial pode então tocar cada cópia.
A solução do comprador não é rejeitar a concentração automaticamente. É definir soberania em declarações testáveis. Os dados de produção serão armazenados em sites mexicanos nomeados. Os dados de backup permanecerão dentro das jurisdições declaradas. O acesso privilegiado será registrado e limitado a locais de suporte nomeados. Os subprocessadores serão listados, as alterações notificadas e as transferências transfronteiriças documentadas. Chaves mantidas pelo cliente serão usadas quando viável. Pelo menos uma cópia de recuperação ou caminho de exportação estará fora do domínio de falha administrativa do provedor.
Essas declarações pertencem ao pedido e ao cronograma de arquitetura. Sem elas, “nuvem mexicana” descreve uma posição de mercado, não um controle.
Recuperação é uma coreografia cronometrada, não um logotipo de backup
A história comercial mais forte da Ebunti é a recuperação, e a recuperação é onde as alegações amplas se tornam mensuráveis. Suapágina de Backup como Serviçodescreve automação baseada em Veeam, trabalhos monitorados, criptografia e opções de restauração. Suapágina de Recuperação de Desastres como Serviçopromove failover, failback e testes automatizados, com recuperação medida em minutos em vez de horas. Suapágina de proteção Microsoftdescreve proteção por usuário para Microsoft 365. Apágina S3promove armazenamento compatível, criptografia e uma alegação de durabilidade muito alta. Essas são descrições úteis de intenção. Não são um design de recuperação para um cliente nomeado.
O design começa com dois relógios. O objetivo de ponto de recuperação pergunta quantos dados recentes podem ser perdidos; o objetivo de tempo de recuperação pergunta quanto tempo um serviço definido pode permanecer indisponível. Ambos exigem um escopo. Um ponto de recuperação de cinco minutos para um banco de dados é sem sentido se seu repositório de arquivos é copiado a cada quatro horas. Um tempo de recuperação de uma hora para máquinas virtuais não é um tempo de recuperação de uma hora para o processo de pedido a pagamento.
O cronômetro pode começar quando a falha ocorre, quando o monitoramento a detecta, quando o cliente abre um ticket de severidade um válido ou quando o provedor aceita uma declaração de desastre. Cada interpretação produz um serviço diferente.
A Veeam fornece blocos de construção críveis, mas sua documentação também expõe escolhas de design. Um provedor Cloud Connect pode oferecer repositórios hospedados e recursos de replicação de sua própria computação, armazenamento e rede. O guia da Veeam sobrerepositórios em nuvemdescreve separação lógica de inquilinos e opções de repositório. A imutabilidade é configurada para um repositório, com consequências para os inquilinos que o compartilham. Aslimitações do Cloud Connectda Veeam identificam restrições em torno de operações de recuperação, appliances de rede e tipos de carga de trabalho protegidos. Seuguia de imutabilidade de armazenamento de objetosexplica que, durante a janela de retenção, os dados protegidos não podem ser simplesmente excluídos – mesmo por pessoal de suporte com acesso.
Essas capacidades criam as perguntas certas para a Ebunti. O repositório de backup primário do cliente é imutável e por quanto tempo? A imutabilidade é aplicada em uma camada de armazenamento fora das credenciais usadas para administrar a produção? Um administrador de inquilino pode encurtar a retenção? Os backups de configuração e as chaves de criptografia são protegidos separadamente? O destino de recuperação já está provisionado ou montado após a declaração? Como os desastres sobrepostos de clientes são priorizados? O planejamento de capacidade assume que um inquilino falha, um site falha ou um evento regional afeta muitos inquilinos?
Quais tipos de carga de trabalho não podem usar o caminho de recuperação anunciado?
Um ambiente Odoo demonstra por que as perguntas são práticas. O teste deve começar com um backup consistente de aplicação do PostgreSQL e do repositório de arquivos, mais o código personalizado exato, configuração, segredos e endpoints de integração exigidos por essa versão. A equipe deve registrar uma transação, introduzir um evento de corrupção controlado e restaurar em uma rede isolada. Os usuários devem fazer login, localizar a transação, criar uma nova, enviar uma mensagem de teste, renderizar um relatório e exercitar uma integração crítica de pagamento ou imposto através de um endpoint de teste seguro.
DNS, certificados e identidade devem então alternar para o ambiente de recuperação. Finalmente, a equipe deve fazer failback sem perder as transações criadas durante a recuperação.
Esse exercício mede mais do que armazenamento. Mede se a central de serviços pode identificar o ponto de restauração correto, se a política de rede segue a carga de trabalho, se um banco de dados e repositório de arquivos permanecem consistentes, se o licenciamento sobrevive com identificadores de hardware alterados, se as listas de permissão de terceiros aceitam os endereços de recuperação e se o cliente tem conhecimento suficiente da aplicação para declarar sucesso. Também revela lacunas de responsabilidade.
Se a Ebunti restaura máquinas virtuais, mas o parceiro Odoo valida módulos, o runbook deve declarar quando o relógio de recuperação para e qual parte é dona da coordenação.
PMEs são particularmente vulneráveis à distinção entre “backup concluído” e “negócio recuperado”. Elas podem não ter uma segunda equipe de infraestrutura, nenhum ambiente de identidade sobressalente e nenhum mapa de aplicação recente. A recuperação gerenciada pode ser valiosa porque fornece repetição e experiência que o cliente não pode reter economicamente. Isso torna a evidência de testes anteriores mais importante, não menos. O comprador deve pedir relatórios de sucesso de trabalho, frequência de teste de restauração, tratamento de exceções, evidência de recuperação, propriedade nomeada de runbook e um relatório de pós-teste de amostra.
Um painel verde de backup é uma entrada. Um exercício bem-sucedido, cronometrado e validado por aplicação é o produto.
A linguagem pública também deve ser separada em durabilidade, disponibilidade e recuperabilidade. A página S3 da Ebunti apresenta uma alegação de “onze noves”, uma formulação comumente associada à durabilidade anual de objetos. Isso não é onze noves de disponibilidade de serviço, não garante que uma aplicação possa listar ou recuperar um objeto em todos os momentos, e não define os domínios de falha por trás de um bucket específico. O pedido deve identificar a métrica aplicável, método de medição, política de replicação, versionamento, imutabilidade, proteção contra exclusão e crédito.
Da mesma forma, uma promessa de recuperar em minutos precisa de um nível de carga de trabalho, volume de dados, condição inicial e resultado de teste. Caso contrário, os verbos mais convincentes no site permanecem aspirações.
A página de status pública muda a conversa de diligência
Muitos provedores regionais publicam pouca evidência operacional. Apágina de status públicada Ebunti é, portanto, um sinal positivo significativo. Ela expõe monitores para infraestrutura mexicana e panamenha, um portal VMware e serviço S3. Um comprador pode ver que a empresa está disposta a colocar pelo menos alguma saúde de serviço em vista pública.
A mesma página torna as alegações simplistas de disponibilidade mais difíceis de aceitar. No congelamento de evidências em 18 de julho de 2026, a página dizia que alguns serviços estavam inativos. Em sua janela de 90 dias exibida, mostrou aproximadamente 99,587% para México POD-1, 96,804% para México POD-2, 98,477% para Panamá POD-1, 99,962% para o portal VMware México e 98,894% para S3 México. A página mostrou uma interrupção de várias horas para México POD-2 em 17 de julho e várias interrupções S3 anteriores.
Dependendo do intervalo do monitor, um resultado de 96,804% em 90 dias corresponde a aproximadamente 69 horas fora do estado bem-sucedido do monitor.
Esses números não devem ser apresentados como resultados de SLA do cliente. Um monitor público pode testar um endpoint, ser afetado por manutenção, permanecer ativo após uma migração de serviço ou falhar enquanto as cargas de trabalho do cliente continuam. Por outro lado, um endpoint verde pode perder latência de armazenamento, falha parcial de inquilino, perda de pacotes, um trabalho de backup com falha ou uma interrupção de aplicação. O arquivo de incidentes públicos da Ebunti não exibiu narrativas de incidentes para vários períodos em que o histórico do monitor mostrou inatividade.
Isso pode refletir a diferença entre eventos de monitor e incidentes declarados, mas a ausência de explicações impede um comprador externo de reconciliar os dois.
Oacordo de nível de serviçocontratual cria outra camada. Ele declara um objetivo de uptime mensal de pelo menos 99,5% para serviços cobertos. No entanto, sua tabela de crédito começa com uma faixa abaixo de 99,9% e em ou acima de 99,0%, uma aparente incompatibilidade que deve ser esclarecida no pedido. Ele define indisponibilidade de forma restrita: todas as instâncias ou tarefas em execução de um cliente devem simultaneamente carecer de conectividade externa. Uma lentidão de armazenamento, uma máquina virtual com falha, uma falha no portal de gerenciamento, um backup perdido ou uma interrupção de aplicação podem não atender a essa definição.
Os créditos são aplicados a pagamentos futuros em vez de reembolsados, e o cliente deve enviar uma reclamação detalhada através do portal de suporte antes do final do segundo ciclo de faturamento após o evento. O SLA exclui eventos além do controle razoável da Ebunti, condições de internet fora de sua demarcação, ações do cliente e de terceiros, algumas tecnologias de terceiros e suspensões permitidas pelo acordo. Os créditos são o único recurso declarado para falha em atingir o nível de serviço. Um cliente que não preserva carimbos de data/hora, tickets e evidências pode experimentar uma interrupção real, mas não receber crédito.
A aritmética dá significado prático ao contrato. Uma meta mensal de 99,5% permite aproximadamente três horas e 39 minutos de indisponibilidade em um mês médio antes que a meta seja perdida. Se isso é adequado depende da aplicação. Um arquivo de folha de pagamento pode tolerar. Um sistema de ponto de venda ou controle logístico pode não. Mais importante, a definição contratual pode contar menos falhas do que o negócio experimenta.
Um comprador capaz não deve usar a página pública para condenar o provedor, nem ignorá-la. Deve pedir à Ebunti que mapeie cada monitor para um serviço e local, explique as condições de julho de 2026, divulgue o tratamento de manutenção programada e forneça relatórios de disponibilidade específicos do cliente. O pedido deve adicionar medidas de componente e carga de trabalho onde necessário: conclusão de trabalho de backup, idade do ponto de restauração, latência de armazenamento, acesso ao portal, atraso de replicação e sucesso de teste de recuperação.
O relatório de incidentes deve declarar gravidade, serviço afetado, cronograma, causa, ação corretiva e se o relógio do SLA correu. Publicar telemetria é a primeira metade da transparência. Explicar o que ela mede e o que mudou é a segunda.
Suporte é parte do plano de controle da Ebunti
Para uma PME, o suporte pode ser a principal razão para escolher a Ebunti em vez de infraestrutura autogerenciada. Uma nuvem global pode fornecer automação profunda e documentação extensa, mas o cliente ainda é dono da arquitetura, monitoramento e grande parte da coordenação de incidentes. A proposta da Ebunti é que um especialista local e seu canal podem absorver mais desse fardo operacional. Seu site apresenta repetidamente cobertura 24 horas, e suas entrevistas de parceiros enfatizam a capacitação de revendedores que podem não ter sua própria plataforma de backup ou recuperação.
O acordo mestre revela o limite mais importante. Um cliente direto contrata com a Ebunti. Um cliente de canal contrata com o parceiro autorizado, e o acordo diz que a Ebunti não tem relacionamento direto de faturamento, garantia ou suporte com esse cliente final, a menos que um acordo separado por escrito diga o contrário. Essa pode ser uma estrutura de distribuição sensata, mas altera a cadeia de recuperação. O cliente final pode acreditar que a Ebunti opera seu serviço enquanto a primeira obrigação contratual recai sobre um revendedor.
Cada pedido deve, portanto, nomear o proprietário do suporte para cada tarefa. Quem monitora trabalhos com falha? Quem recebe um alerta automatizado? Quem pode declarar um desastre? Quem tem permissão para iniciar um failover? Quem valida uma aplicação? Quem coordena Veeam ou VMware? Quem se comunica com o negócio? Um gráfico de responsabilidade deve incluir Ebunti, o revendedor, o cliente, o implementador de software e qualquer provedor de conectividade. Deve identificar um único comandante de incidente para o serviço combinado.
A definição de serviço deve tornar “24/7” mensurável. Uma função de operações com pessoal está monitorando o ambiente continuamente, ou um chamador pode simplesmente abrir um ticket a qualquer hora? Quais são os intervalos de resposta, engajamento e atualização para cada gravidade? A escalada telefônica está disponível? Engenheiros que falam espanhol estão disponíveis durante a noite? Que condições permitem acesso administrativo remoto? Como as mudanças de emergência são aprovadas e registradas? Quando um problema pertence a um fornecedor, a Ebunti permanece responsável pela coordenação ou entrega ao cliente um número de caso?
A implementação merece especificidade igual. O cliente deve receber um resultado de descoberta, mapa de dependências, design de rede e identidade, política de proteção, plano de cópia inicial completa, estimativa de largura de banda, runbook de recuperação e teste de aceitação. Grandes transferências iniciais de backup podem exigir semeadura; a restauração rápida pode exigir mídia física ou capacidade local. A Ebunti anuncia tais opções, mas o pedido deve definir logística, custódia, criptografia e prazos.
Um serviço bem suportado após a ativação pode ainda falhar porque a integração omitiu um banco de dados, módulo personalizado ou credencial de administrador.
A melhor evidência seria operacional: relatórios de amostra anonimizados, demonstração de escalação de ticket, um exercício de recuperação observado e referências de clientes com cargas de trabalho comparáveis. Alegações de pessoal e escritório podem indicar capacidade, mas não provam cobertura. O suporte se torna um plano de controle apenas quando responsabilidades, autoridade e evidências abrangem o provedor, canal e cliente. Caso contrário, é outra entrada de catálogo.
O cartão de preços público é o começo do custo, não o preço
O site da Ebunti inclui uma calculadora incomumente acessível denominada em dólares americanos. No congelamento de evidências, ela mostrava mínimos indicativos de $99 por mês para BaaS, $150 para IaaS, $30 para proteção Microsoft e $25 para S3. Os valores unitários exibidos incluíam $0,23 por gigabyte e $11 por máquina virtual para BaaS; $16 por CPU virtual, $13 por gigabyte de memória, $0,12 por gigabyte de armazenamento de alta velocidade e $10 por IP público para IaaS; $2,90 por usuário para proteção Microsoft; e $0,23 por gigabyte para S3. A própria calculadora avisa que o preço final varia com volume, prazo e requisitos.
Esses números são úteis para orientação, mas a cotação assinada governa. Um comprador precisa saber se a capacidade protegida é medida antes ou após compressão e deduplicação, se o valor de armazenamento é mensal, qual tráfego e operações são cobrados, quais licenças estão incluídas, quantos testes de restauração são cobertos e se suporte, integração ou serviços profissionais são separados. Os números públicos podem, de outra forma, produzir combinações que parecem precisas enquanto escondem os maiores direcionadores de custo.
Oacordo mestrefornece a gravidade comercial. Ele diz que o prazo inicial é de pelo menos 12 meses, a menos que um pedido diga o contrário. Os serviços renovam por períodos iguais, a menos que o aviso seja dado pelo menos 60 dias antes do vencimento. A Ebunti pode aumentar os preços de renovação em até oito por cento com aviso; um aumento maior requer consentimento. Durante um prazo, um cliente pode reduzir um recurso individual em não mais de 20 por cento, e uma redução não reduz o compromisso mínimo. Aumentos são permitidos sujeitos à disponibilidade.
A saída antecipada é mais consequente. Se um cliente rescindir por conveniência, o acordo torna as taxas restantes para o prazo devidas. A Ebunti pode rescindir por conveniência com 30 dias de aviso, enquanto a rescisão do cliente por justa causa está vinculada a condições especificadas e períodos de cura. O não pagamento pode levar à suspensão após 15 dias e aceleração do compromisso restante após 30. Após a rescisão, o cliente tem 30 dias para baixar seu conteúdo antes que o provedor possa excluí-lo.
Para serviços mexicanos, o limite geral de responsabilidade são as taxas pagas nos três meses anteriores, sujeito aos detalhes do acordo e lei aplicável.
Esses termos não tornam o serviço unicamente pouco atraente; compromissos, créditos corretivos e limites de responsabilidade são comuns em contratos de nuvem. Eles criam uma assimetria que deve ser precificada. Um cliente pode dever quase um ano de taxas restantes, ter apenas um mês para extrair dados e recuperar no máximo uma pequena fração do gasto anual para muitas reivindicações. Enquanto isso, mover um grande corpus de backup ou reconstruir um ambiente de recuperação pode levar mais de 30 dias.
A comparação relevante é o custo total de continuidade. Inclui infraestrutura, armazenamento, licenças, transferência de rede, endereços públicos, monitoramento, suporte, semeadura inicial, exercícios periódicos de recuperação, trabalho profissional de emergência e saída. Também inclui mão de obra do cliente. Um serviço gerenciado pode permanecer mais barato do que contratar pessoas suficientes para executá-lo bem, mesmo que seu preço unitário exceda a capacidade bruta de hiperescala. Por outro lado, uma taxa de armazenamento baixa pode ser cara se restaurações, tráfego e assistência forem excluídos.
Antes de assinar, um comprador deve negociar uma tabela de preços completa e três cenários: estado estacionário, um desastre declarado e saída. Deve limitar ou definir aumentos de renovação, alinhar a janela de não renovação com o orçamento, permitir redução quando as cargas de trabalho desaparecerem, estender o período de exportação quando o volume de dados exigir e declarar formatos, largura de banda e assistência. Deve exigir acesso de leitura continuado durante uma disputa de boa-fé de faturamento e proteger os dados de recuperação contra exclusão enquanto uma disputa está sendo resolvida. Preço não é o número ao lado de um gigabyte.
É o custo de reter a escolha operacional.
Distintivos de segurança não podem substituir um cronograma de controle
O site atual da Ebunti exibe sinais de segurança e gerenciamento de serviços, incluindo uma alegação de ISO/IEC 20000-1:2018 e um relacionamento Veeam Platinum. O prêmio regional da Veeam é independentemente visível no site do fornecedor e indica participação significativa nesse ecossistema. Essas são razões legítimas para levar o provedor a sério. Elas respondem a perguntas mais restritas do que um comprador pode supor.
A descrição ISO da ISO/IEC 20000-1:2018diz respeito a requisitos para um sistema de gerenciamento de serviços. Não é o mesmo padrão queISO/IEC 27001, que trata de um sistema de gerenciamento de segurança da informação. Um bom gerenciamento de serviços pode melhorar processos de incidente, mudança e fornecedor, mas um logotipo não diz a um comprador qual entidade legal e locais foram certificados, o escopo dos serviços, o organismo de certificação, o status atual do certificado ou quaisquer exclusões. Nenhum certificado público contendo esses detalhes foi localizado nas fontes congeladas. O comprador deve solicitá-lo e verificar o emissor, acreditação, escopo, titular, validade e vigilância mais recente.
O cronograma de controle deve então abordar os caminhos de ameaça reais do cliente. O acesso administrativo precisa de autenticação multifator resistente a phishing, separação de funções, privilégios limitados no tempo e registro. O pessoal do provedor não deve usar o mesmo domínio de identidade ou credenciais que um evento de ransomware pode comprometer no cliente. A exclusão de backup, alterações de retenção e acesso a chaves devem exigir controles mais fortes do que o trabalho de restauração de rotina. O gerenciamento de rede, gerenciamento de virtualização, armazenamento e orquestração de backup devem ocupar zonas de confiança separadas.
Os logs devem sair do sistema que monitoram e ser retidos tempo suficiente para investigar uma intrusão.
A imutabilidade merece precisão particular. Um recurso compatível com Veeam ou S3 object lock pode resistir à exclusão apenas sob suas condições configuradas. O comprador precisa da janela de retenção, fonte de relógio, configuração de governança ou conformidade, capacidades do administrador, tipo de repositório e evidência de uma tentativa deliberada de exclusão. Deve determinar se um administrador de armazenamento, administrador de nuvem e administrador de backup podem conspirar através de um sistema de identidade. Pelo menos uma cópia deve resistir ao comprometimento dos caminhos de administração de produção e backup comum.
A cláusula de incidente deve conectar operações técnicas a deveres de privacidade mexicanos e obrigações setoriais. Deve definir quando a Ebunti notifica o cliente, que informação se segue, como a evidência é preservada e como os subcontratados participam. O aviso de privacidade promete medidas razoáveis e identifica propósitos amplos de processamento, mas não fornece uma arquitetura de segurança específica do cliente.
Um comprador regulado também pode precisar de resumos de testes de penetração, janelas de remediação de vulnerabilidades, triagem de pessoal, descarte seguro de mídia, resultados de continuidade de negócios e evidência de seguro cibernético.
Os serviços de segurança cibernética criam um limite adicional. Um provedor pode revender ou gerenciar produtos de segurança sem assumir responsabilidade pela segurança geral do cliente. O pedido deve separar a segurança da nuvem da Ebunti de serviços de segurança opcionais fornecidos ao cliente. Deve declarar quais alertas são monitorados, quem investiga, que resposta está incluída e onde os logs residem. Linguagem vaga como “protegido pela tecnologia líder” não pode definir responsabilidade.
A conclusão justa não é que a Ebunti carece de controles. A evidência pública é insuficiente para avaliá-los no nível necessário para uma carga de trabalho crítica. A posição de parceiro, uma rede registrada, telemetria publicada e um padrão de gerenciamento de serviços afirmado são pontos de partida críveis. Um pacote de certificados, workshop de arquitetura, evidência de controle e teste de recuperação ao vivo devem completar o quadro.
Substituição local agora compete com três regiões de hiperescala mexicanas
A chegada da infraestrutura AWS, Microsoft e Google no México muda a questão competitiva da Ebunti. Um comprador pode buscar residência local de dados de uma plataforma global, muitas vezes em várias zonas de disponibilidade, mantendo acesso a extensos serviços de identidade, segurança, análise e automação. A Ebunti não pode vencer meramente dizendo que a nuvem estrangeira é remota.
Ela pode competir em uma unidade diferente de valor. Uma pequena empresa raramente quer uma zona de disponibilidade; ela quer que a folha de pagamento funcione após um ataque. Pode valorizar uma equipe de língua espanhola que conhece seu ambiente VMware, um parceiro de canal que já suporta seus escritórios, um pacote de recuperação previsível e a capacidade de falar com as pessoas que operam a plataforma. O ASN visível, especialização Veeam e mix de serviços da Ebunti podem apoiar essa posição. Sua história Softtek liderada pelo provedor também sugere experiência operando através de parceiros em escala significativa.
A troca é amplitude e concentração. Um hiperescalador oferece mais regiões, automação mais profunda, escolha de marketplace mais ampla e grande investimento em segurança, mas pode deixar arquitetura e controle de custos para o cliente. A Ebunti pode montar e operar uma pilha mais estreita, mas o cliente pode depender de um provedor para infraestrutura, backup, recuperação, rede e escalação. A região local de um hiperescalador ainda pode depender de serviços de gerenciamento globais; um provedor regional ainda pode usar fornecedores globais e suporte transfronteiriço. Nenhum rótulo responde à soberania por si só.
Uma comparação séria deve usar a mesma carga de trabalho e teste de aceitação. Precifique o ambiente de produção, cópia imutável, segundo domínio de falha, monitoramento, suporte e dois exercícios anuais de recuperação em ambos os caminhos. Meça a latência de usuários reais e integrações. Teste a recuperação de credenciais comprometidas. Identifique a pessoa que coordena todo o incidente. Mapeie todas as localizações de dados e gerenciamento. Calcule o tempo e taxas de saída. O design vencedor pode ser Ebunti, um hiperescalador com parceiro gerenciado, ou um híbrido onde um detém produção e outro uma cópia independente.
Esse híbrido merece atenção. Se a Ebunti executa produção e o único repositório de recuperação também está sob sua administração, o cliente tem concentração de provedor. Se a produção está em outro lugar e a Ebunti detém uma cópia protegida e destino de recuperação, a Ebunti se torna uma alternativa local de continuidade em vez de uma substituição completa. Por outro lado, um cliente pode usar infraestrutura Ebunti enquanto exporta uma cópia de recuperação independente. A proposta mais forte de nuvem local pode não ser “substitua tudo”. Pode ser “crie um caminho operacional mexicano recuperável que não compartilhe cada falha com o titular”.
Custos de troca se escondem no caminho de recuperação
A saída de nuvem é muitas vezes reduzida a egress de dados. Para um cliente Ebunti, o custo de troca pode se acumular em mais lugares. Máquinas virtuais podem ser moldadas em torno de VMware. Histórico de backup, catálogos e cadeias de retenção podem depender de Veeam. Política de firewall, endereços públicos, DNS e circuitos de parceiros podem apontar para infraestrutura do provedor. Aplicações compatíveis com S3 podem confiar em comportamento que difere nas bordas entre implementações. Permissões de restauração do Microsoft 365 e escolhas de retenção podem viver em um console gerenciado pelo provedor.
Runbooks de recuperação podem existir principalmente nas cabeças das pessoas que os operam.
O cliente não é dono do AS265618 meramente porque seu serviço usa um endereço anunciado por essa rede. Mover-se pode exigir novos endereços públicos e atualizações para allowlists, DNS, certificados, sistemas de parceiros e regras de segurança. Se um ambiente Odoo tem módulos personalizados, anexos e integrações, exportar apenas seu banco de dados não é suficiente. Se as chaves de criptografia ou metadados de backup estão inacessíveis, uma cópia de blocos de armazenamento pode não ser prontamente recuperável em outro lugar.
O período de download de 30 dias pós-rescisão do acordo torna essas dependências concretas. Um corpus de vários terabytes em um link limitado pode consumir grande parte dessa janela. Restaurar todo um histórico de retenção em outro ambiente Veeam pode exigir versões compatíveis, acesso ao repositório e assistência operacional. Uma política de retenção imutável pode complicar o timing de exclusão mesmo enquanto o cliente precisa de exportações utilizáveis.
O pedido deve, portanto, especificar o que “download” significa: arquivos de backup nativos, imagens de disco virtual, despejos de banco de dados, versões de objetos, exportações de configuração, logs, chaves e documentação.
Um teste de saída deve acontecer antes da produção e anualmente depois. Exporte uma máquina representativa, um banco de dados, um conjunto de dados S3 e um item Microsoft 365 através do caminho pretendido do cliente. Importe-os em um ambiente não controlado pela Ebunti. Meça tempo, taxas e trabalho do provedor. Verifique se o cliente pode obter sua configuração e histórico de recuperação. Confirme como os dados são destruídos com segurança após os períodos de retenção e suspensão legal, e solicite evidência de destruição.
O custo de troca não é inerentemente ruim. Pode ser o resíduo de integração valiosa e experiência gerenciada. Torna-se perigoso quando descoberto durante uma disputa ou interrupção. Um comprador que precifica e ensaia a saída pode aceitar um compromisso longo com olhos abertos. Um que confia em linguagem genérica de portabilidade transferiu mais controle do que a fatura revela.
Uma prova de 30 dias pode transformar as afirmações da Ebunti em um serviço
As evidências apoiam um piloto disciplinado em vez de um sim ou não imediato. Trinta dias é suficiente para testar a cadeia com uma carga de trabalho representativa se o provedor e o cliente prepararem dados, acesso e tomadores de decisão com antecedência.
Durante os dias um a cinco, resolva identidade e escopo. O vendedor deve fornecer o documento corporativo mexicano atual, RFC, endereços de aviso e serviço, prova do relacionamento de nome DRP-Ebunti e uma explicação de qual entidade detém ou opera AS265618. O pedido de rascunho deve identificar as entidades de contratação, faturamento, processamento de dados, operação de infraestrutura e suporte. Se um revendedor estiver envolvido, deve assinar um cronograma de responsabilidade com a Ebunti e o cliente. A ARTEM não deve aparecer no escopo, a menos que um relacionamento documentado e responsabilidade precisa sejam fornecidos.
A mesma fase deve congelar a definição da carga de trabalho. Selecione uma aplicação com banco de dados, arquivos, autenticação, integração externa e objetivo de recuperação significativo. Uma implantação Odoo seria adequada se o cliente realmente a usa, mas Odoo não deve ser incluído meramente porque o diretório lista DRP Cloud México como cliente. Inventarie volume de dados, alteração diária, transações de pico, dependências, portas necessárias, identidades, certificados, versões de software, licenças e etapas de validação de negócios.
Defina o ponto de recuperação e tempo de recuperação do evento de negócio para serviço aceito, não meramente da aceitação do ticket para máquina virtual ligada.
Durante os dias seis a dez, mapeie arquitetura e soberania. A Ebunti deve fornecer um diagrama específico do cliente mostrando produção, repositórios, destinos de replicação, sistemas de gerenciamento, redes, caminhos de suporte e provedores externos. Cada componente deve ter um país, site ou região, operador, controlador legal, estado de criptografia e domínio de falha. O diagrama deve distinguir privilégios do cliente, revendedor, Ebunti e fornecedor. O cliente deve compará-lo com a lista de fornecedores do aviso de privacidade e documentar qualquer dado ou acesso de suporte fora do México.
O teste de rede deve ser executado em paralelo. Verifique a origem pública da rota, autorização de rota, upstreams esperados e endpoints do cliente. Meça latência, jitter, perda de pacotes e throughput de locais reais. Desabilite um túnel primário ou circuito acordado e observe failover, monitoramento e criação de ticket. Confirme se a rede de recuperação usa um caminho independente. Se IPv6 importa para a aplicação ou política de aquisição, obtenha um design suportado ou um roadmap datado em vez de assumir que a observação pública do ASN conta toda a história.
Durante os dias onze a vinte, ataque as suposições de recuperação. Semeie a carga de trabalho, registre a duração do backup de base e confirme que as falhas criam alertas acionáveis. Tente uma alteração de retenção não autorizada e exclusão usando as funções mais propensas a serem comprometidas. Crie transações conhecidas, corrompa ou isole a produção, e exija que a equipe de serviço selecione um ponto de restauração limpo. Recupere em uma rede segregada sem confiar no sistema de identidade de produção com falha. Teste a aplicação, integrações e relatórios contra um script de aceitação escrito.
Em seguida, declare um evento de recuperação. Meça detecção, reconhecimento, engajamento do engenheiro, restauração de dados, comutação de rede, validação de aplicação e aceitação de negócios separadamente. Continue operando tempo suficiente para criar novas transações no site de recuperação. Faça failback e prove que essas transações sobrevivem. Registre o ponto de recuperação e tempo alcançados, cada dependência manual, restrição de capacidade e direito de decisão. Repita uma etapa com falha após mudar uma pessoa no turno de suporte; um runbook que funciona apenas com seu autor não é resiliente.
Durante os dias vinte e um a vinte e cinco, teste suporte e segurança. Abra tickets baixos, altos e críticos através dos canais que o contrato realmente cobre. Escale um após o intervalo prometido. Pergunte ao revendedor e à Ebunti separadamente quem é o dono da próxima ação e compare as respostas. Inspecione os logs de acesso para o exercício de recuperação, atribuições de funções privilegiadas, controles multifator, registros de aprovação e evidência de que os caminhos de gerenciamento e backup estão separados.
Revise o certificado ISO/IEC 20000-1 reivindicado em vez de um logotipo: titular, escopo, locais, emissor, acreditação, validade e vigilância. Obtenha um pacote de controle de segurança apropriado ao risco, incluindo gerenciamento de vulnerabilidades, notificação de incidentes, governança de subcontratados, descarte de mídia e teste de continuidade. Verifique a imutabilidade do repositório com um resultado técnico, não um nome de produto. Se um serviço de monitoramento de segurança cibernética estiver incluído, injete um alerta de teste seguro e siga-o da detecção à comunicação com o cliente.
Durante os dias vinte e seis a trinta, teste economia e saída. Reconcilie a calculadora pública com uma cotação assinada para o consumo medido do piloto. Adicione licenças, transferência, suporte, exercícios de recuperação, integração e trabalho profissional. Precifique um desastre declarado e uma saída antecipada. Peça ao provedor para exportar uma máquina virtual representativa, banco de dados, conjunto de objetos, configuração e pacote de logs. Importe-os fora de sua administração. Meça a taxa de transferência e calcule se o patrimônio completo pode sair dentro da janela contratual.
A folha de aceitação final deve ser binária sempre que possível. A identidade legal reconcilia ou não. As localizações de dados são nomeadas ou não. Uma tentativa de exclusão falhou para a janela imutável acordada ou não. Uma recuperação atendeu ao relógio de negócios ou não. Um segundo caminho de rede funcionou ou não. A cadeia de suporte alcançou um engenheiro responsável ou não. A exportação foi utilizável em outro lugar ou não. A incerteza residual pode então ser precificada, segurada, mitigada com uma cópia independente ou tornada uma condição antes da produção.
Essa prova não é aquisição hostil. Dá à Ebunti uma chance de demonstrar a vantagem operacional que sua marca promete. Um provedor gerenciado local deve ser capaz de superar um catálogo genérico em coordenação, contexto e prática de recuperação. O piloto mede exatamente esses pontos fortes.
As evidências se enquadram em quatro baldes diferentes
Os fatos verificados são significativos. A DRP Cloud México anunciou oficialmente a marca Ebunti. Os registros atuais da LACNIC ligam o nome legal da DRP e os contatos da Ebunti ao AS265618 e a uma alocação de endereço mexicana. Material universitário independente ainda usa DRP Cloud México ao lado de Ebunti. A Veeam reconheceu publicamente a Ebunti como uma parceira líder de provedora de serviços latino-americana. A Ebunti publica termos legais, um SLA, telemetria de serviço e páginas de produto identificáveis. Esses fatos estabelecem um negócio operacional real com recursos de rede e uma proposta focada em continuidade.
As afirmações da empresa formam um segundo balde. A Ebunti descreve vários locais latino-americanos, suporte 24 horas, características de infraestrutura específicas, recuperação rápida, alta durabilidade de objetos, práticas de segurança e resultados de clientes. Seus estudos de caso e entrevistas executivas adicionam detalhes, e alguns carregam contexto de cliente ou fornecedor nomeado. Eles permanecem declarações que devem ser testadas para o serviço do comprador. Uma capacidade em um site ou para um cliente não pode ser presumida em cada cotação.
Inferências fundamentadas formam o terceiro balde. A combinação de uma rede registrada, posição Veeam, estrutura de produto e monitores de status sugere que a Ebunti opera mais do que um catálogo de revenda de papel. Sua abordagem de canal pode dar às PMEs uma rota gerenciada prática para backup e recuperação. Seu controle de várias camadas pode acelerar a coordenação de incidentes. A mesma combinação pode aumentar a concentração e o custo de troca. Essas são conclusões extraídas das evidências juntadas, não declarações diretas de um regulador ou contrato de cliente.
As incógnitas são a agenda de aquisição. A evidência pública não reconcilia a denominação legal mais recente com todos os registros mais antigos e atuais. Não prova um relacionamento ARTEM. Não mostra uma implementação Odoo ou competência de hospedagem. Não divulga locais de data center nomeados e domínios de falha para cada serviço, localizações de dados específicas do cliente, certificação de segurança completa, política de sobresscrição, capacidade de recuperação durante eventos correlacionados, pessoal exato de suporte, narrativas de causa raiz para o histórico de monitor visível ou a portabilidade de uma cadeia de retenção completa.
Manter os baldes separados evita dois erros opostos. Um é descartar um provedor regional porque carece do volume de divulgação de um hiperescalador público. O outro é converter cada badge de parceiro e página de produto em um controle assumido. A Ebunti forneceu evidências suficientes para merecer diligência técnica direta. O comprador deve fornecer a disciplina para manter o que é observado, afirmado, inferido e desconhecido de colapsar em uma história de vendas.
Observe o nome, os monitores e a independência da cópia de recuperação
O primeiro ponto de observação é a identidade corporativa. Faturas futuras, avisos legais, registros LACNIC e anúncios de parceiros devem convergir para uma denominação documentada. Uma atualização formal do titular do registro de rede, ou evidência de que a DRP Cloud México permanece como titular do ativo enquanto a Ebunti México contrata, mudaria a análise de risco. Divergência continuada não é prova de irregularidade, mas aumenta o custo de fazer cumprir a responsabilidade.
O segundo é a transparência operacional. A página de status da Ebunti deve ser observada ao longo do tempo. Os compradores devem procurar disponibilidade melhorada, narrativas de incidentes duráveis e um mapeamento claro entre monitores e serviços contratuais. Um arquivo silencioso ao lado de períodos vermelhos visíveis é menos útil do que uma explicação franca. Mudanças no objetivo de 99,5% do SLA, limite de crédito de 99,9% e definição restrita de conectividade simultânea também seriam materiais.
O terceiro é a maturidade da rede. AS265618 fornece uma base para observar origens de prefixo, autorização de rota, mudanças upstream e adoção de IPv6. Crescimento em prefixos não é automaticamente melhoria, e dois upstreams visíveis não são automaticamente diversidade física. O sinal relevante é se o cliente pode verificar caminhos independentes e resposta documentada a incidentes de roteamento.
O quarto é a independência de recuperação. À medida que o ransomware visa cada vez mais a administração de backup, os compradores devem observar se a Ebunti publica evidências mais claras sobre imutabilidade, identidade isolada, capacidade entre sites e exercícios de recuperação. Uma cópia armazenada em outro rack, mas controlada pelas mesmas credenciais comprometidas, não é um caminho de recuperação independente. Um provedor regional que pode demonstrar separação administrativa e geográfica terá uma resposta mais forte do que um que meramente adiciona armazenamento.
O quinto é a adaptação competitiva. As regiões de hiperescala mexicanas reduzem a força da residência sozinha. A Ebunti precisará mostrar por que sua camada operacional gerenciada, cadeia de suporte e prática de recuperação superam a alternativa do cliente. Documentação clara de serviço, controles específicos do local, preços transparentes e recuperação portátil podem se tornar mais importantes do que adicionar mais logotipos ao catálogo.
Finalmente, observe uma ponte ARTEM documentada. Se um arquivo corporativo confiável, aviso de aquisição, parceria assinada ou declaração de serviço autoritativa eventualmente conectar a ARTEM à DRP Cloud México ou Ebunti, seu papel pode ser avaliado então. Até esse ponto, importar as reivindicações Odoo e nuvem da ARTEM enfraqueceria, em vez de enriquecer, as evidências.
O contrato é o produto de nuvem soberana
DRP CLOUD MEXICO SAPI DE CV não é um nome vazio por trás de um site. A transição DRP-Ebunti é suportada por um anúncio oficial, contatos de rede ao vivo, referências de terceiros e um negócio de recuperação consistente. AS265618, telemetria de serviço pública e reconhecimento Veeam dão aos compradores alças observáveis que muitos provedores locais não expõem.
As perguntas abertas são igualmente reais. O nome legal preciso atual não é consistente em registros públicos. O SLA mede uma condição mais restrita do que a maioria das empresas quer dizer com disponibilidade. O acordo dá à cotação enorme importância e torna compromisso, reivindicações e saída consequentes. A página de status mostra condições que merecem explicação. As páginas de produto descrevem recuperação rápida, armazenamento durável e segurança sem divulgar a arquitetura específica do cliente que torna essas declarações verdadeiras. ARTEM e Odoo não podem ser usados para preencher as lacunas.
Essa combinação produz um veredito mais útil do que uma classificação. A Ebunti é credível o suficiente para testar e insuficientemente transparente para comprar apenas com catálogo. Para uma PME mexicana, sua maior vantagem possível não são CPUs virtuais mais baratas. É um serviço conjunto no qual infraestrutura local, cópias recuperáveis, controle de rede e pessoas que atendem o telefone reduzem o trabalho de sobreviver a uma interrupção. Seu maior risco é que o mesmo serviço conjunto concentra o controle técnico e contratual enquanto deixa os limites implícitos.
Um comprador pode resolver grande parte dessa tensão antes da produção. Reconcilie a contraparte legal. Anexe o mapa de arquitetura e localização de dados. Transforme a linguagem de recuperação em um exercício de aplicação cronometrado. Mapeie AS265618 para o caminho real do cliente. Coloque o revendedor e a Ebunti em um cronograma de responsabilidade. Verifique o escopo de segurança e a separação imutável. Reconcilie o histórico do monitor público com o SLA. Precifique o desastre e ensaie a saída.
Se a Ebunti puder passar nesses testes, a reformulação da marca representará mais do que uma nova apresentação comercial. Descreverá um operador de continuidade mexicano cuja rede local, prática de recuperação e suporte tornam a dependência de nuvem mais gerenciável. Se não puder, o comprador fica com um catálogo amplo e uma mudança de nome. Na aquisição de nuvem soberana, a diferença não é decidida pela página inicial. Está escrita no contrato, demonstrada na sala de recuperação e preservada na cópia que o cliente ainda pode restaurar depois que o provedor não está mais lá.