Backups automáticos en Linux con rsync y cron (2026)

¿Por qué Rsync y Cron son una combinación tan efectiva?

• Rsync es una herramienta flexible y eficiente para sincronizar archivos y directorios, tanto localmente como a través de una red. Su gran ventaja es que solo transfiere los cambios (delta) entre el origen y el destino, en lugar de copiar todo desde cero cada vez.
• Cron es el programador de tareas nativo de Linux, encargado de ejecutar comandos automáticamente en los horarios que definas, sin que nadie tenga que iniciar el proceso manualmente.

Qué necesitas antes de empezar

• Acceso a un servidor Linux con permisos de sudo.
• Un destino para los backups: puede ser un disco externo, otro servidor remoto, o un servicio de almacenamiento en la nube.
• Tiempo para probar la configuración con simulaciones antes de confiar en ella al 100% en producción.

Instalación de Rsync

En distribuciones basadas en Debian/Ubuntu:

sudo apt update
sudo apt install rsync -y

En distribuciones basadas en Red Hat (AlmaLinux, Rocky Linux, RHEL):

sudo dnf install rsync -y

Si sigues alguna guía antigua que use yum, ten en cuenta que CentOS Linux 7 dejó de recibir soporte el 30 de junio de 2024: en las distribuciones actuales de esa familia el gestor de paquetes es dnf, y yum solo sobrevive como alias.

Verifica la instalación:

rsync --version

Comando básico de Rsync

La sintaxis general es:

rsync [opciones] origen destino

Un ejemplo típico para respaldar la carpeta de un sitio web:

rsync -avz /var/www /backup

• -a: modo archivo, preserva permisos, enlaces simbólicos y la estructura completa de directorios.
• -v: modo detallado (verbose), muestra el progreso durante la transferencia.
• -z: comprime los datos durante la transferencia para ahorrar ancho de banda, especialmente útil en backups remotos.

Estas son las opciones que más se usan en un respaldo real y lo que hace cada una:

Cuidado con --delete: convierte el respaldo en un espejo, y un espejo replica también los borrados. Si un ransomware cifra tus archivos hoy y el respaldo corre esta noche con --delete, el destino queda igual de cifrado. Por eso la sección de rotación, más abajo, no es opcional.

Backup hacia un servidor remoto

Rsync puede transferir datos directamente a otro servidor por SSH:

rsync -avz /var/www usuario@servidor_remoto:/ruta/del/backup

Si es la primera vez que te conectas a ese servidor, prueba primero el acceso SSH manualmente para confirmar credenciales y aceptar la huella digital del host:

ssh usuario@servidor_remoto

Para automatizar completamente el proceso sin que pida contraseña cada vez, configura autenticación por llaves SSH entre ambos servidores.

Automatizar el backup con Cron

Abre el editor de tareas programadas del usuario actual:

crontab -e

Y agrega una línea con el horario y el comando deseado. Por ejemplo, para ejecutar el backup todos los días a las 2:00 a.m.:

0 2 * * * rsync -avz /var/www usuario@servidor_remoto:/ruta/del/backup

• **0 2 ***: expresión cron que representa "a las 2:00 a.m., todos los días".
• El resto de la línea es el mismo comando rsync que ya probaste manualmente.

Para confirmar que la tarea quedó registrada correctamente:

crontab -l

Una versión mejor de esa misma línea guarda un registro con fecha, para que puedas comprobar si el respaldo corrió y cuánto tardó:

0 2 * * * rsync -az --delete /var/www usuario@servidor_remoto:/ruta/del/backup >> /var/log/backup.log 2>&1

El 2>&1 es la parte importante: sin él, los mensajes de error no llegan al archivo y un respaldo que falla todas las noches parece exitoso. Revisa ese log al menos una vez al mes, o configura una alerta si el archivo deja de crecer.

Simular el backup antes de ejecutarlo en serio

Rsync incluye un modo de simulación que te muestra exactamente qué archivos se transferirían, sin copiar nada realmente. Es una práctica muy recomendable antes de confiar una tarea crítica a Cron:

rsync -avz --dry-run /var/www usuario@servidor_remoto:/ruta/del/backup

Buenas prácticas para una estrategia de backups sólida

• Respalda todo lo crítico: no olvides bases de datos, archivos de configuración importantes y contenido estático, no solo el código de la aplicación.
• Define la frecuencia según la criticidad del dato: datos críticos (bases de datos transaccionales) idealmente diarios o cada pocas horas; datos menos sensibles, semanales.
• Mantén copias en múltiples ubicaciones: disco local, servidor remoto y almacenamiento en la nube, siguiendo la estrategia 3-2-1 (3 copias, 2 medios distintos, 1 fuera del sitio).
• Cifra los backups sensibles: usa herramientas como GPG para proteger datos confidenciales antes de transferirlos o almacenarlos.
• Monitorea el proceso: configura alertas o revisa logs periódicamente para confirmar que los backups se están ejecutando correctamente y no fallando en silencio.

Rotación de backups: conservar versiones antiguas

Para no perder versiones anteriores cuando un archivo se elimina o modifica en el origen, Rsync permite mover los cambios a un directorio de "backup antiguo" en lugar de descartarlos:

rsync -avz --delete --backup --backup-dir=/backup/old /var/www /backup/current

• --delete: elimina en el destino los archivos que ya no existen en el origen, para mantener ambos directorios sincronizados.
• --backup + --backup-dir: en lugar de simplemente borrar esos archivos del destino, los mueve al directorio indicado, conservando un historial de cambios.

Respaldar una base de datos: el paso que casi todos olvidan

Copiar con rsync los archivos de datos de MySQL o MariaDB mientras el servicio está encendido produce un respaldo inconsistente que puede negarse a restaurar. La secuencia correcta es volcar primero la base a un archivo y dejar que rsync copie ese archivo:

# 1. Volcar todas las bases a un archivo comprimido con fecha
mysqldump --single-transaction --all-databases | gzip > /respaldos/db-$(date +%F).sql.gz

# 2. Sincronizar la carpeta de respaldos al servidor remoto
rsync -az /respaldos/ usuario@servidor_remoto:/ruta/del/backup/db/

La opción --single-transaction genera el volcado sin bloquear las tablas InnoDB, de modo que el sitio sigue funcionando mientras se respalda. Para el usuario que ejecuta esto en cron, guarda las credenciales en un archivo ~/.my.cnf con permisos 600 en lugar de escribir la contraseña en la línea de comandos, donde queda visible para cualquiera que liste los procesos.

Cómo probar que el respaldo sirve

Un respaldo que nunca se restauró no es un respaldo: es una suposición. La prueba mínima toma cinco minutos y consiste en restaurar en otro lado y verificar:

# Traer un archivo cualquiera del respaldo a una carpeta temporal
rsync -av usuario@servidor_remoto:/ruta/del/backup/index.php /tmp/prueba/

# Comparar el respaldo completo contra el origen sin copiar nada
rsync -avn --delete /var/www/ usuario@servidor_remoto:/ruta/del/backup/

El segundo comando, con -n (simulación), lista las diferencias entre origen y destino. Si la salida está vacía, ambos están sincronizados. Anota además cuánto tardas en restaurar todo el sitio: ese número, y no el tamaño del respaldo, es lo que de verdad importa el día del incidente.

Casos de uso prácticos

• E-commerce: garantiza que nunca pierdas datos de clientes, pedidos o inventario ante una falla inesperada.
• Medios y noticias: mantiene respaldos frecuentes de imágenes, videos y artículos publicados.
• Desarrollo de software: copias regulares de código fuente y archivos de configuración como capa adicional a tu control de versiones.