Resumen
- El cambio de DRP Cloud México a la marca Ebunti está respaldado por el anuncio oficial de la empresa, los datos actuales de registro de red y referencias recientes de terceros. Sin embargo, el registro público deja una importante cuestión contractual: las páginas legales más recientes de Ebunti utilizan "Ebunti México, S.A.P.I. de C.V." mientras que los registros de redes, universidades y empresas siguen identificando a DRP CLOUD MEXICO SAPI DE CV.
- La evidencia operativa es más sustancial que el folleto típico de un revendedor. La empresa controla un sistema autónomo mexicano y espacio de direcciones, publica telemetría de servicios, mantiene una distinción actual como socio de Veeam y expone términos contractuales para infraestructura, respaldo, recuperación y protección de Microsoft 365. Ninguno de esos hechos, por sí solo, prueba la ubicación de los datos de un cliente, el tiempo de recuperación o la disponibilidad de extremo a extremo.
- El material público asociado con ARTEM no establece que ARTEM sea DRP Cloud México, Ebunti, un sucesor o un afiliado. ARTEM identifica una empresa diferente, mientras que una entrada del directorio de Odoo simplemente identifica a DRP Cloud México como cliente de Odoo. Por lo tanto, el catálogo cloud de ARTEM y las capacidades de Odoo no pueden atribuirse de manera segura a esta entidad.
- Un comprador puede convertir la incertidumbre en una ventaja de adquisición. La prueba decisiva es una prueba respaldada por contrato que cubra la contraparte legal, las ubicaciones de las cargas de trabajo y las copias de seguridad, las rutas de red, el rendimiento de restauración y conmutación por error, la titularidad del soporte, el alcance de la seguridad, la escalación de precios y una salida ensayada, no una lista de logotipos de productos.
A las 2 a. m., el nombre de la factura se convierte en infraestructura
Imagínese el fallo que importa. Son las 2 a. m. de un domingo. Un evento de ransomware ha puesto bajo sospecha las máquinas virtuales de producción de un cliente, las réplicas más recientes pueden haber copiado el daño y el equipo de finanzas necesita su entorno de Odoo antes del lunes. El cliente llama al número en su manual de operaciones. Un ingeniero de soporte solicita el identificador del servicio. El portal cloud tiene un nombre, la factura fiscal tiene otro, el revendedor puede ser el dueño de la relación comercial y una plataforma externa proporciona la maquinaria de recuperación.
En ese momento, la arquitectura de marca deja de ser una preocupación de marketing. Se convierte en parte de la arquitectura de recuperación.
Esa es la introducción correcta para DRP CLOUD MEXICO SAPI DE CV, porque la evidencia pública respalda la continuidad y al mismo tiempo expone una brecha que un comprador serio no debería ignorar. En unanuncio oficial alojado en el antiguo dominio de DRP México, la empresa declaró que su marca comercial se convertiría en Ebunti. Presentó el movimiento como una evolución del mismo negocio, dio la dirección web de Ebunti y mantuvo a DRP Cloud México SAPI de CV como el nombre para facturación y contratos. El aviso también describía una expansión más allá de México hacia Panamá y Colombia. Esa es una evidencia inusualmente útil: establece tanto el puente operativo como la distinción entre una marca y la empresa detrás de ella.
El registro de red activo fortalece el puente. Elregistro de LACNIC para AS265618identifica a DRP CLOUD MEXICO SAPI DE CV como el registrante, mientras que su contacto técnico actual utiliza una dirección de@ebunti.comy su contacto de abuso se llama Ebunti. Laasignación 45.190.180.0/22relacionada lleva la misma combinación. Esto no es simplemente un logotipo antiguo que redirige a un nuevo sitio web; los datos de contacto operativo actual vinculan el nombre legal de DRP al nombre operativo de Ebunti en un recurso de Internet real. Un informe de febrero de 2026 de la unidad de innovación de la Universidad Politécnica de Chiapas describe asimismo una colaboración con"DRP Cloud México (EBUNTI)". Juntas, esas fuentes respaldan la conclusión de que Ebunti es la continuación comercial de DRP Cloud México.
No resuelven el panorama legal. Elacuerdo maestro actualde Ebunti, actualizado en enero de 2026, identifica a la entidad contractual mexicana como "Ebunti México, S.A.P.I. de C.V." Suaviso de privacidad mexicano, actualizado en julio de 2026, utiliza ese nombre y proporciona el RFC DCM170329Q19. Mientras tanto, los recursos de LACNIC todavía nombran a DRP CLOUD MEXICO SAPI DE CV, lalista de acuerdos 2025 de la Universidad de Guadalajaratodavía enumera a DRP Cloud México SAPI DE CV, y unaentrada comercial de Dunsguideconserva ese nombre legal. Las direcciones también difieren entre las páginas públicas: el acuerdo apunta a López Mateos Sur 7000, mientras que el aviso de privacidad apunta a una dirección en Avenida de las Américas.
Hay varias explicaciones inocentes. La empresa puede haber completado un cambio de nombre formal; un documento puede estar desactualizado; una dirección puede ser una oficina operativa y la otra una dirección registrada o de notificación. Las fuentes públicas inspeccionadas no prueban qué explicación es correcta. Por lo tanto, la conclusión prudente es más estrecha que "solo cambió el logotipo" o "una empresa completamente nueva tomó el control". La continuidad comercial y operativa está bien respaldada.
La denominación corporativa exacta actual, la dirección de notificación, la propiedad de los recursos de red y la responsabilidad por un contrato DRP existente deben verificarse para cada compra.
Un archivo de adquisición debe contener la constancia de situación fiscal actual, el nombre corporativo y el RFC, la orden firmada, la entidad que aparece en las facturas, la entidad nombrada como procesador de datos, la entidad que opera cada servicio de centro de datos y un cronograma de subcontratistas. Si el sistema autónomo y el espacio de direcciones permanecen registrados a nombre de DRP Cloud México mientras Ebunti México firma la orden, el contrato debe declarar cómo el primero pone esos recursos a disposición del segundo y quién es responsable de un incidente de enrutamiento o abuso.
Si los nombres se refieren a la misma corporación renombrada, el cliente debe conservar el documento que prueba el cambio. Ese papeleo no es burocracia en torno a la nube. Es la primera dependencia en la nube.
El atajo de ARTEM falla la prueba de identidad
El error más tentador al investigar un catálogo cloud local amplio es unir empresas porque su vocabulario se superpone. "DRP" también es una abreviatura común de planificación de recuperación ante desastres. Los servicios de Odoo, respaldo, ciberseguridad, infraestructura y el lenguaje de centros de datos mexicanos aparecen en muchos proveedores no relacionados. Por lo tanto, un resultado de búsqueda puede hacer que dos catálogos parezcan un solo grupo operativo incluso cuando no existe un vínculo corporativo.
El material público de ARTEM inspeccionado para este artículo no supera esa prueba de puente. Lapágina "Acerca de" de ARTEMpresenta a Arquitectos de Tecnología Mouan como la empresa detrás de la marca, con su propia historia y equipo. Su sitio ha utilizado un número de teléfono diferente y una presencia en la Ciudad de México diferente del material de Ebunti. Ningún aviso corporativo, registro regulatorio, anuncio de cliente, página de socio o registro de red autorizado encontrado en el conjunto de evidencia congelada dice que ARTEM adquirió DRP Cloud México, se convirtió en Ebunti, opera para ella o pertenece al mismo grupo. Las referencias superpuestas a cloud, recuperación ante desastres, seguridad u Odoo no son evidencia de control.
La pista de Odoo es aún más estrecha. El directorio oficial de clientes de Odoo tiene una página tituladaDRP CLOUD MEXICO. La página demuestra que Odoo enumeró a la empresa como cliente. No proporciona ninguna narrativa de caso, alcance de implementación, estado de socio, certificación, arquitectura de implementación o compromiso de soporte. No puede establecer que DRP Cloud México implemente Odoo para otras empresas, aloje Odoo de producción bajo un servicio definido, o suministre las integraciones que muestra ARTEM.
Esto importa porque una carga de trabajo de Odoo es una excelente prueba de resiliencia. Su disponibilidad depende no solo de la potencia de la máquina virtual sino también de la consistencia de PostgreSQL, la sincronización del almacén de archivos, los trabajos programados, los relés de correo, el DNS, los certificados, la identidad, las integraciones de pago e impuestos, y un conjunto recuperable de módulos personalizados. Un proveedor que puede restaurar un disco virtual no ha restaurado necesariamente el proceso de negocio. Ebunti puede ser capaz de hacer más; la entrada pública de Odoo simplemente no lo demuestra.
En consecuencia, el catálogo de ARTEM se excluye de la evaluación de DRP CLOUD MEXICO SAPI DE CV. Un comprador abordado bajo ambos nombres debe pedir al vendedor que documente la relación, identifique la entidad contratante y separe el trabajo subcontratado de los servicios operados por Ebunti. Hasta que exista esa evidencia, el límite seguro es claro: el puente verificado de DRP a Ebunti puede respaldar la diligencia de adquisición; un puente de ARTEM a DRP no puede.
El catálogo de Ebunti describe componentes, no un sistema operativo
La oferta pública de Ebunti tiene un centro coherente. Susitio web actualagrupa Infraestructura como Servicio, Respaldo como Servicio, Recuperación ante Desastres como Servicio, Protección de Microsoft 365 como Servicio y almacenamiento compatible con S3. Su acuerdo maestro define las mismas familias y agrega servicios gestionados. El énfasis está en la continuidad más que en el desarrollo de aplicaciones de propósito general: ejecutar máquinas virtuales, copiar datos, preservar contenido de Microsoft 365, mantener réplicas recuperables y tener a alguien que supervise el resultado.
Ese centro está reforzado por evidencia del proveedor. Veeam nombró a Ebunti susocio del año en la nube y proveedor de servicios para América Latina en 2024. En entrevistas comerciales, los ejecutivos de Ebunti describen el negocio como un fabricante de servicios para socios de canal, empaquetando respaldo y recuperación basados en Veeam con infraestructura y soporte. Laentrevista de ITware Latam de 2024conecta explícitamente el antiguo nombre de DRP México con Ebunti y describe BaaS, DRaaS, S3, IaaS y protección de Microsoft. Elrelato de ITsellerpresenta un diseño similar liderado por socios. Estas son entrevistas que contienen afirmaciones de la empresa, no mediciones independientes, pero la consistencia y el reconocimiento de Veeam hacen que la propuesta operativa sea creíble.
Un flujo de trabajo plausible del cliente sigue. El cliente o su revendedor define las cargas de trabajo protegidas. La conectividad transporta el tráfico de respaldo a un repositorio del proveedor o destino de replicación. VMware proporciona parte de la capa de virtualización; Veeam proporciona gran parte de la política, movimiento, catálogo y maquinaria de recuperación; Ebunti suministra infraestructura, capacidad, monitoreo, trabajo operativo y una ruta de soporte. Para Microsoft 365, el sistema protegido, la autenticación y los destinos de restauración son diferentes, pero la idea comercial es similar.
El almacenamiento S3 puede ser un destino o un servicio de aplicación. El presupuesto decide qué piezas están realmente presentes.
La documentación de Veeam muestra por qué esta distinción importa. Laarquitectura de Cloud Connectpermite a un proveedor de servicios exponer sus propios recursos de cómputo, almacenamiento y red para repositorios alojados y replicación. LaConsola de Proveedor de Serviciosadmite monitoreo centralizado y una jerarquía de proveedores, revendedores y empresas gestionadas. Estas son capacidades útiles, pero la capacidad de una plataforma no es una declaración de la implementación de un proveedor. El comprador aún necesita saber dónde está el servidor de gestión, qué parte tiene privilegios administrativos, cómo se separan los inquilinos, si el repositorio es inmutable, a dónde van las copias de seguridad de configuración, qué redes transportan el tráfico de gestión y cómo se evita que una identidad de cliente comprometida elimine la copia de recuperación.
Las historias de éxito público agregan señales de escala sin cerrar esas brechas. Elcaso de estudio de Softtekde Ebunti llama a Ebunti el antiguo DRP México y dice que su protección alcanza 14,000 endpoints en 25 países. Incluye mejoras de rendimiento y una cita del cliente. Es material publicado por el proveedor más que un informe técnico auditado, por lo que respalda la existencia de un compromiso sustancial, no el rendimiento universal para otro cliente. Las historias nombradas que involucran a Softtek, Sí Vale, Carnes Viba y otros socios muestran rutas hacia el mercado; no divulgan dominios de falla, períodos de retención u objetivos de recuperación contractuales.
La diferencia entre un catálogo y un sistema operativo es la diferencia entre sustantivos y verbos. "Respaldo", "recuperación", "S3", "seguridad" y "soporte 24/7" son sustantivos. Un sistema operativo dice quién detecta un trabajo fallido, quién llama a quién, cómo se selecciona una copia inmutable, cómo se reconstruye la identidad, cuánto tiempo lleva la restauración, qué verificaciones de aplicación determinan el éxito y cómo el cliente sale con datos utilizables. Ebunti tiene suficiente infraestructura visible y evidencia de socios para justificar probar esos verbos. El sitio web solo no puede responderlos.
AS265618 es evidencia sólida, pero solo para una capa
La adquisición de servicios cloud a menudo trata las afirmaciones de red como invisibles. DRP Cloud México ofrece una excepción: tiene una identidad de red observable externamente. Los registros de LACNICAS265618pertenecen a DRP CLOUD MEXICO SAPI DE CV, con un estado activo y una fecha de registro original de diciembre de 2019. El registro también registra la asignación 45.190.180.0/22. Los contactos operativos actuales vinculan esos recursos al dominio de Ebunti. Esa es una evidencia más sólida que una afirmación genérica de "conectividad de clase mundial".
Los observadores de enrutamiento agregan una visión útil, aunque no autorizada, del perímetro.bgp.toolsmuestra cinco prefijos IPv4 anunciados, incluidos los cuatro /24 dentro de la asignación de LACNIC y una ruta 38.58.140.0/22. Identifica a Alestra y Cogent entre los proveedores de upstream. Lapágina de AS265618 de IPinforeporta de manera similar cinco prefijos IPv4, ningún prefijo IPv6 observado y una autorización de origen de ruta válida para la ruta 38.58.140.0/22. Estas instantáneas pueden cambiar, y los recolectores de enrutamiento no ven cada conexión privada, por lo que son evidencia de enrutamiento público más que un diagrama de red completo.
¿Qué prueba el sistema autónomo? Prueba que la empresa nombrada tiene una identidad de enrutamiento de Internet duradera y que los contactos con la marca Ebunti la operan. Le da al comprador algo concreto para monitorear: cambios de origen, validación de ruta, diversidad de upstream y accesibilidad de prefijo. Puede permitir que el proveedor controle la política de enrutamiento más directamente que una empresa que simplemente alquila direcciones detrás de un operador.
¿Qué no prueba? No localiza una carga de trabajo. Una etiqueta de geolocalización IP no es una dirección de rack. No muestra si dos upstreams ingresan a una instalación a través de conductos diversos, si los enrutadores de borde comparten energía, si la protección contra denegación de servicio distribuida está en línea, si el tráfico de gestión utiliza la misma ruta, si existen circuitos privados, o si un sitio de recuperación ante desastres tiene conectividad independiente. No demuestra que un cliente recibirá direcciones portables. No demuestra durabilidad de almacenamiento o disponibilidad de virtualización.
La ausencia de un anuncio IPv6 observado tampoco establece que no exista IPv6 interna o privada, pero es un tema razonable para una pregunta de hoja de ruta.
Un comprador debe convertir la evidencia de red en una prueba en vivo. Primero, enumere cada prefijo de producción y recuperación y verifique el origen esperado. Pregunte por el estado de la autorización de origen de ruta, el proceso de carta de autorización y las reglas de notificación para un cambio de origen o upstream. Segundo, trace las rutas desde las oficinas principales del cliente, usuarios remotos y socios de integración clave en varios momentos del día.
Tercero, fuerce el fallo de conectividad acordado: deshabilite el túnel o circuito principal, mida la reconvergencia, confirme que el monitoreo nota el evento y verifique que las cargas de trabajo restauradas sean accesibles a través de la ruta secundaria. Cuarto, distinga Internet pública, conectividad privada, replicación y redes de gestión. Un proveedor puede tener dos operadores de Internet mientras un cliente todavía tiene una ruta de recuperación frágil.
La demarcación comercial importa tanto como la topología. El SLA de Ebunti excluye fallas más allá de su demarcación y muchas causas de terceros. Si un revendedor suministra el circuito, un firewall de oficina termina el túnel y Ebunti suministra la máquina virtual, una sola interrupción puede caer entre tres colas de soporte. El pedido debe nombrar el punto de demarcación, la parte responsable, la fuente de evidencia y el reloj para cada capa. AS265618 es valioso precisamente porque hace observable una porción de esa cadena. Debe ser el comienzo de la diligencia, no el final.
La soberanía de datos mexicana es un mapa, no una dirección
Ebunti comercializa infraestructura en México y Panamá y se dirige a clientes que buscan servicio local. Eso puede ser valioso. La capacidad local puede reducir la latencia, simplificar las visitas al sitio y la facturación, mantener el conocimiento operativo en la misma zona horaria y dar al cliente una alternativa práctica a exportar cada carga de trabajo a una región distante. Pero "soberano" y "local" no son atributos binarios conferidos por una oficina mexicana o una dirección IP. Son propiedades de un flujo de datos particular, un arreglo legal y un diseño de control.
La primera razón es visible en el propioaviso de privacidad mexicanode Ebunti. Enumera proveedores de tecnología que incluyen Microsoft, Google, AWS, Veeam y Wasabi, así como afiliados de Ebunti en Colombia, Panamá y Estados Unidos, entre posibles destinatarios o procesadores. Eso no es evidencia de que el contenido de la carga de trabajo del cliente se envíe rutinariamente a todos ellos. Los avisos de privacidad generalmente cubren un conjunto amplio de procesos comerciales, incluyendo ventas, soporte, análisis y administración. Muestra por qué una promesa general de que "los datos permanecen en México" debe descomponerse.
Para cada servicio, el comprador necesita una matriz de ubicaciones. ¿Dónde están los discos virtuales primarios? ¿Dónde están los bloques de respaldo, las réplicas y las copias de archivo? ¿Dónde están las claves de cifrado, las bases de datos del plano de gestión, los catálogos de trabajos, las métricas de monitoreo, los archivos adjuntos de tickets, las grabaciones de soporte y los registros de administradores? ¿Desde qué países puede conectarse el personal privilegiado? ¿Un proveedor recibe paquetes de diagnóstico? ¿Un revendedor ve metadatos del inquilino?
Si la replicación S3 está habilitada, ¿la segunda ubicación física está dentro de México o en otro país? Una carga de trabajo puede permanecer en Guadalajara mientras sus datos de soporte, servicio de identidad o metadatos de recuperación cruzan una frontera.
La ley de privacidad mexicana hace que los controles y la transparencia sean consecuentes sin convertir cada carga de trabajo del sector privado en un mandato de localización universal. La actualLey Federal de Protección de Datos Personales en Posesión de los Particulares, emitida en 2025 y posteriormente modificada, exige que los responsables mantengan medidas de seguridad administrativas, técnicas y físicas y notifiquen a los titulares de los datos sobre violaciones materialmente significativas. También regula las transferencias de datos y el aviso de privacidad. Los deberes exactos dependen de los roles, los datos y el sector, por lo que un comprador debe obtener asesoría legal para sus circunstancias en lugar de confiar en un eslogan cloud. LaNMX-I-27018 de Méxicoofrece un punto de referencia adicional para la protección de datos personales en el procesamiento en nube pública, pero la existencia de una norma no es evidencia de que Ebunti esté certificado bajo ella.
La segunda razón es la competencia. Los principales proveedores globales ahora ofrecen regiones mexicanas.AWS abrió su región México Centralen enero de 2025 con tres zonas de disponibilidad. Microsoft anunció la operación de suregión cloud México Centralen 2024, yGoogle Cloud abrió una región en Querétaromás tarde ese año. La sustitución local ya no es una simple elección entre un proveedor mexicano y una región extranjera a miles de kilómetros. Es una elección entre capacidad física local, diferentes planos de control, diferentes estructuras de soporte y diferente apalancamiento contractual.
Por lo tanto, la posible distinción de Ebunti no es una bandera plantada sobre un servidor. Es la posibilidad de combinar infraestructura mexicana, una red local visible, continuidad centrada en Veeam, soporte operativo en español y relaciones de canal en un servicio que una pyme pueda realmente ejecutar. Eso puede ser más útil para una empresa con tres administradores que un vasto catálogo de hiperescala. También puede introducir concentración: el mismo proveedor puede operar el entorno de producción, el repositorio de respaldo, el sitio de recuperación y el soporte de primera línea.
Un fallo de control o una disputa comercial puede entonces tocar cada copia.
La solución del comprador no es rechazar la concentración automáticamente. Es definir la soberanía en declaraciones comprobables. Los datos de producción se almacenarán en sitios mexicanos nombrados. Los datos de respaldo permanecerán dentro de las jurisdicciones declaradas. El acceso privilegiado será registrado y limitado a ubicaciones de soporte nombradas. Los subprocesadores serán listados, los cambios notificados y las transferencias transfronterizas documentadas. Se utilizarán claves controladas por el cliente cuando sea factible.
Al menos una copia de recuperación o ruta de exportación estará fuera del dominio de fallo administrativo del proveedor. Esas declaraciones pertenecen al pedido y al cronograma de arquitectura. Sin ellas, "nube mexicana" describe una posición de mercado, no un control.
La recuperación es una coreografía cronometrada, no un logotipo de respaldo
La historia comercial más fuerte de Ebunti es la recuperación, y la recuperación es donde las afirmaciones amplias se vuelven medibles. Supágina de Respaldo como Serviciodescribe automatización basada en Veeam, trabajos monitoreados, cifrado y opciones de restauración. Supágina de Recuperación ante Desastres como Serviciopromueve conmutación por error, recuperación y pruebas automatizadas, con recuperación medida en minutos en lugar de horas. Supágina de protección de Microsoftdescribe protección por usuario para Microsoft 365. Lapágina de S3promueve almacenamiento compatible, cifrado y una afirmación de durabilidad muy alta. Estas son descripciones útiles de la intención. No son un diseño de recuperación para un cliente nombrado.
El diseño comienza con dos relojes. El objetivo de punto de recuperación pregunta cuántos datos recientes se pueden perder; el objetivo de tiempo de recuperación pregunta cuánto tiempo puede permanecer no disponible un servicio definido. Ambos requieren un alcance. Un punto de recuperación de cinco minutos para una base de datos no tiene sentido si su almacén de archivos se copia cada cuatro horas. Un tiempo de recuperación de una hora para máquinas virtuales no es un tiempo de recuperación de una hora para el proceso de pedido a cobro.
El cronómetro puede comenzar cuando ocurre el fallo, cuando el monitoreo lo detecta, cuando el cliente abre un ticket válido de severidad uno o cuando el proveedor acepta una declaración de desastre. Cada interpretación produce un servicio diferente.
Veeam suministra bloques de construcción creíbles, pero su documentación también expone opciones de diseño. Un proveedor de Cloud Connect puede ofrecer repositorios alojados y recursos de replicación desde su propio cómputo, almacenamiento y red. La guía de Veeam sobrerepositorios clouddescribe la separación lógica de inquilinos y las opciones de repositorio. La inmutabilidad se configura para un repositorio, con consecuencias para los inquilinos que lo comparten. Laslimitaciones de Cloud Connectde Veeam identifican restricciones en torno a las operaciones de recuperación, dispositivos de red y tipos de carga de trabajo protegidos. Su guía deinmutabilidad de almacenamiento de objetosexplica que, durante la ventana de retención, los datos protegidos no pueden simplemente eliminarse, incluso por personal de soporte con acceso.
Esas capacidades crean las preguntas correctas para Ebunti. ¿Es inmutable el repositorio de respaldo principal del cliente, y por cuánto tiempo? ¿Se aplica la inmutabilidad en una capa de almacenamiento fuera de las credenciales utilizadas para administrar la producción? ¿Puede un administrador de inquilino acortar la retención? ¿Están protegidas las copias de seguridad de configuración y las claves de cifrado por separado? ¿El destino de recuperación ya está aprovisionado o se ensambla después de la declaración? ¿Cómo se priorizan los desastres de clientes superpuestos?
¿La planificación de capacidad asume que falla un inquilino, un sitio o un evento regional que afecta a muchos inquilinos? ¿Qué tipos de carga de trabajo no pueden usar la ruta de recuperación anunciada?
Un entorno Odoo demuestra por qué las preguntas son prácticas. La prueba debe comenzar con una copia de seguridad coherente con la aplicación de PostgreSQL y el almacén de archivos, más el código personalizado exacto, la configuración, los secretos y los endpoints de integración requeridos por esa versión. El equipo debe registrar una transacción, introducir un evento de corrupción controlada y restaurar en una red aislada.
Los usuarios deben iniciar sesión, localizar la transacción, crear una nueva, enviar un mensaje de prueba, generar un informe y ejercitar una integración crítica de impuestos o pago a través de un endpoint de prueba seguro. Luego, el DNS, los certificados y la identidad deben cambiar al entorno de recuperación. Finalmente, el equipo debe revertir sin perder las transacciones creadas durante la recuperación.
Ese ejercicio mide más que el almacenamiento. Mide si la mesa de servicio puede identificar el punto de restauración correcto, si la política de red sigue la carga de trabajo, si una base de datos y un almacén de archivos permanecen consistentes, si las licencias sobreviven a cambios de identificadores de hardware, si las listas de permitidos de terceros aceptan las direcciones de recuperación y si el cliente tiene suficiente conocimiento de la aplicación para declarar éxito. También revela brechas de responsabilidad.
Si Ebunti restaura máquinas virtuales pero el socio de Odoo valida los módulos, el manual de operaciones debe indicar cuándo se detiene el reloj de recuperación y qué parte es propietaria de la coordinación.
Las pymes son particularmente vulnerables a la distinción entre "respaldo completado" y "negocio recuperado". Pueden no tener un segundo equipo de infraestructura, ningún entorno de identidad de repuesto y ningún mapa de aplicación reciente. La recuperación gestionada puede ser valiosa porque proporciona repetición y experiencia que el cliente no puede retener económicamente. Eso hace que la evidencia de pruebas anteriores sea más importante, no menos.
El comprador debe solicitar informes de finalización de trabajos, frecuencia de pruebas de restauración, manejo de excepciones, evidencia de recuperación, propiedad nombrada del manual de operaciones y un informe de prueba posterior a la restauración. Un panel verde de respaldo es un insumo. Un ejercicio exitoso, cronometrado y validado por la aplicación es el producto.
El lenguaje público también debe separarse en durabilidad, disponibilidad y recuperabilidad. La página S3 de Ebunti presenta una afirmación de "nueve nueves", una formulación comúnmente asociada con la durabilidad anual de objetos. Eso no es nueve nueves de disponibilidad de servicio, no garantiza que una aplicación pueda listar o recuperar un objeto en cada momento, y no define los dominios de fallo detrás de un bucket en particular. El pedido debe identificar la métrica aplicable, el método de medición, la política de replicación, el versionado, la inmutabilidad, la protección contra eliminación y el crédito.
De manera similar, una promesa de recuperar en minutos necesita un nivel de carga de trabajo, volumen de datos, condición inicial y resultado de prueba. De lo contrario, los verbos más convincentes en el sitio web siguen siendo aspiraciones.
La página de estado público cambia la conversación de diligencia
Muchos proveedores regionales publican poca evidencia operativa. Lapágina de estado públicade Ebunti es, por lo tanto, una señal positiva significativa. Expone monitores para la infraestructura mexicana y panameña, un portal de VMware y el servicio S3. Un comprador puede ver que la empresa está dispuesta a colocar al menos parte de la salud del servicio en vista pública.
La misma página hace que las afirmaciones simplistas de disponibilidad sean más difíciles de aceptar. En la congelación de evidencia del 18 de julio de 2026, la página decía que algunos servicios estaban caídos. En su ventana de 90 días mostrada, mostró aproximadamente 99.587% para México POD-1, 96.804% para México POD-2, 98.477% para Panamá POD-1, 99.962% para el portal de VMware México y 98.894% para S3 México. La página mostró una interrupción de varias horas para México POD-2 el 17 de julio y varias interrupciones anteriores de S3.
Dependiendo del intervalo del monitor, un resultado del 96.804% en 90 días corresponde aproximadamente a 69 horas fuera del estado exitoso del monitor.
Esas cifras no deben presentarse como resultados de SLA del cliente. Un monitor público puede probar un endpoint, verse afectado por mantenimiento, permanecer activo después de una migración de servicio o fallar mientras las cargas de trabajo del cliente continúan. Por el contrario, un endpoint verde puede perder latencia de almacenamiento, falla parcial de inquilino, pérdida de paquetes, un trabajo de respaldo fallido o una interrupción de aplicación. El archivo de incidentes público de Ebunti no mostró narrativas de incidentes para múltiples períodos en los que el historial del monitor mostró tiempo de inactividad.
Eso puede reflejar la diferencia entre eventos del monitor e incidentes declarados, pero la ausencia de explicaciones impide que un comprador externo concilie ambos.
Elacuerdo de nivel de serviciocontractual crea otra capa. Establece un objetivo mensual de tiempo de actividad de al menos 99.5% para los servicios cubiertos. Sin embargo, su tabla de créditos comienza con una banda por debajo del 99.9% y en o por encima del 99.0%, un aparente desajuste que debe aclararse en el pedido. Define la no disponibilidad de manera estricta: todas las instancias o tareas en ejecución de un cliente deben carecer simultáneamente de conectividad externa. Una desaceleración de almacenamiento, una máquina virtual fallida, un fallo del portal de gestión, un respaldo perdido o una interrupción de aplicación pueden no cumplir con esa definición.
Los créditos se aplican a pagos futuros en lugar de reembolsarse, y el cliente debe presentar un reclamo detallado a través del portal de soporte antes del final del segundo ciclo de facturación después del evento. El SLA excluye eventos más allá del control razonable de Ebunti, condiciones de Internet fuera de su demarcación, acciones del cliente y de terceros, alguna tecnología de terceros y suspensiones permitidas por el acuerdo. Los créditos son el único recurso declarado por incumplimiento del nivel de servicio.
Un cliente que no conserve marcas de tiempo, tickets y evidencia podría experimentar una interrupción real pero no recibir crédito alguno.
La aritmética le da significado práctico al contrato. Un objetivo mensual del 99.5% permite aproximadamente tres horas y 39 minutos de no disponibilidad en un mes promedio antes de que se pierda el objetivo. Que eso sea adecuado depende de la aplicación. Un archivo de nómina puede tolerarlo. Un sistema de punto de venta o control logístico puede no hacerlo. Más importante aún, la definición contractual puede contar menos fallos de los que experimenta el negocio.
Un comprador capaz no debe usar la página pública para condenar al proveedor, ni ignorarla. Debe pedir a Ebunti que mapee cada monitor a un servicio y ubicación, explique las condiciones de julio de 2026, divulgue el tratamiento del mantenimiento programado y proporcione informes de disponibilidad específicos del cliente. El pedido debe agregar medidas de componente y carga de trabajo donde sea necesario: finalización de trabajos de respaldo, antigüedad del punto de restauración, latencia de almacenamiento, acceso al portal, retraso de replicación y éxito de pruebas de recuperación.
El informe de incidentes debe indicar severidad, servicio afectado, cronología, causa, acción correctiva y si el reloj del SLA corrió. Publicar telemetría es la primera mitad de la transparencia. Explicar lo que mide y lo que cambió es la segunda.
El soporte es parte del plano de control de Ebunti
Para una pyme, el soporte puede ser la razón principal para elegir Ebunti sobre la infraestructura autogestionada. Un cloud global puede proporcionar automatización profunda y documentación extensa, pero el cliente aún posee la arquitectura, el monitoreo y gran parte de la coordinación de incidentes. La propuesta de Ebunti es que un especialista local y su canal pueden absorber más de esa carga operativa. Su sitio web presenta repetidamente cobertura de 24 horas, y sus entrevistas con socios enfatizan la habilitación de revendedores que pueden no tener su propia plataforma de respaldo o recuperación.
El acuerdo maestro revela el límite más importante. Un cliente directo contrata con Ebunti. Un cliente de canal contrata con el socio autorizado, y el acuerdo dice que Ebunti no tiene relación directa de facturación, garantía o soporte con ese cliente final a menos que un acuerdo por escrito separado diga lo contrario. Esto puede ser una estructura de distribución sensata, pero cambia la cadena de recuperación. El cliente final puede creer que Ebunti opera su servicio mientras la primera obligación contractual recae en un revendedor.
Por lo tanto, cada pedido debe nombrar al propietario del soporte para cada tarea. ¿Quién monitorea los trabajos fallidos? ¿Quién recibe una alerta automática? ¿Quién puede declarar un desastre? ¿Quién tiene permiso para iniciar una conmutación por error? ¿Quién valida una aplicación? ¿Quién coordina con Veeam o VMware? ¿Quién se comunica con el negocio? Un gráfico de responsabilidades debe incluir a Ebunti, el revendedor, el cliente, el implementador de software y cualquier proveedor de conectividad. Debe identificar un único comandante de incidentes para el servicio combinado.
La definición del servicio debe hacer que "24/7" sea medible. ¿Hay una función de operaciones con personal supervisando el entorno continuamente, o un llamante solo puede abrir un ticket a cualquier hora? ¿Cuáles son los intervalos de respuesta, compromiso y actualización para cada severidad? ¿Está disponible la escalación telefónica? ¿Hay ingenieros de habla hispana disponibles durante toda la noche? ¿Qué condiciones permiten el acceso administrativo remoto? ¿Cómo se aprueban y registran los cambios de emergencia?
Cuando un problema pertenece a un proveedor, ¿Ebunti sigue siendo responsable de la coordinación o le entrega al cliente un número de caso?
La implementación merece igual especificidad. El cliente debe recibir un resultado de descubrimiento, un mapa de dependencias, un diseño de red e identidad, una política de protección, un plan de copia completa inicial, una estimación de ancho de banda, un manual de recuperación y una prueba de aceptación. Las transferencias grandes de respaldo inicial pueden requerir siembra; la restauración rápida puede requerir medios físicos o capacidad local. Ebunti anuncia tales opciones, pero el pedido debe definir logística, custodia, cifrado y tiempo.
Un servicio bien soportado después de la activación aún puede fallar porque la incorporación omitió una base de datos, un módulo personalizado o una credencial de administrador.
La mejor evidencia sería operativa: informes de muestra anonimizados, una demostración de escalación de tickets, un ejercicio de recuperación observado y referencias de clientes con cargas de trabajo comparables. Las afirmaciones de personal y oficina pueden indicar capacidad pero no prueban cobertura. El soporte se convierte en un plano de control solo cuando las responsabilidades, la autoridad y la evidencia abarcan al proveedor, el canal y el cliente. De lo contrario, es otra entrada de catálogo.
La tarjeta de precios pública es el comienzo del costo, no el precio
El sitio web de Ebunti incluye una calculadora inusualmente accesible denominada en dólares estadounidenses. En la congelación de evidencia, mostraba mínimos indicativos de $99 al mes para BaaS, $150 para IaaS, $30 para protección de Microsoft y $25 para S3. Los valores unitarios mostrados incluían $0.23 por gigabyte y $11 por máquina virtual para BaaS; $16 por CPU virtual, $13 por gigabyte de memoria, $0.12 por gigabyte de almacenamiento de alta velocidad y $10 por IP pública para IaaS; $2.90 por usuario para protección de Microsoft; y $0.23 por gigabyte para S3.
La calculadora misma advierte que el precio final varía según el volumen, el plazo y los requisitos.
Estas cifras son útiles para orientación, pero el presupuesto firmado gobierna. Un comprador necesita saber si la capacidad protegida se mide antes o después de la compresión y deduplicación, si la cifra de almacenamiento es mensual, qué tráfico y operaciones se cobran, qué licencias están incluidas, cuántas pruebas de restauración están cubiertas y si el soporte, la incorporación o los servicios profesionales son separados. Los números públicos pueden producir combinaciones que parecen precisas mientras ocultan los mayores impulsores de costos.
Elacuerdo maestroproporciona la gravedad comercial. Dice que el plazo inicial es de al menos 12 meses a menos que un pedido indique lo contrario. Los servicios se renuevan por períodos iguales a menos que se notifique al menos 60 días antes del vencimiento. Ebunti puede aumentar los precios de renovación hasta un ocho por ciento con notificación; un aumento mayor requiere consentimiento. Durante un plazo, un cliente puede reducir un recurso individual en no más del 20%, y una reducción no reduce el compromiso mínimo. Se permiten aumentos sujetos a disponibilidad.
La salida temprana es más consecuente. Si un cliente rescinde por conveniencia, el acuerdo hace que las tarifas restantes para el plazo sean debidas. Ebunti puede rescindir por conveniencia con 30 días de aviso, mientras que la rescisión por causa de un cliente está vinculada a condiciones específicas y períodos de cura. El impago puede llevar a la suspensión después de 15 días y a la aceleración del compromiso restante después de 30. Tras la rescisión, el cliente tiene 30 días para descargar su contenido antes de que el proveedor pueda eliminarlo.
Para servicios mexicanos, el límite general de responsabilidad son las tarifas pagadas en los tres meses anteriores, sujeto a los detalles del acuerdo y la ley aplicable.
Estos términos no hacen que el servicio sea únicamente poco atractivo; los compromisos, los remedios de crédito y los límites de responsabilidad son comunes en los contratos cloud. Sí crean una asimetría que debe valorarse. Un cliente puede deber casi un año de tarifas restantes, tener solo un mes para extraer datos y recuperar como máximo una pequeña fracción del gasto anual para muchos reclamos. Mientras tanto, mover un gran corpus de respaldo o reconstruir un entorno de recuperación puede llevar más de 30 días.
La comparación relevante es el costo total de continuidad. Incluye infraestructura, almacenamiento, licencias, transferencia de red, direcciones públicas, monitoreo, soporte, siembra inicial, ejercicios periódicos de recuperación, trabajo profesional de emergencia y salida. También incluye mano de obra del cliente. Un servicio gestionado puede seguir siendo más barato que contratar suficientes personas para ejecutarlo bien, incluso si su precio unitario supera la capacidad bruta de hiperescala. Por el contrario, una tasa de almacenamiento baja puede ser costosa si las restauraciones, el tráfico y la asistencia están excluidos.
Antes de firmar, un comprador debe negociar una tarjeta de precios completa y tres escenarios: estado estable, un desastre declarado y salida. Debe limitar o definir los aumentos de renovación, alinear la ventana de no renovación con la presupuestación, permitir la reducción cuando las cargas de trabajo desaparezcan, extender el período de exportación cuando el volumen de datos lo requiera y especificar formatos, ancho de banda y asistencia. Debe exigir acceso de lectura continuado durante una disputa de facturación de buena fe y proteger los datos de recuperación de la eliminación mientras se resuelve una disputa.
El precio no es el número junto a un gigabyte. Es el costo de retener la opción operativa.
Las insignias de seguridad no pueden sustituir un programa de control
El sitio actual de Ebunti muestra señales de seguridad y gestión de servicios, incluyendo una afirmación de ISO/IEC 20000-1:2018 y una relación Platinum con Veeam. El premio regional de Veeam es visible independientemente en el sitio del proveedor e indica una participación significativa en ese ecosistema. Estas son razones legítimas para tomar al proveedor en serio. Responden preguntas más estrechas de lo que un comprador puede suponer.
Ladescripción de ISO de ISO/IEC 20000-1:2018se refiere a los requisitos para un sistema de gestión de servicios. No es el mismo estándar queISO/IEC 27001, que aborda un sistema de gestión de seguridad de la información. Una buena gestión de servicios puede mejorar los procesos de incidentes, cambios y proveedores, pero un logotipo no le dice a un comprador qué entidad legal y sitios fueron certificados, el alcance de los servicios, el organismo de certificación, el estado actual del certificado o las exclusiones. No se localizó ningún certificado público que contenga esos detalles en las fuentes congeladas. El comprador debe solicitarlo y verificar el emisor, la acreditación, el alcance, el titular, la validez y la vigilancia más reciente.
El programa de control debe entonces abordar las rutas de amenaza reales del cliente. El acceso administrativo necesita autenticación multifactor resistente al phishing, separación de roles, privilegios limitados en el tiempo y registro. El personal del proveedor no debe usar el mismo dominio de identidad o credenciales que un evento de ransomware puede comprometer en el cliente. La eliminación de respaldos, los cambios de retención y el acceso a claves deben requerir controles más fuertes que el trabajo de restauración de rutina.
La gestión de red, la gestión de virtualización, el almacenamiento y la orquestación de respaldos deben ocupar zonas de confianza separadas. Los registros deben salir del sistema que monitorean y conservarse el tiempo suficiente para investigar una intrusión.
La inmutabilidad merece precisión particular. Una característica compatible con Veeam o un bloqueo de objetos S3 puede resistir la eliminación solo bajo sus condiciones configuradas. El comprador necesita la ventana de retención, la fuente del reloj, la configuración de gobernanza o cumplimiento, las capacidades del administrador, el tipo de repositorio y la evidencia de un intento de eliminación deliberado. Debe determinar si un administrador de almacenamiento, un administrador de nube y un administrador de respaldos pueden coludir a través de un sistema de identidad.
Al menos una copia debe resistir el compromiso de las rutas de administración de producción y respaldo ordinario.
La cláusula de incidentes debe conectar las operaciones técnicas con los deberes de privacidad mexicanos y las obligaciones del sector. Debe definir cuándo Ebunti notifica al cliente, qué información sigue, cómo se preserva la evidencia y cómo participan los subcontratistas. El aviso de privacidad promete medidas razonables e identifica propósitos de procesamiento amplios, pero no proporciona una arquitectura de seguridad específica del cliente.
Un comprador regulado también puede necesitar resúmenes de pruebas de penetración, ventanas de remediación de vulnerabilidades, selección de personal, eliminación segura de medios, resultados de continuidad del negocio y evidencia de seguro cibernético.
Los servicios de ciberseguridad crean un límite adicional. Un proveedor puede revender o gestionar productos de seguridad sin asumir la responsabilidad de la seguridad general del cliente. El pedido debe separar la seguridad del cloud de Ebunti de los servicios de seguridad opcionales suministrados al cliente. Debe indicar qué alertas se monitorean, quién investiga, qué respuesta está incluida y dónde residen los registros. El lenguaje vago como "protegido por tecnología líder" no puede definir la responsabilidad.
La conclusión justa no es que Ebunti carezca de controles. La evidencia pública es insuficiente para evaluarlos al nivel necesario para una carga de trabajo crítica. El estatus de socio, una red registrada, telemetría publicada y un estándar de gestión de servicios afirmado son puntos de partida creíbles. Un paquete de certificados, un taller de arquitectura, evidencia de control y una prueba de recuperación en vivo deben completar el cuadro.
La sustitución local ahora compite con tres regiones de hiperescala mexicanas
La llegada de infraestructura de AWS, Microsoft y Google a México cambia la pregunta competitiva de Ebunti. Un comprador puede buscar residencia de datos local de una plataforma global, a menudo a través de múltiples zonas de disponibilidad, mientras mantiene acceso a extensos servicios de identidad, seguridad, análisis y automatización. Ebunti no puede ganar simplemente diciendo que el cloud extranjero es remoto.
Puede competir en una unidad de valor diferente. Una pequeña empresa rara vez quiere una zona de disponibilidad; quiere que la nómina se ejecute después de un ataque. Puede valorar un equipo de habla hispana que conoce su parque de VMware, un socio de canal que ya soporta sus oficinas, un paquete de recuperación predecible y la capacidad de hablar con las personas que operan la plataforma. El ASN visible de Ebunti, la especialización en Veeam y la combinación de servicios pueden respaldar esa posición. Su historia de Softtek liderada por proveedores también sugiere experiencia operando a través de socios a escala significativa.
La compensación es amplitud y concentración. Un hiperescalador ofrece más regiones, automatización más profunda, una elección de mercado más amplia y una gran inversión en seguridad, pero puede dejar la arquitectura y el control de costos al cliente. Ebunti puede ensamblar y operar una pila más estrecha, pero el cliente puede depender de un solo proveedor para infraestructura, respaldo, recuperación, red y escalación. La región local de un hiperescalador aún puede depender de servicios de gestión globales; un proveedor regional aún puede usar proveedores globales y soporte transfronterizo.
Ninguna etiqueta responde a la soberanía por sí misma.
Una comparación seria debe usar la misma carga de trabajo y prueba de aceptación. Precio del entorno de producción, copia inmutable, segundo dominio de falla, monitoreo, soporte y dos ejercicios anuales de recuperación en ambas rutas. Mida la latencia desde usuarios reales e integraciones. Pruebe la recuperación desde credenciales comprometidas. Identifique a la persona que coordina todo el incidente. Mapee todas las ubicaciones de datos y gestión. Calcule el tiempo y las tarifas de salida.
El diseño ganador puede ser Ebunti, un hiperescalador con un socio gestionado, o un híbrido en el que uno tenga la producción y otro una copia independiente.
Ese híbrido merece atención. Si Ebunti ejecuta la producción y el único repositorio de recuperación también está bajo su administración, el cliente tiene concentración de proveedor. Si la producción se ejecuta en otro lugar y Ebunti tiene una copia protegida y un destino de recuperación, Ebunti se convierte en una alternativa local de continuidad más que en una sustitución completa. Por el contrario, un cliente puede usar infraestructura de Ebunti mientras exporta una copia de recuperación independiente. La propuesta de cloud local más fuerte puede no ser "reemplazar todo".
Puede ser "crear una ruta operativa mexicana recuperable que no comparta cada fallo con el titular".
Los costos de cambio se esconden en la ruta de recuperación
La salida del cloud a menudo se reduce a la salida de datos. Para un cliente de Ebunti, el costo de cambio puede acumularse en más lugares. Las máquinas virtuales pueden estar moldeadas alrededor de VMware. El historial de respaldos, los catálogos y las cadenas de retención pueden depender de Veeam. La política de firewall, las direcciones públicas, el DNS y los circuitos de socios pueden apuntar a la infraestructura del proveedor. Las aplicaciones compatibles con S3 pueden confiar en un comportamiento que difiere en los bordes entre implementaciones.
Los permisos y las opciones de retención de restauración de Microsoft 365 pueden vivir en una consola gestionada por el proveedor. Los manuales de recuperación pueden existir principalmente en las cabezas de las personas que los operan.
El cliente no es dueño de AS265618 simplemente porque su servicio utilice una dirección anunciada por esa red. Mudarse puede requerir nuevas direcciones públicas y actualizaciones en listas de permitidos, DNS, certificados, sistemas de socios y reglas de seguridad. Si un entorno Odoo tiene módulos personalizados, archivos adjuntos e integraciones, exportar solo su base de datos no es suficiente. Si las claves de cifrado o los metadatos de respaldo son inaccesibles, una copia de los bloques de almacenamiento puede no ser recuperable fácilmente en otro lugar.
El período de descarga de 30 días posterior a la rescisión del acuerdo hace que estas dependencias sean concretas. Un corpus de varios terabytes a través de un enlace restringido puede consumir gran parte de esa ventana. Restaurar todo un historial de retención en otro entorno de Veeam puede requerir versiones compatibles, acceso al repositorio y asistencia operativa. Una política de retención inmutable puede complicar el momento de la eliminación incluso cuando el cliente necesita exportaciones utilizables.
Por lo tanto, el pedido debe especificar qué significa "descarga": archivos de respaldo nativos, imágenes de disco virtual, volcados de base de datos, versiones de objetos, exportaciones de configuración, registros, claves y documentación.
Una prueba de salida debe ocurrir antes de la producción y anualmente después. Exporte una máquina representativa, una base de datos, un conjunto de datos S3 y un elemento de Microsoft 365 a través de la ruta prevista del cliente. Impórtelos en un entorno no controlado por Ebunti. Mida el tiempo, las tarifas y la mano de obra del proveedor. Verifique que el cliente pueda obtener su configuración e historial de recuperación. Confirme cómo se destruyen los datos de forma segura después de los períodos de retención y suspensión legal, y solicite evidencia de destrucción.
El costo de cambio no es inherentemente malo. Puede ser el residuo de una integración valiosa y una experiencia gestionada. Se vuelve peligroso cuando se descubre durante una disputa o interrupción. Un comprador que valora y ensaya la salida puede aceptar un compromiso largo con los ojos abiertos. Uno que confía en un lenguaje genérico de portabilidad ha transferido más control de lo que revela la factura.
Una prueba de 30 días puede convertir las afirmaciones de Ebunti en un servicio
La evidencia respalda un piloto disciplinado en lugar de un sí o un no inmediato. Treinta días son suficientes para probar la cadena con una carga de trabajo representativa si el proveedor y el cliente preparan datos, acceso y tomadores de decisiones con anticipación.
Durante los días uno al cinco, establezcan identidad y alcance. El vendedor debe proporcionar el documento corporativo mexicano actual, RFC, aviso y direcciones de servicio, prueba de la relación de nombre de DRP a Ebunti, y una explicación de qué entidad posee u opera AS265618. El borrador del pedido debe identificar las entidades de contratación, facturación, procesamiento de datos, operación de infraestructura y soporte. Si un revendedor está involucrado, debe firmar un cronograma de responsabilidades con Ebunti y el cliente.
ARTEM no debe aparecer en el alcance a menos que se proporcione una relación documental y una responsabilidad precisa.
La misma fase debe congelar la definición de la carga de trabajo. Seleccione una aplicación con una base de datos, archivos, autenticación, integración externa y un objetivo de recuperación significativo. Una implementación de Odoo sería adecuada si el cliente realmente la usa, pero Odoo no debe incluirse simplemente porque el directorio enumera a DRP Cloud México como cliente. Inventario de volumen de datos, cambio diario, transacciones pico, dependencias, puertos requeridos, identidades, certificados, versiones de software, licencias y pasos de validación de negocio.
Defina el punto de recuperación y el tiempo de recuperación desde el evento de negocio hasta el servicio aceptado, no meramente desde la aceptación del ticket hasta la máquina virtual encendida.
Durante los días seis al diez, mapeen la arquitectura y la soberanía. Ebunti debe proporcionar un diagrama específico del cliente que muestre producción, repositorios, destinos de replicación, sistemas de gestión, redes, rutas de soporte y proveedores externos. Cada componente debe tener un país, sitio o región, operador, controlador legal, estado de cifrado y dominio de falla. El diagrama debe distinguir los privilegios del cliente, revendedor, Ebunti y proveedor. El cliente debe compararlo con la lista de proveedores del aviso de privacidad y documentar cualquier dato o acceso de soporte fuera de México.
Las pruebas de red deben ejecutarse en paralelo. Verifique el origen de la ruta pública, la autorización de ruta, los upstreams esperados y los endpoints del cliente. Mida latencia, jitter, pérdida de paquetes y rendimiento desde ubicaciones reales. Deshabilite un túnel primario o circuito acordado y observe la conmutación por error, el monitoreo y la creación de tickets. Confirme si la red de recuperación utiliza una ruta independiente. Si IPv6 es importante para la aplicación o la política de adquisición, obtenga un diseño compatible o una hoja de ruta con fecha en lugar de asumir que la observación pública del ASN cuenta toda la historia.
Durante los días once al veinte, ataquen los supuestos de recuperación. Siembre la carga de trabajo, registre la duración del respaldo base y confirme que los fallos creen alertas accionables. Intente un cambio de retención y eliminación no autorizados utilizando los roles más probables de ser comprometidos. Cree transacciones conocidas, corrompa o aísle la producción, y exija que el equipo de servicio seleccione un punto de restauración limpio. Recupérese en una red segregada sin confiar en el sistema de identidad de producción fallido. Pruebe la aplicación, las integraciones y los informes contra un script de aceptación por escrito.
Luego declaren un evento de recuperación. Midan la detección, el acuse de recibo, la participación del ingeniero, la restauración de datos, el cambio de red, la validación de la aplicación y la aceptación del negocio por separado. Continúen operando el tiempo suficiente para crear nuevas transacciones en el sitio de recuperación. Vuelvan atrás y demuestren que esas transacciones sobreviven. Registren el punto y tiempo de recuperación logrados, cada dependencia manual, restricción de capacidad y derecho de decisión.
Repitan un paso fallido después de cambiar a una persona en el turno de soporte; un manual que funciona solo con su autor no es resiliente.
Durante los días veintiuno al veinticinco, prueben el soporte y la seguridad. Abran tickets de baja, media y alta severidad a través de los canales que el contrato realmente cubre. Escalen uno después del intervalo prometido. Pregunten al revendedor y a Ebunti por separado quién es el propietario de la siguiente acción y comparen las respuestas. Inspeccionen los registros de acceso para el ejercicio de recuperación, las asignaciones de roles privilegiados, los controles multifactor, los registros de aprobación y la evidencia de que las rutas de gestión y respaldo están separadas.
Revisen el certificado ISO/IEC 20000-1 reclamado en lugar de un logotipo: titular, alcance, sitios, emisor, acreditación, validez y vigilancia. Obtengan un paquete de control de seguridad apropiado para el riesgo, incluyendo gestión de vulnerabilidades, notificación de incidentes, gobierno de subcontratistas, eliminación de medios y pruebas de continuidad. Verifiquen la inmutabilidad del repositorio con un resultado técnico, no un nombre de producto. Si se incluye un servicio de monitoreo de ciberseguridad, inyecten una alerta de prueba segura y síganla desde la detección hasta la comunicación con el cliente.
Durante los días veintiséis al treinta, prueben la economía y la salida. Concilien la calculadora pública con un presupuesto firmado para el consumo medido del piloto. Añadan licencias, transferencia, soporte, ejercicios de recuperación, incorporación y trabajo profesional. Precien un desastre declarado y una salida anticipada. Pidan al proveedor que exporte una máquina virtual representativa, una base de datos, un conjunto de objetos, la configuración y un paquete de registros. Impórtenlos fuera de su administración. Midan la tasa de transferencia y calculen si todo el patrimonio puede salir dentro de la ventana contractual.
La hoja de aceptación final debe ser binaria cuando sea posible. La identidad legal se concilia o no. Las ubicaciones de datos están nombradas o no. Un intento de eliminación falló para la ventana inmutable acordada o no. Una recuperación cumplió con el reloj de negocio o no. Una segunda ruta de red funcionó o no. La cadena de soporte llegó a un ingeniero responsable o no. La exportación fue utilizable en otro lugar o no. La incertidumbre residual puede entonces valorarse, asegurarse, mitigarse con una copia independiente o convertirse en una condición antes de la producción.
Esta prueba no es una adquisición hostil. Le da a Ebunti la oportunidad de demostrar la ventaja operativa que su marca promete. Un proveedor gestionado local debería poder superar a un catálogo genérico en coordinación, contexto y práctica de recuperación. El piloto mide exactamente esas fortalezas.
La evidencia cae en cuatro cubos diferentes
Los hechos verificados son significativos. DRP Cloud México anunció oficialmente la marca Ebunti. Los registros actuales de LACNIC vinculan el nombre legal de DRP y los contactos de Ebunti con AS265618 y una asignación de direcciones mexicana. Material universitario independiente aún usa DRP Cloud México junto con Ebunti. Veeam reconoció públicamente a Ebunti como un socio proveedor de servicios líder en América Latina. Ebunti publica términos legales, un SLA, telemetría de servicios y páginas de productos identificables. Esos hechos establecen un negocio operativo real con recursos de red y una propuesta centrada en la continuidad.
Las afirmaciones de la empresa forman un segundo cubo. Ebunti describe múltiples ubicaciones latinoamericanas, soporte las 24 horas, características específicas de infraestructura, recuperación rápida, alta durabilidad de objetos, prácticas de seguridad y resultados de clientes. Sus estudios de caso y entrevistas ejecutivas añaden detalle, y algunos llevan contexto de cliente o proveedor nombrado. Siguen siendo declaraciones que deben probarse para el servicio del comprador. Una capacidad en un sitio o para un cliente no puede presumirse en cada presupuesto.
Las inferencias razonadas forman el tercer cubo. La combinación de una red registrada, el estatus de Veeam, la estructura de productos y los monitores de estado sugiere que Ebunti opera más que un catálogo de reventa de papel. Su enfoque de canal podría dar a las pymes una ruta gestionada práctica hacia el respaldo y la recuperación. Su control de varias capas podría acelerar la coordinación de incidentes. La misma combinación podría aumentar la concentración y el costo de cambio. Estas son conclusiones extraídas de la evidencia conjunta, no declaraciones directas de un regulador o un contrato de cliente.
Las incógnitas son la agenda de adquisición. La evidencia pública no concilia la última denominación legal con todos los registros antiguos y actuales. No prueba una relación con ARTEM. No muestra una implementación o competencia de alojamiento de Odoo.
No divulga los sitios de centros de datos nombrados y los dominios de falla para cada servicio, las ubicaciones de datos específicas del cliente, la certificación de seguridad completa, la política de sobresuscripción, la capacidad de recuperación durante eventos correlacionados, la dotación de personal de soporte exacta, las narrativas de causa raíz para el historial de monitores visible, o la portabilidad de una cadena de retención completa.
Mantener los cubos separados previene dos errores opuestos. Uno es descartar a un proveedor regional porque carece del volumen de divulgación de un hiperescalador público. El otro es convertir cada insignia de socio y página de producto en un control asumido. Ebunti ha proporcionado suficiente evidencia para merecer diligencia técnica directa. El comprador debe proporcionar la disciplina para mantener lo observado, afirmado, inferido y desconocido de colapsar en una sola historia de ventas.
Vigile el nombre, los monitores y la independencia de la copia de recuperación
El primer punto de vigilancia es la identidad corporativa. Las facturas futuras, los avisos legales, los registros de LACNIC y los anuncios de socios deben converger en una denominación documentada. Una actualización formal del registrante de la red, o evidencia de que DRP Cloud México sigue siendo el titular de los activos mientras Ebunti México contrata, cambiaría el análisis de riesgo. La divergencia continua no es prueba de irregularidades, pero aumenta el costo de hacer cumplir la responsabilidad.
El segundo es la transparencia operativa. La página de estado de Ebunti debe observarse a lo largo del tiempo. Los compradores deben buscar una disponibilidad mejorada, narrativas de incidentes duraderas y un mapeo claro entre los monitores y los servicios contractuales. Un archivo silencioso junto con períodos rojos visibles es menos útil que una explicación sincera. Los cambios al objetivo del 99.5% del SLA, el umbral de crédito del 99.9% y la definición estrecha de conectividad simultánea también serían materiales.
El tercero es la madurez de la red. AS265618 proporciona una línea base para observar los orígenes de prefijos, la autorización de ruta, los cambios de upstream y la adopción de IPv6. El crecimiento en prefijos no es automáticamente una mejora, y dos upstreams visibles no son automáticamente diversidad física. La señal relevante es si el cliente puede verificar rutas independientes y respuesta documentada a incidentes de enrutamiento.
El cuarto es la independencia de la recuperación. A medida que el ransomware ataca cada vez más la administración de respaldos, los compradores deben observar si Ebunti publica evidencia más clara sobre inmutabilidad, identidad aislada, capacidad entre sitios y ejercicios de recuperación. Una copia almacenada en otro rack pero controlada por las mismas credenciales comprometidas no es una ruta de recuperación independiente. Un proveedor regional que pueda demostrar separación administrativa y geográfica tendrá una respuesta más sólida que uno que simplemente añada almacenamiento.
El quinto es la adaptación competitiva. Las regiones de hiperescala mexicanas reducen la fuerza de la residencia por sí sola. Ebunti necesitará mostrar por qué su capa operativa gestionada, su cadena de soporte y su práctica de recuperación superan la alternativa del cliente. Una documentación de servicio clara, controles específicos del sitio, precios transparentes y una recuperación portátil podrían volverse más importantes que añadir más logotipos al catálogo.
Finalmente, esté atento a un puente documentado con ARTEM. Si una presentación corporativa confiable, un aviso de adquisición, una asociación firmada o una declaración de servicio autorizada conectan eventualmente a ARTEM con DRP Cloud México o Ebunti, su papel puede evaluarse entonces. Hasta ese momento, importar las afirmaciones cloud y de Odoo de ARTEM debilitaría en lugar de enriquecer la evidencia.
El contrato es el producto de nube soberana
DRP CLOUD MEXICO SAPI DE CV no es un nombre vacío detrás de un sitio web. La transición de DRP a Ebunti está respaldada por un anuncio oficial, contactos de red en vivo, referencias de terceros y un negocio de recuperación consistente. AS265618, la telemetría de servicios pública y el reconocimiento de Veeam dan a los compradores asas observables que muchos proveedores locales no exponen.
Las preguntas abiertas son igualmente reales. El nombre legal preciso actual no es consistente en todos los registros públicos. El SLA mide una condición más estrecha de lo que la mayoría de las empresas entiende por disponibilidad. El acuerdo le da al presupuesto una importancia enorme y hace que el compromiso, los reclamos y la salida sean consecuentes. La página de estado muestra condiciones que merecen explicación. Las páginas de producto describen recuperación rápida, almacenamiento duradero y seguridad sin revelar la arquitectura específica del cliente que hace que esas afirmaciones sean verdaderas.
ARTEM y Odoo no pueden usarse para llenar los vacíos.
Esa combinación produce un veredicto más útil que una calificación. Ebunti es lo suficientemente creíble para probar e insuficientemente transparente para comprar solo con catálogo. Para una pyme mexicana, su mayor ventaja posible no son CPUs virtuales más baratos. Es un servicio conjunto en el que la infraestructura local, las copias recuperables, el control de red y las personas que responden al teléfono reducen el trabajo de sobrevivir a una interrupción. Su mayor riesgo es que el mismo servicio conjunto concentre el control técnico y contractual mientras deja los límites implícitos.
Un comprador puede resolver gran parte de esa tensión antes de la producción. Concilie la contraparte legal. Adjunte el mapa de arquitectura y ubicación de datos. Convierta el lenguaje de recuperación en un ejercicio de aplicación cronometrado. Mapee AS265618 a la ruta real del cliente. Ponga al revendedor y a Ebunti en un solo cronograma de responsabilidades. Verifique el alcance de seguridad y la separación inmutable. Concilie el historial de monitores público con el SLA. Valore el desastre y ensaye la salida.
Si Ebunti puede pasar esas pruebas, el cambio de marca representará más que una nueva presentación comercial. Describirá un operador de continuidad mexicano cuya red local, práctica de recuperación y soporte hacen que la dependencia del cloud sea más manejable. Si no puede, el comprador se queda con un catálogo amplio y un cambio de nombre. En la adquisición de nube soberana, la diferencia no la decide la página de inicio. Está escrita en el contrato, demostrada en la sala de recuperación y preservada en la copia que el cliente aún puede restaurar después de que el proveedor ya no esté allí.