Resumen
- Own Cloud Networks tiene una huella pública más fuerte de lo que sugeriría un simple nombre de empresa. Los registros RDAP de APNIC muestran ORG-OCN2-AP, AS134606, una asignación IPv4 160.250.204.0/23 y una asignación IPv6 2001:df4:bf40::/48, con contactos de registro y abuso vinculados a buzones de Own Cloud Networks y WebDedis.
- Las pruebas de enrutamiento actuales no demuestran que el ASN de Own Cloud opere de forma independiente. RIPEstat mostraba AS134606 sin prefijos anunciados y con visibilidad RIS cero a las 08:00 UTC del 12 de julio de 2026, mientras que 160.250.204.0/24, 160.250.205.0/24 y 2001:df4:bf40::/48 eran visibles con origen en AS140641, YOTTA Network Services Private Limited. Hurricane Electric muestra el mismo patrón práctico: los prefijos de Own Cloud son anunciados por Yotta y constan como válidos para ese origen.
- La superficie comercial de WebDedis vende VPS baratos, alojamiento web, colocación en centros de datos indios, servidores dedicados, variantes de VPS gestionados y autogestionados, alojamiento cPanel, alojamiento de aplicaciones, alojamiento para revendedores y soporte. Esas páginas son una prueba útil de un negocio de alojamiento orientado al cliente, pero no demuestran la propiedad de los racks, la redundancia de las instalaciones, la disponibilidad de hardware de repuesto, la diversidad de tránsito, la independencia de las copias de seguridad ni el tiempo de recuperación que recibiría un cliente concreto.
- La degradación operativa es, por tanto, «visible pero con recuperación no probada». Los compradores deben verificar la ubicación del centro de datos, si Yotta es solo tránsito o una dependencia de alojamiento más profunda, qué ocurre si se retira la ruta originada por Yotta, qué equipo de soporte puede actuar fuera del horario laboral, cómo se restauran las copias de seguridad fuera de la ruta fallida y si los datos pueden exportarse antes de que un fallo de facturación, hardware, enlace ascendente o portal provoque una interrupción del negocio.
El registro público muestra una huella real, no un caso de resiliencia probada
La primera distinción útil con Own Cloud Networks es entre existencia y resiliencia. El registro público respalda la existencia. Elregistro RDAP de AS134606de APNIC identificaOWNCLOUDNETWORKS-AS-APcomo Own Cloud Networks en India, con registro el 6 de diciembre de 2024 y última modificación el 2 de julio de 2025. Laentidad de organización ORG-OCN2-APde APNIC nombra a Own Cloud Networks, indica una dirección en Gurugram, un número de teléfono y utiliza[email protected]como contacto de correo electrónico. Laentidad de administrador de Own Cloud Networksy laentidad de abuso IRTusan la misma dirección en Gurugram y[email protected]. Eso constituye un rastro tangible de identidad como operador de red.
El rastro de los recursos de numeración también es tangible. Elregistro RDAP IPv4 de 160.250.204.0de APNIC muestra el rango 160.250.204.0-160.250.205.255 comoOWNCLOUDNETWORKS-IN, asignado de forma portable, país IN, registrado el 11 de diciembre de 2024. Elregistro RDAP IPv6de APNIC muestra 2001:df4:bf40::/48 asignado de forma portable a la misma organización. No son páginas de marketing. Son registros de recursos de numeración de Internet.
La superficie de servicios de cara al cliente es visible a través de WebDedis. Lapágina de inicio de WebDedisanuncia alojamiento web, alojamiento VPS y servidores dedicados, describe la oferta como alojamiento barato con soporte 24x7 y muestra la navegación de productos para servidores dedicados, VPS, alojamiento web, alojamiento de aplicaciones y dominios. Lapágina de VPS baratosvende planes de VPS indios con VPS Linux KVM, acceso root completo, una dirección IPv4 dedicada, líneas de ancho de banda y la característica "centro de datos en India". Lapágina de servidores dedicadosanuncia servicio de servidores dedicados en India, Estados Unidos y Europa. APNIC no indica que todos los productos de WebDedis sean operados directamente por Own Cloud Networks, pero los contactos de APNIC utilizan buzones de WebDedis, lo que convierte a la superficie de WebDedis en evidencia relevante de la huella operativa de Own Cloud.
Eso basta para rechazar la interpretación más débil. No se trata de un mero nombre de directorio sin señales de infraestructura. Tiene un ASN, espacio de direcciones, contactos de abuso, páginas de servicio y visibilidad de rutas activas para sus prefijos. Pero ese mismo registro no responde a la pregunta más importante para el cliente: si una carga de trabajo falla, ¿dónde está exactamente lo que falla, quién lo controla y cómo se recupera el cliente?
Esa brecha es importante porque los productos que se venden no son solo suscripciones de software. Un VPS es una partición de servidores físicos. Un servidor dedicado es una caja concreta o un pequeño conjunto de cajas. El alojamiento web depende de paneles de control, almacenamiento compartido, colas de correo, DNS, bases de datos, copias de seguridad y personal de soporte. Un dominio o una cuenta de facturación pueden formar parte de la ruta de recuperación.
La etiqueta de marketing puede ser «nube», pero la ruta de fallo sigue pasando por racks, alimentación eléctrica, refrigeración, fibra, origen de ruta, inventario de repuestos y personas capaces de hacer cambios bajo presión.
El juicio de este artículo es, por tanto, mixto. Own Cloud Networks tiene evidencia pública creíble de una huella de alojamiento activa. Aún no posee evidencia pública suficiente para considerar esa huella como infraestructura cloud independientemente resiliente. La lectura responsable no es «evitar por defecto», sino «verificar antes de confiar en ella para un sistema que no puede tolerar un rescate manual».
WebDedis vende economía de alojamiento: precios bajos, planes pequeños y riesgo físico compartido
Las páginas de WebDedis dejan claro el modelo comercial. La oferta está dirigida a compradores que buscan alojamiento web de bajo coste, servicio VPS, servidores dedicados y alojamiento de aplicaciones comunes, no a empresas que buscan un contrato de resiliencia multirregional completamente auditado. El título de la página de inicio describe «El mejor alojamiento web barato, alojamiento VPS y servidores dedicados». La página de VPS baratos anuncia VPS indios desde 99 rupias al mes, y sus datos estructurados indican que el servicio es una oferta VPS.
La página explica el VPS como servidores físicos dedicados divididos en múltiples servidores virtuales, donde cada nodo opera de forma independiente con recursos de CPU, RAM, almacenamiento y sistema operativo asignados.
Esa descripción es útil porque expone el límite de la abstracción. Un cliente puede comprar un plan virtual pequeño, pero el proveedor aún debe colocar ese plan en un nodo anfitrión con capacidad finita de CPU, memoria, disco, red y alimentación. Un precio de entrada bajo puede ser perfectamente razonable para sitios de desarrollo, sitios web de pequeñas empresas, aplicaciones de poco tráfico, entornos de prueba y clientes que saben que están comprando una recuperación basada en el mejor esfuerzo. No es por sí mismo una prueba de capacidad de reserva.
El menú de productos también muestra una variedad de modelos de control del servicio. WebDedis enumera VPS baratos, VPS cPanel, VPS autogestionados, VPS totalmente gestionados, VPS Windows autogestionados y VPS Windows totalmente gestionados. Esa distinción cambia la ruta de fallo. En un VPS autogestionado, el cliente puede asumir la carga del mantenimiento del sistema operativo mientras el proveedor es responsable del nodo, la alimentación, la red y la capa de virtualización. En un VPS totalmente gestionado, el cliente puede esperar más ayuda en la capa de software.
El límite del soporte debe estar por escrito, porque el momento del fallo suele ser cuando «gestionado» se vuelve ambiguo.
El servicio de servidores dedicados crea una dependencia diferente. Lapágina de servidores dedicadosanuncia una oferta de servidores dedicados y navegación a páginas de servidores dedicados Linux y Windows para India, Estados Unidos y Europa. Un servidor dedicado puede reducir el riesgo de vecinos ruidosos, pero aumenta la exposición al riesgo de inventario de hardware y ventanas de reparación. Si una placa base, SSD, fuente de alimentación, NIC o controlador RAID falla, la recuperación depende de piezas de repuesto, derechos de acceso, manos remotas y la disposición del proveedor para reemplazar o migrar la caja rápidamente. El cliente puede tener más control sobre el sistema operativo pero menos elasticidad que en una gran nube pública.
El alojamiento web y el alojamiento cPanel añaden otra capa. Lapágina de alojamiento cPanely otras páginas de alojamiento anuncian características de alojamiento compartido como bases de datos, cuentas de correo electrónico, ubicación en centros de datos indios, lenguaje de tiempo de actividad y soporte. El alojamiento compartido suele ser la forma más económica de mantener un sitio pequeño en línea, pero también es el lugar más fácil para que un fallo en un pool de almacenamiento, panel de control, subsistema de correo o proceso de copia de seguridad afecte a muchos clientes a la vez. El cliente pequeño a menudo no puede ver de qué servidor, volumen de almacenamiento o enlace ascendente depende.
El hecho económico importante no es que el alojamiento de bajo coste sea malo. El alojamiento de bajo coste es un mercado legítimo, y muchos sitios necesitan exactamente esa relación precio-rendimiento. Lo importante es que el alojamiento de bajo coste obliga al comprador a hacer preguntas más claras sobre qué se ha reservado. ¿Está incluida la copia de seguridad? ¿Es mensual, diaria o manual? ¿Está en el mismo sistema de almacenamiento? ¿Puede el cliente recuperarla sin un panel de control operativo? ¿Hay capacidad de reserva para reiniciar un nodo en otro lugar?
¿La promesa de soporte incluye la reparación del sistema operativo o solo la accesibilidad del nodo?
Si Own Cloud Networks y WebDedis quieren ser juzgados como infraestructura resiliente en lugar de capacidad barata, la evidencia pública debería ir más allá del menú de productos y el precio. Debería mostrar la ubicación de las instalaciones, la topología de los enlaces ascendentes, la arquitectura de copias de seguridad, la escalación del soporte, las ventanas de mantenimiento y la restauración probada. A falta de esa evidencia, la lectura más justa es comercial: esto es una huella minorista de alojamiento y VPS con recursos visibles, no una plataforma cloud independiente documentada públicamente.
La evidencia de enrutamiento es real, pero pasa por Yotta
La evidencia técnica más sólida está en la capa de espacio de direcciones. La parte más débil es el enrutamiento independiente. El 12 de julio de 2026, la consulta deprefijos anunciados de RIPEstat para AS134606no devolvió prefijos en la ventana de consulta de dos semanas. La consulta deestado de enrutamiento de RIPEstat para AS134606informó de visibilidad IPv4 e IPv6 cero, espacio anunciado cero y cero vecinos observados a las 08:00 UTC del momento de la consulta. Elresumen de ASde RIPEstat describió AS134606 comoOWNCLOUDNETWORKS-AS-AP - Own Cloud Networkspero lo marcó como no anunciado.
El espacio de direcciones de Own Cloud sí es visible. La consulta deestado de enrutamiento de RIPEstat para 160.250.204.0/24mostró el prefijo visto por primera vez el 7 de enero de 2025, visto por última vez el 12 de julio de 2026, con origen AS140641 y visibilidad en 325 de 325 pares IPv4 de RIS. Laconsulta para 160.250.205.0/24mostró el mismo origen y visibilidad IPv4 completa. Laconsulta para 2001:df4:bf40::/48mostró origen AS140641 y visibilidad IPv6 completa en 322 de 322 pares IPv6 de RIS. En términos sencillos, los prefijos eran visibles globalmente, pero no desde el propio ASN de Own Cloud.
AS140641 pertenece a Yotta Network Services Private Limited en el registro de APNIC. Elregistro RDAP de AS140641de APNIC nombra aYOTTAen India, registrado en 2020. Elresumen de AS de RIPEstat para AS140641indica que el titular esYOTTA - YOTTA NETWORK SERVICES PRIVATE LIMITEDy marca el ASN como anunciado. Losdatos de prefijos anunciados de RIPEstat para AS140641incluyen los dos /24 IPv4 y el /48 IPv6 de Own Cloud en la vista actual de dos semanas.
El BGP Toolkit de Hurricane Electric corrobora esa división. Lapágina de AS134606identifica a Own Cloud Networks en India pero muestra cero prefijos originados y cero anunciados. Las páginas de160.250.204.0/24,160.250.205.0/24y2001:df4:bf40::/48muestran cada una a Own Cloud Networks como el registrante del prefijo y a AS140641, Yotta Network Services Private Limited, como el origen del anuncio. También muestran validez IRR y RPKI para ese origen.
El RPKI es especialmente revelador. Las vistas de validación RPKI de RIPEstat para160.250.204.0/24,160.250.205.0/24y2001:df4:bf40::/48muestran a AS140641 como origen válido. Los mismos datos también muestran entradas de AS134606 que serían inválidas como origen para esos anuncios de prefijos específicos en el momento de la consulta. Eso no es automáticamente un problema. Podría reflejar un acuerdo de enrutamiento alojado de forma intencionada. Pero sí significa que un cliente no debería tratar el propio ASN de Own Cloud como el límite de resiliencia activa a menos que Own Cloud pueda explicar el diseño de enrutamiento.
Este es el hallazgo central de red del artículo. Own Cloud Networks parece controlar recursos de numeración, y esos recursos son visibles en la Internet global. El origen de ruta visible, sin embargo, es Yotta. Eso podría ser un diseño sensato: un proveedor de alojamiento más pequeño puede utilizar una red india más grande para el enrutamiento ascendente, la colocación en centros de datos o ambas cosas. Pero convierte a Yotta en parte de la cadena de dependencia del cliente.
Si la política de rutas, las instalaciones, la interconexión, la relación de cuenta o la cola de soporte de Yotta fallan, los recursos públicos de Own Cloud pueden verse afectados incluso si la marca de Own Cloud y el panel del cliente siguen activos.
La pregunta técnica del comprador es, por tanto, específica: ¿es Yotta solo un origen de ruta ascendente para los prefijos asignados a Own Cloud, o es Yotta también la dependencia de centro de datos, rack, alimentación, manos remotas y acceso de emergencia? El registro público no responde a eso. Hasta que lo haga, un cliente debe tratar a Yotta como un proveedor crítico en la ruta del servicio.
El lenguaje de centro de datos indio ayuda a la localidad, pero no prueba el dominio de fallo
Las páginas de WebDedis utilizan repetidamente lenguaje de alojamiento indio. La página de VPS baratos anuncia «centro de datos en India» como una característica. Varias tablas de alojamiento web utilizan «centro de datos indio». La página de inicio y la navegación de productos orientan a los compradores indios hacia alojamiento local de bajo coste y VPS. Para muchos clientes, eso es una ventaja real.
Una huella de centro de datos local puede reducir la latencia, simplificar los pagos, mantener el soporte en un mercado familiar y facilitar las discusiones sobre la ubicación de los datos en comparación con un proveedor de alojamiento compartido extranjero.
Sin embargo, localidad no es lo mismo que resiliencia. Un servicio puede estar en India y aun así tener un solo rack, una sola dependencia ascendente, un solo pool de almacenamiento, una sola ubicación de copias de seguridad, un solo sistema de facturación y una sola cola de soporte. También puede estar en un gran centro de datos indio mientras el cliente no tiene derecho contractual a contactar con el operador de las instalaciones, ni visibilidad sobre las alimentaciones eléctricas, ni garantía de que otro rack o sala tenga capacidad reservada para la conmutación por error.
La evidencia pública no identifica la sala o el rack exactos donde se ejecutan las cargas de trabajo de Own Cloud/WebDedis. No dice si la afirmación de centro de datos indio se refiere a instalaciones de Yotta, a otro proveedor de colocación, a un conjunto de servidores alquilados, a un acuerdo de reventa o a múltiples ubicaciones. No dice si los servidores dedicados en India son propiedad de WebDedis, alquilados a otro proveedor o aprovisionados a través de un socio mayorista. No dice si los hosts VPS, los nodos de alojamiento web, las copias de seguridad y los paneles de control se encuentran en la misma instalación.
Esa incertidumbre cambia lo que «soberanía y localidad de datos» debería significar para un comprador. No basta con preguntar si el servicio es indio. El comprador necesita saber dónde se almacenan los datos de producción, dónde se almacenan las copias de seguridad, dónde se almacenan los registros, desde dónde puede originarse el acceso de soporte y si aparece alguna ubicación no india en la ruta de recuperación. Una página de marketing puede decir India. Un contrato y una prueba de restauración deberían mostrar la ruta de datos real.
LaLey de Protección de Datos Personales Digitales de 2023convierte la gobernanza de datos personales en un asunto de nivel directivo para las organizaciones indias. No convierte a cada VPS indio en un diseño que cumpla automáticamente. Los clientes siguen necesitando obligaciones para el procesador, procedimientos de notificación de violaciones, compromisos de eliminación, controles de acceso y registros que muestren dónde residen los datos y las copias de seguridad. Si una pequeña empresa utiliza WebDedis para alojar formularios de clientes, registros escolares, citas clínicas, pedidos minoristas o documentos de empleados, necesita evidencia de que la ubicación del alojamiento y la gestión de copias de seguridad coinciden con sus responsabilidades legales.
Lasdirectrices de incidentes cibernéticos de CERT-Intambién son relevantes para las operaciones de alojamiento porque establecen expectativas de notificación de incidentes y retención de registros para proveedores de servicios y usuarios en India. La cuestión para los clientes de Own Cloud es práctica: si un servidor alojado se ve comprometido, suspendido, restaurado o migrado, ¿quién tiene los registros, durante cuánto tiempo se conservan y puede el cliente obtenerlos con la suficiente rapidez para cumplir con sus obligaciones?
Para los clientes financieros regulados, ladirectriz maestra del RBI sobre externalización de TIes un recordatorio de que externalizar operaciones en la nube o de alojamiento no externaliza la responsabilidad. Incluso cuando el proveedor es pequeño, el cliente debe comprender la subcontratación, el acceso a los datos, los derechos de auditoría, la continuidad del negocio y los acuerdos de salida. Las páginas públicas de Own Cloud no publican esas respuestas para clientes regulados. Eso no inhabilita el servicio para uso ordinario. Significa que el uso regulado necesita evidencia privada.
La localidad de datos es, por tanto, un beneficio solo cuando es explícita. La ubicación en India puede ser valiosa. La huella visible de APNIC y WebDedis de Own Cloud es india. Pero ningún comprador debería equiparar «centro de datos indio» con «protección de datos independiente, copia de seguridad independiente y recuperación probada».
La principal ruta de fallo es el rack, el origen de ruta, el soporte y la facturación juntos
La ruta de fallo probable para Own Cloud Networks no es un evento dramático único. Es un conjunto de dependencias ordinarias que se vuelven visibles al mismo tiempo. Un rack pierde alimentación. Un nodo falla. Un dispositivo de almacenamiento se degrada. Se retira una ruta. Un filtro DDoS cambia. Se suspende una cuenta de facturación. Un cliente no puede acceder al panel. Un ticket de soporte espera en una cola. Cada evento es manejable de forma aislada. Juntos definen si el proveedor es un servicio en la nube o un conjunto de alojamiento frágil.
La ruta del rack es la más simple. Si un host VPS falla, el cliente necesita saber si las máquinas virtuales se reinician automáticamente en otro lugar o si el soporte debe intervenir. Si un servidor dedicado falla, el cliente necesita saber si hay hardware de repuesto en el sitio, si los discos se pueden mover, si el reemplazo está cubierto y si el cliente o el proveedor es propietario de los medios que contienen los datos. Si el alojamiento compartido falla, el cliente necesita saber si el panel de control, la base de datos y las colas de correo se pueden restaurar de forma independiente.
La ruta ascendente es más específica debido al enrutamiento originado por Yotta. Si AS140641 deja de anunciar 160.250.204.0/24, 160.250.205.0/24 o 2001:df4:bf40::/48, la accesibilidad pública del cliente podría desaparecer incluso si los servidores de Own Cloud siguen encendidos. Si el problema es una política de rutas de Yotta, Own Cloud debe tener una vía de escalación hacia Yotta. Si el problema es una falla de interconexión o de las instalaciones, Own Cloud debe tener autoridad para abrir el incidente adecuado. Si el problema es una relación comercial, el cliente puede no tener ninguna palanca directa.
La ruta del portal y la facturación es más silenciosa pero igual de importante. Muchos proveedores de alojamiento barato centralizan el estado de la cuenta, las renovaciones, la suspensión del servicio, las copias de seguridad y el soporte en un único panel de facturación. Si el panel no está disponible o un error de facturación suspende el servicio, el cliente puede quedar bloqueado sin acceso a los mismos datos que necesita migrar. Las páginas de WebDedis enlazan a un inicio de sesión de facturación y flujos de pedido. Eso es normal.
Los compradores aún deberían preguntar qué sucede cuando un estado de facturación entra en conflicto con la recuperación de emergencia.
La ruta del soporte es donde el lenguaje del servicio se convierte en realidad operativa. WebDedis anuncia soporte 24x7 en sus páginas de inicio y alojamiento. Eso es útil, pero el soporte 24x7 puede significar muchas cosas: chat en vivo, teléfono, acuse de recibo de tickets, clasificación inicial, acción del administrador del sistema o manos remotas en el centro de datos. Un cliente pequeño necesita saber cuál de esas opciones se aplica a su plan. Un cliente más grande necesita una escalación nominada, tiempos de respuesta y la autoridad para aprobar cambios fuera del horario laboral.
La ruta de las copias de seguridad une todo esto. Si las copias de seguridad se almacenan en la misma instalación y están controladas por el mismo panel de cuenta, ayudan con los errores pero no con la falla de acceso al proveedor. Si las copias de seguridad son mensuales, pueden ser demasiado antiguas para un sistema empresarial. Si las copias de seguridad están gestionadas por el proveedor, el cliente necesita saber si puede recibir una copia mientras el servidor principal está caído. Si las copias de seguridad no están incluidas, el cliente necesita su propia copia fuera del proveedor antes de que algo se rompa.
La mejor prueba de fallo para Own Cloud no es, por tanto, una pregunta genérica sobre el tiempo de actividad. La prueba es: asumir que un rack o host está caído, se requieren cambios de ruta en AS140641, la cola de tickets estándar es lenta y el panel del cliente no está disponible. ¿Quién actúa, desde dónde, con qué credenciales y cómo consigue el cliente que los datos o el tráfico vuelvan a fluir?
Las afirmaciones de capacidad deben convertirse en capacidad de recuperación utilizable
Los proveedores de alojamiento a menudo venden capacidad instalada. Los clientes necesitan capacidad de recuperación utilizable. La diferencia es fácil de pasar por alto. La capacidad instalada es la cantidad total de CPU, RAM, disco y red disponible en todo el conjunto del proveedor. La capacidad de recuperación utilizable es la cantidad que puede absorber un fallo mientras el resto de los clientes continúan funcionando.
Las páginas de planes de WebDedis muestran tamaños y características de los planes, incluidos VPS pequeños, límites de ancho de banda, direcciones IPv4 dedicadas y ubicación en centros de datos indios. Esos son hechos del producto. No le dicen a un cliente si hay capacidad de reserva si el nodo subyacente falla. No dicen si una afirmación de 1 Gbps se aplica al puerto, al enlace ascendente compartido, a la política de uso justo del plan o a la ruta durante la congestión. No dicen si el I/O de almacenamiento es dedicado, compartido o respaldado por matrices compartidas.
Los servidores dedicados hacen que la capacidad sea más tangible pero no necesariamente más recuperable. Si un cliente alquila un servidor específico, esa capacidad está instalada porque la caja existe. La capacidad de recuperación requiere otra caja compatible, discos de repuesto o una restauración de imagen probada. También requiere una propiedad clara de las licencias y claves de software.
Si el proveedor no puede suministrar el mismo conjunto de instrucciones de CPU, la misma disposición de almacenamiento, la misma asignación de IP pública o el mismo estado del cortafuegos, la recuperación puede ser una reconstrucción en lugar de un reinicio.
La recuperación de VPS depende del clúster de virtualización. WebDedis describe los VPS como nodos virtuales en servidores físicos dedicados. Eso puede ser fiable si los hosts están bien gestionados, pero la resiliencia depende de si se utiliza disco local o almacenamiento compartido, si las instantáneas están fuera del host, si un nodo puede migrarse en caliente, si hay anti-afinidad disponible y si hay capacidad de host sobrante después de un fallo. Ninguno de esos detalles es visible públicamente.
La recuperación del alojamiento compartido depende de la pila del plano de control. Un servidor cPanel puede ser fácil de gestionar y fácil de respaldar, pero muchos hosts pequeños ejecutan servidores compartidos densos. Un solo fallo del servidor puede tumbar múltiples sitios de clientes, buzones de correo y bases de datos. El cliente debe preguntar si las copias de seguridad son por cuenta, dónde se almacenan, si la restauración es de autoservicio y si el proveedor ha restaurado un servidor completo recientemente.
La misma lógica se aplica a la capacidad IP. Own Cloud posee una asignación IPv4 /23 y una asignación IPv6 /48, pero la evidencia BGP muestra las piezas enrutadas como dos /24 IPv4 y un /48 IPv6 a través de Yotta. El espacio de direcciones ayuda a un host a evitar la dependencia del pool de IP de un tercero, pero debido a que el origen es Yotta, la capacidad de enrutamiento utilizable aún depende de ese acuerdo ascendente. Un cliente que necesite continuidad de IP estática debe preguntar si puede mantener las mismas direcciones si la relación de alojamiento, el rack o el enlace ascendente cambian.
La pregunta práctica de adquisición es simple: ¿qué se ha reservado para el fallo? Un plan VPS de bajo coste puede no reservar nada más allá de la gestión normal del host. Un plan de alojamiento empresarial puede incluir copia de seguridad mensual pero no conmutación por error rápida. Un servidor dedicado puede incluir reemplazo en el mejor esfuerzo. Un servidor gestionado puede incluir ayuda práctica pero no un segundo sitio. El comprador debe hacer coincidir el plan con el riesgo en lugar de asumir que la palabra «nube» significa que existe capacidad excedente.
Las copias de seguridad y la migración son la verdadera ruta de salida
Para un proveedor de alojamiento pequeño, el control más fuerte del cliente a menudo no es la conmutación por error dentro del proveedor. Es la capacidad de irse limpiamente. Eso comienza con las copias de seguridad, pero no termina ahí. Una copia de seguridad solo es útil si se puede restaurar fuera de la ruta fallida, con los datos correctos, claves, DNS, consistencia de la base de datos y configuración de la aplicación.
Laguía de planificación de contingencias del NISTtrata el análisis de impacto empresarial, las estrategias de recuperación, las pruebas de planes y el mantenimiento como controles centrales de continuidad. Laguía de seguridad de almacenamiento del NISTdistingue entre instantáneas, copias de seguridad, replicación, archivado y garantía de restauración. Esas distinciones son importantes para los clientes de Own Cloud. Una instantánea local en un nodo VPS no es lo mismo que una copia de seguridad fuera del proveedor. Una copia de seguridad mensual de alojamiento compartido no es lo mismo que una restauración probada. Una copia de seguridad en poder del proveedor no es lo mismo que una copia de salida en poder del cliente.
La cuestión de la portabilidad en la nube también es lo suficientemente antigua como para tener un marco claro. Lasinopsis y recomendaciones sobre la nube del NISTconecta los acuerdos de servicio, el rendimiento, la fiabilidad, la transferencia de datos, la seguridad y la portabilidad. Para un cliente de Own Cloud/WebDedis, eso significa preguntar no solo si los datos se pueden descargar, sino en qué formato, a qué velocidad, bajo qué estado de cuenta, con qué credenciales y mientras qué servicio está caído.
La superficie de productos de WebDedis incluye lenguaje sobre migración en algunas páginas y enfatiza actualizaciones sencillas y soporte. Ese es un lenguaje de ventas útil, pero debería convertirse en un manual de salida. Para un sitio web, el manual incluye archivos, bases de datos, zonas DNS, buzones de correo, certificados SSL, tareas cron, secretos de aplicación y credenciales de cuenta. Para un VPS, incluye imágenes de disco o scripts de reconstrucción, reglas de cortafuegos, claves SSH, monitorización y versiones de paquetes.
Para un servidor dedicado, incluye la disposición del disco, firmware, licencias, asignaciones de IP y hardware de reemplazo.
El cliente debe probar la salida mientras todo está en buen estado. Restaurar una copia en un proveedor diferente. Apuntar un dominio de prueba al host alternativo. Confirmar la integridad de la base de datos. Confirmar el flujo de correo electrónico. Confirmar que el antiguo proveedor puede suministrar una copia de seguridad utilizable sin súplicas manuales. Confirmar que la dependencia de la IP pública no está oculta dentro de listas de permitidos del cortafuegos, pasarelas de pago, integraciones API o glue de DNS.
Esto es especialmente importante para los clientes que utilizan el espacio de direcciones de Own Cloud para muchos sitios web pequeños. Las páginas de Hurricane Electric para 160.250.204.0/24 y 160.250.205.0/24 muestran muchas asignaciones de dominio bajo los prefijos. Esas señales pasivas de DNS y derivadas de certificados no prueban listas de clientes, ingresos o responsabilidad legal. Sí sugieren que el espacio de direcciones está sirviendo propiedades web reales.
Si esas propiedades incluyen pequeñas empresas, escuelas, clínicas, tiendas o empresas de servicios locales, es posible que sus propietarios no tengan personal separado de recuperación ante desastres. Su control de resiliencia más seguro es una copia de seguridad actual y portátil.
La migración no es una falta de confianza. Es una parte normal de poseer una carga de trabajo alojada. Un proveedor puede ser honesto, receptivo y técnicamente competente y aun así sufrir un evento de alimentación, enlace ascendente, facturación o hardware que supere su capacidad pública. El cliente que ha ensayado la migración puede tratar la interrupción como un incidente de servicio. El cliente que no ha ensayado la migración puede descubrir que su única copia del negocio está detrás del mismo panel fallido.
Quién se ve afectado cuando este sistema falla
Las partes afectadas son más amplias que el titular de la cuenta. Un plan de alojamiento barato puede albergar una tienda, escuela, clínica, sitio de noticias, agencia de viajes, organización comunitaria, portafolio de desarrollador o proveedor de software local. Si el host falla, la persona que compró el plan puede ser la única que conoce Own Cloud o WebDedis por su nombre, pero el impacto público lo sienten clientes, pacientes, estudiantes, donantes, personal, socios de pago, socios de entrega y personas que buscan información.
Las señales BGP y de dominios pasivos hacen ese riesgo concreto. Las páginas de Hurricane Electric para los prefijos IPv4 de Own Cloud muestran numerosos dominios asignados a direcciones dentro de 160.250.204.0/24 y 160.250.205.0/24. Esto no debe sobreinterpretarse. Las asignaciones DNS pueden estar obsoletas, el alojamiento compartido puede ubicar dominios no relacionados y la agregación de terceros puede incluir registros históricos. Aun así, la señal encaja con el modelo de productos de WebDedis: una huella de alojamiento densa para muchas propiedades web más pequeñas.
Cuando el alojamiento denso falla, la comunicación importa tanto como la reparación. El proveedor necesita un canal de estado que no dependa del conjunto de alojamiento fallido. Los clientes necesitan saber si deben esperar, restaurar en otro lugar, cambiar DNS, renovar un pago, contactar con el soporte por teléfono o evitar empeorar la situación. Un proveedor que solo se comunica a través del mismo portal o servidor de correo que falló deja a los clientes adivinando.
Los clientes más vulnerables son aquellos que combinan producción, copia de seguridad, DNS y soporte dentro de la misma cuenta. Si el panel del proveedor no está disponible, es posible que no puedan cambiar el DNS. Si las copias de seguridad se almacenan con el mismo proveedor, es posible que no puedan restaurar en otro lugar. Si el correo electrónico está alojado en el mismo servidor, es posible que no reciban mensajes de incidencia. Si la facturación también está vinculada a la misma cuenta, un problema de renovación o suspensión puede parecer una interrupción técnica.
Para los compradores profesionales, la respuesta es mapear las funciones empresariales, no solo los servidores. ¿Qué funciones necesitan sobrevivir: sitio web, base de datos, correo electrónico, pagos, reservas, ingreso de pacientes, gestión de aprendizaje, tickets de soporte, autenticación, intercambio de archivos, registros de auditoría? ¿Qué componente de Own Cloud o WebDedis soporta cada una? ¿Qué ruta alternativa funciona si ese componente no está disponible? ¿Qué persona está autorizada para moverlo? El mapeo puede ser breve, pero debe existir antes de la interrupción.
Para Own Cloud Networks, una mejor evidencia pública también ayudaría. Una página de estado, descripción de las instalaciones, explicación del enlace ascendente, política de copias de seguridad, proceso de abuso, alcance del soporte y documentación de recuperación en lenguaje claro reducirían la incertidumbre. Nada de eso requiere publicar arquitectura sensible. Simplemente permiten a los clientes distinguir el alojamiento de bajo coste basado en el mejor esfuerzo de la capacidad gestionada crítica para el negocio.
Preguntas de adquisición que deben responderse antes del uso en producción
Un comprador puede utilizar Own Cloud Networks o WebDedis de manera racional si la carga de trabajo coincide con la evidencia. Lo importante es hacer las preguntas correctas antes de que la primera factura se convierta en una dependencia.
Primero, pregunte sobre la ubicación de las instalaciones. ¿Qué centro de datos indio aloja el plan? ¿Es una instalación de Yotta, una sala de colocación separada o un proveedor de servidores al por mayor? ¿Hay más de una ubicación? ¿Están las copias de seguridad en la misma sala? ¿Están separados los hosts virtuales, paneles de control, facturación, DNS y sistemas de copia de seguridad? ¿Puede el cliente elegir o verificar la localidad?
Segundo, pregunte sobre el enrutamiento. ¿Por qué los prefijos de Own Cloud son originados por AS140641 en lugar de AS134606? ¿Está AS134606 reservado para uso futuro, política interna o conmutación por error? ¿Qué sucede si Yotta no puede originar las rutas? ¿Tiene Own Cloud un enlace ascendente u origen de ruta alternativo? ¿Son portátiles las IPs del cliente si el proveedor cambia de enlace ascendente? ¿Existe un plan RPKI para la conmutación por error que no haga que el origen alternativo sea inválido?
Tercero, pregunte sobre hardware y reparación. Para servidores dedicados, ¿quién es el propietario del servidor? ¿Qué piezas hay en stock? ¿Cuál es la ventana de reemplazo? ¿Se mueven los discos o se restauran desde la copia de seguridad? ¿Quién maneja los medios que contienen datos? Para VPS, ¿la falla del host es automática o manual? ¿El almacenamiento es local o compartido? ¿Hay suficiente capacidad de reserva para reiniciar las máquinas virtuales afectadas durante el mantenimiento?
Cuarto, pregunte sobre la autoridad de soporte. ¿Qué significa el soporte 24x7 para el plan adquirido? ¿Es acuse de recibo de tickets, resolución de problemas en vivo o acción de ingeniería? ¿Hay soporte telefónico disponible para incidentes críticos? ¿Quién puede escalar al centro de datos o a Yotta? ¿Recibe el cliente una ruta de emergencia nominada para cargas de trabajo en producción?
Quinto, pregunte sobre copias de seguridad y portabilidad. ¿Están incluidas las copias de seguridad? ¿Con qué frecuencia se realizan? ¿Dónde se almacenan? ¿Puede el cliente descargarlas sin un panel operativo? ¿Son las copias de seguridad de la base de datos consistentes con la aplicación? ¿Puede el proveedor restaurar en otro host? ¿Ha probado el cliente la restauración fuera de Own Cloud/WebDedis? ¿Qué sucede si el servicio se suspende o se disputa?
Sexto, pregunte sobre el proceso legal y de seguridad. ¿Qué registros se conservan? ¿Cómo se manejan los informes de abuso? ¿Cómo se protegen los datos, credenciales y copias de seguridad del cliente? ¿Cómo se apoyan las obligaciones indias de notificación de incidentes y protección de datos? ¿Qué subcontratistas pueden acceder al sistema? ¿Cuál es el proceso de salida cuando un cliente se va normalmente?
Estas preguntas no son excesivas. Son las preguntas normales ocultas debajo de cada compra de VPS barato. Cuanto más bajo es el precio mensual, más importante es saber qué riesgos están excluidos del trato.
El veredicto: huella de red visible, confianza operativa condicionada
Own Cloud Networks obtiene un hallazgo de huella real. Los registros de APNIC muestran una organización india, AS134606, recursos IPv4 e IPv6 portátiles, contactos vinculados a WebDedis y una entidad de abuso actualizada. WebDedis anuncia una superficie minorista de alojamiento activa en VPS, alojamiento web, servidores dedicados, alojamiento de aplicaciones, alojamiento para revendedores y soporte. RIPEstat y Hurricane Electric muestran los prefijos de Own Cloud visibles en la Internet global.
La degradación es igualmente clara. El origen de ruta activo es AS140641 de Yotta, no AS134606 de Own Cloud. Las páginas públicas no identifican la instalación exacta, el límite de propiedad, la ubicación de los racks, el modelo de hardware de repuesto, la ubicación de las copias de seguridad, el historial de restauraciones, la escalación del soporte o los derechos de portabilidad de datos. La evidencia respalda la disponibilidad del servicio como una huella de alojamiento; no respalda tratar a Own Cloud como una plataforma cloud independientemente resiliente sin pruebas privadas.
Para sitios de bajo riesgo, experimentos, pequeñas empresas con su propia copia de seguridad, cargas de trabajo de desarrollo y clientes que aceptan la recuperación manual, el servicio puede ajustarse al precio. Para datos regulados, producción de alta disponibilidad, sistemas de pago, registros de salud o escolares, sitios de servicio público, portales de clientes o cualquier carga de trabajo donde una restauración prolongada sería materialmente perjudicial, el listón de la diligencia es más alto. Esos clientes deben exigir una respuesta de recuperación por escrito antes de mover la producción.
La frase más importante para un comprador es simple: Own Cloud Networks vende capacidad alojada, y la capacidad parece real, pero el límite de recuperación no es público. El cliente debe comprar solo la resiliencia que puede ver, probar y exportar. Todo lo demás sigue siendo una suposición apoyada en un rack, una ruta originada por Yotta y una cola de soporte.