Cómo hacer respaldos automáticos de tu sitio en la nube

Hacer un backup en un servidor nube consiste en copiar automáticamente los archivos de tu sitio y el volcado de tu base de datos a una ubicación segura fuera del servidor principal, de forma programada y sin intervención manual. Con un cron job, rsync y mysqldump puedes lograrlo en menos de 30 minutos de configuración.

Esta guía te muestra exactamente cómo hacerlo, qué estrategia de retención usar y cómo verificar que tus respaldos realmente funcionan cuando los necesitas.

Por qué los respaldos en la nube no son opcionales

Muchos usuarios asumen que su proveedor cloud ya respalda todo. La realidad es más matizada:

• Los snapshots del proveedor suelen costarse por hora o volumen almacenado, y no siempre incluyen el plan básico.
• Un snapshot respaldado automáticamente hoy podría incluir archivos corruptos o infectados con malware.
• Si borras un archivo por error, depender solo del proveedor puede dejarte con una ventana de recuperación de 24 h o más.
• Tener tus propios respaldos te da control total sobre frecuencia, retención y destino.

La regla de oro es la estrategia 3-2-1: 3 copias de los datos, en 2 medios distintos, con 1 copia fuera del sitio (offsite).

Qué necesitas respaldar

Un sitio web en servidor cloud tiene dos componentes críticos que deben respaldarse por separado:

Respaldar solo los archivos sin la base de datos — o viceversa — te deja con un respaldo inútil al momento de restaurar.

Paso 1 — Crear el script de respaldo

Crea el archivo /home/tu_usuario/scripts/backup.sh con el siguiente contenido y ajusta las variables al inicio:

#!/bin/bash
# --- Configura estas variables ---
SITE_DIR="/var/www/html/mi-sitio"
DB_NAME="mi_base_de_datos"
DB_USER="usuario_db"
DB_PASS="contraseña_db"
BACKUP_DIR="/home/tu_usuario/backups"
RETAIN_DAYS=14
# ----------------------------------

DATE=$(date +%Y-%m-%d_%H-%M)
mkdir -p "$BACKUP_DIR"

# Respaldo de archivos
tar -czf "$BACKUP_DIR/files_$DATE.tar.gz" -C "$SITE_DIR" .

# Respaldo de base de datos
mysqldump -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" \
  | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

# Limpieza de respaldos viejos
find "$BACKUP_DIR" -type f -mtime +$RETAIN_DAYS -delete

echo "Backup completado: $DATE"

Después de guardarlo, dale permisos de ejecución:

chmod +x /home/tu_usuario/scripts/backup.sh

Dónde guardar la contraseña de forma segura

Nunca incluyas credenciales en texto plano dentro de scripts que puedas versionar accidentalmente. Usa un archivo ~/.my.cnf con permisos 600:

[client]
user=usuario_db
password=contraseña_db

Y luego en el script reemplaza la línea de mysqldump por:

mysqldump --defaults-file=~/.my.cnf "$DB_NAME" | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

Paso 2 — Programar el cron job

Abre el editor de cron con crontab -e y añade la siguiente línea para ejecutar el respaldo todos los días a las 2:00 a.m.:

0 2 * * * /home/tu_usuario/scripts/backup.sh >> /home/tu_usuario/logs/backup.log 2>&1

Guarda el archivo. Puedes verificar que el cron quedó registrado con crontab -l.

Frecuencias recomendadas según el tipo de sitio

• Blog o sitio corporativo estático: diario es suficiente.
• Tienda en línea o SaaS: cada 6-12 horas para no perder pedidos o datos de usuarios.
• Sitio de alto tráfico con datos críticos: considera replicación en tiempo real + snapshots diarios.

Paso 3 — Copiar los respaldos fuera del servidor (offsite)

Un respaldo en el mismo servidor que el sitio no te protege de un fallo del disco, un hack que borre todo, o la eliminación accidental del droplet. Copia los respaldos a un destino externo.

Opciones comunes:

• Object Storage del proveedor (DigitalOcean Spaces, Hetzner Object Storage, Linode Object Storage) — económico y rápido de integrar con la CLI de s3cmd o rclone.
• Backblaze B2 — muy bajo costo (≈ $6 USD/TB/mes) con API compatible con S3.
• Otro servidor en distinta región — usa rsync vía SSH hacia un VPS secundario.

Ejemplo de subida a Backblaze B2 con rclone (configurado previamente con rclone config):

rclone copy /home/tu_usuario/backups b2:mi-bucket-backups --transfers=4

Añade esta línea al mismo script de backup, después de la limpieza de archivos viejos.

Si quieres apoyo especializado para montar una estrategia de respaldos offsite a medida, el equipo de elenlace.com puede diseñar e implementar la solución que se adapte a tu infraestructura.

Paso 4 — Verificar que el respaldo funciona

Un respaldo que nunca has probado es como no tener respaldo. Verifica tu configuración con estos pasos:

1. Ejecuta el script manualmente: bash /home/tu_usuario/scripts/backup.sh y revisa que se creen los archivos .tar.gz y .sql.gz en el directorio de destino.
2. Comprueba el log de cron: al día siguiente de activarlo, revisa /home/tu_usuario/logs/backup.log para confirmar que corrió sin errores.
3. Haz una restauración de prueba: descomprime el tar en un directorio temporal e importa el SQL en una base de datos de prueba. Si el sitio funciona con esos archivos, el respaldo es válido.

Haz esta verificación al menos una vez al mes. Las sorpresas en un respaldo solo aparecen cuando más las necesitas.

Para más guías sobre gestión de servidores cloud, visita nuestra sección de cloud hosting en el blog.

Conclusiones clave

• Respalda siempre los dos componentes: archivos del sitio y base de datos por separado.
• Un script de bash + cron job diario es suficiente para la mayoría de los sitios.
• Guarda contraseñas en ~/.my.cnf (modo 600), no en el script directamente.
• Copia los respaldos fuera del servidor (object storage, Backblaze B2 o VPS secundario).
• Prueba la restauración al menos una vez al mes para asegurarte de que el respaldo es válido.

¿Tu sitio todavía no tiene una estrategia de respaldos sólida? Contacta al equipo de elenlace.com y te ayudamos a implementar un sistema automatizado y probado desde el primer día.

Preguntas frecuentes

¿Mi proveedor cloud ya hace respaldos automáticos?

Depende del plan. Muchos proveedores ofrecen snapshots opcionales con costo adicional, pero no siempre están habilitados por defecto. Revisa tu panel y nunca asumas que existe un respaldo hasta verificarlo. Tener tus propios respaldos es siempre la práctica más segura.

¿Cuánto espacio ocupan los respaldos?

Un volcado comprimido de base de datos con mysqldump + gzip suele ser el 10-20 % del tamaño original de la BD. Los archivos del sitio comprimidos con tar+gzip dependen del volumen de imágenes. Para un sitio típico de 500 MB, un respaldo diario ocupa entre 50 y 200 MB.

¿Con qué frecuencia debo hacer respaldos?

Para un blog o sitio corporativo, un respaldo diario es suficiente. Para tiendas en línea o aplicaciones con transacciones frecuentes, considera respaldos cada 6-12 horas para minimizar la pérdida de datos ante un incidente.

¿Cómo restauro mi sitio desde un respaldo?

Descomprime el .tar.gz en el directorio raíz del sitio (tar -xzf files_FECHA.tar.gz -C /var/www/html/mi-sitio) e importa el SQL con mysql -u usuario -p base_de_datos < dump.sql tras descomprimirlo. Si tienes dudas, haz siempre la prueba en un entorno de staging primero.

Para saber más

Otros proveedores y guías que vale la pena comparar:

• HostGator México
• Hostinger
• HubSpot