VPS administrado o no administrado: ¿cuál necesita?

VPS administrado frente a no administrado: respuesta breve

Elegir entre un VPS administrado y uno no administrado es una cuestión de trabajo, no de producto. En un VPS no administrado, usted se encarga de aplicar parches, configurar el firewall, realizar copias de seguridad, supervisar el sistema y reiniciar el servidor a las 2am. En un VPS administrado, el proveedor realiza parte de esas tareas por usted, pero el alcance varía mucho entre proveedores. La única comparación útil es la lista de tareas que cada plan elimina de sus responsabilidades, comparada con el coste de sus propias horas.

No existe una definición estándar de la palabra administrado. Para un proveedor, significa que el sistema operativo recibe parches y que una persona responde a los tickets. Para otro, significa que se instaló un panel de control y que todo lo demás queda a su cargo. Para un tercero, significa un contrato de servicio escrito con un tiempo de respuesta definido. Dos planes que usan la misma palabra pueden diferir en todos los aspectos importantes. Por eso, lea el documento de alcance antes de consultar el precio. Si todavía está decidiendo para qué sirve realmente la máquina, qué puede hacer realmente con un VPS es la pregunta que debe resolver primero.

Las tareas que alguien debe asumir

Todo servidor en ejecución tiene la misma lista de tareas. En un plan no gestionado, esa lista es responsabilidad suya. En un plan gestionado, paga para que se eliminen tareas de esa lista. Revise la lista y escriba un nombre junto a cada tarea.

• Aplicar parches al sistema operativo y realizar los reinicios que requieren las actualizaciones del kernel.
• Mantener correctas las reglas del firewall al añadir y eliminar servicios. Los conceptos básicos del firewall ufw para un VPS cubren el conjunto inicial de reglas.
• Acceso SSH: gestionar las claves, desactivar el inicio de sesión con contraseña, revocar una clave cuando alguien deja el equipo y disponer de una forma de recuperar el acceso si se bloquea.
• Copias de seguridad, una copia externa y una restauración que haya realizado realmente.
• Supervisión: saber si el servidor es accesible, si el disco tiene espacio, si el servicio sigue en ejecución y si el certificado no ha caducado.
• Revisar los registros y responder cuando algo parece incorrecto en ellos.
• Configurar los servicios del servidor web, la base de datos, el proxy inverso y la cola, si utiliza una.
• Renovar los certificados y corregir el problema cuando la renovación automática deja de funcionar.
• Capacidad: detectar que la memoria se ha agotado antes de que el killer de out of memory (OOM) lo detecte por usted.
• Respuesta ante incidentes: estar despierto y localizable a una hora que usted no elige.

La mayoría de estas tareas son rutinarias y se pueden delegar a un script. La respuesta ante incidentes es la excepción, porque requiere que una persona pueda tomar decisiones. Ese es el servicio real que vende un plan gestionado. Por eso, la lista de comprobación más adelante dedica la mayoría de sus preguntas al alcance del soporte y no a la aplicación de parches.

Lo que normalmente no incluye la gestión

Aquí es donde los compradores se llevan sorpresas, así que sea preciso. Un contrato de gestión normalmente cubre el sistema operativo y el software que instaló el proveedor. La cobertura termina en el límite de su aplicación.

Su propio código es responsabilidad suya. Un error 500 de su aplicación no es un fallo del servidor. El proveedor confirmará que el proceso del servidor web está en ejecución y devolverá el ticket. Ese es un límite razonable. También es la mayor diferencia entre lo que esperan los compradores y lo que adquirieron.

Los problemas del nivel de aplicación normalmente están fuera del alcance. Una consulta lenta a la base de datos, un plugin que dejó de funcionar después de una actualización, una caché mal configurada o una cola de correo que dejó de procesar mensajes están por encima de ese límite, aunque el proveedor haya instalado el software subyacente.

La mayor parte de la recuperación de datos está fuera del alcance. Las copias de seguridad del proveedor protegen la imagen que este tiene del servidor completo y existen para el caso de que falle el hardware del host. Rara vez están preparadas para el caso en que eliminó una fila, ejecutó una migración incorrecta o dañó un archivo hace seis semanas y lo detectó hoy. Pregunte cuál es el periodo de retención, si se puede extraer un solo archivo y quién ejecuta la restauración.

El software que instaló es responsabilidad suya. Si instala Docker, el proveedor normalmente es responsable del host y usted de todo lo que haya dentro de los contenedores.

Las modificaciones manuales pueden anular el soporte. Algunos contratos excluyen un componente del alcance después de que un cliente haya editado directamente su configuración. Pregunte por esta condición si tiene previsto ajustar algún componente.

Valore su tiempo según la diferencia mensual

Toma las dos cotizaciones que tienes delante y anota la diferencia mensual. Esa cantidad es lo que cobra el proveedor por eliminar los elementos de la lista anterior. Ahora asigna un valor a tu parte de la decisión.

• ¿Cuánto vale una hora de tu tiempo y cuántas horas al mes requiere esa lista una vez automatizada?
• ¿Cuánto cuesta una hora de tiempo de inactividad para el servicio que se ejecuta en este servidor?

Un sistema Ubuntu estable, con actualizaciones automáticas y monitorización externa, requiere muy poca atención rutinaria. La mayoría de los meses no requiere ninguna. El trabajo rutinario es barato cuando lo gestiona un script. Las interrupciones son la parte costosa, y las interrupciones son lo que vende un plan administrado. Si el servidor ejecuta un proyecto personal, una interrupción no cuesta nada y la opción no administrada es la respuesta obvia. Si procesa pedidos, analiza con atención si un contrato de soporte realmente acorta una interrupción, porque un proveedor administrado aún tiene que leer tu ticket, reproducir el fallo y actuar.

La diferencia también aumenta con el número de servidores. Las tarifas de administración normalmente se cobran por servidor, mientras que la automatización se escribe una vez y se copia. El segundo servidor reduce a la mitad el costo efectivo del script que escribiste para el primero, así que lee cómo administrar varios servidores Linux antes de comprometerte con una tarifa por servidor. Para conocer las cifras base de ambos lados de la comparación, cuánto cuesta realmente un VPS al mes establece el mínimo, y la comparación entre VPS y servidor dedicado adquiere importancia cuando la carga de trabajo es lo bastante grande como para que la prima por administración sea un error de redondeo.

Preguntas que debe hacer al proveedor antes de pagar por la administración premium

Pregunte antes de pagar y solicite las respuestas por escrito. Una página de ventas no es un documento de alcance.

1. ¿Qué está incluido, tarea por tarea? Solicite la lista, no el folleto.
2. ¿El soporte cubre el software que instalo yo o solo el software que instalaron ustedes?
3. ¿Aplican parches automáticamente y reinician el servidor para actualizar el kernel sin preguntarme antes?
4. ¿Quién es responsable si un parche aplicado por ustedes rompe mi aplicación?
5. ¿Realizan copias de seguridad? ¿Dónde se almacenan, cuánto tiempo se conservan y quién realiza una restauración?
6. ¿Han restaurado recientemente el servidor de un cliente y cuánto tiempo tardaron?
7. ¿Cuál es el tiempo de respuesta de los tickets y cambia a las 03:00 de un domingo?
8. ¿Conservo el acceso de root y usarlo reduce el soporte que me proporcionarán?
9. ¿La tarifa se cobra por servidor o por cuenta?
10. Si me voy, ¿qué me llevo? Una configuración que reside dentro de un panel de control propietario puede ser difícil de exportar.

La pregunta 5 determina la mayoría de las demás. Un proveedor que responde con precisión demuestra que ya lo ha hecho antes. Una respuesta vaga significa que la restauración nunca se ha probado, y una copia de seguridad no probada es solo una copia. La pregunta 5 también incluye el aspecto de la ubicación: dónde se encuentran físicamente las copias es tanto una cuestión legal como técnica, y lo que realmente importa al elegir un país para alojar el servidor lo explica.

El punto intermedio: sin gestión y con automatización

La mayoría de los lectores técnicos no quiere ninguno de los dos extremos. Quiere un plan sin gestión, con las tareas rutinarias a cargo de la máquina, y reservar su atención para lo que una máquina no puede evaluar. Configúrelo el primer día. Los primeros diez minutos en un VPS nuevo es el punto de partida práctico para cualquiera que elija un plan sin gestión, y proteger el acceso SSH forma parte de esa misma primera sesión.

Actualizaciones de seguridad automáticas

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Ese archivo debería contener ahora APT::Periodic::Update-Package-Lists "1"; y APT::Periodic::Unattended-Upgrade "1";. La ausencia del archivo, o un 0 en cualquiera de las líneas, significa que no se ejecuta nada y no recibirá ningún aviso.

Pruébelo sin modificar el sistema. Tenga en cuenta que el paquete es unattended-upgrades, mientras que el comando está en singular:

sudo unattended-upgrade --dry-run --debug

La salida muestra todos los paquetes que consideró y termina con una línea como No packages found that can be upgraded unattended cuando no hay nada pendiente. Las ejecuciones reales se escriben en /var/log/unattended-upgrades/unattended-upgrades.log, así que compruébelo allí en lugar de hacer suposiciones.

Una actualización del kernel no tiene efecto hasta que se reinicia la máquina, porque el kernel en ejecución es el que se carga durante el arranque. El archivo /var/run/reboot-required aparece cuando hay un reinicio pendiente. Puede vigilar ese archivo o dejar que la máquina lo gestione mediante /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" impide el reinicio mientras haya alguien conectado, lo que es más seguro en un equipo que usa de forma interactiva y no sirve de nada en uno al que nadie inicia sesión. La configuración completa de actualizaciones desatendidas en Ubuntu explica la sintaxis de la lista de bloqueo y las opciones de correo electrónico.

Supervisión desde otro lugar

Un monitor que se ejecuta en el servidor no puede informarle de que el servidor está caído, porque el monitor también lo está. Ejecute la comprobación en un segundo host o en un servicio externo. Uptime Kuma para supervisar el estado es la opción habitual para instalaciones propias, y debe ejecutarse en una máquina distinta de la que supervisa.

Como mínimo, supervise cuatro aspectos: la accesibilidad, el uso del disco, si la aplicación responde en su puerto real y la caducidad del certificado. El disco es el aspecto que más problemas causa. Un archivo de log o una base de datos que crece un poco cada día puede dejar el equipo fuera de servicio en un momento que nada más permite predecir, y el primer síntoma suele ser un servicio que no puede escribir y termina.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

Añada también un heartbeat. Un timer del servidor llama a una URL después de cada backup correcto o comprobación de estado, y el monitor genera una alerta cuando la llamada deja de llegar. De este modo, un servidor silencioso genera su propia alerta, algo que una comprobación que solo realiza consultas no puede hacer cuando lo que falla es la ruta de red.

Backups restaurados al menos una vez

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init muestra created restic repository <id> at sftp:... una sola vez. Ejecutarlo contra un repositorio que ya existe falla en lugar de sobrescribirlo, que es el comportamiento que necesita. Guarde una copia de esa passphrase fuera del servidor: el repositorio no se puede leer sin ella y no existe ningún método de recuperación.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots debería mostrar la ejecución que acaba de realizar, con la fecha de hoy. restic check verifica la estructura del repositorio y muestra no errors were found. Ahora haga la parte que la mayoría omite:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

El archivo que esperaba está o no está, y descubrirlo ahora solo cuesta diez minutos. Después, programe la ejecución con un timer para que no dependa de usted. Escriba /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Y /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers muestra la próxima ejecución y el tiempo restante. Un resultado vacío significa que activó el servicio en lugar del timer, que es el error más común en este punto. Persistent=true ejecuta un trabajo omitido después del siguiente arranque, de modo que una máquina que estuvo apagada durante la noche sigue haciendo su backup. Backups con Restic en un VPS explica con más detalle la estructura y la retención del repositorio, y servicios y timers de systemd explica los archivos de unidad línea por línea.

Lo que la automatización no le proporciona

No le proporciona criterio. Un reinicio automático a las 02:00 ocurre independientemente de que la aplicación vuelva a iniciarse correctamente, así que confirme que cada servicio se inicia por sí solo y después reinicie de forma intencionada mientras esté despierto:

systemctl is-enabled nginx docker
sudo reboot

Una actualización desatendida también puede instalar un paquete que rompa la aplicación, y nada de la canalización sabe que ha ocurrido. El monitor es lo que lo detecta, por lo que deja de ser opcional cuando las actualizaciones son automáticas. La máquina se encarga de lo rutinario. El incidente sigue siendo responsabilidad suya.

Cuándo vale la pena pagar por un servicio gestionado

Hay que valorar de forma justa la opción gestionada. Cuatro situaciones hacen que sea la compra adecuada.

• Nadie del equipo administra Linux y no está previsto contratar a alguien.
• Un requisito de cumplimiento designa a una parte responsable de aplicar parches, y esa parte no puede ser usted.
• La pila tecnológica es una de las que el proveedor conoce bien, por lo que su equipo de soporte ya ha visto fallos como el suyo.
• La persona que haría el trabajo de otro modo es su empleado más caro, y una de sus horas cuesta más que un mes del plan premium.

Un servicio gestionado no es automáticamente más seguro. Los planes gestionados pueden aplicar parches más rápido que un propietario que no presta atención, y eso supone una mejora real. Además, suelen instalar un panel de control, que es una aplicación grande expuesta a la red, con una página de inicio de sesión y un historial propio de vulnerabilidades. Puede ser una compensación razonable, pero sigue siendo una compensación.

La decisión se reduce siempre a la misma lista. Anote las diez tareas, indique quién es responsable de cada una en cada oferta y compare la diferencia con el valor de una hora de su atención. La mayoría de los lectores técnicos que hacen esto terminan eligiendo un servicio no gestionado y asignando las tareas rutinarias a un temporizador. Es una respuesta defendible, no simplemente una opción barata.

FAQ

¿Cuál es la diferencia entre un VPS administrado y uno no administrado?

Un VPS no administrado le proporciona la máquina y nada más. Usted se encarga de aplicar parches, configurar el firewall, realizar copias de seguridad, supervisar el sistema y reiniciarlo después de una actualización del kernel. Un VPS administrado traslada parte de ese trabajo al proveedor, normalmente la capa del sistema operativo y el software que el proveedor instaló para usted. El límite exacto lo establece cada proveedor, no la denominación. Por eso, solicite por escrito el alcance de cada tarea antes de comparar dos precios.

¿Un VPS administrado significa que no necesito mis propias copias de seguridad?

No. Las copias de seguridad del proveedor suelen proteger la imagen que este tiene del servidor completo y están pensadas para casos en los que falla el host. Rara vez ayudan si eliminó un archivo, ejecutó una migración incorrecta o dañó datos hace varias semanas y lo detectó hoy. Pregunte cuánto tiempo se conservan las instantáneas, si se puede restaurar un solo archivo y quién realiza la restauración. Después, mantenga su propia copia externa con una herramienta como restic y pruébela con restic restore latest --target /tmp/restore-check para confirmar que funciona.

¿Un VPS administrado es más seguro que uno no administrado?

No por sí mismo. Un plan administrado aplica los parches más rápido que un propietario que nunca inicia sesión, lo que reduce realmente el riesgo. Muchos planes administrados también instalan un panel de control. Un panel es una aplicación grande expuesta a la red, con su propia página de inicio de sesión y su propio historial de vulnerabilidades. Un servidor no administrado con actualizaciones de seguridad automáticas, un firewall cerrado, SSH que solo use claves y ningún servicio adicional escuchando representa un objetivo menor que un servidor administrado con un panel.

¿Puedo empezar con un VPS no administrado y cambiar después a uno administrado?

Normalmente sí, aunque rara vez se trata de marcar una casilla. Los proveedores suelen auditar o reconstruir el servidor antes de asumir su administración, porque no ofrecen soporte para una configuración que no pueden revisar. Pregunte en qué consiste la incorporación, si requiere una reinstalación y si algo de lo que configuró usted queda fuera del alcance del soporte posteriormente.

¿Conservo el acceso root en un VPS administrado?

En la mayoría de los planes de VPS administrados, sí. Sin embargo, el acceso root y el alcance del soporte están relacionados. Algunos proveedores reducen o anulan el soporte de un componente que usted modificó manualmente. Otros reconstruyen el servidor a partir de su propia plantilla si el caso requiere una intervención profunda. Obtenga esta regla por escrito antes de ajustar nada y mantenga los archivos de configuración bajo control de versiones. Así, una reconstrucción costará una hora en lugar de un fin de semana.