Resumen

  • kCore Cloud tiene una superficie operativa verificable. Su sitio web acepta pedidos de hosting compartido, su portal del cliente publicó un aviso de mantenimiento de emergencia en mayo de 2026, ARIN la identifica como titular de AS401197 y dos asignaciones de direcciones, y RIPEstat observó sus rutas IPv4 e IPv6 en todos los peers de alimentación completa informantes en julio de 2026.
  • La red visible es compacta y concentrada. AS401197 originó un /24 IPv4 y un /40 IPv6, con AS4213 como su único vecino observado. La ruta IPv6 tenía autorización válida de origen de ruta, mientras que la ruta IPv4 devolvió un estado desconocido porque no se encontró ninguna autorización de validación.
  • La afirmación de la empresa de que posee hardware y tiene su propio espacio de centro de datos es plausible pero no suficientemente localizada. Su sitio corporativo utiliza una dirección AS4213 dentro de un bloque registrado comoKRYPT-IAD1, y las mediciones de baja latencia desde Ashburn apuntan hacia el norte de Virginia, pero ninguna página pública de la empresa identifica una instalación, cantidad de racks, diseño eléctrico, inventario de repuestos o sitio de producción alternativo.
  • La garantía anual de red del 99.9% publicada excluye el mantenimiento programado, el trabajo de emergencia, las fallas de hardware o software reparadas en una hora, los ataques de denegación de servicio, el trabajo de soporte y varias otras clases de interrupción. Por lo tanto, es un remedio financiero limitado, no una prueba de que un sitio web, buzón de correo y panel de control puedan recuperarse dentro del tiempo requerido por el cliente.
  • El riesgo de copia de seguridad y localidad es explícito en el contrato. Se requiere que los clientes mantengan una copia independiente; una copia de seguridad alojada puede no estar disponible o estar corrupta; y los datos de la cuenta o las copias de seguridad pueden trasladarse a otro centro de datos, estado, país o continente. Un ASN estadounidense y una dirección en Texas no establecen dónde descansa cada copia del cliente.
  • El grado de evidencia es Medio. Las rutas actuales, el comercio en vivo y un aviso operativo reciente establecen que la empresa está activa, pero el único upstream observado, la ausencia de identidad pública de la instalación, el patrimonio de hardware no cuantificado, la vista de estado de red privada y la evidencia de recuperación limitada impiden una evaluación más sólida.

La promesa de pequeña empresa tiene una dirección física, pero aún no un mapa físico

kCore Cloud no se presenta como una utilidad inmensa. Supágina de iniciodice que es una pequeña empresa con su propio hardware y su propio espacio de centro de datos. Supágina acerca dela llama una pequeña empresa fundada por un experto en infraestructura de Internet. El producto actualmente visible para un comprador no autenticado es más limitado de lo que la palabra nube puede implicar: alojamiento compartido de sitios web y correo electrónico, registro de dominios, asistencia para migración y orientación técnica paga. Lapágina de hostingenumera planes con 5GB, 10GB o 40GB de almacenamiento SSD, asignaciones de bases de datos correspondientes y un número finito de cuentas de correo y dominios.

Eso no es una crítica. El hosting compartido sigue siendo un servicio de infraestructura importante para pequeñas organizaciones que no quieren operar un servidor, parchear una pila web, administrar el correo o negociar directamente con una empresa de colocación. El cliente compra una abstracción: un inicio de sesión, una cuota de almacenamiento, una base de datos, un certificado, buzones de correo y soporte. kCore a su vez debe ensamblar un sistema mucho menos abstracto.

Necesita servidores, discos, memoria, puertos de red, energía para racks, refrigeración, tránsito a Internet, servicios de dominio, software de facturación, monitoreo y personas capaces de intervenir cuando una de esas partes falla.

La frase "nuestro propio espacio de centro de datos" define solo parte de ese límite. Sugiere un modelo de colocación o espacio arrendado, no la propiedad de un edificio completo. En ese modelo, kCore puede ser propietaria de servidores y equipos de red mientras que otro operador controla la propiedad, las alimentaciones de servicios públicos, los generadores, los sistemas de alimentación ininterrumpida, la refrigeración, la extinción de incendios, el muelle de carga, la lista de acceso, la sala de interconexión y el servicio de manos remotas.

Un proveedor de red puede controlar los circuitos externos y los enrutadores a través de los cuales AS401197 llega a Internet. Esos arreglos pueden ofrecer un excelente servicio. También dividen la responsabilidad a través de contratos que un cliente de hosting compartido puede nunca ver.

Ninguna página pública de kCore revisada para este artículo identifica una instalación de producción por nombre o dirección postal. La dirección en Houston en elregistro ARINde la empresa coincide con la dirección registrada en sus términos legales, pero una dirección postal corporativa no es una ubicación de servidor. El sitio no publica una cantidad de racks, asignación de energía, inventario actual de servidores, espacio libre de almacenamiento, certificado de instalación o segunda región de producción. No dice si "espacio" significa parte de un gabinete, varios gabinetes, una jaula o capacidad obtenida a través de un proveedor de hosting.

Este mapa faltante cambia cómo se debe evaluar el servicio. Un comprador no puede asumir que la dirección legal en Houston es la ubicación de los datos. No puede asumir que dos equipos están en edificios diferentes porque tienen direcciones IP diferentes. No puede asumir que existen bahías de disco de repuesto, unidades de rack sin usar o energía no comprometida simplemente porque se aceptan nuevos pedidos. La primera pregunta de diligencia debida es, por lo tanto, simple: identificar el operador de la instalación, el área metropolitana, el edificio, la huella de racks y la propiedad del equipo para el servicio que se está comprando.

Hasta que kCore publique o suministre contractualmente esa respuesta, su ubicación física sigue siendo una hipótesis bien respaldada en lugar de un hecho verificado para el cliente.

AS401197 demuestra un borde activo, no un gran patrimonio

La evidencia más fuerte de que kCore es más que un escaparate es su huella de recursos de números de Internet. Elregistro de ARIN para AS401197identifica a kCore Cloud LLC, registra la asignación del sistema autónomo en junio de 2024 y apunta akcore.net. Elregistro IPv6 de ARINasigna a la empresa la asignación activa2602:f897::/40, registrada en junio de 2024. Elregistro IPv4 de ARINmuestra una asignación directa activa de199.184.211.0/24, registrada en octubre de 2025. El bloque IPv4 contiene 256 direcciones; el /40 IPv6 contiene 256 posibles redes de tamaño /48 para clientes, aunque las matemáticas del espacio de direcciones no dicen nada sobre cuántas están en uso.

Lavista de estado de enrutamiento de RIPEstatobservó un prefijo IPv4, un prefijo IPv6 y un sistema autónomo vecino en julio de 2026. Todos los 326 peers de alimentación completa IPv4 informantes y los 322 peers IPv6 vieron las rutas en esa observación. Lavista de prefijos anunciadosidentifica esas rutas como199.184.211.0/24y2602:f897::/40. Esta es una fuerte evidencia de un borde de red de doble pila globalmente visible.

El momento es revelador. Elhistorial de rutas de RIPEstatvio la ruta IPv6 desde julio de 2024, poco después de la asignación, mientras que el /24 IPv4 actual apareció en octubre de 2025. Ese patrón es consistente con una red que estableció IPv6 primero y agregó un bloque IPv4 asignado directamente más tarde. No muestra si el tráfico de clientes utilizó direcciones de otro proveedor antes de octubre de 2025, o cuánta producción se movió cuando apareció el /24. Sí muestra visibilidad de ruta continua en lugar de una asignación completamente inactiva.

Las rutas también tienen diferentes estados de seguridad de origen. Laverificación RPKI de RIPEstat para la ruta IPv6encontró una Autorización de Origen de Ruta válida que permite a AS401197 anunciar el /40. Laverificación IPv4correspondiente devolvió desconocido porque no encontró ninguna autorización de validación. Desconocido no es lo mismo que inválido: significa que el sistema criptográfico de origen de ruta no puede confirmar el origen a partir de una autorización coincidente. Crear una autorización válida para la ruta IPv4 eliminaría esa ambigüedad evitable.

Lo que los datos de ruta no pueden revelar es igualmente importante. Un /24 puede soportar cientos de direcciones individuales o un pequeño número de frontends compartidos. Un /40 puede subdividirse generosamente mientras solo unos pocos hosts responden. BGP no expone el conteo de CPU, el estado de los discos, el número de inquilinos, las solicitudes web, la carga de la base de datos o la energía restante del rack. No muestra si un servidor tiene dos fuentes de alimentación, si esas fuentes ingresan a caminos de distribución independientes, o si una segunda máquina puede absorber sus inquilinos.

La evidencia de red establece un límite operativo real. No convierte la afirmación no cuantificada de hardware de la empresa en una cifra de capacidad.

Mediciones independientes refuerzan esa precaución. Lapágina de IPinfo para AS401197enumera los mismos dos rangos de direcciones pero estimó solo un dominio alojado y encontró muy pocas direcciones que respondieran a ping en escaneos recientes. Su traceroute de junio de 2026 desde Ashburn alcanzó una dirección en el /24 de kCore después de AS4213 con baja latencia. Lavista de IPinfo del bloque IPv4también reporta un uso de dominio visible escaso. Estas son señales de mercado no oficiales, no un censo. El hosting compartido puede colocar muchos nombres detrás de una dirección, los firewalls pueden suprimir sondas, los servicios IPv6 pueden ignorar el tráfico no solicitado, y las direcciones de gestión privadas serán invisibles. Las mediciones sugieren una huella pública pequeña; no pueden probar el número de clientes, los ingresos, la capacidad inactiva o la falta de uso.

Un upstream observado es la concentración más clara

Losdatos de vecinos de RIPEstatobservaron solo AS4213 en el lado izquierdo de AS401197 y ningún sistema autónomo descendente.bgp.toolstambién identifica a AS4213, registrado históricamente como Krypt Technologies y ahora presentado públicamente como Evocative Global, como el upstream tanto para IPv4 como para IPv6. ElInforme CIDRmuestra la misma adyacencia única en las rutas recopiladas.

Esto es una concentración, no una prueba de mala ingeniería. Un proveedor puede ofrecer dos circuitos físicos, puertos diversos y una red troncal robusta. Puede existir un segundo camino pero permanecer inactivo, privado o invisible para los recolectores utilizados aquí. El proveedor puede operar enrutadores y enlaces redundantes dentro de una instalación aunque la tabla de rutas global vea un ASN upstream. Por el contrario, dos sesiones BGP hacia AS4213 podrían compartir un conducto, tarjeta de línea, cuenta, área metropolitana o borde de instalación y fallar juntas.

El enrutamiento público puede contar caminos de sistemas autónomos; no puede inspeccionar las bandejas de cables.

La distinción importa porque la página de inicio promete "redundancia incorporada". La redundancia debe estar vinculada a un dominio de falla. Los discos en espejo protegen contra algunas fallas de disco. Dos fuentes de alimentación protegen contra una sola fuente solo si se conectan a alimentaciones genuinamente independientes. Dos conmutadores protegen un servidor solo si sus interfaces, red virtual y ruta upstream están configuradas para usar ambos. Dos enlaces a un mismo operador pueden sobrevivir a un problema de panel de conexiones pero no a la suspensión comercial del operador o a una falla de enrutador compartido.

Un segundo operador en el mismo edificio puede seguir compartiendo la entrada de fibra externa.

ElRFC 4116explica por qué el multihoming a Internet es útil pero no mágico: múltiples caminos pueden mejorar la supervivencia de las sesiones, pero aún existen retrasos de convergencia, políticas de direcciones y complejidad operativa. Para kCore, una divulgación convincente de redundancia indicaría si hay un segundo upstream con capacidad predeterminada; si los circuitos salen por caminos físicos separados; si los enrutadores de borde, ópticas y energía están duplicados; y si el camino sobreviviente tiene suficiente capacidad comprometida para transportar tráfico prioritario. También mostraría que la conmutación por error se ejercita y no solo se configura.

La ausencia de una entrada de kCore en laconsulta de PeeringDB para AS401197no agrega prueba en ningún sentido. La participación en PeeringDB es voluntaria, especialmente para redes pequeñas que compran tránsito en lugar de buscar interconexión pública. Por el contrario, elregistro de AS4213 en PeeringDBdescribe una red mucho más grande que opera en muchas instalaciones. Esa amplitud pertenece a AS4213. No debe atribuirse automáticamente a kCore. Una ruta de cliente que ingresa a un gran upstream no hereda capacidad independiente de kCore en todos los sitios del upstream.

El resultado práctico es directo. Una falla o disputa contractual en la entrega de AS4213 es un camino de modo común creíble para las rutas públicas de kCore. La evidencia que reduciría esta preocupación incluye un segundo upstream observado, una prueba de conmutación por error publicada, un recolector de rutas que muestre caminos alternativos, o un contrato que describa entregas diversas con suficiente ancho de banda de respaldo. Hasta entonces, el borde de doble pila de kCore está vivo y es globalmente visible, pero externamente tiene una sola salida.

El norte de Virginia es la señal de ubicación más fuerte, no una instalación confirmada

La red de kCore deja pistas sobre dónde puede operar al menos algún equipo. El sitio web corporativo resuelve a67.198.230.22. Larespuesta de información de red de RIPEstatcoloca esa dirección en67.198.230.0/24, originada por AS4213 en lugar de AS401197. Los resúmenes de registros públicos etiquetan el bloque circundante67.198.230.0/23comoKRYPT-IAD1, utilizando el código de aeropuerto comúnmente asociado con el mercado de Washington Dulles y el norte de Virginia. La fuente de geolocalización comercial de RIPEstat coloca el bloque en Reston. El traceroute de IPinfo al propio bloque IPv4 de kCore alcanzó el objetivo desde Ashburn en aproximadamente dos milisegundos después de la red AS4213.

Tomados en conjunto, esas observaciones sugieren fuertemente un punto de operación en el norte de Virginia. No identifican el edificio exacto. La geolocalización IP puede reflejar el registro, la política de enrutamiento o un enrutador cercano en lugar del rack del servidor.IAD1es una etiqueta del proveedor, no una declaración contractual de kCore. AS4213 opera en numerosas áreas metropolitanas de EE. UU., y una ruta puede entregarse de forma remota. La baja latencia hace que una ubicación de producción distante sea menos probable para la dirección medida, pero una medición no puede localizar cada servicio o cada copia de seguridad.

Es por esto que las señales de Houston y el norte de Virginia no deben fusionarse. Houston es la superficie legal y de contacto mostrada en ARIN y en los términos de la empresa. El norte de Virginia es la mejor señal técnica para la infraestructura medida públicamente. Un aviso legal separado en el sitio enumera otra dirección en Houston para correspondencia de derechos de autor. Ninguna de esas direcciones establece dónde se almacenan los archivos, correos electrónicos o copias de seguridad de los clientes.

Lostérminosde la empresa preservan amplios derechos de movimiento. La sección 4.3 dice que las configuraciones de hardware pueden variar y que kCore puede reemplazar el hardware del host, mover una cuenta a otro servidor, o transferirla a otro centro de datos o ubicación geográfica cuando lo considere necesario para la calidad y seguridad del servicio. La sección 15.4 dice que una cuenta y sus copias de seguridad pueden estar en diferentes ubicaciones de centro de datos, que las copias de seguridad pueden almacenarse en otro estado, país o continente, y que la restauración de emergencia puede ocurrir fuera de la ubicación elegida por el cliente.

Esas cláusulas pueden ayudar a la recuperación al permitir que el operador escape de hardware fallido o un sitio problemático. También significan que la localidad no es fija simplemente porque la empresa y el ASN son estadounidenses. Un comprador con restricciones estatales, nacionales, contractuales o sectoriales necesita un compromiso de colocación por escrito que cubra la producción, la copia de seguridad, la recuperación temporal, el acceso de soporte y los subcontratistas. El contrato debe explicar el aviso y el consentimiento cuando una copia cruce el límite acordado.

Sin ese compromiso, el derecho del proveedor a mover datos es más amplio que el mapa de infraestructura pública.

El DNS muestra una separación útil, pero no es una segunda región de hosting

El diseño del servicio de dominios de kCore está más distribuido que su borde BGP público. Larespuesta de registro A de Google Public DNSmuestra el sitio corporativo en la dirección AS4213 en lugar del propio /24 IPv4 de la empresa. Surespuesta NSdelega la zona aa.ns.cl0secall.netyb.ns.cl0secall.net. En el momento de la revisión, el primer servidor autoritativo usaba direcciones en AS4213 y AS401197, mientras que el segundo usaba direcciones en AS25795 y una red IPv6 separada. Larespuesta MXtambién colocó un intercambiador de correo en AS401197 y otro en la red separada.

Esa disposición puede proporcionar beneficios genuinos. Si AS401197 desaparece, un servidor autoritativo secundario fuera de esa ruta puede continuar respondiendo por el dominio. Un intercambiador de correo externo puede poner en cola mensajes mientras el servidor primario no está disponible. Alojar el sitio de ventas en el espacio de direcciones del upstream puede mantener la página pública accesible durante una falla de origen de ruta que afecte al /24 de kCore. Estas son separaciones sensatas en las capas de dominio y comunicaciones.

También crean dependencias que deberían nombrarse. Los nombres de host autoritativos usancl0secall.net, un dominio diferente cuyos términos de propiedad y servicio no se explican en el sitio de kCore. La página corporativa permanece dentro de AS4213, el mismo sistema autónomo observado públicamente como el único upstream de kCore. Por lo tanto, un incidente a nivel de ruta en AS4213 podría afectar la red del cliente y el sitio web de la empresa, aunque sus direcciones pertenezcan a asignaciones diferentes. El segundo camino de DNS y correo puede sobrevivir, pero la evidencia pública no establece cómo el personal de soporte publicaría un incidente si el portal del cliente y la red primaria fallaran juntos.

El portal del cliente enlaza a una página de estado de la red, pero una solicitud no autenticada es redirigida al inicio de sesión. Elfeed de anuncios públicoses visible y útil, aunque no es un panel de estado actualizado continuamente. La distinción importa durante una interrupción. Un cliente que no puede autenticarse porque el portal o el servicio de identidad está inactivo necesita una fuente pública, alojada de forma independiente, de la propiedad del incidente, los servicios afectados y las actualizaciones de restauración.

La diversidad de DNS, por lo tanto, merece crédito pero no debe interpretarse erróneamente como redundancia de aplicación. Un sitio web puede resolverse correctamente mientras su base de datos, almacenamiento o panel de control no están disponibles. Un intercambiador de correo secundario puede aceptar un mensaje sin restaurar el buzón del cliente. Un canal de estado separado puede describir una falla sin reducirla. Cada capa tiene valor; ninguna prueba que la carga de trabajo de hosting compartido subyacente pueda moverse a otra pila de producción.

SSD RAID 10 es capacidad instalada, no capacidad utilizable garantizada

La página de hosting de kCore dice que toda la plataforma se ejecuta en almacenamiento SSD RAID 10. RAID 10 normalmente combina mirroring y striping, permitiendo algunas fallas de disco sin perder el conjunto y mejorando el rendimiento en comparación con un solo disco. Es una elección de diseño razonable para hosting compartido. Aún deja varias preguntas sin respuesta: el número y modelo de discos, diseño del controlador, política de repuestos, tiempo de reconstrucción, umbrales de monitoreo, diseño del sistema de archivos, protección de caché de escritura y si las réplicas comparten el mismo chasis o dominio de energía.

La economía se esconde detrás de esos detalles. El plan de entrada listado cuesta menos de diez dólares al mes e incluye almacenamiento, espacio de base de datos, correo electrónico, automatización de certificados, soporte, monitoreo y migración. Los precios bajos son posibles porque muchos inquilinos comparten servidores, licencias de software, capacidad de red y tiempo del personal. El proveedor obtiene un retorno manteniendo una alta utilización.

La resiliencia requiere el margen opuesto en momentos cruciales: bahías de disco sin usar, servidores de repuesto, almacenamiento libre, energía de rack no comprometida y tiempo del personal disponible cuando varias cosas fallan al mismo tiempo.

La capacidad instalada es la cantidad físicamente presente. La capacidad utilizable es lo que se puede vender de forma segura mientras se preserva el rendimiento, el espacio de reconstrucción y el margen de recuperación. Un servidor puede tener abundante espacio nominal en disco pero carecer de suficiente rendimiento de entrada/salida durante una reconstrucción RAID. Un rack puede tener unidades vacías pero sin asignación de energía restante. Un host virtual puede aceptar otra cuenta pero carecer de memoria para absorber vecinos después de que un nodo falla.

Los límites del plan público describen la cuota del cliente, no la reserva restante del proveedor.

Lapágina de plataformade kCore dice que utiliza hardware de servidor de grado empresarial, diseña en torno a fallas de componentes individuales y gestiona activamente los ciclos de vida del equipo. Esas son las categorías correctas. La página no publica generaciones de hardware, umbrales de reemplazo, tasas de falla o un inventario de repuestos listos. El contrato permite que las configuraciones de hardware varíen. Esa flexibilidad apoya las operaciones prácticas, pero impide que un comprador infiera una flota estándar o una clase de reemplazo garantizada.

Las ventanas de reparación dependen del stock y el acceso. Si falla un disco, un repuesto local puede instalarse rápidamente; si no hay un disco compatible en el sitio, la adquisición y el envío pasan a formar parte de la interrupción. Si falla una placa base, un repuesto de sistema completo puede acortar la recuperación; de lo contrario, el operador puede tener que trasplantar discos, restaurar en hardware diferente o esperar una pieza. En espacio arrendado, kCore puede necesitar que el personal de la instalación admita a un técnico o realice manos remotas. Una exclusión de una hora en el SLA no hace posible un reemplazo físico en una hora.

Una respuesta de capacidad sólida cuantificaría la reserva de fallas sin exponer detalles sensibles: número de sitios de producción, número de dominios de falla de servidor, margen mínimo de nodos de repuesto, categorías de reemplazo en el sitio, umbral de espacio libre de almacenamiento y política máxima de sobresuscripción. Revelaría si un solo servidor puede fallar sin mover inquilinos manualmente. También distinguiría el almacenamiento de copias de seguridad del almacenamiento redundante en vivo. RAID mantiene un servicio funcionando a través de algunas fallas de componentes; no crea una copia histórica independiente.

La garantía del 99.9% es más limitada que el titular

kCore promete repetidamente un 99.9% de tiempo de actividad. Sobre una base anual, ese porcentaje permite aproximadamente ocho horas y 46 minutos de indisponibilidad contada. La página de hosting redondea esto a aproximadamente nueve horas al año. Para un folleto, esa aritmética es comprensible. Para un operador que decide si un sitio web puede estar fuera de línea durante un día laboral completo, la definición de tiempo de inactividad contado importa más que el porcentaje.

La sección 5 de lostérminos publicadosdefine el compromiso como tiempo de actividad de la red medido anualmente. El remedio comienza con un mes de hosting gratuito si el tiempo de actividad total está por debajo del 99.9% pero por encima del 99%, con otro mes por cada punto porcentual por debajo del 99%. La compensación es limitada, y los registros internos de la empresa son el único estándar para determinar el derecho. El acuerdo describe este crédito como el remedio exclusivo para fallas de red, software, hardware o equipo donde la ley lo permita.

Las exclusiones son amplias. El mantenimiento programado no cuenta. El mantenimiento de emergencia y las fallas de hardware o software reparadas dentro de una hora no cuentan. Tampoco cuentan los ataques de denegación de servicio distribuida, los ataques de hackers, el tiempo de inactividad causado por alcanzar los límites del plan, los cambios de servicio, los períodos dedicados a procesar solicitudes de soporte técnico, la configuración del cliente, las aplicaciones de terceros, ciertos cambios notificados de DNS o dirección, las violaciones de políticas, la fuerza mayor o los eventos fuera del control de la empresa.

Estas exclusiones pueden tener sentido operativo individualmente. El mantenimiento es necesario; los clientes causan incidentes; los ataques pueden abrumar la capacidad adquirida. Sin embargo, colectivamente crean una gran diferencia entre el tiempo de inactividad experimentado y el tiempo de inactividad acreditado. Once fallas de hardware de 59 minutos cada una podrían producir casi once horas de interrupción mientras caen dentro de la exclusión de menos de una hora. Un cliente puede no poder servir tráfico durante un ataque de denegación de servicio mientras el evento no reduce el cálculo del SLA.

Una restauración dependiente de soporte puede permanecer fuera del cálculo precisamente mientras el cliente espera ayuda.

La garantía también es sobre la red, mientras que el servicio vendido es más amplio. Una ruta puede ser alcanzable cuando el servidor web devuelve errores. Un servidor web puede funcionar mientras la base de datos está bloqueada. Un panel de control puede estar inactivo mientras los sitios estáticos continúan sirviendo. El correo electrónico puede retrasarse mientras un sitio web está sano. Un cliente necesita indicadores de servicio específicos de componentes o una definición de extremo a extremo que comience con la solicitud del visitante e incluya las dependencias de la aplicación que kCore controla.

Elaviso de mantenimiento de emergencia de mayo de 2026ilustra la distinción. kCore dijo que un problema urgente de seguridad requería una breve interrupción del portal del cliente a las 10 p.m. hora del este y luego marcó el mantenimiento como completado a las 10:25 p.m. Esta es una evidencia operativa positiva: un aviso con fecha, razón declarada, actualización de finalización e invitación de soporte. Concernía al portal, no necesariamente a los sitios web alojados. El registro público no muestra si la interrupción contó contra alguna medida de servicio, si los clientes retuvieron otro camino de gestión, o si se emitió una revisión posterior del incidente.

Un registro de disponibilidad más útil para la toma de decisiones publicaría mediciones mensuales, duración del incidente desde el punto de vista del cliente, exclusiones específicas del servicio y el número de inquilinos afectados. Separaría el trabajo planificado del trabajo de emergencia e informaría con qué frecuencia se utiliza la excepción de una hora. El SLA actual es lo suficientemente real como para fijar el precio de un crédito limitado. No es un compromiso de tiempo de recuperación para cada capa de la que el cliente depende.

El lenguaje de copia de seguridad hace del cliente la última línea de recuperación

El contrato es más claro donde la página de marketing es menos específica. La sección 11.20 requiere que los clientes mantengan copias de todo el contenido en una ubicación independiente de kCore y dice que no deben usar el servicio de copia de seguridad de kCore como su única copia de seguridad. La sección 15 dice que kCore utilizará esfuerzos comercialmente razonables para respaldar los datos de la cuenta de hosting, pero una copia puede no estar disponible debido al número de archivos, falla del software de respaldo, falla de almacenamiento o corrupción.

Mantiene un número limitado de copias como se indica en la página del producto aplicable y puede eliminar copias antiguas después de un cambio de plan.

La página de hosting pública revisada aquí promueve características de respaldo y restauración a nivel de aplicación pero no indica un recuento de retención para la copia de seguridad de la plataforma. Los términos agregan que una copia restaurada puede llegar como datos sin procesar que requieren formateo, y que el remedio del cliente después de una restauración insatisfactoria es usar su propia copia de seguridad. La creación y restauración de copias de seguridad pagadas están excluidas de la política de devolución de dinero. Esto no es una garantía de un punto de recuperación o tiempo de recuperación particular.

Los riesgos son diferentes. RAID 10 aborda algunas fallas de disco en vivo. Una copia de seguridad aborda la eliminación, corrupción, compromiso o la necesidad de volver a un estado anterior. Una copia en el mismo rack puede sobrevivir a una falla de disco pero no a un evento de energía del rack. Una copia en la misma cuenta administrativa puede sobrevivir a la pérdida del servidor pero no necesariamente a una toma de control de la cuenta.

Una copia geográficamente remota puede sobrevivir a un incidente en la instalación pero puede introducir tiempo de transferencia, restricciones de localidad y una dependencia de las mismas credenciales o proveedor.

Laguía de ransomware de CISArecomienda copias de seguridad cifradas fuera de línea y pruebas de restauración regulares. La palabra importante es probado. Un trabajo de copia de seguridad que informa éxito prueba que los bytes se escribieron en algún lugar; no prueba que las bases de datos sean consistentes, que existan credenciales, que las claves de cifrado estén disponibles, que los nombres puedan redirigirse, o que el sitio restaurado funcione en la pila objetivo. Una prueba útil mide el tiempo desde la declaración de falla hasta servir tráfico desde la copia recuperada.

Para los clientes de kCore, la copia independiente debe incluir archivos del sitio web, volcados de base de datos, correo si es importante, registros DNS, material de certificado y clave cuando corresponda, configuración de cuenta, trabajos programados y documentación de las versiones de software necesarias para ejecutar el sitio. La copia debe ser accesible sin el portal de kCore. Su destino de restauración debe identificarse antes de un incidente, no después de que el servidor compartido no esté disponible.

kCore podría fortalecer la evidencia publicando períodos de retención, frecuencia de copia, separación de almacenamiento, práctica de cifrado, prioridad de restauración y éxito histórico de restauración. Podría definir un objetivo de punto de recuperación y objetivo de tiempo de recuperación por plan. En la actualidad, el contrato sensatamente dice a los clientes que no deleguen su última copia al proveedor. Los compradores deben tomar esa advertencia literalmente.

La migración hacia kCore está descrita; la migración hacia afuera sigue siendo un ejercicio del cliente

Lapágina de migraciónofrece una secuencia de entrada simple: comprar hosting, transferir opcionalmente el dominio, abrir un ticket de conserjería y dejar que el equipo migre el sitio web. La página de hosting dice que los expertos moverán los datos del sitio web del proveedor anterior con poco o ningún tiempo de inactividad. Para un sitio pequeño, la ayuda práctica de migración puede ser más valiosa que una herramienta sofisticada de autoservicio.

La asistencia de entrada no establece la portabilidad de salida. El material público no define qué paneles de control de origen, versiones de base de datos, formatos de buzón, tareas programadas o pilas de aplicaciones son compatibles. No promete una exportación completa de la cuenta, tiempo máximo de exportación, ancho de banda de salida o ayuda para mudarse a un proveedor competidor. El único artículo público de acceso a shell dice que los clientes pueden solicitar acceso a shell para hosting compartido o WordPress a través de un ticket de soporte.

Eso puede facilitar la transferencia de archivos, pero no especifica el nivel de privilegio, la duración o el acceso durante la suspensión de la cuenta.

LaHoja de Ruta de Estándares de Computación en la Nube de NISTtrata la portabilidad como la capacidad de mover datos o aplicaciones y destaca las diferencias en interfaces, formatos y tecnologías de máquinas virtuales como fuentes de bloqueo. El hosting compartido es más simple que mover un complejo entorno virtual, pero el mismo principio se aplica. Los archivos son solo una parte de un servicio funcional. La codificación de la base de datos, los buzones de correo, la sincronización de DNS, los certificados, las extensiones PHP, los permisos de archivos, los trabajos en segundo plano y los secretos de la aplicación deben llegar en un estado utilizable.

El contrato también crea presión de salida en torno a la facturación. Las tarifas se deben por adelantado. El pago fallido puede llevar a la suspensión o terminación, y kCore rechaza la responsabilidad por el contenido perdido como resultado. La renovación automática puede fallar incluso cuando está habilitada, y el cliente sigue siendo responsable de asegurar el pago. Los servicios pueden terminar al vencimiento. Durante una disputa de facturación, un contracargo puede llevar a la suspensión hasta que se paguen los montos pendientes.

Esto no es inusual en el hosting de bajo costo, pero convierte la facturación en una dependencia de infraestructura. Una tarjeta vencida puede convertirse en un evento de disponibilidad de datos. Un cliente cuya única copia reciente está detrás del inicio de sesión del proveedor puede descubrir que el momento de preparar una exportación fue antes de la disputa de factura. El remedio es operativo: mantener más de un contacto de pago actual, monitorear las confirmaciones de renovación, mantener copias independientes y probar la restauración en otro lugar.

Una declaración de salida madura especificaría cuánto tiempo permanecen disponibles los datos después de la cancelación, suspensión o vencimiento; si las exportaciones son posibles durante una disputa; los formatos suministrados; el rendimiento esperado; y el costo de soporte para una salida gestionada. Separaría el registro de dominio del hosting para que el cliente entienda qué nombres, registros y contenido pueden moverse independientemente. kCore explica cómo llegar. Los clientes aún necesitan diseñar cómo irse.

El trabajo de soporte es parte de la capacidad vendida

kCore se diferencia con soporte humano. Lapágina de conserjeríadice que sus técnicos tienen conocimientos y no son subcontratados a un gran centro de soporte genérico. Ofrece orientación técnica uno a uno y consultoría limitada por una tarifa por hora. La página de plataforma afirma monitoreo continuo y cobertura completa de respuesta en guardia. Los planes de hosting incluyen soporte por ticket, y el sitio publica contactos telefónicos y de correo electrónico.

El soporte de un equipo pequeño puede ser excelente porque la persona que responde puede entender todo el entorno. También puede concentrar el conocimiento y la autorización. ARIN enumera una persona nombrada en todos los roles administrativos, técnicos, de enrutamiento, DNS, operaciones de red y abuso para los recursos de la empresa. Eso no prueba que haya solo un operador; los contactos de registro a menudo se consolidan deliberadamente. La empresa no publica un recuento de personal, modelo de turnos, escalera de escalada, objetivos de respuesta o arreglos de sucesión.

El lenguaje del contrato reduce la promesa. El soporte técnico se proporciona según disponibilidad, y kCore no garantiza que cada consulta será manejada dentro de los promedios estadísticos anunciados. Puede tener acceso completo a servicios y contenido mientras asiste. Se dice a los clientes que hagan una copia de seguridad antes de solicitar ayuda porque los cambios pueden afectar la función del sitio web. Las solicitudes fuera del alcance incluido pueden requerir pago por adelantado, y el soporte puede ser rechazado en varias circunstancias.

La reparación, por lo tanto, tiene una cola humana. Una alerta de monitoreo debe llegar a alguien que pueda diagnosticar la capa correcta. Esa persona puede necesitar acceso a la instalación, un ticket con el upstream, una pieza de repuesto, una licencia del proveedor o la aprobación del cliente. Si varios inquilinos fallan con el mismo servidor, un experto puede ser eficiente porque la causa es compartida. Si un incidente de instalación o seguridad produce muchas tareas distintas, el mismo equipo pequeño puede convertirse en el recurso limitante.

El aviso del portal de mayo de 2026 muestra al menos un ciclo de comunicación rápido y directo y una actualización de finalización. No mide la respuesta a una falla de almacenamiento a medianoche o una interrupción de ruta generalizada. La superficie de estado de red enlazada públicamente requiere autenticación, por lo que los posibles clientes no pueden inspeccionar el tiempo de actividad o incidentes históricos. El archivo de anuncios contiene poca historia pública. La ausencia de informes no es prueba de ausencia de incidentes; es ausencia de un registro público a partir del cual los externos puedan calcular el rendimiento.

Los compradores deben preguntar por definiciones de severidad, objetivos de primera respuesta, propiedad de la restauración y un camino que permanezca accesible cuando el portal no esté disponible. Deben identificar quién puede autorizar cambios de DNS de emergencia y liberación de datos. Para un servicio crítico para el negocio, la capacidad de soporte pertenece a la arquitectura tan ciertamente como el disco y el tránsito.

La falla viaja a través de inquilinos, dominios y comunicaciones

Una falla de hosting compartido rara vez afecta solo al propietario de un servidor. Un host físico puede llevar muchos sitios web, bases de datos y buzones de correo no relacionados. Un problema de almacenamiento puede dejar a varios clientes fuera de línea a la vez. Un panel de control comprometido puede exponer dominios y cuentas. Una falla de DNS puede hacer que el contenido sano sea inalcanzable. Una falla de facturación o renovación de dominio puede interrumpir un sitio sin ningún hardware roto.

La pequeña huella de direcciones visible de kCore hace importante esta agregación. La estimación de dominios alojados de IPinfo es demasiado incompleta para contar clientes, y una IP compartida puede estar al frente de muchos nombres. La evidencia necesaria para establecer la exposición es una distribución de inquilinos proporcionada por el proveedor: no identidades de clientes, sino el número máximo de cuentas por dominio de falla, porcentaje de clientes en el servidor más grande, y si el correo, DNS y servicios de control comparten ese dominio.

El producto de dominio agrega otra cadena de dependencia. kCore dice que revende nombres de dominio a través de un socio registrador. Lapágina de dominiospermite a los clientes gestionar servidores de nombres, bloqueos de registrador e información de contacto en el mismo entorno del cliente. Agrupar simplifica la administración y la facturación. También significa que una cuenta comprometida o una renovación fallida puede tocar tanto el contenido como el nombre utilizado para alcanzarlo. El contrato señala que las transferencias y registros de dominio siguen sujetos a las reglas del registro y del registrador.

Los clientes pueden reducir ese radio de explosión separando las credenciales de propiedad, requiriendo autenticación multifactor, preservando registros DNS en otro lugar y decidiendo si el registro de dominio debe permanecer con un registrador independiente. Los términos de kCore requieren autenticación de dos factores para el área de usuario, lo cual es un control útil. La recuperación de la cuenta aún necesita un método de contacto independiente y un proceso documentado de prueba de propiedad.

La idoneidad del servicio también tiene límites. Los términos dicen que el servicio no es compatible con HIPAA y prohíben la información de salud protegida. Los usos de alto riesgo requieren confirmación previa y sistemas redundantes independientes. Estas exclusiones ayudan a evitar que una pequeña plataforma de hosting compartido sea confundida con infraestructura diseñada para seguridad de vida o datos de salud regulados. No responden a todas las preguntas de localidad o privacidad para datos ordinarios de clientes.

Cuando kCore falla, las partes más directamente afectadas son los propietarios de sitios web, sus visitantes, los usuarios de buzones de correo y cualquier persona que dependa de un dominio alojado. Los efectos secundarios pueden incluir pérdida de ventas, mensajes perdidos, enlaces de autenticación caducados, información comunitaria inaccesible y coordinación de incidentes retrasada. La barata factura mensual puede, por lo tanto, estar aguas arriba de actividades que valen mucho más que la tarifa de hosting. Es poco probable que el crédito del SLA coincida con ese costo externo, razón por la cual la recuperación independiente es importante.

Lo que demostraría resiliencia en lugar de simplemente describirla

kCore tiene suficiente evidencia pública para evitar una evaluación operativa negativa. Su superficie de pedidos está activa. Sus rutas son actuales y ampliamente visibles. Tiene espacio de direcciones asignado directamente, anuncios de doble pila, servicios autoritativos y de correo funcionales, un contrato documentado, canales de soporte activos y una comunicación de mantenimiento de 2026 fechada. Esas son señales sustanciales para un pequeño proveedor.

La siguiente evidencia debería ser operativa y de alcance limitado. Primero, identificar el área metropolitana de producción y el operador legal de la instalación, permitiendo que el detalle sensible del rack permanezca privado. Indicar si existe un segundo sitio de producción activo y qué servicios pueden funcionar allí. Distinguir la ubicación de la copia de seguridad de la capacidad de conmutación por error. Una copia remota es valiosa, pero no es una plataforma de aplicación lista a menos que también estén preparados la computación, el software, las credenciales, el DNS y la capacidad de red.

Segundo, documentar los dominios de falla de red. Nombrar el número de proveedores upstream, enrutadores de borde y entregas físicas; revelar si los enlaces utilizan entradas y energía separadas; y publicar la fecha y el resultado de un ejercicio de conmutación por error. Agregar una autorización de origen de ruta válida para el /24 IPv4. La autorización IPv6 muestra que la empresa ya comprende el mecanismo.

Tercero, revelar los controles de capacidad utilizable. Un comprador no necesita números de serie. Necesita saber que el servidor más grande puede fallar sin sobrecargar a los supervivientes, que hay reemplazos compatibles en el sitio o disponibles contractualmente, y que las reconstrucciones de almacenamiento preservan el rendimiento. Indicar el margen reservado y el objetivo de reemplazo para discos, servidores y dispositivos de red.

Cuarto, convertir el lenguaje de copia de seguridad en recuperación medible. Publicar frecuencia, retención, separación, prioridad de restauración y rangos de recuperación probados. Ofrecer un procedimiento de exportación legible por el cliente que no dependa de un portal sano. Aclarar la ubicación de los datos para la producción, las copias de seguridad y la restauración de emergencia, especialmente cuando un cliente paga por la colocación en EE. UU.

Quinto, hacer pública la evidencia de incidentes. Una página de estado alojada de forma independiente con historial de componentes permitiría a los clientes distinguir fallas de sitio web, portal, DNS, correo y hosting. Publicar revisiones concisas de incidentes para eventos materiales e informar tanto el tiempo de inactividad experimentado como el contado en el SLA. Esto haría que el número del 99.9% sea auditable sin revelar información del cliente.

Finalmente, describir la escalada de soporte. Publicar niveles de severidad, objetivos de acuse de recibo, canales fuera de horario y quién puede autorizar trabajo en la instalación o una migración de emergencia. Una pequeña empresa no necesita imitar a un hiperescalador. Sí necesita mostrar que una persona no disponible, un procesador de pagos fallido o una cola de tickets sobrecargada no pueden bloquear la restauración indefinidamente.

El veredicto operativo es real pero deliberadamente limitado

kCore Cloud está operando. La evidencia actual es más fuerte de lo que una descripción superficial de directorio podría sugerir: AS401197 tiene enrutamiento de doble pila sostenido, la empresa adquirió su propio espacio IPv4, el sitio comercial y el portal están activos, y un aviso de mantenimiento de seguridad de 2026 muestra a alguien atendiendo el servicio. El propio lenguaje de la empresa también establece una expectativa útil al enfatizar la pequeña escala y el hardware propio en lugar de pretender ser una utilidad global.

La misma evidencia define el límite. Un upstream observado externamente lleva ambas familias de rutas. El sitio físico no está identificado públicamente. El norte de Virginia es la inferencia más fuerte, no un compromiso confirmado con el cliente. La cantidad de hardware instalado y la capacidad de conmutación por error restante son desconocidas. El SLA excluye muchas experiencias reales de interrupción. La restauración de copias de seguridad no está garantizada, las copias independientes son responsabilidad del cliente, y los datos pueden cruzar fronteras estatales o nacionales.

El historial de incidentes público y la escalada de soporte siguen siendo escasos.

Para un sitio web modesto cuyo propietario mantiene una copia externa probada y puede tolerar horas de interrupción, ese riesgo puede ser aceptable al precio publicado. Para un servicio que debe permanecer disponible a través de una falla del operador, escasez de hardware, disputa de cuenta o evacuación de la instalación, la evidencia pública es insuficiente. El cliente necesitaría colocación contractual, tránsito diverso, capacidad de recuperación cuantificada, derechos de exportación y un destino de restauración independiente.

Ese es el intercambio central de la economía del hosting. kCore combina racks, licencias, tránsito y experiencia humana para que los clientes no tengan que comprarlos por separado. La baja tarifa mensual funciona porque esos recursos se comparten. La resiliencia funciona solo cuando algunos de ellos no están completamente consumidos, cuando los dominios de falla son genuinamente separados, y cuando una reparación puede ocurrir antes de que el cliente agote su tolerancia. kCore ha mostrado un servicio en vivo y una pequeña red creíble. Aún no ha mostrado, en público, el sistema de repuesto que llevaría ese servicio cuando el visible se rompa.