Un backup VPS automático es una copia periódica de tus archivos y bases de datos que se ejecuta sin intervención manual. Configurarlo correctamente es la diferencia entre recuperarte de un fallo en minutos y perder semanas de trabajo.
Esta guía muestra cómo automatizar tus copias de seguridad en Linux usando herramientas ya disponibles en tu servidor: rsync, mysqldump y cron.
1. Por qué no puedes depender solo del proveedor
La mayoría de los proveedores de VPS ofrecen snapshots automáticos, pero tienen limitaciones importantes:
- Los snapshots suelen hacerse una vez al día como máximo.
- El historial de retención es corto (7–14 días en la mayoría de planes).
- Restaurar un snapshot puede deshacer cambios recientes no relacionados con el problema.
- Un error de configuración en tu cuenta o un fallo del proveedor puede eliminar snapshots y datos al mismo tiempo.
La regla de oro es la estrategia 3-2-1: tres copias de tus datos, en dos medios diferentes, una fuera del sitio (offsite). Tu propio script de backup es el primer paso para cumplirla.
2. Qué necesitas respaldar
Antes de escribir una sola línea de script, identifica exactamente qué datos son críticos:
| Tipo de dato | Ubicación típica | Herramienta recomendada |
|---|---|---|
| Archivos del sitio web | /var/www/html o /home/user/public_html | rsync |
| Bases de datos MySQL/MariaDB | Gestionadas por el motor, no en filesystem | mysqldump |
| Configuración del servidor | /etc/nginx, /etc/apache2, /etc/php | rsync o tar |
| Certificados SSL | /etc/letsencrypt o /etc/ssl | rsync |
| Correo electrónico | /var/mail o /home/user/Maildir | rsync |
Documenta estas rutas antes de continuar. Un script de backup que respalde el directorio equivocado da una falsa sensación de seguridad.
3. Script básico de backup con rsync y mysqldump
El siguiente script realiza una copia local comprimida de archivos y bases de datos. Guárdalo en /usr/local/bin/backup-vps.sh y hazlo ejecutable con chmod +x.
#!/bin/bash
# backup-vps.sh — copia de seguridad local de archivos y bases de datos
FECHA=$(date +%Y-%m-%d)
DIR_BACKUP="/var/backups/vps/$FECHA"
WEB_SRC="/var/www"
DB_USER="backupuser"
DB_PASS="contraseña_segura"
RETENTION_DAYS=14
mkdir -p "$DIR_BACKUP/web" "$DIR_BACKUP/db" "$DIR_BACKUP/config"
# 1. Archivos del sitio web
rsync -az --delete "$WEB_SRC/" "$DIR_BACKUP/web/"
# 2. Bases de datos (una por una)
for DB in $(mysql -u"$DB_USER" -p"$DB_PASS" -e "SHOW DATABASES;" 2>/dev/null \
| grep -Ev "^(Database|information_schema|performance_schema|mysql|sys)$"); do
mysqldump -u"$DB_USER" -p"$DB_PASS" \
--single-transaction --routines --triggers "$DB" \
| gzip > "$DIR_BACKUP/db/${DB}_${FECHA}.sql.gz"
done
# 3. Configuración del servidor
rsync -az /etc/nginx/ "$DIR_BACKUP/config/nginx/" 2>/dev/null
rsync -az /etc/apache2/ "$DIR_BACKUP/config/apache2/" 2>/dev/null
rsync -az /etc/php/ "$DIR_BACKUP/config/php/" 2>/dev/null
# 4. Eliminar backups más antiguos que RETENTION_DAYS días
find /var/backups/vps -maxdepth 1 -type d -mtime +"$RETENTION_DAYS" -exec rm -rf {} +
echo "Backup completado: $DIR_BACKUP"
Nota de seguridad: crea un usuario de base de datos con permisos mínimos solo para backups (SELECT, LOCK TABLES, SHOW DATABASES). No uses root de MySQL en scripts.
4. Automatización con cron
Una vez que el script funciona manualmente, configura cron para ejecutarlo automáticamente. Edita el crontab del usuario que ejecutará el backup:
crontab -e
Añade una línea para ejecutar el backup cada día a las 03:00 AM (hora de menor tráfico):
# Backup VPS diario a las 3 AM, log en archivo
0 3 * * * /usr/local/bin/backup-vps.sh >> /var/log/backup-vps.log 2>&1
Verifica que el log se genera correctamente al día siguiente. Un cron silencioso que falla es peor que no tener cron.
Para más estrategias de mantenimiento de servidores, revisa la sección de servidores VPS donde cubrimos temas desde configuración inicial hasta seguridad avanzada.
5. Enviar backups a destino remoto (offsite)
El backup local protege contra errores de configuración o borrado accidental, pero no contra un fallo físico del servidor o del proveedor. Necesitas un destino remoto.
Opción A: servidor remoto con rsync sobre SSH
# Añadir al script, después de crear el backup local:
REMOTE_USER="backupuser"
REMOTE_HOST="servidor-remoto.com"
REMOTE_DIR="/backups/mi-vps/$FECHA"
rsync -az -e "ssh -i /root/.ssh/id_backup" \
"$DIR_BACKUP/" \
"$REMOTE_USER@$REMOTE_HOST:$REMOTE_DIR/"
Genera una clave SSH dedicada para backups (ssh-keygen -t ed25519 -f /root/.ssh/id_backup -N "") y añade solo la clave pública al servidor remoto con permisos restringidos.
Opción B: almacenamiento de objetos compatible con S3
Servicios como Backblaze B2, Wasabi o Amazon S3 ofrecen almacenamiento barato e ilimitado. Usa rclone para subir los backups:
# Configurar rclone (una vez):
rclone config
# Subir backup al bucket:
rclone copy "$DIR_BACKUP/" remote:mi-bucket-backups/$FECHA/ --transfers=4
Rclone soporta cifrado del lado del cliente: ningún dato sensible llega al bucket sin cifrar.
Conclusiones clave
- Los backups del proveedor son un complemento, no un sustituto de tu propia estrategia.
- Respalda archivos, bases de datos y configuración del servidor por separado.
- Usa un usuario de base de datos con permisos mínimos exclusivamente para backups.
- Automatiza con cron y verifica los logs al menos una vez por semana.
- Almacena al menos una copia en destino remoto (regla 3-2-1).
- Prueba la restauración periódicamente — un backup que no restaura no existe.
Si prefieres que alguien gestione esto por ti, en elenlace.com configuramos y monitoreamos tus backups como parte del servicio de VPS administrado.
Preguntas frecuentes
¿Con qué frecuencia debo hacer backups en mi VPS?
Para la mayoría de sitios web, un backup diario es suficiente. Si tu aplicación genera datos con mucha frecuencia (ecommerce activo, foro, CRM), considera backups cada 4–6 horas para la base de datos.
¿Cuánto espacio necesito para los backups?
Depende del tamaño de tus datos y la retención deseada. Como referencia, si tu sitio ocupa 5 GB, un backup comprimido suele pesar 1–2 GB. Con retención de 14 días necesitas ~15–30 GB para los backups locales.
¿mysqldump bloquea la base de datos durante el backup?
Con el flag --single-transaction (para tablas InnoDB), mysqldump hace un snapshot consistente sin bloquear escrituras. Para tablas MyISAM sí hay un breve bloqueo, por lo que se recomienda migrar a InnoDB.
¿Cómo verifico que mis backups funcionan correctamente?
Revisa el log de cron regularmente. Además, una vez al mes restaura un backup en un entorno de prueba y verifica que el sitio funciona. Esta prueba es la única forma real de saber si tu backup es válido.
¿Prefieres que lo hagamos por ti? En El Enlace resolvemos hosting y desarrollo web profesional.
Para saber más
Otros proveedores y guías que vale la pena comparar: