Resumen
- ServerHosh presenta un amplio catálogo de alojamiento compartido, VPS y servidores dedicados desde una base comercial en India, con ubicaciones anunciadas en Seattle, Filadelfia, Phoenix y Londres. La evidencia de red independiente actual más clara es más reducida: AS136175 origina un prefijo IPv4 /24 a través de Wowrack y cuenta con una conexión de 1 Gbps en el Seattle Internet Exchange.
- La empresa afirma ser propietaria del hardware y del equipo de red, operar tránsito directo y utilizar suites privadas en las instalaciones de Wowrack en Seattle y en Iron Mountain LON-1. Los registros públicos confirman las instalaciones y cierto espacio de direcciones etiquetado como ServerHosh, pero no revelan el número de bastidores, la potencia contratada, la capacidad de conmutación por error utilizable, el inventario de repuestos ni la sala concreta de Londres.
- La etiqueta de puerto de servidor de 1 Gbps o 10 Gbps no equivale a una capacidad dedicada extremo a extremo. Las propias condiciones de uso justo de ServerHosh permiten restringir el puerto para cargas de trabajo sostenidas de alto ancho de banda, mientras que la ruta global actual de su propio ASN solo expone un único proveedor ascendente observado y ningún espacio IPv6 originado.
- La recuperación también varía según el producto. El alojamiento compartido anuncia copias de seguridad diarias en dos niveles y migración con cPanel, mientras que los términos generales consideran los VPS y los servidores dedicados como no gestionados e imponen cortos plazos de eliminación tras el impago. Por tanto, los clientes necesitan un plan de restauración, exportación y continuidad de facturación independiente, en lugar de considerar un precio mensual bajo como un producto de resiliencia completo.
Una fachada de nube con una cadena de suministro física
ServerHosh hace que la infraestructura parezca una lista de pequeñas opciones mensuales. Supágina principal actualpromociona alojamiento compartido desde $1.99, máquinas virtuales en Estados Unidos y Gran Bretaña, y servidores dedicados en Francia, Seattle y Londres. El catálogo va desde una cuenta de alojamiento web de un gigabyte hasta una máquina dedicada con 128 gigabytes de memoria. Un cliente puede seleccionar núcleos, memoria, disco y velocidad de puerto sin ver nunca un bastidor, un disyuntor, una bandeja de fibra o la persona que reemplazará una unidad defectuosa.
Esa separación es normal en el alojamiento. También es donde reside el riesgo. ServerHosh no se limita a vender tiempo de CPU. Está ensamblando un servicio a partir de servidores físicos, software de virtualización, direcciones IP, redes ascendentes, un sistema de facturación y mano de obra de soporte. En Seattle y Londres, también depende de organizaciones que controlan los edificios, los sistemas eléctricos, la planta de refrigeración, los mostradores de seguridad y el acceso de manos remotas. La capacidad visible para un comprador es la última porción de una cadena más larga.
La empresa se describe a sí misma como un proveedor de alojamiento indio que opera desde 2012. Supágina "acerca de"cita a Anirban Ghosh y Srabanti Paul como propietarios y enumera funciones operativas y de soporte. Un registro corporativo independiente indica que Serverhosh Internet Service Private Limited seconstituyó en Bengala Occidental en octubre de 2020, con Ghosh y Paul como directores. Estas fechas pueden coexistir: una marca comercial o una operación no constituida puede preceder a una sociedad de responsabilidad limitada. No deben agruparse para afirmar que la empresa actual ha tenido los mismos activos, contratos o estructura operativa desde 2012.
La oficina de cara al cliente también está separada de las máquinas. Lapágina de contactode ServerHosh indica una dirección en Calcuta y un número de teléfono indio. Anuncia soporte las 24 horas, mientras que las ventas y la facturación figuran de lunes a sábado. Se promociona que las máquinas están a miles de kilómetros de distancia. Se trata de un acuerdo de servicio distribuido: administración comercial en India, capacidad de hardware y red en instalaciones extranjeras y demanda de clientes que puede proceder de cualquier lugar.
Este acuerdo puede resultar económico. Un pequeño proveedor no necesita construir un centro de datos para alquilar una jaula privada, comprar servidores dedicados, contratar tránsito IP y situar clientes en máquinas virtuales. Puede combinar menores gastos generales con soporte directo y opciones de producto limitadas. Pero el mismo acuerdo crea varios límites que un comprador debe trazar. ¿Quién es el propietario del servidor? ¿Quién tiene el contrato de las instalaciones? ¿Quién está autorizado a entrar en la sala? ¿Quién anuncia el espacio de direcciones? ¿Qué parte reemplaza un disco a las 03:00 hora local?
¿Qué contrato controla un reembolso, una suspensión, una ventana de mantenimiento o una exportación de datos?
Los materiales públicos de ServerHosh responden a partes de esas preguntas y dejan otras abiertas. La conclusión útil no es que el servicio sea imaginario ni que deban aceptarse todas las afirmaciones. Es que la operación es visible en algunos niveles y opaca en otros. La red tiene un rastro público actual. El catálogo de productos está activo. Existen instalaciones de terceros designadas. Sin embargo, la cantidad de capacidad vendible, el camino desde un ticket hasta un servidor reparado y la capacidad de restaurar los datos del cliente después de un fallo común no se publican de forma que un cliente pueda comprobarlos.
La evidencia actual más sólida es una ruta de Seattle
ServerHosh tiene su propio sistema autónomo, AS136175. Elregistro de APNICidentifica a Serverhosh Internet Service, una dirección en Calcuta y a Anirban Ghosh como contacto administrativo y técnico. El registro asigna al sistema autónomo un código de país de los Países Bajos, mientras que el registro de organización asociado dice India. Los campos de país en los registros de Internet son etiquetas administrativas, no un mapa fiable de dónde está instalado cada servidor o enrutador.
El panorama de enrutamiento en vivo es compacto. Elperfil de AS136175de Hurricane Electric mostraba un prefijo IPv4 originado, 209.90.232.0/24, un vecino IPv4 observado, AS23033 de Wowrack, y ningún prefijo IPv6 originado el 10 de julio de 2026. Lamedición de estado de enrutamientode RIPE mostraba de forma independiente el mismo espacio IPv4 de 256 direcciones, sin espacio IPv6 y un vecino observado. Suhistorial de prefijos anunciadosmostraba ese /24 visible de forma continua durante la ventana de consulta de dos semanas anterior.
Esa es una evidencia operativa positiva. Una ruta actual no aparece simplemente porque un sitio web diga que existe un servicio. Requiere administración de direcciones, una política de enrutador y un proveedor ascendente dispuesto a propagar el prefijo. IPinfo también informa deespacio de direcciones recientemente respondido en el /24, incluida una respuesta medida desde Seattle. Las observaciones respaldan una huella de red activa en Seattle asociada con ServerHosh.
El Seattle Internet Exchange añade una segunda forma de evidencia. Sutabla de participantes actualenumera a ServerHosh en la dirección IPv4 206.81.81.217 y la dirección IPv6 2001:504:16::2:13ef, conectado a 1 Gbps en el conmutador de Wowrack. La entrada marca la conexión y la membresía con derecho a voto como actuales. Elregistro de red de ServerHosh en PeeringDBinforma de las mismas direcciones, una política de peering abierta y un alcance global.
La entrada del intercambio debe leerse con cuidado. No muestra que ServerHosh entregue rutas a los servidores de ruta de SIX, y no convierte un puerto de intercambio de 1 Gbps en un segundo proveedor de tránsito. El peering puede mejorar el alcance a los miembros dispuestos, pero un puerto de intercambio público y un ascendente de Internet completo realizan trabajos diferentes. Una carga de trabajo de cliente sigue necesitando una ruta completa a redes que no hacen peering con ServerHosh. El único vecino observado a nivel global sigue siendo Wowrack.
También hay una gran diferencia de alcance entre las observaciones actuales y lapágina de redde ServerHosh. La empresa afirma que su servicio de Seattle tiene 110 Gbit/s de capacidad combinada actual, una conexión de tránsito de 100 Gbps con Hurricane Electric, una conexión de 10 Gbps con Wowrack, conmutadores redundantes y acceso a SIX. Esas cifras pueden describir la conectividad de las instalaciones, el diseño histórico, la capacidad disponible para un proveedor o enlaces no utilizados para anunciar el único prefijo visible de AS136175. No están corroboradas por la ruta pública para ese ASN ni por la entrada de intercambio de 1 Gbps.
Esto no prueba que los enlaces más grandes estén ausentes. Un proveedor de alojamiento puede utilizar direcciones asignadas por el proveedor y anunciadas bajo el ASN de un proveedor, VLAN privadas, tránsito protegido o capacidad que los colectores no pueden atribuir a su propio sistema autónomo. La evidencia actual establece menos: ServerHosh controla una ruta IPv4 visible a través de Wowrack y una conexión de intercambio en Seattle. Se necesitaría un inventario de circuitos actual, un resumen de configuración del enrutador y gráficos de tráfico separados por ubicación para validar la declaración de mayor capacidad.
IPv6 ilustra la misma distinción. SIX y PeeringDB asignan a ServerHosh una dirección de intercambio IPv6, por lo que existe una interfaz con capacidad IPv6 en el tejido del intercambio. Sin embargo, la empresa no origina ningún prefijo IPv6 de cliente en la tabla global. Una dirección LAN de intercambio es infraestructura para el peering; no es una asignación enrutable que un cliente de VPS pueda necesariamente utilizar.
Por tanto, un comprador que requiera un servicio de doble pila debería probar una máquina virtual aprovisionada y confirmar un prefijo IPv6, la ruta predeterminada, el DNS inverso y el comportamiento de conmutación por error, en lugar de basarse únicamente en el registro del intercambio.
La instalación de Seattle pertenece al dominio operativo del propietario
ServerHosh dice tener una suite privada con Wowrack en Seattle. Laficha técnica de SEA1de Wowrack describe una instalación de 18,000 pies cuadrados y 450 bastidores en 12201 Tukwila International Boulevard, con 3 MW de capacidad eléctrica, refrigeración N+1, sistemas de UPS y generadores, manos remotas, conectividad neutral para el operador y acceso a SIX en la red. Lahistoria de la empresade Wowrack dice que se expandió a una instalación de 3 MW y 18,000 pies cuadrados en Seattle en 2014.
La coincidencia entre esas cifras y la propia descripción de ServerHosh es sorprendente. Ambos citan 18,000 pies cuadrados, 3 MW, redundancia de la planta de refrigeración, alta densidad de bastidores, acceso a SIX y el mismo contexto operativo general de Seattle. Esto respalda la interpretación de que ServerHosh está describiendo las capacidades de la instalación de Wowrack en la que alquila espacio, no un edificio de su propiedad. Eso es coherente con su declaración de que se coloca en Seattle y con la relación BGP pública con Wowrack.
La capacidad de la instalación sigue siendo importante para un inquilino. Si fallan los generadores, enfriadoras o sistemas de acceso del sitio, los bastidores de ServerHosh se ven afectados. Pero una especificación de todo el edificio no puede trasladarse automáticamente a cada producto de cliente. Una planta de 3 MW no dice nada sobre el número de kilovatios contratados para ServerHosh, la carga de sus regletas de alimentación, si sus servidores tienen fuentes de alimentación duales conectadas a rutas separadas o cuánto margen queda tras un fallo de componente.
La dirección física también requiere cuidado. Un directorio comercial asocia a ServerHosh con una dirección de Seattle de aspecto más antiguo, mientras que los documentos actuales de Wowrack sitúan SEA1 en 12201 Tukwila International Boulevard. La ficha técnica actual del operador de la instalación es una evidencia más sólida para la ubicación actual. Aun así, no identifica la jaula, suite, número de bastidores o potencia de armario de ServerHosh.
Un cliente que busque una garantía física debería solicitar la dirección de servicio actual en el pedido, el operador de la instalación, el derecho a suite o jaula, el procedimiento de acceso y el punto en el que comienza la responsabilidad de ServerHosh.
Lasnormas de las instalacionesde Wowrack muestran por qué el límite tiene consecuencias operativas. Las entregas deben gestionarse a través de un ticket de soporte de Wowrack, y el operador puede tomar medidas correctivas cuando no se corrijan condiciones inseguras o inaceptables. Se trata de una gobernanza de colocación habitual, pero significa que la sustitución de hardware de ServerHosh puede depender de los procedimientos del proveedor, la aceptación del envío y la coordinación de las manos remotas antes de que su propio personal pueda completar la reparación.
Por tanto, el límite de propiedad tiene al menos cuatro niveles. Wowrack o el propietario del inmueble gestiona la planta del sitio y el régimen de acceso. Wowrack proporciona el tránsito de red visible en BGP. ServerHosh dice ser propietaria del hardware y del equipo de red dentro de su espacio. El cliente controla el sistema operativo y la aplicación para los productos no gestionados. Un plan de recuperación que nombre únicamente a ServerHosh omite las partes que controlan la sala, la ruta y la carga de trabajo.
Londres es visible, pero la sala exacta no
La historia británica de ServerHosh es más compleja. La empresa dice que su suite privada está en Iron Mountain LON-1. Elperfil oficial de LON-1de Iron Mountain describe una gran instalación en Slough con seis salas de datos, 17,000 metros cuadrados y 8.7 MW de potencia, además de armarios individuales, jaulas, suites privadas y manos inteligentes las 24 horas. Unadescripción general de ubicacionesseparada de Iron Mountain enumera LON-1 en 724-729 Dundee Road, con enfriadoras N+1, generadores y sistemas de UPS.
Esos registros establecen LON-1 y sus amplias capacidades de instalación. No establecen qué sala, bastidor o ruta de alimentación ocupa ServerHosh. ServerHosh no figura en ningún servicio de interconexión de Londres en su registro de PeeringDB, y AS136175 no expone una ruta de Londres. Ninguno de estos hechos refuta la existencia de una suite privada. Los despliegues privados de clientes a menudo no aparecen en las bases de datos públicas de instalaciones, y un proveedor puede utilizar espacio de direcciones anunciado por otra red.
Hay una señal más específica de Londres. El nombre de host que ServerHosh publica para su looking glass de Londres se resuelve en 41.216.187.0/24. Elperfil de registro y enrutamiento de ese prefijolo etiqueta como ServerHosh Internet Service y lo sitúa bajo el ASN de cliente de PebbleHost AS201002 en el Reino Unido. BGP.tools también muestra el/24 etiquetado como ServerHosh bajo PebbleHost. Esto respalda una relación actual de espacio de direcciones británico, pero no vincula la ruta a Iron Mountain LON-1.
La distinción importa porque la ubicación del centro de datos y el origen de la red son hechos diferentes. Un servidor de ServerHosh podría estar en LON-1 mientras su tráfico es transportado por PebbleHost. También podría estar alojado en otra instalación británica utilizando el mismo prefijo. El nombre de host DNS, el registro del prefijo y las observaciones de baja latencia en Londres establecen una presencia de red británica a un nivel útil, pero un comprador que requiera residencia en Slough necesita una confirmación contractual del sitio físico y la lista de subproveedores.
Lapágina de servidores dedicados del Reino Unidode ServerHosh nombra explícitamente Iron Mountain LON-1 y anuncia sistemas Ryzen con conexiones de 1 Gbps no medidas. Sin embargo, elcatálogo de pedidosvinculado mostraba cero unidades disponibles para cada configuración de servidor dedicado del Reino Unido mostrada en el momento de la consulta. Un stock cero no prueba que la ubicación esté inactiva. Sí muestra por qué el diseño del catálogo y la capacidad instalada deben separarse. Una página puede seguir anunciando un producto cuyo inventario inmediatamente aprovisionable está agotado o espera un montaje personalizado.
El catálogo de VPS de Londres hace una promesa más amplia. ServerHosh anunciamáquinas virtuales de 10 Gbpscon ancho de banda no medido, protección DDoS y un 99.99% de tiempo de actividad de red. La página dice que el host físico tiene un puerto full-duplex redundante de 10 Gbps y que ServerHosh posee su hardware y equipo de red. No indica cuántas instancias de VPS comparten ese host, si ambos puertos redundantes terminan en conmutadores independientes, el umbral de uso justo o el rendimiento medido disponible durante un ataque o un fallo del ascendente.
Esto no es una objeción semántica. Un cliente que compra una máquina virtual no puede consumir más capacidad física de la que pueden ofrecer el host, el conmutador y el enlace ascendente. Si veinte invitados comparten un puerto de host de 10 Gbps, sus interfaces anunciadas pueden ser todas de 10 Gbps mientras que el rendimiento simultáneo utilizable es mucho menor. Si un segundo puerto es de reserva en la misma pila de conmutadores, protege un cable o interfaz pero no el conmutador, el operador de tránsito o la instalación.
La cifra que falta no es la velocidad del puerto; es la capacidad de servicio comprometida y probada bajo contención y fallo.
La capacidad instalada no es lo mismo que la capacidad en venta
Las páginas de productos de ServerHosh revelan una amplia mezcla de generaciones de hardware y supuestos comerciales. Lapágina de alojamiento compartido NVMeanuncia planes en una plataforma Intel E3-1270v6, desde uno hasta 70 gigabytes de almacenamiento, con cPanel, CloudLinux, LiteSpeed y una conexión de servidor de 1 Gbps. Lapágina de VPS de almacenamientodice que cada servidor físico tiene cuatro unidades SATA de 4 TB en RAID 10 y vende asignaciones virtuales de 500 GB a 4 TB. La página de servidores dedicados de Estados Unidos enumera máquinas Xeon E3 y de doble Xeon más antiguas en Seattle junto con opciones Ryzen y Xeon más nuevas en Filadelfia y stock previsto en Phoenix.
No hay nada inherentemente malo en el hardware más antiguo. Un servidor ya amortizado puede hacer viable un plan de alojamiento de bajo coste, y las plataformas maduras pueden ser estables si se mantienen. La antigüedad cambia la ecuación operativa. Las placas base de repuesto, la memoria compatible, los controladores RAID y las unidades empresariales pueden ser más difíciles de conseguir rápidamente. El consumo de energía por unidad de trabajo suele ser mayor. El soporte de firmware puede ser limitado.
La pregunta correcta no es si todas las máquinas son nuevas, sino si el proveedor dispone de repuestos probados y puede restaurar la carga de trabajo en un plazo determinado.
Elcatálogo de servidores dedicados de EE.UU.expone este efecto de inventario. Algunos sistemas de Seattle aparecen como agotados mientras que otros siguen siendo pedibles; las configuraciones de Phoenix están marcadas como próximamente. La página dice que la mayoría de los servidores se configuran a medida y da un plazo de entrega habitual de 48 horas, con hasta tres días hábiles. Esa demora es una prueba de que una ficha de producto no es necesariamente una máquina instalada, alimentada y lista. El aprovisionamiento puede requerir montaje, pruebas, asignación o una transferencia del proveedor.
La capacidad virtual añade otra capa. Un plan VPS asigna núcleos y memoria virtuales, pero las páginas públicas no indican el número de invitados por host, la política de contención de CPU, el exceso de asignación de memoria, el objetivo de latencia de almacenamiento o la proporción de hosts de reserva. Un proveedor puede vender más núcleos virtuales nominales que núcleos físicos porque los clientes rara vez alcanzan el pico juntos. Ese es el motor económico del alojamiento VPS asequible.
Se convierte en un problema de fallo cuando demasiados invitados necesitan capacidad a la vez o cuando un host falla y los hosts restantes carecen de espacio para absorberlos.
El almacenamiento tiene una aritmética similar. Cuatro unidades de 4 TB en RAID 10 proporcionan aproximadamente la mitad de la capacidad bruta antes del formateo y el espacio de reserva, no 16 TB de almacenamiento protegido vendible. Si un proveedor asigna varios discos virtuales de 4 TB, puede depender del aprovisionamiento ligero o de que los clientes no utilicen todas sus asignaciones al mismo tiempo. La página no revela el método de aprovisionamiento. RAID 10 puede tolerar ciertos fallos de unidad, pero la reconstrucción consume E/S y un segundo fallo en el espejo incorrecto puede seguir perdiendo el array.
La capacidad reservada para reconstrucciones y migraciones forma parte de la capacidad de servicio utilizable aunque no produzca facturación.
Las etiquetas de ancho de banda son especialmente fáciles de sobreinterpretar. ServerHosh utiliza repetidamente "no medido" junto a puertos de 1 Gbps y 10 Gbps. Sustérminos generalesdefinen el servicio no medido como sujeto a uso justo, prohíben varias aplicaciones continuas de alto ancho de banda y permiten la restricción de la velocidad del puerto cuando el uso queda fuera del patrón establecido. Eso convierte "no medido" en una descripción de facturación, no en una garantía de transferencia sostenida a la velocidad de línea.
Por tanto, un cliente debería preguntar por cuatro cifras de capacidad separadas: la velocidad de interfaz presentada al servidor; cualquier límite de transferencia mensual o umbral de uso justo; la velocidad comprometida durante la contención ordinaria; y la velocidad mínima esperada tras un fallo de enlace, conmutador o host. Solo la primera es destacada en el catálogo. Sin las otras tres, una etiqueta de 10 Gbps describe una condición de interfaz local máxima, no el rendimiento disponible para restaurar terabytes de datos durante un incidente.
La alimentación y la refrigeración siguen siendo promesas heredadas
Los dos operadores de instalaciones nombrados publican descripciones de ingeniería creíbles. Wowrack dice que SEA1 de Seattle tiene 3 MW de potencia, configuraciones de UPS 2N o N+1, respaldo de generador, refrigeración N+1 y soporte de alta densidad. Iron Mountain describe una planta N+1 en LON-1. Estos son atributos de sitio significativos. Los bastidores de ServerHosh aún dependen de cómo esté conectado su propio equipo dentro de esos sitios.
Un servidor con doble cable puede recibir dos rutas de alimentación. Un servidor de bajo coste con un solo cable conectado a una regleta de alimentación de bastidor no puede. Dos regletas de bastidor pueden seguir compartiendo un panel ascendente. Una suite puede estar limitada a una envolvente de kilovatios contratada incluso aunque el edificio tenga megavatios de capacidad instalada. Una vez que un inquilino alcanza esa envolvente, puede tener unidades de bastidor vacías pero sin potencia disponible para otro servidor.
ServerHosh no publica su potencia contratada, la carga actual del bastidor, el mapa de rutas de alimentación ni el porcentaje de equipos con doble cable. Tampoco indica si sus conmutadores de red, almacenamiento y gestión fuera de banda siguen el mismo patrón de redundancia. Una instalación puede cumplir su propio diseño mientras un inquilino crea un punto único de fallo dentro de la jaula.
La refrigeración sigue la carga. El operador del edificio puede mantener enfriadoras N+1, pero el inquilino controla los paneles ciegos, el flujo de aire, la obstrucción de cables, la densidad del bastidor y la rapidez con la que se añade nuevo equipo. Un bastidor de alta densidad puede desarrollar un punto caliente local mientras la sala permanece dentro de su objetivo promedio. Una garantía útil para el cliente informaría de la temperatura de entrada en el bastidor, los umbrales de alarma, la responsabilidad de la respuesta y el tiempo necesario para reducir la carga o mover los invitados tras una pérdida de refrigeración.
La energía sigue siendo la causa más común de interrupciones graves y severas en los centros de datos según elanálisis de interrupciones de 2025de Uptime Intelligence. El informe también advierte que los datos de interrupciones son incompletos y que los fallos en los procedimientos del personal importan. Ese es el nivel correcto de inferencia aquí. No muestra que ServerHosh o alguna de las instalaciones haya sufrido un evento de energía en particular. Muestra por qué un porcentaje de tiempo de actividad sin calificar es más débil que una ruta probada a través de la pérdida de servicio público, el arranque del generador, el funcionamiento del UPS, la distribución en bastidor y el reinicio del servidor.
El mantenimiento crea una prueba más ordinaria que el desastre. Los generadores necesitan pruebas de carga. Los módulos de UPS necesitan servicio. Los conmutadores necesitan cambios de software. Los discos necesitan sustitución. Un proveedor resiliente debería poder aislar un componente sin detener la carga de trabajo alojada, o explicar la interrupción planificada si no puede. ServerHosh no publica un calendario de mantenimiento, un período de notificación, una exclusión de mantenimiento en su reclamación de tiempo de actividad ni un historial de pruebas de conmutación por error completadas.
El impacto en el cliente varía según el producto. Un usuario de alojamiento compartido puede perder un sitio web, correo electrónico y base de datos a la vez porque comparten un mismo servidor. Un usuario de VPS puede conservar un disco virtual intacto pero perder el acceso cuando el host o el ascendente fallan. Un usuario de servidor dedicado puede no tener ninguna máquina alternativa. La planta redundante de la instalación reduce el riesgo común, pero solo la replicación de aplicaciones en un dominio de fallo genuinamente separado puede proteger contra la pérdida del bastidor, la suite, la cuenta del proveedor o el sitio.
La diversidad de tránsito es más reducida que la lista de ubicaciones
ServerHosh comercializa múltiples ciudades, lo que puede sonar como diversidad de red. Una lista de ubicaciones no es un diseño de conmutación por error. Los productos de Seattle, Filadelfia, Phoenix y Londres pueden pedirse por separado, utilizar diferentes proveedores y no tener una relación automática entre sí. Un cliente con un VPS en una ciudad tiene una ubicación de carga de trabajo, independientemente de cuántas otras ciudades aparezcan en el menú.
Para el propio ASN de ServerHosh, la ruta de Internet visible es de un solo origen a través de Wowrack. La conexión SIX proporciona una conexión de intercambio separada, pero no parece originar el único prefijo de cliente de la empresa a través de los servidores de ruta del intercambio. Si falla la sesión de tránsito de Wowrack, el traspaso interno o el enrutador de ServerHosh, el /24 puede retirarse aunque el edificio y los servidores sigan alimentados.
La página de red de la empresa nombra a Hurricane Electric como proveedor principal de tránsito de 100 Gbps, pero los colectores públicos no mostraban AS6939 adyacente a AS136175 el 10 de julio de 2026. Son posibles varias explicaciones: el enlace puede servir direcciones asignadas por el proveedor, estar detrás de Wowrack, estar inactivo o ser una capacidad de instalación descrita como capacidad del inquilino. El registro público no puede elegir entre ellas. Un resumen BGP actual que muestre las sesiones ascendentes establecidas y qué prefijos recibe cada una resolvería la cuestión.
También hay una falta de coincidencia de escala entre un puerto SIX visible de 1 Gbps y las páginas de productos que ofrecen múltiples servidores de 1 Gbps o 10 Gbps. El puerto de intercambio no es la única capacidad de red en la instalación, por lo que el catálogo no es matemáticamente imposible. Sí significa que el intercambio no puede transportar la velocidad de interfaz anunciada completa de cada cliente simultáneamente. Lo mismo se aplica a cualquier conexión de host de 10 Gbps compartida entre máquinas virtuales.
La protección DDoS introduce otra dependencia. Las páginas de productos anuncian servicio protegido, y el catálogo de pedidos de Londres hace referencia a una cifra de protección estándar de 600 Gbps en algunos sistemas. Esa cifra puede describir la capacidad agregada de una plataforma de mitigación en lugar del tráfico entregable a un solo servidor. La protección efectiva también depende de la detección, la política de limpieza, la capacidad de la ruta limpia, el tipo de ataque, los umbrales de enrutamiento nulo y la comunicación con el cliente. Nada de esto se define públicamente.
La prueba práctica de redundancia tiene tres partes. Primero, ¿puede el prefijo seguir siendo alcanzable globalmente tras la desactivación de una sesión ascendente? Segundo, ¿puede el cliente recibir suficiente tráfico limpio tras la mitigación para que la aplicación siga siendo útil? Tercero, ¿se puede seguir accediendo al DNS, al panel de control y a los sistemas de tickets durante el mismo fallo? Superar solo la primera deja el servicio operativo en teoría pero inutilizable para el cliente.
El fallo de hardware se convierte en un problema de stock y acceso
Los servidores físicos fallan de formas específicas. Las unidades acumulan errores. Los ventiladores se agarrotan. Las fuentes de alimentación se disparan. La memoria desarrolla fallos. Las placas base y los controladores RAID dejan de responder. El tiempo de recuperación depende menos de la frase "hardware fiable" que de si el repuesto exacto está cerca, probado y accesible.
ServerHosh dice ser propietaria de su hardware y equipo de red. Eso puede ser una ventaja porque la empresa no espera a que una nube minorista exponga una opción de reemplazo. La propiedad también pone el riesgo de inventario en un proveedor relativamente pequeño. El catálogo público no muestra recuentos de repuestos, hosts de reserva, resistencia de las unidades, cobertura de garantía o la distribución por antigüedad del equipo instalado.
En Seattle, una reparación puede requerir que ServerHosh diagnostique el fallo de forma remota, abra la solicitud correcta de Wowrack, identifique el armario, autorice el trabajo y proporcione o envíe la pieza. Wowrack anuncia manos remotas las 24 horas, pero el alcance, el tiempo de respuesta y el coste en el contrato de ServerHosh no son públicos. En Londres, Iron Mountain anuncia un objetivo de acuse de recibo de la mayoría de las solicitudes de manos inteligentes en 30 minutos. El acuse de recibo no es la restauración; el técnico sigue necesitando un método aprobado y un componente de repuesto.
Los servidores dedicados configurados a medida hacen visible el problema de inventario antes de una interrupción. ServerHosh da un plazo de entrega de uno a tres días hábiles y marca varias configuraciones como no disponibles. La sustitución durante un fallo puede no seguir la ventana de entrega de ventas, especialmente para una plataforma Xeon más antigua o un diseño de disco específico del cliente. Un compromiso útil especificaría el objetivo de reparación por componente, las piezas mantenidas en el sitio y la alternativa si no se puede encontrar un repuesto exacto.
La recuperación de VPS puede ser más rápida si el proveedor dispone de almacenamiento compartido o imágenes replicadas que puedan arrancar en otro host. ServerHosh no describe dicha arquitectura de clúster. La virtualización KVM, anunciada en varias páginas, aísla a los invitados y puede soportar la migración, pero KVM por sí sola no replica un disco ni reserva capacidad de destino. Si el disco virtual existe solo en unidades dentro del host fallido, otro hipervisor no puede recuperarlo hasta que se repare o restaure el almacenamiento.
La ventana de reparación también interactúa con la seguridad. Una sustitución apresurada necesita firmware correcto, desinfección de unidades, aislamiento del cliente y control de configuración. Un repuesto que nunca se ha probado puede alargar el incidente. Una unidad fallida retirada del sistema de un cliente sigue conteniendo datos. Los términos públicos no especifican la retención de medios, la destrucción o las opciones del cliente para las unidades fallidas.
Los clientes pueden reducir este riesgo tratando un servidor virtual o dedicado como reemplazable. Mantenga la configuración de la máquina fuera del host, automatice las reconstrucciones, mantenga imágenes de software actuales y pruebe la restauración de la aplicación en un proveedor o ubicación diferente. Eso desplaza la recuperación de esperar una placa base concreta a lanzar capacidad válida conocida en otro lugar.
Las afirmaciones sobre copias de seguridad se dividen drásticamente por producto
La página principal de ServerHosh dice que realiza copias de seguridad diarias para el alojamiento. La página de alojamiento compartido NVMe es más específica, indicando una copia de seguridad diaria en dos niveles y almacenamiento RAID 1. Esas promesas parecen aplicarse al alojamiento compartido. Los términos generales dicen que todos los VPS y servidores dedicados no son gestionados y reciben solo soporte básico. No prometen copias de seguridad gestionadas por el proveedor para esos productos.
Esa distinción es fácil de pasar por alto porque "copia de seguridad gratuita" aparece junto a algunas promociones de VPS. Un comprador necesita saber si la copia de seguridad significa una instantánea del host, una copia en el mismo bastidor, una copia en otra instalación o un servicio que el cliente debe configurar. También necesita la duración de la retención, la frecuencia, el cifrado, el coste de restauración y la última prueba de restauración exitosa. Ninguno de esos detalles se publica en todo el conjunto de productos.
RAID no sustituye a la copia de seguridad. La redundancia en espejo o por bandas puede mantener un volumen en funcionamiento tras el fallo de una unidad, pero también reproduce el borrado accidental, la corrupción y el ransomware. Si se pierde todo el servidor, el controlador o el bastidor, el array se pierde con ellos. Una instantánea del host puede fallar por la misma razón si reside en el mismo conjunto de almacenamiento.
Laguía sobre ransomwarede CISA recomienda copias de seguridad fuera de línea, cifradas y pruebas periódicas de integridad y restauración. Laguía de planificación de contingenciasde NIST también trata el almacenamiento alternativo, el procesamiento alternativo, las telecomunicaciones y las copias de seguridad como partes relacionadas de la recuperación. Estos son puntos de referencia generales, no evidencia de que ServerHosh los siga o no.
Para ServerHosh, la evidencia decisiva sería un calendario de copias de seguridad específico por producto y un resultado de restauración. Un informe de alojamiento compartido podría indicar cuándo se completó cada nivel, dónde reside la segunda copia y cuánto tardó una restauración completa de la cuenta. Una opción de VPS podría definir instantáneas por separado de las copias de seguridad independientes. Un cliente de servidor dedicado debería asumir que no hay copia del proveedor a menos que el pedido la añada expresamente.
Lapágina pública de tiempo de actividadno cubre esta laguna. Presenta un calendario de siete días y una calculadora de rango de fechas, pero no expone servicios con nombre, historial de incidentes, desglose por ubicación ni métricas de restauración en la vista accesible. Un monitor de tiempo de actividad puede mostrar que un endpoint respondió; no puede mostrar si las copias de seguridad están actualizadas o si un servidor corrupto puede reconstruirse.
Las opiniones de los clientes solo proporcionan señales débiles. Elperfil de Trustpilotreclamado por ServerHosh contiene relatos positivos de servicio estable y ayuda rápida, junto con quejas sobre tiempo de inactividad, comunicación del soporte y pérdida de datos. Había 64 reseñas y ninguna en los 12 meses anteriores en el momento de la comprobación. Las reseñas son autoseleccionadas, cubren diferentes productos y períodos, y no pueden establecer una tasa de fallos actual. Sí identifican las preguntas que los compradores deberían comprobar: tiempo de respuesta, interpretación del ancho de banda y responsabilidad de la restauración.
La facturación puede detener un servidor sano más rápido que el hardware
No todas las interrupciones comienzan en una sala de datos. Los términos de ServerHosh dicen que un servidor dedicado puede ser cancelado permanentemente 24 horas después de una factura impagada, un VPS eliminado después de 72 horas y el alojamiento compartido o de revendedor cancelado después de cinco días. Estos plazos son cortos en comparación con muchos procesos de recuperación empresarial. Una tarjeta de pago caducada, un correo electrónico perdido o una factura impugnada pueden convertirse en un evento de pérdida de datos mientras la máquina física permanece en buen estado.
El riesgo se amplifica por la división de los horarios de soporte. El soporte técnico se anuncia de forma continua, pero la facturación se indica de lunes a sábado. Una suspensión a finales de semana puede requerir una autorización comercial que un responsable técnico no tiene. Los materiales públicos no indican una vía de escalado para un error de facturación que amenace con una eliminación inminente.
El lenguaje sobre reembolsos es incoherente entre las páginas. Lapolítica general de reembolsosotorga al alojamiento compartido mensual una garantía de 15 días, excluye los servidores dedicados, restringe varios otros casos y dice que las políticas pueden cambiar. La página NVMe describe un reembolso de 15 días seguido de un posible reembolso parcial. La página de VPS de Londres ofrece un reembolso completo en 48 horas y un reembolso parcial después. La página de servidores dedicados del Reino Unido dice que hay un reembolso disponible si la entrega no se produce en 48 horas. Un comprador no puede combinar de forma segura la frase más favorable de cada página.
Los términos comerciales que rigen deben adjuntarse al pedido específico. Deben indicar la entrega, la cancelación, el crédito de servicio, el aviso de suspensión, el momento de la eliminación y la gestión de los pagos impugnados. Para una carga de trabajo importante, el cliente también debería mantener más de un contacto de facturación autorizado, supervisar la entrega de facturas fuera del dominio alojado y evitar almacenar la única copia del correo de facturación en el servicio que podría ser suspendido.
Se trata de una cuestión de economía del alojamiento, no de mera administración. Los precios bajos dependen de la estandarización, la automatización y un control estricto del abuso y el impago. ServerHosh revisa manualmente los pedidos, limita los usos de alto ancho de banda y puede cancelar actividades prohibidas. Esas políticas protegen la escasa reputación de IP, el tiempo de soporte y la capacidad de tránsito. También crean la necesidad de una detección precisa y un proceso de escalado justo, porque una decisión incorrecta de abuso o facturación puede eliminar el único servidor de un cliente.
La empresa tiene direcciones diferenciadas de soporte, ventas, facturación y abuso, lo cual es mejor que un único buzón genérico. No publica niveles de gravedad, objetivos de respuesta, funciones de incidente designadas, escalado telefónico para clientes existentes ni una práctica de informes posteriores al incidente. Por tanto, la disponibilidad las 24 horas describe el canal, no un tiempo garantizado hasta el diagnóstico o la reparación.
La migración es posible, pero la portabilidad es condicional
ServerHosh anuncia descuentos para clientes que se trasladan desde otro proveedor. Su página de alojamiento NVMe dice que la migración gratuita solo está disponible cuando el host anterior utiliza cPanel. Ese es un límite concreto y sensato: cPanel puede empaquetar cuentas, bases de datos, buzones y configuraciones en un formato que otro servidor cPanel puede restaurar. También significa que la oferta de migración no es universal.
Un sitio WordPress a menudo puede trasladarse con archivos y una base de datos. Un VPS puede contener usuarios del sistema, reglas de cortafuegos, software con licencia, trabajos programados, redes privadas y un disco grande. Un servidor dedicado puede utilizar un diseño RAID o un sistema operativo que no se pueda copiar directamente a hardware diferente. Las páginas públicas de ServerHosh no definen cómo se exportan estas cargas de trabajo ni si el personal ayudará después del traslado inicial.
Las direcciones IP son otro límite de portabilidad. Un cliente normalmente no puede llevarse una dirección asignada por el proveedor a un nuevo host. Trasladarse desde el espacio de Seattle de ServerHosh o un rango de Londres anunciado por un proveedor puede requerir renumeración, cambios de DNS, nuevo DNS inverso y actualizaciones de las listas de permitidos. La reputación del correo electrónico vinculada a una dirección no se transfiere automáticamente. Por tanto, un traslado realizado durante una interrupción puede llevar más tiempo que copiar los datos.
Los paneles de control reducen la administración rutinaria pero pueden crear dependencias propias. ServerHosh utiliza cPanel para el alojamiento compartido y anuncia paneles de máquina virtual para la instalación del sistema operativo, el reinicio y el acceso a la consola. Un cliente debería exportar los datos en formatos ordinarios y conservar las credenciales fuera de la cuenta del proveedor. El portal de gestión, el sistema de facturación y la máquina alojada no deberían formar un único dominio de fallo de autenticación.
NIST describe la planificación de contingencias como una combinación de medidas técnicas, procedimientos y ubicaciones de procesamiento alternativas, no simplemente un archivo de copia de seguridad. Para un cliente de ServerHosh, una prueba realista de portabilidad consistiría en aprovisionar una máquina limpia en otro lugar, restaurar la aplicación, rotar los secretos, cambiar el DNS y medir el tiempo hasta que los usuarios puedan conectarse. La prueba debería incluir los datos creados después de la última copia de seguridad y las dependencias como el correo, los certificados y las devoluciones de llamada de pago.
La recuperación multisitio no se establece pidiendo dos ubicaciones de ServerHosh a menos que se mapeen sus dependencias. Seattle depende claramente de Wowrack para la ruta observada. El espacio de direcciones de Londres visible a través del nombre de host publicado depende del enrutamiento de PebbleHost. Esto es una prometedora diversidad de proveedores, pero el cliente aún necesita confirmar que las cuentas, los planos de control, las copias de seguridad y la facturación no se comparten de manera que un solo incidente comercial o de seguridad desactive ambos.
La mejor posición de salida es aquella que funciona sin intervención del proveedor. Eso significa copias de datos actuales, registros de configuración, control del dominio, supervisión independiente, un destino probado y suficiente ancho de banda para trasladarse dentro del tiempo de recuperación requerido. Una oferta de migración gratuita puede reducir el coste de entrada; solo una exportación probada reduce el coste de salida.
La ubicación de los datos necesita un contrato, no una etiqueta de ciudad
El área de servicio de ServerHosh es global, pero su geografía operativa tiene varios niveles. La administración de la empresa y del cliente está en India. Las páginas de productos públicas sitúan máquinas en Estados Unidos y el Reino Unido, con ofertas adicionales que mencionan Francia y los Países Bajos. Los registros de red muestran un /24 originado por ServerHosh en Seattle y un /24 etiquetado como ServerHosh enrutado a través de un proveedor británico. Los datos de un cliente también pueden pasar por servicios de pago, soporte, supervisión y panel de control fuera de la ciudad del servidor.
Lapolítica de privacidadde la empresa dice que procesa nombres, datos de contacto, direcciones IP, información comercial, datos de pago y comunicaciones, y que los datos de la relación con el cliente pueden almacenarse en WHMCS. Describe la seguridad y la retención en términos generales. No identifica los subencargados del alojamiento, los países de procesamiento, un calendario fijo de eliminación, los mecanismos de transferencia internacional ni la instalación utilizada para cada producto.
Esto es independiente del contenido de un servidor no gestionado. Un proveedor de alojamiento puede actuar en diferentes roles para los registros de facturación, los tickets de soporte y los datos personales alojados por el cliente. La Oficina del Comisionado de Información del Reino Unido explica en suguía sobre responsables y encargados del tratamientoque los roles dependen de quién determina los fines y los medios del tratamiento, y que el subencargo cambia las responsabilidades. Suguía sobre transferencias internacionalesaborda específicamente el caso de un encargado que transfiere información a un subencargado en el extranjero.
El marco de protección de datos de India también ha ido más allá de una declaración de privacidad genérica. El Ministerio de Electrónica y Tecnología de la Información publicó lasReglas de Protección de Datos Personales Digitales de 2025, con un calendario de implementación. Las obligaciones legales para un cliente en particular dependen de los datos, las partes y las disposiciones vigentes. La lección de infraestructura es más simple: un comprador no puede evaluar la localidad solo por la ciudad en el título de un producto.
Un cliente con requisitos de residencia o soberanía debería preguntar a ServerHosh por el país físico exacto, el operador de la instalación, los subproveedores, las ubicaciones de las copias de seguridad, los países de acceso del soporte, las ubicaciones de registro y el proceso de eliminación. También debería preguntar si el rango de IP asignado es portátil dentro del mismo país si cambia el proveedor subyacente. La respuesta debería formar parte del pedido de servicio y del proceso de notificación de cambios.
La evidencia de Londres muestra por qué. Una página puede nombrar Iron Mountain LON-1 mientras que un prefijo etiquetado como ServerHosh y un host de looking glass se enrutan a través de PebbleHost. Estos hechos no son contradictorios, pero describen diferentes superficies de control. La ubicación de la instalación responde a dónde está un servidor. El origen de la ruta responde a quién transporta su espacio de direcciones. La ubicación del soporte responde a quién puede acceder a él. La ubicación de la copia de seguridad responde a dónde existe otra copia. La soberanía de los datos requiere las cuatro.
Seis fallos revelan el servicio real
El primer fallo es una interrupción del bastidor o de la instalación. Si falla la ruta de alimentación contratada, la zona de refrigeración o el armario de ServerHosh, la redundancia subyacente del edificio puede limitar el incidente, pero solo el equipo con doble cable y la capacidad sobrante pueden mantener la carga de trabajo activa. Los clientes en un solo host se ven afectados hasta que vuelva la alimentación, el host se reinicie o la carga de trabajo se traslade.
La evidencia que mejoraría la confianza incluye un mapa de alimentación a nivel de inquilino, la cobertura de doble alimentación, la última prueba integrada y un registro de notificación al cliente.
El segundo es la pérdida del ascendente. AS136175 tiene actualmente un vecino global observado. La membresía en SIX es útil, pero por sí sola no proporciona una ruta alternativa completa. Un fallo en la sesión de tránsito puede eliminar el /24 de la empresa mientras los servidores siguen funcionando. Un segundo ascendente enrutado de forma independiente, una conmutación por error de prefijo probada y la participación actual en el servidor de rutas reducirían este riesgo.
El tercero es el fallo de stock de hardware. Una unidad puede reemplazarse rápidamente si hay un repuesto compatible en el mismo edificio y las manos remotas están autorizadas. Puede llevar mucho más tiempo si la pieza debe conseguirse, enviarse, admitirse e instalarse. Las generaciones de servidores dedicados más antiguas aumentan la importancia de los repuestos almacenados. La medida relevante es el tiempo de reparación y restauración de la carga de trabajo, no el tipo de CPU en la tabla de ventas.
El cuarto es el fallo del soporte. Un canal de tickets puede estar abierto mientras el diagnóstico, el escalado al proveedor o la aprobación comercial esperan. Los clientes necesitan una vía de gravedad que llegue a alguien con autoridad para contactar con Wowrack, Iron Mountain u otro proveedor de red. Los objetivos publicados de acuse de recibo, diagnóstico, solución provisional y restauración harían medible el soporte 24 horas.
El quinto es el fallo de facturación o de política. Un servidor válido puede ser eliminado según los plazos de impago publicados, y la aplicación de usos prohibidos puede suspender el servicio. Múltiples contactos de facturación, plazos de preaviso más largos para clientes establecidos, una vía de apelación y un período de gracia para la exportación evitarían que una disputa administrativa se convierta en una pérdida de datos irreversible.
El sexto es el fallo de migración. Un cliente puede descubrir durante una interrupción que su copia de seguridad es local, que la exportación del panel de control está incompleta, que la reputación de IP no puede trasladarse y que las credenciales de DNS están atrapadas en la misma cuenta. Una restauración exitosa en otro proveedor es una evidencia más sólida de portabilidad que una promesa de migración gratuita de entrada.
Estos fallos afectan a diferentes grupos. El propietario de un sitio personal puede tolerar varias horas y reconstruir a partir de una copia reciente. Un revendedor puede tener docenas de clientes descendentes y ningún acceso directo al operador de la instalación. Una empresa que utiliza un VPS no gestionado puede ser totalmente responsable de su aplicación sin dejar de depender de ServerHosh para la recuperación del host y el enrutamiento. Un cliente de servidor dedicado puede ser dueño de la pila de software pero no tener acceso físico para reemplazar el hardware.
Qué mejoraría materialmente la confianza
ServerHosh ya publica más detalles de infraestructura que muchos proveedores de bajo coste. Nombra instalaciones, proveedores de tránsito, clases de equipos, membresía en intercambios, afirmaciones sobre copias de seguridad y límites de productos. La siguiente mejora no es una cifra de tiempo de actividad mayor. Es un conjunto más reducido de hechos actuales y delimitados.
Para cada ubicación, la empresa podría publicar el operador de la instalación y la dirección, su papel como propietario o inquilino, el número de bastidores activos, la potencia contratada y disponible, la política de repuestos de servidores y red, las sesiones ascendentes, los puertos de intercambio, la disponibilidad de IPv4 e IPv6 para clientes, la política DDoS, el aviso de mantenimiento y el escalado de manos remotas. No son necesarios diagramas sensibles ni detalles de clientes. Bastarían hechos operativos agregados.
Para cada clase de producto, podría separar la velocidad de interfaz de la política de uso justo y el rendimiento comprometido; definir si el servicio es gestionado; especificar la frecuencia, ubicación y retención de las copias de seguridad; establecer objetivos de recuperación; y adjuntar una política coherente de reembolso, suspensión y eliminación al pedido. Una página de estado podría nombrar servicios y ubicaciones, conservar el historial de incidentes e informar del mantenimiento sin exponer información de seguridad.
La prueba más sólida sería un ejercicio rutinario. Retirar una ruta de tránsito y mostrar la ruta alternativa. Restaurar una cuenta de alojamiento compartido desde el segundo nivel de copia de seguridad. Evacuar un VPS de un host fallido. Reemplazar una unidad de servidor dedicado mediante manos remotas. Reconstruir una aplicación de cliente representativa en otra ubicación. Informar del tiempo, las limitaciones y las acciones correctivas.
Hasta que esa evidencia sea pública, ServerHosh debe ser evaluado como un pequeño proveedor de alojamiento activo con una huella de red real pero concentrada, acceso creíble a capacidad de centros de datos de terceros y una incertidumbre sustancial en torno a la redundancia a nivel de inquilino. Sus precios bajos y su amplio menú pueden ser adecuados para cargas de trabajo diseñadas para ser reemplazables. No deben confundirse con un servicio gestionado de recuperación multisitio.
La lección física es la más importante. ServerHosh puede empaquetar núcleos, almacenamiento y ancho de banda en un conveniente producto mensual, pero no puede virtualizar la ausencia de un bastidor fallido, una ruta retirada, un repuesto no disponible, una factura olvidada o una restauración no probada. Los clientes solo compran resiliencia cuando esas dependencias se nombran, se dividen en dominios de fallo independientes y se ejercitan antes de que comience la ventana de reparación.