Resumen

  • TodoEnCloud es una empresa operativa de servicios en la nube y gestionados con sede en Madrid, no simplemente un registro corporativo o de red inactivo. Afirma que opera una nube pública desde 2011; Tessi registró la adquisición del negocio en 2018; y los registros actuales, certificaciones, sitio web y evidencia de enrutamiento apuntan a una actividad continua.
  • La nube pública española de la compañía se presenta como tres zonas en tres centros de datos del área de Madrid conectados por un anillo de fibra oscura. Un certificado ENS de noviembre de 2025 identifica los sitios como Interxion en Calle Albasanz 71, DATA4 en Avenida de la Industria 15 en Alcobendas e IPCore en Calle Marzo 16. Estos son operadores de instalaciones independientes; TodoEnCloud parece poseer o controlar el equipamiento de servicio y la capa de red, en lugar de los edificios, subestaciones o generadores.
  • AS201346 originó cuatro rutas IPv4 /24 que cubren 1.024 direcciones el 12 de julio de 2026. Los recolectores de RIPE vieron tres redes ascendentes adyacentes, asociadas con Cogent, Lumen y NEAR IP, y la ruta probada tenía una autorización RPKI válida. Esta es una evidencia operativa sustancial, aunque la ausencia de IPv6 visible y de un registro en PeeringDB deja lagunas en la imagen de interconexión pública.
  • Tres instalaciones son útiles solo cuando los componentes de cómputo, almacenamiento, red, identidad, gestión y respaldo de un cliente se colocan deliberadamente entre ellas. TodoEnCloud no publica el número de servidores instalados, la capacidad de CPU o almacenamiento utilizable, el margen por sitio, la sobresuscripción, el rendimiento de recuperación, el historial de incidentes o un calendario de nivel de servicio estándar. La capacidad de las instalaciones no debe interpretarse como prueba de que cada recurso alquilado sobrevive a la pérdida de un sitio.
  • La evidencia operativa general es Fuerte, mientras que la evidencia de recuperación pública es Media. Un comprador puede verificar la empresa legal, la matriz, los sitios, las certificaciones, el espacio de direcciones y el enrutamiento activo. Un comprador aún necesita una arquitectura específica para la carga de trabajo, límites de energía y fibra, compromisos de punto y tiempo de recuperación, reglas de mantenimiento, escalado de soporte, política de repuestos y una prueba de salida cronometrada antes de tratar la nube como portable o tolerante a fallos de sitio.

La nube se concentra en tres edificios específicos de Madrid

La propuesta de TodoEnCloud es inusualmente útil para el análisis de infraestructura porque nombra la capa física debajo de su nube. Lapágina de nube públicade la compañía dice que el servicio se distribuye en tres centros de datos españoles, unidos por un anillo de fibra de alta velocidad y baja latencia, y se presenta a los clientes como tres zonas dentro de una zona de disponibilidad. Supágina de centro de datosnombra a Digital Realty, DATA4 e IPCore. De manera más decisiva, elcertificado ENSde la compañía, emitido en noviembre de 2025, identifica a Interxion en Calle Albasanz 71, DATA4 Group en Avenida de la Industria 15 en Alcobendas e IPCore centros de datos en Calle Marzo 16 en Madrid.

Esas ubicaciones hacen que la afirmación sea más que un diagrama. Digital Realty lista Calle Albasanz 71 como suinstalación MAD1, un sitio de 8.280 metros cuadrados en una cartera de cuatro instalaciones en Madrid. Lapágina del campus de Madrid de DATA4sitúa su sitio MAD01 en la misma dirección de Alcobendas registrada en el certificado de TodoEnCloud y describe un campus con reservas eléctricas sustanciales. Ladescripción de la instalación de IPCoresitúa un edificio de 1.200 metros cuadrados, neutral respecto al operador, en Calle Marzo 16, con energía y refrigeración redundantes, múltiples entradas de fibra y manos remotas las 24 horas.

El patrón físico es, por lo tanto, una nube metropolitana de Madrid en lugar de una dispersión nacional por regiones españolas distantes. Albasanz y Calle Marzo están en la ciudad de Madrid; DATA4 está en Alcobendas, al norte del centro. La separación dentro de un área metropolitana puede proteger contra un incendio en un rack, una interrupción del edificio, un fallo de un conmutador local o trabajos en una conexión de servicios públicos.

Hace menos contra una interrupción regional de las comunicaciones, una emergencia amplia del sistema eléctrico, un fallo de software desplegado en todas partes, un problema común de proveedor o un error operativo propagado por un equipo.

Esta distinción no es una crítica al diseño metropolitano. La baja latencia entre sitios puede hacer prácticos el almacenamiento sincrónico y los servicios en clúster, mientras que una región distante introduciría retraso y coste. Es una declaración sobre el fallo que está asegurado. Un clúster de Madrid unido por fibra puede ser excelente para sobrevivir al fallo de una sala o edificio. No debe representarse como equivalente a una región de recuperación con personal independiente a cientos de kilómetros de distancia, a menos que un cliente haya contratado y probado realmente dicha región.

TodoEnCloud en sí misma utiliza una formulación inusual: tres zonas que forman una zona de disponibilidad. La terminología de la nube no está estandarizada entre proveedores, por lo que las palabras por sí solas no determinan la ingeniería. Un cliente necesita las reglas de colocación reales. Si tres máquinas virtuales con tres etiquetas de zona aún pueden compartir una matriz de almacenamiento, un clúster de gestión, un par de cortafuegos o un catálogo de copias de seguridad, las etiquetas exageran el aislamiento.

Si el planificador asigna cada copia a edificios separados con almacenamiento y salidas de red independientes, las mismas etiquetas pueden ocultar un diseño robusto. La arquitectura, no el vocabulario, decide el resultado.

TodoEnCloud opera la capa de servicio, no toda la propiedad física

La identidad corporativa es clara. Elaviso de privacidaddel sitio web identifica a TODOENCLOUD S.L. en Madrid y proporciona el mismo número de teléfono que se encuentra en los directorios de empresas. Los registros comerciales sitúan su constitución en 2011. El informe anual de Tessi de 2019 registra laadquisición en 2018 de Todo en Cloudcomo parte de la expansión del grupo francés en arquitectura de nube y servicios de centros de datos. El sitio de TodoEnCloud ahora dice que sus servicios forman parte de la fábrica digital Innovation & Trust de Tessi.

Esa filiación importa en dos sentidos. Proporciona un contexto corporativo más amplio de lo que sugeriría la plantilla de la filial española por sí sola, y el anuncio de adquisición original de Tessi dijo que el acuerdo conectaría la capacidad española de TodoEnCloud con plataformas de alojamiento en Francia. Pero la propiedad de la matriz no prueba que la capacidad francesa sea un destino de conmutación por error activo para los clientes españoles. A menos que un contrato, diseño de replicación y prueba de recuperación nombren un sitio francés, la red de la matriz es una opción estratégica en lugar de una redundancia contratada.

El lenguaje de propiedad en el sitio web de la compañía necesita un cuidado similar. TodoEnCloud describe "infraestructura propia en España" y a veces se refiere a "nuestros" centros de datos. Sin embargo, los edificios identificados son operados por Digital Realty, DATA4 e IPCore. La lectura más precisa es que TodoEnCloud posee, alquila o controla servidores, almacenamiento, dispositivos de red y software desplegados en instalaciones de colocación de terceros, y compra energía, espacio, seguridad física y servicios del sitio bajo acuerdos con esos operadores.

También puede alquilar fibra mientras ilumina esa fibra con su propio equipo óptico.

Esta propiedad en capas es normal. Pocas nubes regionales necesitan poseer una subestación, envolvente de hormigón y tanques de diésel para proporcionar un servicio serio. La consecuencia es que la responsabilidad cruza contratos. Digital Realty, DATA4 o IPCore responde a una alarma del edificio y mantiene la planta de la instalación. Un operador o proveedor de fibra repara una ruta externa. TodoEnCloud opera la plataforma del cliente, la política de red y quizás la capa óptica iluminada. Los proveedores de hardware suministran servidores, discos, tarjetas de red y componentes de repuesto. Tessi controla en última instancia la filial.

El cliente posee la aplicación, el modelo de datos, las credenciales y cualquier diseño de recuperación que haya adquirido.

Durante un mes rutinario, esos límites son casi invisibles. Durante un incidente, determinan quién puede entrar en la sala, quién tiene una pieza de repuesto, quién autoriza una reparación de fibra, quién se comunica con el cliente y si se debe un crédito de nivel de servicio. Un proveedor puede ser responsable ante el cliente sin controlar directamente cada paso de restauración. La cuestión importante es si sus contratos, monitoreo y derechos de escalado son lo suficientemente sólidos para gestionar esas dependencias externas bajo presión.

Los certificados demuestran un alcance operativo definido, no una resiliencia ilimitada

TodoEnCloud proporciona evidencia de certificación inusualmente concreta. Su actualcertificado ISO 27001cubre los sistemas de gestión de la información que soportan IaaS pública y privada en la oficina central de Madrid y dos direcciones de centros de datos: Albasanz 71 y Avenida de la Industria 15. Es válido desde julio de 2024 hasta junio de 2027. Uncertificado ISO 27701separado cubre el sistema de gestión de información de privacidad para la misma actividad y dos sitios hasta septiembre de 2027.

El certificado ENS posterior es más amplio. Registra los tres centros de datos nombrados y dice que los sistemas que soportan IaaS pública y privada fueron auditados contra el Esquema Nacional de Seguridad de España en la categoría Media. Esto proporciona un puente fechado entre el marketing de tres sitios de la compañía y un alcance de auditoría externa. También resuelve una aparente inconsistencia en la página de seguridad de la compañía, que todavía dice que ISO 27001 cubre dos centros de datos. La explicación más plausible es el momento: los documentos ISO enumeran dos sitios, mientras que la auditoría ENS posterior añade IPCore.

La certificación es valiosa porque establece gobernanza, un alcance definido, un auditor y un período de validez. No revela capacidad ni hace que cada carga de trabajo sea altamente disponible. ISO 27001 se refiere a un sistema de gestión de seguridad de la información. ISO 27701 extiende la gestión de privacidad. ENS Medio impone controles para sistemas que sirven a necesidades relevantes del sector público español.

Ninguno de esos documentos dice cuántos nodos de cómputo están activos en cada edificio, si los volúmenes de los clientes se replican sincrónicamente, cuánto tarda en reemplazarse un host fallido, o cómo se comportó una base de datos particular en la última interrupción.

Las certificaciones de las instalaciones deben separarse también de las certificaciones del proveedor. La página de centro de datos de TodoEnCloud hace afirmaciones amplias sobre instalaciones Tier III+ o Tier IV, componentes N+1, subestaciones independientes, baterías y generadores, y disponibilidad entre el 99,95 y el 99,999 por ciento. Estas parecen resumir las capacidades del sitio en los operadores elegidos. No son un acuerdo de nivel de servicio publicado de TodoEnCloud, y el rango en sí mismo abarca márgenes de tiempo de inactividad muy diferentes.

En un año de 365 días, el 99,95 por ciento permite aproximadamente 4 horas y 23 minutos de indisponibilidad; el 99,999 por ciento permite alrededor de 5 minutos y 15 segundos. El contrato del cliente debe identificar qué cifra, punto de medición y exclusiones se aplican.

Una certificación también puede excluir una dependencia que los clientes suponen que cubre. Los certificados ISO nombran dos CPD mientras que la nube pública ahora describe tres. Un servicio gestionado de AWS o Azure vendido por TodoEnCloud depende de esas plataformas externas en lugar de depender únicamente de la nube española certificada. Un nodo periférico en una fábrica o farola está físicamente fuera de las instalaciones de Madrid. El propio clúster local de un cliente tiene su propia frontera de energía y seguridad.

Por lo tanto, el alcance debe leerse servicio por servicio, no aplicarse al logotipo de la compañía como una propiedad universal.

La capacidad instalada y la capacidad utilizable permanecen sin revelar

La mayor brecha de evidencia pública es la capacidad. TodoEnCloud ofrece nube pública, nube privada, bare metal, Kubernetes, instancias GPU, copia de seguridad, recuperación ante desastres, colocación y operaciones gestionadas. Dice que los clientes pueden escalar y pagar por uso. No publica el número o generación de hosts de cómputo, núcleos físicos totales, memoria, inventario de aceleradores, medios de almacenamiento, petabytes utilizables, utilización normal, potencia del rack, margen reservado o distribución por sitio.

Sin esas cifras, un comprador no puede distinguir la capacidad instalada de la utilizable. Un rack puede contener servidores pero carecer de suficiente potencia comprometida para todos ellos a máximo consumo. Un clúster de almacenamiento puede anunciar capacidad bruta de disco mientras que la paridad, replicación, instantáneas y reserva consumen una gran parte. Un grupo de nube pública puede tener CPU agregada de sobra pero no suficiente memoria, GPU o almacenamiento local para una forma específica.

Un proveedor puede ser capaz de vender una instancia más durante el funcionamiento normal pero carecer de espacio para absorber todas las cargas de trabajo supervivientes después de un fallo del sitio.

La última distinción es la más importante. La capacidad que es utilizable en un día normal no es necesariamente capacidad tolerante a fallos. Supongamos que tres sitios funcionan cada uno al 60 por ciento de su carga segura de clientes. Perder uno dejaría dos sitios tratando de soportar el 90 por ciento cada uno antes de tener en cuenta formas de carga de trabajo desiguales, localidad de almacenamiento o límites de red. Eso podría ser recuperable.

Con una ocupación normal del 80 por ciento, los dos supervivientes necesitarían alcanzar el 120 por ciento, lo cual es imposible sin desprenderse de carga o dejar algunos servicios fuera de servicio. Los números aquí son ejemplos, no estimaciones de la utilización de TodoEnCloud. Muestran por qué el recuento de sitios por sí solo no puede establecer la recuperabilidad.

El inventario de hardware crea otra brecha. Laoferta de nube privadade TodoEnCloud va desde despliegues de tres nodos hasta grandes entornos a medida, utilizando hardware del cliente o equipos financiados por el proveedor. Suoferta de bare metalpromete control físico dedicado con consumo al estilo de la nube. Esos servicios no pueden restaurarse asignando cualquier máquina virtual genérica. La recuperación puede requerir la misma familia de CPU, tamaño de memoria, interfaz de red, acelerador, firmware o conexión de almacenamiento. Un nodo de repuesto que existe en un almacén aún no está cableado, configurado y unido al clúster.

Los precios públicos también son escasos. El proveedor enfatiza un modelo de gasto operativo y gestión de costes, pero no expone una tarjeta de tarifas general para cómputo, almacenamiento, salida, copia de seguridad, manos remotas o capacidad reservada. Eso es comprensible para la arquitectura B2B a medida. Significa que la economía del alojamiento debe establecerse en una propuesta y contrato.

Los compradores deben preguntar cómo los cambios en el precio de la energía, los costes de licencia, el hardware de reemplazo, la capacidad de ráfaga, el tráfico entre sitios, el tránsito externo y el trabajo fuera de horario se trasladan a la factura.

Los operadores más pequeños a veces pueden proporcionar un servicio más económico o atento que los hiperescalares porque evitan un enorme catálogo de productos y conocen cada entorno. También pueden enfrentarse a adquisiciones a granel. Un controlador de almacenamiento fallido, una línea de servidores al final de su vida útil o un pedido de óptica retrasado pueden importar más cuando la flota es compacta.

Por lo tanto, una discusión de capacidad creíble necesita tanto un número como un plan de reposición: recursos contratados, recursos vendibles seguros, recursos mantenidos para fallos, plazos de entrega de proveedores y sustituciones ya calificadas.

La red está visiblemente activa y es más diversa que una sola línea de tránsito

La evidencia de red es la señal operativa independiente más fuerte. RIPE asignóAS201346a TODO EN CLOUD SL en noviembre de 2014. La compañía también posee la asignación IPv4 activa 185.77.132.0 a 185.77.135.255. El 12 de julio de 2026, lavista de estado de enrutamiento de RIPEstatmostró cuatro prefijos /24 originados, 1.024 direcciones IPv4 anunciadas, visibilidad completa en sus pares IPv4 informantes y ningún espacio IPv6 anunciado.

Losdatos de vecinos observados de RIPEmostraron tres redes en el lado ascendente de AS201346: AS174, asociada con Cogent; AS3356, asociada con Lumen; y AS49600, NEAR IP. Un /24 representativo tenía unaautorización de ruta RPKI válida. El Informe CIDR también vio a AS201346 originar el equivalente a un /22 a través de las rutas de Cogent y Lumen. Estas observaciones corroboran el alojamiento activo y la diversidad de rutas de manera más persuasiva que una página de producto por sí sola.

Aún necesitan límites. Un colector BGP puede mostrar que tres sistemas autónomos ascendentes propagan las rutas de TodoEnCloud. No puede mostrar que cada sitio tenga entradas físicamente separadas a los tres, que cada operador pueda soportar la carga de tráfico completa, o que los circuitos eviten un conducto compartido, sala de encuentro o plataforma óptica. Dos contratos de operador pueden converger en una ruta de fibra metropolitana. Tres rutas pueden terminar en un chasis de borde. Un corte de fibra oscura puede aislar un sitio incluso mientras los prefijos públicos siguen siendo accesibles desde otro.

La política de enrutamiento registrada de la compañía también parece más antigua que la red observada. Su objeto aut-num de RIPE nombra AS35699 y AS201942 en las declaraciones de importación y exportación, mientras que las observaciones en vivo muestran Cogent, Lumen y NEAR IP. Los objetos de política de registro comúnmente van por detrás de los acuerdos operativos, pero el desajuste es una advertencia útil contra tratar el texto administrativo como un mapa de topología en vivo.

Un cliente que requiera garantía de ruta debe obtener el diagrama de red actual y probar la conmutación por error, no inferirla de un objeto de una década de antigüedad.

No se devolvió ninguna entrada AS201346 en la consulta de red pública de PeeringDB. Esa ausencia no implica una conectividad deficiente. PeeringDB es un directorio operativo voluntario, y una red basada en tránsito puede funcionar sin una lista. Elimina una forma común de verificar la presencia en instalaciones, la participación en intercambios, la política de tráfico y los contactos de red pública. Las propias páginas de la compañía anuncian enlaces a puntos de intercambio de Internet y múltiples operadores, pero no nombran puertos de intercambio ni capacidades para AS201346.

La ausencia de IPv6 visible es una cuestión de servicio más directa. Cuatro rutas IPv4 activas soportan el alojamiento convencional, pero los clientes que construyen servicios públicos modernos pueden requerir pila dual nativa. La traducción de direcciones de red a nivel de proveedor o un ascendente separado a veces puede suministrar IPv6 sin una ruta AS201346, pero ese diseño debe ser explícito. Un comprador debe preguntar si IPv6 está disponible para máquinas virtuales y servidores bare-metal, cómo se enrutan las direcciones durante la conmutación por error del sitio, y si la protección DDoS trata ambas familias de protocolos por igual.

Un anillo de fibra reduce algunos fallos y crea su propio problema de reparación

TodoEnCloud dice que sus sitios están interconectados a través de un anillo de fibra oscura redundante iluminado por la compañía. Esa es una base plausible para una nube metropolitana. La fibra oscura da al operador control del equipo óptico y la capacidad en lugar de forzar cada replicación de almacenamiento o flujo este-oeste a través del tránsito de Internet medido. Un anillo puede enviar tráfico en la otra dirección después de que un tramo se rompa, siempre que la topología, la conmutación y la capacidad restante funcionen según lo previsto.

La palabra "anillo" no es la prueba de recuperación. Las preguntas útiles comienzan por debajo de ella. ¿Están los dos caminos en conductos y calles separados? ¿Entran a cada edificio a través de diferentes elevadores? ¿Están los dispositivos ópticos alimentados por fuentes independientes? ¿Es la conmutación de ruta automática? ¿Cuánto tarda la detección de fallos y la reconvergencia? ¿Puede el lado superviviente soportar la replicación máxima más el tráfico del cliente? ¿El mantenimiento programado abre alguna vez un lado del anillo, dejando un segundo corte capaz de particionar la nube?

También hay una distinción entre poseer la luz y poseer el vidrio. Un proveedor puede alquilar fibra no iluminada a un operador e instalar sus propios transpondedores. Eso da control sobre el equipo de longitud de onda mientras deja la reparación civil al propietario de la fibra. Una rotura de cable puede requerir acceso a la calle, permisos, equipos de empalme y coordinación entre una instalación, el operador y la ciudad. El reloj de reparación es físico incluso cuando el servicio se llama nube.

La latencia y pérdida entre sitios afectan el comportamiento del almacenamiento antes de producir una interrupción total. La replicación sincrónica espera la confirmación remota y puede ralentizarse cuando un enlace se degrada. La replicación asincrónica puede continuar localmente pero aumenta la cantidad de datos recientes en riesgo. Una salvaguarda de cerebro dividido puede detener deliberadamente un lado en lugar de permitir que dos copias acepten escrituras conflictivas.

Desde la perspectiva del cliente, una parada cautelosa del almacenamiento sigue siendo tiempo de inactividad, pero puede ser la elección correcta para proteger la consistencia.

TodoEnCloud anuncia servicios separados detránsito IP, DDoS y VPN. Eso puede simplificar la responsabilidad porque un proveedor puede gestionar tanto el cómputo como la conectividad. También puede concentrar el fallo si el mismo borde, equipo de soporte, estado de cuenta o automatización de red controla todos ellos. Un diseño resiliente debe identificar una ruta de acceso fuera de banda y un canal de comunicaciones que siga siendo utilizable cuando la red de producción o el panel del cliente no están disponibles.

La resiliencia energética se detiene en la ruta real del rack del cliente

Los tres operadores de instalaciones describen sistemas de energía serios. La página de Madrid de Digital Realty enumera refrigeración N+1 en MAD1. DATA4 describe un gran campus en Madrid con una capacidad eléctrica significativa. IPCore anuncia UPS 2N, un generador diésel de respaldo y refrigeración redundante. TodoEnCloud resume sus instalaciones seleccionadas como con subestaciones independientes, rutas separadas, UPS, baterías y generadores.

Esas características mejoran el punto de partida, pero la energía debe rastrearse desde la red eléctrica hasta la carga de trabajo. Un edificio puede tener dos alimentaciones de servicios públicos mientras que una jaula particular tiene una ruta de distribución. Un rack puede recibir alimentaciones A y B mientras que un servidor tiene una sola fuente de alimentación. Un servidor con doble cableado puede conectar ambos cables al mismo panel ascendente por error. Un generador puede soportar carga crítica mientras que la refrigeración o las áreas no críticas siguen una prioridad diferente.

El mantenimiento puede eliminar temporalmente un componente redundante.

La densidad de potencia también limita el hardware utilizable. Los productos GPU y bare-metal pueden consumir mucha más energía por rack que los servidores de propósito general más antiguos. Una instalación con espacio de piso no utilizado puede no tener los kilovatios entregables, la refrigeración o la capacidad del bus para otro despliegue denso. Las nuevas páginas de GPU de TodoEnCloud anuncian recursos NVIDIA L4 y L40 bajo demanda, pero no indican el inventario, la densidad del rack o si la capacidad del acelerador existe en uno o varios sitios.

Los clientes deben tratar el escalado instantáneo como una promesa comercial limitada por la flota instalada.

Los generadores de las instalaciones introducen dependencias de combustible y reinicio. Un breve evento de red puede ser soportado por baterías hasta que los generadores se estabilicen. Un evento más largo requiere reservas de combustible, reabastecimiento exitoso y refrigeración continua. Después de una pérdida total de energía, los sistemas de cómputo, almacenamiento y red necesitan un reinicio ordenado. El almacenamiento debe establecer cuórum, los servicios de control deben regresar y las instancias de los clientes pueden competir por la capacidad del host.

El tiempo de restauración eléctrica de un edificio no es el mismo que el tiempo de recuperación de la aplicación.

El punto de medición contractual importa. Si la instalación suministra energía al rack de TodoEnCloud pero falla una fuente de alimentación del servidor, el edificio puede estar dentro de su compromiso de servicio mientras el cliente está caído. Si el servidor funciona pero un volumen de almacenamiento no está disponible, una medida de tiempo de actividad de cómputo dice poco. El comprador necesita una definición de servicio de extremo a extremo para el recurso adquirido, con mantenimiento planificado, trabajo de emergencia y exclusiones ascendentes claramente establecidas.

Almacenamiento, copia de seguridad y recuperación ante desastres son productos diferentes

El catálogo de servicios español de TodoEnCloud incluye copia de seguridad y recuperación ante desastres, lo cual es una señal positiva porque no finge que el cómputo de alta disponibilidad hace innecesaria la copia de seguridad. Supágina de servicios en la nubedice que las copias de seguridad pueden almacenarse en diferentes centros de datos y accederse a través de una interfaz compatible con S3. La misma página presenta la recuperación ante desastres como un servicio destinado a restaurar datos, sistemas y aplicaciones críticos.

Los clientes aún necesitan saber si esas protecciones están incluidas en el recurso base o se venden por separado. Una máquina virtual replicada entre hosts puede sobrevivir a un fallo de servidor mientras preserva la eliminación accidental o el ransomware en cada copia. Una instantánea en el mismo clúster de almacenamiento puede ayudar con la reversión pero fallar con el clúster. Una segunda copia en otro edificio es más fuerte, aunque puede permanecer expuesta a un conjunto de credenciales o un plano de gestión. Una copia inmutable o fuera de línea protege contra una clase diferente de fallo.

El objetivo de punto de recuperación y el objetivo de tiempo de recuperación convierten estos productos en compromisos medibles. El punto de recuperación determina cuántos datos recientes pueden perderse. El tiempo de recuperación determina cuánto tiempo puede esperar el negocio. Ninguno debe inferirse de la frase "copia de seguridad automática" o del número de instalaciones. Una base de datos replicada sincrónicamente puede apuntar a una pérdida de datos casi nula pero detenerse durante una partición.

Una copia de seguridad nocturna puede restaurarse después de la pérdida de un edificio pero sacrificar un día laboral de transacciones. Ambos diseños pueden ser racionales para diferentes cargas de trabajo.

Las pruebas de restauración son la evidencia que importa. Deben incluir credenciales, claves de cifrado, política de red, dependencias de dominio, orden de aplicación y la capacidad requerida en el sitio de recuperación. Un objeto de copia de seguridad no es un servicio recuperado. Si la restauración depende del mismo sistema de identidad, consola de gestión o almacén de documentación que falló, la copia nominalmente separada puede ser inaccesible en el momento crítico.

Las páginas públicas de TodoEnCloud no publican el éxito agregado de restauración, la retención estándar, los intervalos de replicación entre sitios, las opciones de copia inmutable o los tiempos de recuperación probados. Eso no significa que las características estén ausentes; su oferta es a medida. Significa que el cliente debe insistir en que estos detalles pasen de la conversación de diseño a un calendario de servicio y una prueba de aceptación.

El personal de soporte es parte de la capacidad

La reivindicación comercial central de la compañía es una arquitectura y operaciones atentas. Su sitio ofrece opciones de soporte desde 8x5 hasta 24x7, un servicio de monitoreo las 24 horas, administración de sistemas, ayuda para la migración y contactos técnicos nominados. Los testimonios de clientes enfatizan la capacidad de respuesta. Para un proveedor regional, esta capa humana puede ser una ventaja genuina sobre una cola de tickets que no sabe nada sobre la aplicación del cliente.

La capacidad humana también es finita. Un reemplazo de disco durante una tarde tranquila es diferente de un incidente en el sitio que afecta a muchos inquilinos. El monitoreo puede detectar cientos de alertas a la vez. Los ingenieros deben distinguir la causa de la consecuencia, coordinarse con el personal de la instalación, proteger la consistencia de los datos, comunicar el estado y priorizar la recuperación. Un equipo pequeño puede ser muy capaz y aun así verse saturado por fallos correlacionados.

El material público no indica la dotación de personal por turno, la profundidad de guardia, la respuesta de escalado, las definiciones de gravedad de incidentes o los compromisos de manos remotas. Las estimaciones de LinkedIn y datos empresariales sugieren una empresa española modesta, aunque dichos recuentos son incompletos y no deben tratarse como una cifra de fuerza laboral auditada.

La pregunta relevante para el comprador no es el total de empleados; es cuántas personas calificadas pueden actuar en este servicio a las 03:00, con qué rapidez se une una segunda persona, y quién tiene autoridad para llamar a una emergencia del sitio o del operador.

El inventario de reparaciones conecta el trabajo con el hardware. Las manos remotas pueden volver a colocar un cable o reemplazar una unidad fallida conocida solo cuando existen la pieza y el procedimiento. Los controladores de almacenamiento empresarial, las unidades coincidentes, los transceptores propietarios y los componentes GPU pueden tener plazos de entrega largos. La compatibilidad del firmware puede hacer que un reemplazo nominal sea inutilizable.

Un proveedor que vende nube privada gestionada debe revelar qué componentes se mantienen en el sitio, cuáles están cubiertos por la respuesta del proveedor y qué degradación temporal es aceptable mientras un clúster espera la reparación completa.

Las ventanas de mantenimiento crean el riesgo más sutil. Parchear hipervisores, almacenamiento, enrutadores y equipos ópticos es necesario, pero cada acción consume redundancia. Una actualización progresiva de host es de bajo riesgo si las cargas de trabajo pueden moverse y existe capacidad sobrante. Es de mayor riesgo cuando un sitio ya está degradado o cuando una ruta de fibra está en mantenimiento. Los clientes necesitan reglas de notificación, períodos de bloqueo y una declaración de si el trabajo planificado cuenta para la disponibilidad.

La facturación y el control de cuentas pueden impedir que una máquina sana sea útil

El fallo de la nube no siempre es eléctrico. Una disputa de facturación, un método de pago caducado, un error de cuota, un problema de licencia o una suspensión de cuenta equivocada pueden hacer que una capacidad por lo demás sana no esté disponible. TodoEnCloud enfatiza un único punto de contacto y una factura en todos los servicios gestionados. Eso simplifica la adquisición, pero también puede hacer que la relación de cuenta sea una dependencia común a través del cómputo, la conectividad, la copia de seguridad y el soporte.

Lostérminos y condicionesgenerales del sitio web dicen que pueden aplicarse contratos adicionales de productos o servicios y tener prioridad. Eso es importante: los términos del sitio web no son el SLA de la nube. Un cliente debe revisar el pedido firmado, el calendario de servicio, los términos de procesamiento de datos y las reglas de uso aceptable para los desencadenantes de suspensión, notificación, períodos de subsanación, cálculo de créditos, retención de datos después de la terminación y el tratamiento de una factura disputada.

La cuota es otro control comercial. El lenguaje de pago por uso puede implicar una expansión ilimitada, pero ninguna nube regional tiene servidores infinitos. Una solicitud de API puede fallar porque la cuota del inquilino es baja, la forma de hardware solicitada no está disponible o la capacidad está reservada para otra persona. La arquitectura de recuperación que asume que puede crear cientos de instancias después del incidente puede fallar precisamente porque todos necesitan capacidad sobrante al mismo tiempo. La capacidad de recuperación reservada cuesta dinero porque no puede venderse dos veces.

Un contrato sólido separa la elasticidad ordinaria de la reserva para desastres. Dice qué recursos están garantizados, cuáles son de mejor esfuerzo, con qué rapidez puede aumentarse la cuota y si un sitio de recuperación mantiene disponible una capacidad equivalente. También identifica el remedio. Los créditos de servicio pueden compensar parte de una tarifa mensual, pero rara vez cubren las ventas perdidas del cliente, la exposición regulatoria o el trabajo de recuperación. Por lo tanto, la arquitectura debe prevenir las pérdidas en lugar de confiar en los créditos para reembolsarlas.

La ubicación española es significativa, pero la soberanía es una pila

La localidad de los datos es central en la oferta de TodoEnCloud. La compañía dice que sus centros de datos de nube pública están en España y que no transfiere información fuera de Europa. El certificado ENS sitúa los sistemas IaaS auditados en tres instalaciones del área de Madrid. La entidad legal española y la matriz Tessi son identificables. Para los compradores que buscan una ubicación operativa española, estas son ventajas concretas sobre una vaga etiqueta de región europea.

La ubicación no responde a todas las cuestiones de soberanía. Los proveedores de hardware pueden ser extranjeros. El software de soporte, la emisión de tickets, la telemetría, los servicios de dominio y la inteligencia de amenazas pueden implicar otras jurisdicciones. Un servicio multinube gestionado puede administrar cargas de trabajo en AWS, Azure o Google Cloud. Los metadatos de copia de seguridad pueden viajar de manera diferente a los datos de carga útil. Una matriz francesa puede tener acceso de gobernanza o soporte incluso cuando los servidores permanecen en Madrid.

Ninguna de estas condiciones derrota automáticamente la soberanía; cada una pertenece al mapa de flujo de datos.

Lapolítica de seguridadde la compañía alinea su alcance con los estándares ISO y el Esquema Nacional de Seguridad de España. ElReal Decreto 311/2022de España exige que la seguridad se trate como un proceso integral e incluye continuidad, respuesta a incidentes, protección de la información almacenada y transmitida, y auditoría. Por lo tanto, la certificación ENS Media es más sustantiva que un eslogan de localidad autodeclarado. Sigue siendo una evaluación de categoría y alcance, no una opinión legal específica para el cliente.

Los compradores deben documentar dónde residen los datos primarios, las réplicas, las copias de seguridad, los registros y los registros de soporte; quién puede acceder a ellos; qué claves de cifrado los protegen; y qué ley rige a cada proveedor. También deben distinguir la residencia de datos de la autonomía operativa. Una carga de trabajo almacenada en Madrid puede seguir dependiendo de un repositorio de software remoto, un servidor de licencias o un proveedor de identidad. Un diseño soberano puede elegir esas dependencias conscientemente y proporcionar alternativas donde el negocio las requiera.

La concentración física en Madrid crea un compromiso. Ofrece una clara residencia española y un diseño multisitio de baja latencia. No proporciona una amplia dispersión geográfica. Los clientes que enfrentan un requisito de una copia distante pueden necesitar otra región española, un objetivo local, capacidad de Tessi en otro lugar de Europa o un segundo proveedor. Esa elección debe estar impulsada por el modelo de amenazas y la necesidad legal, no solo por la palabra soberano.

El software abierto ayuda a la salida, pero la migración sigue siendo una transferencia física

TodoEnCloud dice que más del 90 por ciento de su núcleo se basa en software de código abierto y presenta acceso a API, Terraform y OpenTofu. Suservicio multinubee híbrido enfatiza métodos documentados, cargas de trabajo distribuidas y una dependencia reducida de un proveedor. Estas elecciones pueden mejorar la portabilidad al usar imágenes familiares, orquestación e interfaces de objetos en lugar de formatos propietarios únicos.

No hacen que la salida sea instantánea. Un cliente debe exportar discos virtuales, bases de datos, almacenes de objetos, instantáneas, políticas de acceso, definiciones de red, secretos e historial de monitoreo. Grandes volúmenes de datos están limitados por la velocidad del enlace y pueden tardar días o semanas. Las aplicaciones pueden depender de balanceadores de carga específicos del proveedor, catálogos de copias de seguridad, comportamiento del cortafuegos u operaciones gestionadas. Una imagen de origen puede ser abierta mientras que el conocimiento operativo requerido para ejecutarla reside en los ingenieros de TodoEnCloud.

La Ley de Datos de la UE hace que esta cuestión sea especialmente oportuna. Laexplicación de la Ley de Datosde la Comisión Europea dice que los clientes de nube y periferia deben poder cambiar de proveedor y que los cargos por cambio, incluidos los cargos por salida de datos para el proceso de cambio, deben eliminarse a partir del 12 de enero de 2027. El reglamento exige información contractual sobre procedimientos, formatos, restricciones y tiempo estimado, y espera que los proveedores de infraestructura faciliten resultados funcionalmente equivalentes cuando sea posible.

La ley puede eliminar obstáculos contractuales; no puede derogar el ancho de banda o la complejidad de la aplicación. Una salida limpia aún necesita un inventario de activos actual, exportación legible por máquina, capacidad de destino, transferencia segura de claves, sincronización final, validación y una decisión de reversión. Si el hardware es propiedad del cliente y está colocado, el plan también necesita liberación física, embalaje, envío y seguro. Si TodoEnCloud es propietaria del hardware, el cliente necesita imágenes y datos en lugar del servidor en sí.

La mejor prueba de portabilidad es una migración parcial realizada antes de la terminación. Exportar una carga de trabajo representativa, restaurarla en otro lugar, medir la tasa de transferencia, identificar dependencias no documentadas y confirmar que la copia antigua puede eliminarse después de la aceptación. Esta prueba también revela si una copia de seguridad es utilizable fuera de la propia plataforma del proveedor. Un plan de salida escrito solo después de que la calidad del servicio disminuye ya es tarde.

Las rutas de fallo prácticas están correlacionadas

La arquitectura de tres sitios de TodoEnCloud proporciona varias formas de limitar un incidente, pero el impacto en el cliente depende de dónde permanece la correlación.

Un fallo de rack puede detener un host o una estantería de almacenamiento. Los clientes con instancias en otro rack pueden no ver interrupción; un solo inquilino de bare metal puede esperar la reparación. Un evento de energía o refrigeración del edificio puede eliminar una zona entera. Los clientes distribuidos en sitios con alimentación independiente pueden continuar, mientras que los recursos de un solo sitio no pueden. Un corte de fibra puede aislar el tráfico de almacenamiento o gestión incluso cuando cada edificio permanece alimentado. La protección del anillo ayuda solo si la ruta alternativa tiene capacidad y la capa óptica reconverge.

Un fallo ascendente puede cambiar la accesibilidad sin dañar los servidores. Tres proveedores observados son alentadores, pero un borde compartido o un fallo en la política de ruta puede afectar a todos. Un error de software de almacenamiento puede propagarse a través de los sitios si se utiliza la misma versión y automatización en todas partes. Una credencial de administrador comprometida puede eludir la diversidad física. Una actualización defectuosa puede derribar un plano de control común. La redundancia geográfica es más débil contra fallos deliberadamente replicados por consistencia.

La escasez de hardware alarga la reparación cuando falla un nodo especializado. La saturación del soporte alarga el diagnóstico durante un evento amplio. Los errores de facturación o identidad pueden denegar el acceso a través de instalaciones sanas. Una copia de seguridad mantenida bajo las mismas credenciales puede eliminarse con la producción. Una migración puede estancarse porque la capacidad de destino o el tiempo de salida nunca se reservaron. Cada ruta cruza capas técnicas y contractuales.

Quién se ve afectado también varía. Un cliente con una sola máquina virtual puede perder un sitio web y sus usuarios. Un cliente de nube privada gestionada puede perder una aplicación empresarial, el acceso del personal y los proveedores dependientes. Un organismo público que utiliza un servicio con alcance ENS puede tener deberes de información y continuidad. TodoEnCloud enfrenta costes de reparación, créditos y daños a la reputación. Los operadores de instalaciones y de red enfrentan sus propios compromisos de servicio. Tessi asume el riesgo comercial a nivel de grupo.

El incidente es un evento, pero las consecuencias se distribuyen a lo largo de la cadena.

Lo que haría completo el caso de resiliencia

TodoEnCloud ya ha revelado más infraestructura verificable que muchas marcas de nube pequeñas. Un comprador puede nombrar al proveedor legal y la matriz, visitar tres direcciones de instalaciones, inspeccionar los certificados actuales, observar el espacio de direcciones enrutado e identificar múltiples redes ascendentes activas. Esos hechos justifican una evaluación de evidencia operativa Fuerte.

El trabajo restante es específico del cliente. Antes de tratar un despliegue como resiliente al sitio, el comprador debe obtener un mapa de componentes que muestre dónde se ejecutan los sistemas de cómputo, almacenamiento, control, identidad, cortafuegos, copia de seguridad, monitoreo y soporte. El mapa debe identificar al operador de la instalación, la ruta de energía, la ruta del operador y la entrada de fibra en cada sitio sin exponer detalles de seguridad sensibles. Debe indicar qué elementos son activo-activo, activo-pasivo o de un solo sitio.

La evidencia de capacidad debe conciliar los recursos instalados, vendibles y de recuperación. Debe mostrar el margen por sitio para las formas contratadas, la reserva de almacenamiento después de la replicación, la capacidad de red después de un fallo de tramo u operador, y los plazos de entrega para el hardware de reemplazo. El proveedor no necesita publicar la economía de la flota al mundo, pero el cliente que confía en la recuperación necesita una asignación defendible.

El calendario de servicio debe definir la disponibilidad a nivel del recurso adquirido, no simplemente citar los niveles de las instalaciones. Debe especificar la medición, el mantenimiento, las exclusiones, la respuesta de soporte, la prioridad de restauración, los créditos de servicio, la retención de datos y las salvaguardas de suspensión de cuentas. Los términos de copia de seguridad deben indicar la ubicación, la inmutabilidad, la retención, la propiedad del cifrado, el punto de recuperación y el tiempo de recuperación. La sección de salida debe enumerar formatos, interfaces, capacidad de salida, asistencia y evidencia de eliminación.

Finalmente, las partes deben probar. Simular la pérdida de un host, una ruta de almacenamiento, un proveedor de tránsito y un enlace de centro de datos. Restaurar una carga de trabajo desde la copia de seguridad separada. Contactar al soporte a través del canal secundario. Exportar un servicio representativo a otro entorno. Registrar el tiempo y los pasos manuales. Una prueba exitosa es mejor evidencia que otro adjetivo de disponibilidad.

El atractivo de TodoEnCloud es que ofrece una alternativa española visible a una nube global impersonal, con personas cercanas a la arquitectura y tres instalaciones reales de Madrid debajo. Esa cercanía puede ser valiosa. También hace que el trato subyacente sea más fácil de ver: los clientes no están comprando computación sin peso, sino una reclamación gestionada sobre racks, energía, fibra, inventario y atención especializada. El servicio es resiliente cuando esas reclamaciones están separadas, reservadas y ensayadas.

Hasta que el diseño específico del cliente demuestre eso, la plataforma de tres sitios es una capacidad creíble con opciones de recuperación, no una garantía automática de que cada carga de trabajo sobrevivirá a cada fallo.