Backup automático en Linux con cron y rsync: rutina diaria local + offsite

Backup automatizado en servidor Linux no es un lujo — es la única cosa entre tú y una mala noche cuando el disco falla, el filesystem se corrompe o alguien ejecuta rm -rf en el directorio equivocado. A pesar de eso, muchos sysadmins aún postergan esa decisión para “después” y descubren a la hora del incidente que el último snapshot es de hace seis meses.

Este tutorial monta una rutina diaria de backup local con rsync (usando snapshots por hardlink para ahorrar espacio) y replicación offsite por SSH, agendada con cron. Todo en un script idempotente, con log estructurado y retención configurable. Foco en servidor Linux genérico (Debian/Ubuntu/Rocky/Alma) ejecutándose como VPS — sin dependencias exóticas, sin agente propietario.

Tiempo estimado de ejecución: 30-40 minutos para configurar la primera vez, después se ejecuta solo. La restauración de un archivo individual tarda segundos; la restauración completa depende del volumen de datos.

Requisitos previos

Verifica las versiones antes de continuar:

rsync --version | head -n 1
systemctl status cron      # debian/ubuntu
systemctl status crond     # rhel/rocky/alma

Si rsync no está instalado: sudo apt install rsync (Debian/Ubuntu) o sudo dnf install rsync (Rocky/Alma).

Estructura de directorios y estrategia

Antes de escribir el script, define el layout. La receta usa tres niveles:

• /backup/local/daily/YYYY-MM-DD/ — snapshots diarios (mantenidos 7 días)
• /backup/local/weekly/YYYY-WW/ — snapshots semanales (mantenidos 4 semanas)
• /backup/local/monthly/YYYY-MM/ — snapshots mensuales (mantenidos 6 meses)

Cada snapshot diario es una copia completa aparente, pero rsync --link-dest reaprovecha los archivos no modificados como hardlinks del día anterior. Resultado: 30 días de backup ocupan poco más que 1 copia completa + deltas de cambios.

La replicación offsite copia solo el snapshot más reciente (current) a un servidor remoto, creando allí la misma estructura de historial si así se desea (o solo sobrescribiendo la copia más nueva).

Script de backup local

Esta sección arma el script principal que cron va a disparar todos los días. Hace snapshot incremental con hardlinks, rota la retención y genera log.

sudo mkdir -p /backup/local/{daily,weekly,monthly}
sudo mkdir -p /var/log/backup
sudo chown -R root:root /backup /var/log/backup
sudo chmod 700 /backup

#!/bin/bash
set -euo pipefail

# Configuración
SOURCE_DIRS="/etc /home /var/www /var/lib/mysql-dumps"
BACKUP_ROOT="/backup/local"
LOG_FILE="/var/log/backup/backup-$(date +%Y-%m).log"
RETENTION_DAILY=7
RETENTION_WEEKLY=4
RETENTION_MONTHLY=6

TODAY=$(date +%Y-%m-%d)
DEST="$BACKUP_ROOT/daily/$TODAY"
LATEST_LINK="$BACKUP_ROOT/daily/current"

# Función de log con timestamp
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" >> "$LOG_FILE"
}

log "===== Inicio del backup $TODAY ====="

# Detecta snapshot anterior para --link-dest
LINK_DEST_ARG=""
if [ -d "$LATEST_LINK" ]; then
    LINK_DEST_ARG="--link-dest=$(readlink -f "$LATEST_LINK")"
    log "Usando link-dest: $LINK_DEST_ARG"
fi

mkdir -p "$DEST"

# Sync con rsync
rsync -aHAX --delete \
    --numeric-ids \
    $LINK_DEST_ARG \
    $SOURCE_DIRS \
    "$DEST/" >> "$LOG_FILE" 2>&1

# Actualiza symlink 'current'
ln -snf "$DEST" "$LATEST_LINK"

log "Backup local completado. Tamaño del snapshot:"
du -sh "$DEST" >> "$LOG_FILE" 2>&1

# Retención: elimina snapshots diarios antiguos
find "$BACKUP_ROOT/daily" -maxdepth 1 -type d -name "20*" -mtime +$RETENTION_DAILY -exec rm -rf {} \;
log "Retención diaria aplicada (manteniendo $RETENTION_DAILY días)"

log "===== Fin del backup $TODAY ====="

sudo chmod 700 /usr/local/sbin/backup-daily.sh

sudo /usr/local/sbin/backup-daily.sh

tail -n 50 /var/log/backup/backup-$(date +%Y-%m).log

ls -lah /backup/local/daily/
du -sh /backup/local/daily/current/

Replicación offsite por SSH

El backup local protege contra fallos de aplicación o error humano. No protege contra la pérdida total del servidor (incendio, hipervisor corrompido, acceso comprometido). Para eso, replica a otro servidor — idealmente en una región diferente.

sudo ssh-keygen -t ed25519 -f /root/.ssh/backup_key -N "" -C "backup@$(hostname)"
sudo chmod 600 /root/.ssh/backup_key

# En el destino:
sudo useradd -m -s /bin/bash backup-receiver
sudo mkdir -p /home/backup-receiver/.ssh /backup/remote
sudo chown -R backup-receiver: /home/backup-receiver /backup/remote

command="rsync --server -logDtprRe.iLsfxC --delete . /backup/remote/",no-pty,no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAA... backup@servidor-origen

#!/bin/bash
set -euo pipefail

REMOTE_USER="backup-receiver"
REMOTE_HOST="backup.ejemplo.com"
LOCAL_CURRENT="/backup/local/daily/current/"
LOG_FILE="/var/log/backup/offsite-$(date +%Y-%m).log"
SSH_KEY="/root/.ssh/backup_key"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" >> "$LOG_FILE"
}

log "===== Inicio replicación offsite ====="

rsync -aHAX --delete \
    --numeric-ids \
    -e "ssh -i $SSH_KEY -o StrictHostKeyChecking=accept-new" \
    "$LOCAL_CURRENT" \
    "$REMOTE_USER@$REMOTE_HOST:/backup/remote/" >> "$LOG_FILE" 2>&1

log "===== Fin replicación offsite ====="

sudo chmod 700 /usr/local/sbin/backup-offsite.sh
sudo /usr/local/sbin/backup-offsite.sh

Agendamiento con cron

Con los scripts validados, programa la ejecución automática diaria.

sudo crontab -e

# Garantiza PATH consistente — cron usa PATH mínimo por defecto
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
[email protected]

# Backup local todos los días a las 03:00
0 3 * * * /usr/local/sbin/backup-daily.sh

# Replicación offsite todos los días a las 04:30 (después del local)
30 4 * * * /usr/local/sbin/backup-offsite.sh

Verificación

Después de 24-48 horas, confirma que todo está ejecutándose:

# Snapshots diarios acumulando
ls -lah /backup/local/daily/

# Log de la última ejecución
tail -n 30 /var/log/backup/backup-$(date +%Y-%m).log

# Log del offsite
tail -n 30 /var/log/backup/offsite-$(date +%Y-%m).log

# En el servidor de destino
ls -lah /backup/remote/

Debes ver directorios fechados (2026-05-28, 2026-05-29, etc.), con du -sh mostrando un tamaño aparente igual al dataset pero un espacio real consumido bastante menor gracias a los hardlinks. Confirma con:

du -sh /backup/local/daily/2026-05-29        # tamaño aparente
du -sh --total /backup/local/daily/          # tamaño real total

La diferencia entre los dos números es la ganancia de los hardlinks.

Resolución de problemas

El script funciona manualmente pero falla en cron

Casi siempre es el PATH. Cron se ejecuta con PATH=/usr/bin:/bin por defecto. Solución: o usar rutas absolutas en el script (/usr/bin/rsync, /usr/bin/ssh), o definir PATH= al inicio del crontab como se mostró antes. Verifica también si MAILTO está configurado para recibir stderr — sin eso, los fallos se vuelven silencio absoluto.

rsync retorna código 23 o 24

El código 23 indica “algunos archivos no fueron transferidos” (generalmente archivos abiertos o con permiso restringido); el 24 indica “algunos archivos desaparecieron durante la transferencia” (típico en /var/log o /tmp). Estos códigos no son necesariamente error fatal — ajusta el set -e del script para tolerarlos con rsync ... || [ $? -eq 23 ] || [ $? -eq 24 ] si son esperados en tu escenario.

Permission denied en el destino offsite

La directiva command= en authorized_keys es literal — cualquier cambio en los flags del rsync local la rompe. Solución: ejecuta backup-offsite.sh manual con -e "ssh -v" en el rsync, captura la línea exacta rsync --server ... que envía, y actualiza el command= en el destino con esa cadena.

El espacio en disco crece descontroladamente

Probablemente --link-dest no está tomando el snapshot anterior — algún cambio rompió el symlink current o los snapshots están en filesystems diferentes (los hardlinks no cruzan filesystem). Verifica con stat -c '%i' archivo en dos fechas: si el inode es el mismo, hardlink activo; si es diferente, está duplicando.

Próximos pasos

Esta rutina cubre el básico de producción. Para evolucionar:

• Agrega promoción automática semanal/mensual: copia (no hardlink) del snapshot diario a weekly/ todos los lunes y a monthly/ el primer día del mes.
• Integra alerta activa: si el último log tiene más de 25 horas, dispara una notificación (Discord, e-mail, Healthchecks.io). Backup silenciosamente detenido es el peor escenario.
• Prueba restauración mensual automatizada: restaura un archivo aleatorio del backup más antiguo, compara checksum con producción, registra el resultado.
• Evalúa cifrado en tránsito y en reposo para el destino offsite (ya en tránsito vía SSH; en reposo considera LUKS en el volumen del destino).
• Si estás ejecutando esto en producción, una VPS Hostini (/vps) tiene volúmenes NVMe rápidos para acomodar el historial de snapshots y además libera ancho de banda generoso para la replicación offsite — el backup deja de ser factor limitante en la elección del plan.