¿Qué diferencia técnica hay entre un hosting compartido y una nube empresarial cuando tu sitio no se puede caer?

La diferencia técnica de fondo es quién comparte qué y quién puede diseñar la redundancia: en un hosting compartido usas el mismo servidor, CPU, RAM y software que otras cuentas; en un hosting empresarial gestionado tienes recursos separados y el proveedor lo opera por ti; y en una nube con acceso root puedes construir alta disponibilidad con varias instancias, red privada, balanceador y snapshots, pero esa arquitectura la diseñas y mantienes tú. Ninguna opción da 100 % de disponibilidad, y un solo servidor sigue siendo un punto único de falla en cualquier modalidad.

Si ya leíste nuestra guía sobre cuándo pasar de hosting compartido a un servidor en la nube administrado o la comparación web hosting vs cloud hosting, este artículo toma otro camino: revisa capa por capa qué puede fallar, quién lo resuelve y qué puedes hacer tú en cada modalidad cuando tu sitio no se puede caer.

La diferencia en una frase: quién comparte qué

• Hosting compartido: compartes servidor, CPU, RAM y software (servidor web, PHP, base de datos) con otras cuentas. Lo administras desde un panel como cPanel y no tienes acceso root. El proveedor opera todo.
• Hosting empresarial gestionado: tus recursos están separados de los de otros clientes y tienen límites definidos. El proveedor sigue operando la plataforma, aplica los parches y vigila el servicio.
• Nube con root: tienes un servidor virtual con recursos asignados y control total del sistema operativo. Instalas, configuras, actualizas y proteges tú. Si quieres saber más sobre este modelo, revisa qué es un VPS.

Qué significa alta disponibilidad (y qué no)

Alta disponibilidad es la capacidad de un sistema para seguir respondiendo aunque falle uno de sus componentes. Se consigue eliminando puntos únicos de falla: si algo se rompe, otro elemento toma su lugar (a esto se le llama failover). Conviene separarla de dos conceptos con los que suele confundirse:

• Rendimiento: qué tan rápido responde tu sitio. Un servidor muy potente puede ser rápido y aun así caerse si es el único.
• Copias de seguridad: te permiten recuperar datos después de un problema, pero no evitan que el sitio quede fuera de línea mientras restauras.

El SLA de uptime es el compromiso del proveedor sobre la disponibilidad de su infraestructura: servidores, red, almacenamiento. No cubre errores de tu aplicación, un plugin que rompe el sitio, una base de datos mal configurada ni un despliegue fallido. Un porcentaje como 99,9 % indica qué proporción del tiempo el proveedor se compromete a mantener su plataforma operativa, y suele venir acompañado de condiciones y compensaciones definidas en sus términos.

Para planear la continuidad del negocio se usan dos medidas:

• RTO (Recovery Time Objective): cuánto tiempo puede estar caído tu servicio antes de que el daño sea inaceptable.
• RPO (Recovery Point Objective): cuántos datos puedes permitirte perder, medido como el tiempo entre la última copia y el incidente.

Un ejemplo: una tienda online decide que no puede perder pedidos ya confirmados y que debe volver a vender antes de que empiece su horario de mayor tráfico. Su RPO exige copias o réplica de la base de datos muy frecuentes, y su RTO exige tener un procedimiento de restauración probado o una instancia de respaldo lista. Un blog corporativo, en cambio, puede tolerar perder el último borrador y volver en línea más tarde. Las cifras las defines tú según tu negocio, no el proveedor.

Diferencias técnicas capa por capa

1. Almacenamiento y réplica de datos

El disco es uno de los componentes que más fallan. La pregunta clave es si tus datos viven en un solo disco o están replicados en varios.

• Compartido: depende del diseño del proveedor. En plataformas bien construidas el almacenamiento está replicado, de modo que la falla de un disco no implica perder datos. Tú no eliges ni ves esa arquitectura.
• Empresarial gestionado: normalmente con réplica de datos en varios servidores y operada por el proveedor.
• Nube con root: el almacenamiento de la plataforma puede estar replicado, pero eso protege contra la falla del disco, no contra que borres una tabla por error o que tu instancia deje de arrancar. La consistencia de tus datos dentro del servidor es tu responsabilidad.

2. Red

• Compartido y empresarial: la red la diseña y opera el proveedor. Tú no configuras rutas, firewalls de red ni conexiones entre servidores.
• Nube con root: la red de la plataforma (enlaces, rutas, redundancia de proveedores de tránsito) sigue siendo del proveedor, pero tú decides cómo se conectan tus instancias entre sí: red privada, reglas de firewall, qué puertos se exponen a internet y cuáles no.

3. Recursos y vecinos

El efecto vecino ruidoso ocurre cuando otra cuenta que comparte tu servidor consume tanta CPU, RAM o disco que afecta a las demás.

• Compartido: es el escenario donde más puede aparecer. Tecnologías como CloudLinux limitan lo que cada cuenta puede usar y reducen mucho el impacto, pero sigues compartiendo la máquina.
• Empresarial gestionado: recursos separados (por ejemplo en contenedores) con CPU, RAM e IO definidos. Si no hay sobreventa, lo que contrataste está disponible para ti.
• Nube con root: tienes recursos asignados a tu servidor virtual. En opciones dedicadas, la memoria, el procesamiento y el almacenamiento no se comparten con nadie.

4. Software, parches y seguridad

• Compartido: el proveedor actualiza el sistema operativo, el servidor web, PHP y la base de datos. Tú actualizas tu CMS, temas y plugins.
• Empresarial gestionado: igual, con más atención y monitoreo por cuenta.
• Nube con root: todo es tuyo: kernel, paquetes, servidor web, base de datos, certificados, firewall. Un parche olvidado o una actualización mal hecha puede tumbar el servicio o abrir una brecha.

5. Escalado ante picos

• Compartido: tienes los límites de tu plan. Ante un pico fuerte, el sitio se pone lento o devuelve errores hasta que baje la carga o cambies de plan.
• Empresarial gestionado: recursos definidos por plan y el proveedor te ayuda a subir de nivel cuando hace falta.
• Nube con root: puedes escalar verticalmente (más CPU y RAM en el mismo servidor) u horizontalmente (más instancias detrás de un balanceador). El escalado horizontal es el que además mejora la disponibilidad, pero requiere que tu aplicación esté preparada para funcionar en varias copias.

6. Copias y recuperación

• Compartido y empresarial: lo habitual son backups automáticos diarios y ayuda del soporte para restaurar.
• Nube con root: tienes herramientas como snapshots, pero decides qué se copia, cada cuánto, dónde se guarda y cómo se restaura. Para profundizar, revisa qué es un backup en la nube para empresas.

7. Quién atiende a las 3 a. m.

• Compartido: el proveedor detecta y resuelve fallas de plataforma. Si el problema está en tu sitio, el soporte te orienta, pero el código es tuyo.
• Empresarial gestionado: el proveedor monitorea y actúa de forma más proactiva.
• Nube con root: el proveedor responde por el hardware, la red y la virtualización. Si se cae tu servicio web, se llena el disco o falla la base de datos dentro de tu servidor, alguien de tu equipo tiene que estar disponible para atenderlo.

Tabla comparativa

Cómo armar alta disponibilidad paso a paso

Si eliges la nube con root y quieres eliminar puntos únicos de falla, este es un camino práctico:

1. Define qué no se puede caer y tu RTO/RPO. No todo necesita alta disponibilidad: el checkout de una tienda sí; el blog quizá no.
2. Separa la base de datos de la aplicación. Ponerlas en servidores distintos te permite duplicar la aplicación sin duplicar datos.
3. Duplica la aplicación en dos o más instancias. Usa el mismo código y la misma configuración; guarda las sesiones y archivos subidos en un lugar compartido, no en el disco local de cada instancia.
4. Conéctalas por red privada. La base de datos y el tráfico interno no deberían estar expuestos a internet.
5. Pon un balanceador con verificaciones de salud. Herramientas como Nginx o HAProxy reparten el tráfico y dejan de enviarlo a una instancia que no responde. Si quieres entender la diferencia con otros tipos de enrutamiento, lee enrutamiento de modelos de IA vs balanceo de carga.
6. Replica o respalda la base de datos. Una réplica permite cambiar a otro servidor si el principal falla; sin ella, la base de datos sigue siendo un punto único de falla.
7. Toma un snapshot antes de cada cambio. Actualizaciones del sistema, cambios de versión o despliegues grandes: siempre con un punto de regreso.
8. Guarda copias fuera del servidor y prueba la restauración. Una copia que nunca restauraste es una suposición, no un plan.
9. Configura monitoreo externo y alertas. Vigila tu sitio desde fuera de tu infraestructura y recibe avisos por un canal que realmente revises.
10. Ensaya la caída de una instancia. Apaga una a propósito en un horario de bajo tráfico y comprueba que el servicio sigue respondiendo.

Todo esto exige a alguien que sepa administrar servidores y que esté disponible cuando algo falle. Si no tienes ese perfil en tu equipo, un hosting empresarial gestionado suele ser la opción más sensata: obtienes aislamiento y operación profesional sin tener que construirla tú. Las agencias que evalúan esta decisión para varios clientes pueden revisar servidores propios vs nube gestionada para agencias digitales.

Errores comunes

• Confundir backup con alta disponibilidad. El backup recupera datos; la alta disponibilidad evita la caída. Necesitas ambas cosas.
• Creer que más RAM evita caídas. Más recursos mejoran el rendimiento, pero un servidor grande sigue siendo un solo servidor.
• Un solo servidor para todo. Web, base de datos, correo y tareas programadas en la misma máquina: si falla una pieza, cae todo.
• No probar restauraciones. Muchas copias se descubren incompletas justo el día en que se necesitan.
• Actualizar en producción sin snapshot. Un cambio de versión de PHP o de la base de datos sin punto de regreso puede convertirse en horas de trabajo.
• DNS sin plan de respaldo. Si tu DNS falla o no sabes cómo apuntar rápido a otro servidor, tu redundancia no sirve de mucho.
• Monitorear solo desde dentro del mismo servidor. Si el servidor se cae, el monitoreo cae con él y nadie se entera.
• Ignorar la base de datos como punto único de falla. Duplicar la aplicación no sirve de mucho si todas las instancias dependen de una sola base de datos sin réplica.

Cómo encaja Dongee

En Dongee tenemos opciones para cada uno de estos modelos, y lo más honesto es elegir según tu equipo y el impacto real de una caída.

Para sitios estándar: el hosting compartido de Dongee tiene los planes Emprende desde 10 USD/mes y Quantum desde 19 USD/mes, con cPanel y CloudLinux sobre SSD NVMe y 99,9 % de uptime garantizado. Funciona sobre la infraestructura GeeCloud, con datos en triple réplica sobre discos NVMe enterprise, backups automáticos diarios con restauración asistida y Cloudflare.

Para sitios y tiendas críticos sin equipo técnico: el Hosting Empresas de Dongee es gestionado y separa los recursos en contenedores, con CPU, RAM e IO definidos por plan y sin sobreventa. Incluye triple réplica de datos en tres servidores diferentes, backups diarios con ayuda en la restauración, monitoreo 24/7, migración gestionada de web y correos, y soporte 24/7 con respuesta en menos de 60 segundos. Los planes son Zafiro (25 USD/mes), Esmeralda (43 USD/mes), Rubí (60 USD/mes) y Diamante (76 USD/mes).

Para equipos que quieren diseñar su propia redundancia: Dongee Cloud te da acceso root SSH completo, despliegue en menos de 3 minutos y 99,9 % de uptime garantizado, el mismo compromiso que en el hosting compartido. En todos los planes de Cloud tienes red redundante con BGP multihoming, snapshots incrementales automatizados o manuales, backups incluidos, red privada aislada entre tus instancias sin costo extra e IP dedicada. Puedes elegir entre Atlanta, Miami, NY, Dallas, México, São Paulo, Santiago de Chile, Frankfurt, Madrid, Londres y Amsterdam, con 7 planes fijos desde 17 USD/mes (Cloud 1: 1 CPU, 1 GB RAM, 25 GB). Si necesitas recursos que no se comparten, Cloud Dedicado ya se puede contratar: ofrece memoria, procesamiento y almacenamiento exclusivos, con infraestructura de alta disponibilidad y triple réplica de datos, y solo está en la zona Norteamérica Este. Dongee no vende un balanceador gestionado: puedes montar el tuyo con Nginx o HAProxy entre instancias, usando la red privada.

Para dimensionar a la medida: con Cloud On Demand eliges de 1 a 64 vCPU, de 1 a 256 GB de RAM y de 25 a 2.000 GB SSD NVMe. Pagas 6 USD por vCPU, 3 USD por GB de RAM y 0,3 USD por GB de almacenamiento al mes, con un mínimo de 17 USD/mes. Incluye almacenamiento NVMe de alta disponibilidad con triple replicación, copias de seguridad automatizadas y recuperación ante desastres, sin costo extra.

En todos los casos tienes soporte humano 24/7 que te atiende en tu idioma, porque la plataforma traduce al vuelo.

Preguntas frecuentes

¿Un hosting compartido es menos confiable que la nube?

No necesariamente. Un hosting compartido bien gestionado, con almacenamiento replicado y límites por cuenta, puede tener buena disponibilidad para sitios estándar. Su límite es que compartes recursos y no puedes diseñar redundancia propia. Una nube mal administrada puede ser menos confiable que un buen hosting compartido.

¿Qué significa 99,9 % de uptime garantizado?

Es el compromiso del proveedor de mantener su infraestructura operativa durante esa proporción del tiempo, según las condiciones de su SLA. Cubre servidores, red y plataforma, no los errores de tu aplicación, tus plugins ni tus configuraciones. En Dongee, ese 99,9 % aplica tanto al hosting compartido como a Cloud.

¿Un servidor en la nube nunca se cae?

Sí se puede caer. Puede fallar el sistema operativo, llenarse el disco, colgarse la base de datos o fallar una actualización. La nube te da herramientas para construir redundancia, pero un solo servidor sigue siendo un punto único de falla.

¿Necesito un balanceador de carga?

Solo si tienes dos o más instancias de tu aplicación y quieres que el tráfico siga fluyendo cuando una falle. Con un único servidor, un balanceador no aporta disponibilidad. Recuerda que el balanceador también puede ser un punto único de falla si no lo duplicas.

¿Backup y alta disponibilidad son lo mismo?

No. El backup te permite recuperar datos después de un incidente; la alta disponibilidad busca que el servicio siga funcionando durante el incidente. Un sitio con buenos backups puede pasar un buen rato fuera de línea mientras se restaura.

¿Qué es el efecto vecino ruidoso?

Es la degradación que sufre tu sitio cuando otra cuenta que comparte el mismo servidor consume demasiados recursos. Se reduce con límites por cuenta y desaparece en gran medida cuando tus recursos están separados o son dedicados.

¿Puedo empezar en compartido y migrar después?

Sí, y es una ruta habitual. Empieza en compartido mientras tu sitio sea estándar y pasa a empresarial gestionado o a la nube cuando una caída empiece a costarte ventas o clientes. Planea la migración con tiempo y con copias verificadas.

¿Qué conviene a una tienda online que vende todo el día?

Si no tienes a alguien que administre servidores, un hosting empresarial gestionado con recursos separados, réplica de datos y monitoreo suele ser la opción más equilibrada. Si tienes un equipo técnico y necesitas que la tienda siga vendiendo aunque falle un servidor, una arquitectura en la nube con varias instancias, balanceador y base de datos replicada te da más control, a cambio de más trabajo de operación.

Conclusión

La diferencia entre un hosting compartido y una nube empresarial no está solo en la potencia: está en quién comparte los recursos, quién opera cada capa y quién puede diseñar la redundancia. Define primero cuánto tiempo puedes estar fuera de línea y cuántos datos puedes perder, y después elige el modelo que tu equipo realmente pueda sostener. Si quieres ayuda para decidir, nuestro equipo de soporte puede revisar tu caso y recomendarte entre Hosting Empresas y Dongee Cloud.