Los 10 errores más comunes al gestionar un servidor VPS y cómo evitarlos
Contratar un VPS es fácil. Administrarlo bien es otra historia.
La mayoría de problemas graves que ocurren en servidores VPS no son fallos del proveedor, sino errores evitables de configuración y mantenimiento. Esta guía recoge los diez más habituales junto con soluciones concretas para cada caso.
Si acabas de contratar tu primer VPS o llevas tiempo administrando uno y nunca has revisado estos puntos, este artículo es para ti.
Error 1: No configurar backups propios desde el primer día
El proveedor de VPS puede hacer snapshots diarios del servidor, pero eso no exime de configurar tus propios backups de los datos críticos.
La diferencia es importante: un snapshot del servidor completo tarda tiempo en restaurar y, además, a veces no es granular. Es decir, no siempre puedes recuperar solo un archivo o una base de datos sin restaurar todo el sistema. En cambio, un backup propio de la base de datos y de los archivos de la aplicación te permite recuperar exactamente lo que necesitas en cuestión de minutos.
Solución: configura un cron job diario que haga un dump de las bases de datos MySQL y comprima los directorios críticos. Después, envía esas copias a un almacenamiento externo, como un bucket S3, un FTP externo o un servicio como Backblaze B2.
# Ejemplo básico de backup de MySQL
mysqldump -u root -p nombre_base_datos > /backups/db_$(date +%Y%m%d).sql
En BlumHost, ofrecemos VPS con backups diarios automáticos en segunda ubicación.
Aun así, siempre es recomendable añadir una capa propia para los datos más críticos.
Error 2: Usar el usuario root para todo
Conectarte siempre como root al servidor es como trabajar a diario desde la cuenta de administrador de Windows con todos los permisos. Cualquier error de comando o script malicioso tendrá acceso total al sistema.
Solución: crea un usuario con permisos limitados para el trabajo habitual y reserva root solo para tareas que realmente lo requieran.
adduser tuusuario
usermod -aG sudo tuusuario
Después, desactiva el login de root por SSH editando el archivo /etc/ssh/sshd_config y dejando esta directiva:
PermitRootLogin no
Error 3: Dejar el puerto SSH en el 22
El puerto 22 es el objetivo de miles de intentos de acceso automatizados cada día. Los bots escanean internet constantemente buscando servidores con SSH expuesto en el puerto por defecto.
Solución: cambia el puerto SSH a cualquier número superior a 1024, por ejemplo 2222 o 8722. No es una medida de seguridad definitiva, pero reduce muchísimo el ruido en los logs y los intentos de fuerza bruta.
# En /etc/ssh/sshd_config
Port 2222
Lo ideal es combinar esto con autenticación por clave pública, sin contraseña, y con fail2ban para bloquear IPs después de varios intentos fallidos.
Error 4: No actualizar el sistema operativo y los paquetes
Un VPS sin actualizar acumula vulnerabilidades conocidas. Los CVE se publican continuamente y muchos exploits para fallos conocidos están disponibles públicamente.
Solución: en sistemas Debian o Ubuntu, configura actualizaciones automáticas de seguridad:
apt install unattended-upgrades
dpkg-reconfigure unattended-upgrades
Para actualizaciones completas del sistema, conviene hacerlas manualmente cada dos o cuatro semanas, revisando antes el changelog para evitar sorpresas.
Error 5: Firewall desactivado o mal configurado
Un VPS nuevo suele tener todos los puertos abiertos por defecto. Eso significa que cualquier servicio que arranques, como una base de datos, un panel de administración o una API, puede quedar accesible desde internet.
Solución: configura UFW para permitir solo los puertos que realmente necesitas.
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp # SSH (tu puerto personalizado)
ufw allow 80/tcp # HTTP
ufw allow 443/tcp # HTTPS
ufw enable
Revisa la lista de reglas periódicamente y elimina aquellas que ya no uses.
Error 6: No monitorizar el uso de recursos
Un disco lleno puede corromper bases de datos. Un proceso descontrolado que consume toda la CPU puede tumbar todos los servicios. Una fuga de memoria en una aplicación puede dejar el servidor sin respuesta.
Nada de esto debería pillarte por sorpresa si tienes una monitorización mínima.
Solución básica: configura alertas por correo cuando el uso de disco supere el 80 %, cuando el load average supere un umbral razonable o cuando la memoria libre caiga por debajo de un mínimo.
Herramientas como Netdata, que es open source y se instala con un solo comando, o Munin, permiten una monitorización básica sin coste. Para proyectos más críticos, merece la pena considerar Prometheus + Grafana.
Error 7: Exponer la base de datos a internet
MySQL, PostgreSQL y MongoDB no deberían estar accesibles desde internet en un servidor de producción. Lo normal es que solo escuchen en localhost o, como mucho, en una red privada si trabajas con una arquitectura de varios servidores.
Solución: comprueba en qué interfaz está escuchando MySQL:
netstat -tlnp | grep mysql
Si ves 0.0.0.0:3306 en lugar de 127.0.0.1:3306, edita el archivo /etc/mysql/mysql.conf.d/mysqld.cnf y establece:
bind-address = 127.0.0.1
Si necesitas acceso remoto a la base de datos, lo más seguro es hacerlo mediante un túnel SSH, no exponiendo el puerto directamente a internet.
Error 8: Contraseñas débiles o reutilizadas
El acceso a bases de datos, paneles de administración y usuarios del sistema con contraseñas débiles sigue siendo una de las causas más comunes y más evitables de compromisos de seguridad.
Solución: utiliza contraseñas de al menos 20 caracteres generadas aleatoriamente. Un gestor de contraseñas como Bitwarden o KeePass hace esto muy fácil. Para servicios críticos, activa la autenticación en dos factores siempre que esté disponible.
En MySQL, además, conviene revocar usuarios que no necesites y aplicar el principio de mínimo privilegio:
REVOKE ALL PRIVILEGES ON *.* FROM 'usuario'@'%';
GRANT SELECT, INSERT, UPDATE ON base_datos.* TO 'usuario'@'localhost';
Error 9: No configurar SSL en todos los servicios
HTTPS no es opcional en 2026. Y no solo para webs públicas, sino también para paneles de administración, APIs y cualquier servicio que transmita datos.
Solución: Let’s Encrypt con Certbot es gratuito y fácil de automatizar.
apt install certbot python3-certbot-nginx
certbot --nginx -d tudominio.com
Después, verifica que la renovación automática está funcionando correctamente:
certbot renew --dry-run
Error 10: No tener un plan de recuperación ante desastres
El peor momento para pensar en cómo recuperar el servidor es cuando ya ha fallado.
Solución: documenta el proceso de reconstrucción del servidor desde cero. Como mínimo, deja anotado lo siguiente:
- Qué software está instalado y cómo se configura
- Dónde están los backups y cómo restaurarlos
- Qué dominios apuntan a qué IPs
- Qué credenciales se necesitan, guardadas en un gestor de contraseñas
Un servidor bien documentado puede reconstruirse en horas. Uno sin documentación puede costar días de trabajo y mucho estrés.
Si prefieres no gestionar todo esto por tu cuenta, contrata un VPS con backups diarios automáticos y soporte técnico en español.
