Un backup que no has probado restaurar no existe. Esa es la premisa de todo lo que sigue, y no es retórica: hay empresas que perdieron datos creyendo tener backups perfectos porque nadie verificó que se podían recuperar. Antes de hablar de herramientas, necesitamos hablar de estrategia, porque elegir rsync o borg sin tener claro qué proteges y cómo lo recuperas es poner el carro delante de los bueyes.
Estrategia primero
La regla 3-2-1 es el estándar mínimo aceptable en cualquier entorno serio: tres copias de los datos, en dos medios físicos distintos, con una copia fuera del sitio principal. El razonamiento es simple: si tienes dos copias en el mismo disco (o en el mismo servidor), un fallo de hardware las elimina ambas. Si tienes dos discos en el mismo armario, un incendio o robo se lleva todo. La copia offsite rompe esa dependencia. En la práctica, para una máquina Linux de producción esto se traduce en: disco local + disco externo o segundo servidor en la misma red + almacenamiento cloud (S3, Backblaze B2, un servidor remoto vía SFTP, lo que sea).
Sobre los tipos de backup: un backup full copia absolutamente todo cada vez —simple pero costoso en espacio y tiempo—. Un backup incremental copia solo lo que cambió desde el último backup, sea full o incremental anterior; ocupa poco pero para restaurar necesitas toda la cadena desde el último full. Un backup diferencial copia solo lo que cambió desde el último full; crece con el tiempo pero restaurar es más sencillo: solo necesitas el último full y el último diferencial. Herramientas modernas como Borg o Restic hacen esto transparente mediante deduplicación: guardan bloques únicos de datos y solo almacenan nuevas versiones de los bloques que cambiaron, comportándose efectivamente como incrementales con restauración directa a cualquier punto.
Cuándo usar qué: rsync es perfecto para sincronización de directorios y backups simples donde el destino sea un espejo del origen. tar con fecha es útil para snapshots comprimidos puntuales. Borg Backup es la elección para backups frecuentes y automatizados con deduplicación, compresión y cifrado integrados. Restic cubre el mismo espacio que Borg pero con soporte nativo para múltiples backends de almacenamiento (S3, B2, SFTP, local), lo que lo hace preferible cuando el destino es cloud.
Lo que se rompe si lo haces mal: almacenar el backup en el mismo disco que los datos originales (inútil ante fallo de disco), no cifrar backups que van a cloud (expones datos a terceros), nunca verificar la integridad (el backup puede estar corrupto durante meses sin que lo sepas), y no probar la restauración (descubres que falta algo solo cuando lo necesitas).
#!/bin/bash
# /usr/local/bin/backup-diario.sh
# Estrategia 3-2-1: local con rsync + snapshot tar + borg hacia remoto
set -euo pipefail
ORIGEN="/var/www /etc /home/deploy"
DESTINO_LOCAL="/mnt/backup-local"
BORG_REPO="usuario@backup-offsite.ejemplo.com:/backups/borg/servidor1"
BORG_PASSPHRASE="clave-muy-larga-y-aleatoria-aqui"
LOG="/var/log/backup-diario.log"
FECHA=$(date +%Y%m%d-%H%M)
exec >> "$LOG" 2>&1
echo "=== Backup iniciado: $FECHA ==="
# --- COPIA 1: rsync local (espejo rápido, copia 1 de 3) ---
# --delete elimina en destino lo que ya no existe en origen
# --one-file-system evita cruzar montajes accidentalmente
for dir in $ORIGEN; do
rsync -av --delete --one-file-system \
"$dir" "$DESTINO_LOCAL/espejo/"
done
# --- COPIA 2: snapshot tar comprimido con fecha (copia 2 de 3, local) ---
# Útil para recuperar versiones anteriores de ficheros borrados
tar czf "$DESTINO_LOCAL/snapshots/snapshot-${FECHA}.tar.gz" \
--warning=no-file-changed \
$ORIGEN
# Conservar solo los últimos 7 snapshots tar para no llenar disco
find "$DESTINO_LOCAL/snapshots/" -name "snapshot-*.tar.gz" \
-mtime +7 -delete
# --- COPIA 3: Borg hacia servidor remoto (offsite, copia 3 de 3) ---
export BORG_PASSPHRASE
# Inicializar repositorio si no existe aún
# El cifrado repokey guarda la clave en el repositorio, protegida por passphrase
if ! borg info "$BORG_REPO" &>/dev/null; then
borg init --encryption=repokey "$BORG_REPO"
echo "Repositorio Borg inicializado."
fi
# Crear nuevo archivo con nombre basado en fecha
# --compression lz4 es rápida; usa zstd,3 si priorizas ratio sobre velocidad
borg create \
--compression lz4 \
--stats \
"${BORG_REPO}::servidor1-${FECHA}" \
$ORIGEN
# Política de retención: diarios 7 días, semanales 4, mensuales 6
borg prune \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 6 \
"$BORG_REPO"
# --- VERIFICACIÓN DE INTEGRIDAD (ejecutar con menos frecuencia, es costoso) ---
# Descomenta para verificación semanal; en cron puedes condicionarlo al día
# if [ "$(date +%u)" = "7" ]; then
# borg check "$BORG_REPO"
# echo "Verificación de integridad completada."
# fi
echo "=== Backup completado: $(date +%Y%m%d-%H%M) ==="
# Recordatorio activo: la restauración se prueba cada primer domingo de mes
# Ver: /usr/local/bin/test-restauracion.sh
# Para instalar Borg en Debian Bookworm: apt install borgbackup # Automatizar con systemd timer o cron: # Añadir en crontab del root: # 0 2 * * * /usr/local/bin/backup-diario.sh
Desglose de las decisiones clave
El script usa set -euo pipefail al principio: e aborta si cualquier comando falla, u trata variables no definidas como error, y pipefail hace que un fallo en cualquier parte de un pipe corte la ejecución. Sin esto, un backup puede “completarse” silenciosamente con errores.
La primera capa con rsync -av --delete --one-file-system es el espejo rápido. El flag --delete es lo que lo convierte en un espejo real: si borras un fichero en origen, desaparece del destino en la siguiente ejecución. Sin él, el destino acumula basura indefinidamente. El flag --one-file-system evita que rsync cruce puntos de montaje accidentalmente —importante si /home o /var están en particiones separadas y no quieres incluirlos dos veces.
La segunda capa con tar czf genera snapshots con fecha en el nombre. La opción --warning=no-file-changed suprime el aviso que tar emite cuando un fichero cambia mientras lo está leyendo —normal con ficheros de log activos—. El find -mtime +7 -delete de limpieza es crucial: sin rotación, el disco se llena en días.
La tercera capa es donde está la protección real contra desastres. Borg trabaja con repositorios: un directorio estructurado donde guarda los bloques deduplicados. Cada llamada a borg create crea un archivo (snapshot) dentro del repositorio. La deduplicación opera entre todos los archivos del repositorio: si /etc/nginx/nginx.conf no cambió desde ayer, Borg no lo almacena de nuevo, simplemente referencia los mismos bloques. El resultado es que puedes tener 30 puntos de restauración diarios ocupando poco más que el espacio de un solo full.
La opción --encryption=repokey almacena la clave de cifrado dentro del repositorio, protegida por la passphrase. La alternativa keyfile guarda la clave localmente en ~/.config/borg/keys/; más segura si el servidor remoto está comprometido, pero necesitas hacer también backup de esa clave. Con repokey, si tienes la passphrase, puedes acceder desde cualquier máquina.
borg prune con las políticas de retención es lo que impide que el repositorio crezca indefinidamente. Las políticas --keep-daily 7 --keep-weekly 4 --keep-monthly 6 son conservadoras pero razonables: cubre errores que descubres tarde (corrupción silenciosa de datos, borrado accidental descubierto semanas después).
Lo que no está en el script pero es igual de importante: el fichero test-restauracion.sh mencionado en el comentario final. Restaurar un fichero concreto con Borg es borg extract "${BORG_REPO}::nombre-del-archivo" var/www/html/index.php —sin la barra inicial, porque las rutas en el archivo son relativas—. Si nunca ejecutas eso en un entorno de prueba, no sabes si tu backup funciona.
[Ubuntu]: Ubuntu incluye borgbackup en sus repositorios también. En servidores Ubuntu con netplan y cloud-init, ten en cuenta excluir /run y los directorios de cloud-init si usas rutas amplias como /etc completo.
N° 99