VPS o hosting compartido: cuándo dar el paso al VPS

La diferencia, punto por punto

En un hosting compartido, el proveedor administra un servidor que reparte entre muchos clientes: el mismo sistema, las mismas versiones de software, los mismos ajustes para todos, y límites por cuenta para que ningún sitio perjudique a los demás. En un VPS (servidor privado virtual), usted dispone de un servidor aislado, con sus propios recursos, su sistema y el acceso root: instala en él lo que su proyecto necesita.

Las señales de que es hora de pasar a un VPS

1. Su aplicación no es un sitio PHP

Una aplicación Node.js, Python, Go o Java funciona de forma continua: un proceso espera las peticiones y mantiene su estado en memoria. El hosting compartido está construido para lo contrario: scripts PHP que se lanzan en cada petición y se detienen después. Algunos proveedores aceptan Node.js o Python en un marco restringido (versiones impuestas, procesos detenidos tras un periodo de inactividad); en cuanto la aplicación crece, ese marco se convierte en la limitación principal.

2. Necesita un servicio que el proveedor no ofrece

PostgreSQL, Redis, una cola de tareas (RabbitMQ, Celery, BullMQ), un motor de búsqueda, un navegador sin interfaz para generar PDF o capturas, ffmpeg para procesar vídeos, un modelo de IA: todo lo que se instala y funciona como un servicio requiere un servidor en el que usted tenga el control.

3. Alcanza los límites de la cuenta

Un proveedor de hosting compartido limita cada cuenta: tiempo de procesador, memoria, número de procesos simultáneos (entry processes), número de archivos (inodes). Los síntomas: una página «508 Resource Limit Is Reached», errores 503 en horas punta, un sitio lento cuando un vecino está cargado, importaciones interrumpidas. El panel de control suele mostrar estos contadores; si llegan a su tope con regularidad, el sitio ha superado su plan.

4. Hay tareas que deben ejecutarse solas

Tareas programadas cada minuto, procesos en segundo plano, envíos de correo por lotes, sincronizaciones: el hosting compartido espacia las tareas programadas e interrumpe los scripts demasiado largos. En un VPS, un worker funciona de forma permanente y una tarea dura el tiempo que necesita.

5. Necesita ajustar el servidor

Una versión concreta de PHP o de una extensión, la memoria asignada a PHP, un servidor web configurado para su aplicación, un cortafuegos propio, despliegues automatizados con git o con contenedores Docker: son ajustes que un servidor compartido no puede abrir a cada cliente.

6. Sus exigencias de seguridad aumentan

Datos de clientes, obligaciones contractuales, auditoría de seguridad: un servidor aislado, cuyos accesos y registros usted controla, se documenta y se verifica con más sencillez que una cuenta en un servidor compartido.

¿Y para un sitio vitrina?

Un sitio vitrina que presenta una actividad no necesita procesos permanentes ni una base de datos ajustada a medida. Si lo que busca es sobre todo un sitio rápido, seguro y actualizado, sin nada que administrar, la respuesta adecuada es un sitio gestionado, más que un hosting compartido o un VPS: Simafri crea su sitio web, lo aloja, lo protege y lo mantiene actualizado, y usted no tiene ningún servidor que mantener.

Lo que cambia al pasar a un VPS

Con el acceso root llega el mantenimiento del sistema. En un hosting compartido, el proveedor se ocupa de él sin que usted lo vea; en un VPS, cuatro asuntos requieren una respuesta:

• Las actualizaciones de seguridad del sistema y del software instalado, aplicadas con regularidad. Debian y Ubuntu saben instalar solos las correcciones de seguridad (unattended-upgrades).
• El cortafuegos y los accesos: conexión SSH por clave, puertos abiertos limitados a lo necesario.
• Las copias de seguridad: saber qué copia el proveedor, con qué frecuencia, y qué exporta usted además, empezando por la base de datos.
• La supervisión: recibir un aviso cuando el servidor deja de responder, cuando el disco se llena o cuando un certificado está a punto de caducar.

Hay tres formas de ocuparse de ello: hacerlo usted mismo, avanzar con una asistencia que diagnostica y le indica qué hacer, o confiar la explotación a un servicio administrado. La elección depende de quién conoce Linux en su equipo y de lo que le cuesta a su actividad una hora de parada.

Pasar a un VPS sin cortes

1. El inventario: versión de PHP o del lenguaje, extensiones, base de datos y su tamaño, tareas programadas, certificados, y el lugar donde están alojadas sus direcciones de correo.
2. La preparación del VPS: sistema actualizado, servidor web, lenguaje y base de datos, en las mismas versiones que el entorno actual.
3. La copia: los archivos, con rsync o un archivo comprimido, y la base de datos, con una exportación y después una importación.
4. La prueba antes del cambio: solo en su equipo, haga que el dominio apunte al nuevo servidor mediante el archivo hosts, y recorra el sitio como un visitante.
5. La reducción del TTL de los registros DNS del sitio a unos minutos, la víspera del cambio, para que se propague rápido.
6. El cambio: última copia de la base de datos, registros DNS del sitio apuntando al nuevo servidor y, después, vigilancia de los logs. Conserve el antiguo hosting unos días, el tiempo de que todos los visitantes lleguen al nuevo.

rsync -avz --progress usuario@servidor-antiguo:/ruta/del/sitio/ /var/www/site/

203.0.113.10  www.su-sitio.com su-sitio.com

Si sus direcciones de correo están alojadas en la misma cuenta de hosting compartido, cambie solo los registros DNS del sitio y deje los registros MX como están: el correo sigue funcionando durante y después del cambio, y se migra por separado.