Todos hemos cometido errores con nuestro primer VPS. Esta guía te ahorra las horas (o días) de frustración que otros ya vivieron.
Errores críticos de seguridad
1. No cambiar el puerto SSH
El error: Dejar SSH en el puerto 22.
Por qué es malo: Los bots escanean el puerto 22 constantemente. Miles de intentos de login por día.
Solución:
# Editar configuración SSH
sudo nano /etc/ssh/sshd_config
# Cambiar puerto
Port 2222
# Reiniciar
sudo systemctl restart sshd
# No olvides abrir el nuevo puerto en firewall
sudo ufw allow 2222/tcp2. Usar root para todo
El error: Conectarse siempre como root y ejecutar todo como root.
Por qué es malo: Un error con root puede destruir el sistema. Más superficie de ataque.
Solución:
# Crear usuario normal
adduser miusuario
usermod -aG sudo miusuario
# Usar sudo solo cuando necesario
sudo apt update3. No configurar firewall
El error: Dejar todos los puertos abiertos.
Por qué es malo: Expones servicios innecesariamente. Más vectores de ataque.
Solución:
# Configurar UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp # SSH
sudo ufw allow 80/tcp # HTTP
sudo ufw allow 443/tcp # HTTPS
sudo ufw enable4. No instalar Fail2ban
El error: Dejar que los bots intenten login infinitamente.
Por qué es malo: Eventualmente pueden adivinar credenciales débiles.
Solución:
sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban5. Usar contraseñas en vez de claves SSH
El error: Acceder por contraseña en lugar de claves SSH.
Por qué es malo: Las contraseñas son vulnerables a fuerza bruta. Las claves son prácticamente imposibles de romper.
Solución:
# En tu máquina local
ssh-keygen -t ed25519
# Copiar clave al servidor
ssh-copy-id -p 2222 usuario@tu-servidor
# Deshabilitar login por contraseña
sudo nano /etc/ssh/sshd_config
# PasswordAuthentication noErrores de backup
6. No hacer backups
El error: “Ya haré backup mañana” → nunca.
Por qué es malo: Cuando lo necesitas, ya es tarde. Disco corrupto, hack, error humano.
Solución:
# Script básico de backup
#!/bin/bash
mysqldump --all-databases > /backups/db_$(date +%Y%m%d).sql
tar -czf /backups/www_$(date +%Y%m%d).tar.gz /var/www/
# Programar con cron
0 3 * * * /root/scripts/backup.sh7. Guardar backups solo en el mismo VPS
El error: Backup en /backups/ del mismo servidor.
Por qué es malo: Si el disco falla o te hackean, pierdes todo incluyendo backups.
Solución:
# Enviar a almacenamiento externo con rclone
rclone sync /backups remote:backups-vps8. No probar restauración de backups
El error: Asumir que los backups funcionan sin probarlos.
Por qué es malo: Backups corruptos o incompletos son inútiles.
Solución: Al menos una vez, restaura un backup en entorno de prueba. Verifica que funciona.
Errores de rendimiento
9. No configurar swap
El error: VPS sin memoria swap.
Por qué es malo: Cuando se acaba la RAM, procesos mueren sin aviso.
Solución:
# Crear swap de 2GB
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# Hacer permanente
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab10. No activar OPcache
El error: PHP sin caché de bytecode.
Por qué es malo: PHP compila scripts en cada petición. Mucho más lento.
Solución:
# Verificar
php -i | grep opcache.enable
# Si no está activo, editar php.ini
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=1000011. MySQL sin optimizar
El error: Dejar MySQL con configuración por defecto.
Por qué es malo: innodb_buffer_pool_size muy pequeño = consultas lentas.
Solución:
# En my.cnf
[mysqld]
innodb_buffer_pool_size = 512M # ~50-70% de RAM disponibleErrores de gestión
12. No documentar nada
El error: “Me acordaré de cómo lo configuré.”
Por qué es malo: 6 meses después no tienes idea de qué hiciste.
Solución: Documenta todo:
- Cómo acceder (IP, puerto, usuario)
- Qué software instalaste
- Configuraciones especiales
- Proceso de deploy
13. No monitorizar
El error: Enterarte de caídas cuando clientes se quejan.
Por qué es malo: Pierdes clientes y reputación.
Solución:
# UptimeRobot gratis
# Configura alertas por email/Telegram
# O script básico
curl -s -o /dev/null -w "%{http_code}" https://tudominio.com14. Actualizar sin probar
El error: apt upgrade -y en producción sin backup.
Por qué es malo: Una actualización rota = sitio caído sin forma de volver.
Solución:
# Siempre antes de actualizar:
# 1. Backup de base de datos
# 2. Backup de archivos
# 3. Entonces actualizar
# 4. Probar que todo funciona15. Elegir VPS por precio solamente
El error: “Este VPS cuesta €3/mes, perfecto.”
Por qué es malo: Overselling, soporte inexistente, uptime malo, sin backups.
Solución: Considera:
- Uptime garantizado (SLA)
- Soporte en tu idioma
- Reputación del proveedor
- Backups incluidos
- Ubicación de servidores
Checklist anti-errores
□ Puerto SSH cambiado
□ Usuario no-root creado
□ Firewall activo (UFW)
□ Fail2ban instalado
□ Claves SSH (no contraseñas)
□ Backup diario configurado
□ Backup externo configurado
□ Swap configurado
□ OPcache activo
□ MySQL optimizado
□ Documentación creada
□ Monitorización activaPreguntas frecuentes
¿Cuál es el error más grave que puedo cometer?
No hacer backups. Todo lo demás se puede arreglar. Sin backup, una pérdida de datos es permanente. Configura backups automáticos desde el día uno.
¿Es seguro usar root si tengo firewall?
No recomendado. El firewall protege de ataques externos, pero usar root significa que cualquier error tuyo puede destruir el sistema. Usa un usuario normal con sudo.
¿Puedo corregir estos errores en un VPS ya configurado?
Sí, todos son corregibles. Empieza por seguridad (SSH, firewall, fail2ban), luego backups, luego rendimiento. Hazlo con cuidado y backup previo.
¿Cuánto tiempo lleva configurar todo correctamente?
Con experiencia, 1-2 horas. Como principiante, medio día. Pero ese tiempo invertido te ahorra semanas de problemas futuros.
¿Qué hago si ya cometí uno de estos errores y hay problemas?
No entres en pánico. Restaura desde backup si tienes. Si no, documenta el problema y busca la solución específica. Considera contratar ayuda profesional si es crítico.
Nuestra recomendación
Principio #1: Seguridad antes que funcionalidad. Configura SSH, firewall y backups ANTES de instalar tu aplicación.
Principio #2: Backups, backups, backups. No hay excusa. Es la diferencia entre “problema resuelto en 10 minutos” y “perdí todo”.
Principio #3: Documenta mientras haces. Es mucho más fácil documentar en el momento que recordar después.
¿Prefieres evitar estos errores? La administración gestionada de Avantys incluye toda la configuración de seguridad y backups desde el inicio.
Conclusión
Todos cometemos errores al empezar. La diferencia es aprender de los errores de otros en lugar de vivirlos tú mismo.
Usa la checklist de este artículo y tendrás un VPS más seguro que el 90% de los servidores en internet.
¿Quieres un VPS ya configurado correctamente? Explora los VPS de Avantys con configuración de seguridad base incluida.
¿Quieres que lo hagamos por ti?
En Avantys gestionamos tu web, hosting y crecimiento digital de punta a punta. Tú a lo importante.
