Backup offsite con rclone hacia S3 o Backblaze B2 en Linux

Configura backup offsite cifrado en Linux usando rclone con Backblaze B2 o Amazon S3. Incluye programación vía cron, restore y verificación de integridad.

Un servidor Linux con datos importantes necesita backup offsite — en una ubicación físicamente separada de la infraestructura primaria, idealmente en otro proveedor para sobrevivir a incidentes regionales o al compromiso de la cuenta. El rclone resuelve esto con cifrado extremo a extremo opcional, deduplicación por checksum y soporte nativo para S3, Backblaze B2 y más de 40 backends de almacenamiento.

Este tutorial muestra cómo configurar rclone en una VPS Linux (Ubuntu 22.04/24.04 o Debian 12) para copiar directorios hacia Backblaze B2 o Amazon S3, cifrados con una clave que ni el proveedor de almacenamiento puede leer. Cubrimos la instalación, creación de los remotes, capa crypt, programación vía cron, verificación de integridad y procedimiento de restore.

Tiempo estimado: 30-40 minutos para la primera configuración, incluyendo la creación de la cuenta en el proveedor de almacenamiento. El backup inicial varía según el volumen de datos y el ancho de banda.

Prerrequisitos

Lo que necesitas antes de empezar

VPS Linux con acceso sudo, conexión saliente libre en el puerto 443 (HTTPS), al menos 100 MB libres en /usr/bin para el binario y la caché de rclone, y una cuenta activa en Backblaze B2 o AWS S3. Los comandos a continuación asumen Ubuntu 22.04+ o Debian 12, pero funcionan en cualquier distribución adaptando el gestor de paquetes.

Distribución probada Ubuntu 22.04 / 24.04
Versión mínima rclone 1.65+
Backends cubiertos S3, B2
Almacenamiento libre ~100 MB

Ten a mano las credenciales del proveedor elegido antes de empezar:

  • Backblaze B2: Application Key ID + Application Key (creados en “App Keys” en el panel B2, con permisos sobre el bucket objetivo)
  • Amazon S3: Access Key ID + Secret Access Key (usuario IAM con policy que permita s3:PutObject, s3:GetObject, s3:DeleteObject y s3:ListBucket en el bucket)

Instalando rclone

El rclone se distribuye como un binario único — instalar vía paquete de la distribución suele traer una versión antigua (1.53 en Ubuntu 22.04, por ejemplo) que tiene bugs conocidos en el backend B2. Usa el instalador oficial para obtener la release actual.

01

Descarga y ejecuta el instalador oficial:

curl https://rclone.org/install.sh | sudo bash

El script detecta la arquitectura (amd64, arm64), descarga el binario desde GitHub, instala en /usr/bin/rclone y genera la página de manual. La salida final imprime la versión instalada — confirma que está por encima de 1.65.

02

Verifica la instalación:

rclone version

La salida esperada empieza con rclone v1.6x.x seguido por las líneas de OS, arch y Go version. Si aparece “command not found”, /usr/bin no está en el PATH del shell actual — abre una nueva sesión o ejecuta hash -r.

Configurando el remote en Backblaze B2

B2 es la opción estándar para quien empieza: el almacenamiento cuesta cerca de USD 6 por TB/mes y el egress es gratuito hasta 3x el volumen almacenado por mes (suficiente para restores ocasionales sin costo extra).

03

Crea la Application Key en el panel B2 con acceso al bucket que recibirá los backups. Guarda el keyID y la applicationKey — B2 solo muestra la applicationKey una vez. Crea también el bucket de destino (privado, sin cifrado server-side — vamos a cifrar del lado cliente).

04

Inicia el configurador interactivo de rclone:

rclone config

Selecciona n (new remote), nómbralo como b2-raw, elige el tipo 5 (Backblaze B2). Pega el keyID en “account” y la applicationKey en “key”. Confirma con y cuando pregunte si quieres aceptar los defaults restantes.

05

Prueba la conexión listando los buckets:

rclone lsd b2-raw:

La salida debe mostrar los buckets de la cuenta, uno por línea, con fecha de creación. Un error 401 unauthorized significa que el keyID/applicationKey son incorrectos o la Application Key fue revocada en el panel.

Configurando el remote en Amazon S3 (alternativa)

Si prefieres S3, el procedimiento es equivalente — el crypt configurado más adelante funciona idéntico sobre cualquier backend.

06

Ejecuta rclone config, elige n, nómbralo como s3-raw, tipo 4 (Amazon S3). En “provider” selecciona AWS. En “env_auth” deja false para pegar credenciales manualmente. Pega access_key_id y secret_access_key. En “region” elige la region del bucket (ej: us-east-1, sa-east-1). En “storage_class” deja vacío para Standard o elige STANDARD_IA para acceso infrecuente (más barato para backup raramente leído).

La storage class importa mucho para el costo

Para un backup que restauras raramente, STANDARD_IA cuesta la mitad de Standard pero cobra retrieval. Para un backup que nunca se lee salvo en desastre, GLACIER_DEEP_ARCHIVE cuesta una décima parte pero tarda 12-48h en restaurar. No uses Glacier para backup diario rotativo — la tarifa de early deletion (180 días) anula el ahorro.

Añadiendo la capa crypt

Esta es la parte crítica: el crypt cifra nombres de archivo y contenido con NaCl Secretbox (XSalsa20+Poly1305) antes de enviar al backend remoto. Sin la contraseña del crypt, el proveedor de almacenamiento ve solo bloques opacos.

07

En rclone config, crea otro remote con n, nómbralo como b2-crypt (o s3-crypt), tipo 13 (crypt). En “remote” escribe b2-raw:nombre-del-bucket/backups (sustituye por tu bucket y ruta). En “filename_encryption” elige 1 (standard — oculta nombres). En “directory_name_encryption” elige true.

08

Cuando pregunte por la contraseña, elige g (generate random) — genera una contraseña fuerte de 1024 bits. Copia y guarda la contraseña generada en un gestor de contraseñas antes de continuar. Sin esa contraseña, el backup es irrecuperable incluso con acceso al bucket.

Perdiste la contraseña, perdiste el backup

El crypt es simétrico — no hay recuperación. Antes de mover datos a producción, haz un test de restore en un servidor limpio usando solo la contraseña guardada. Guarda la contraseña en al menos dos lugares físicos distintos (gestor de contraseñas personal + cofre de la empresa).

09

Para la “password2” (salt), también usa g para generar aleatorio. Guárdala junto con la contraseña principal. Confirma con y en el resumen, después q para salir del configurador.

Ejecutando el primer backup

Con los remotes configurados, el backup es una llamada rclone copy. A diferencia de sync, copy solo añade o actualiza archivos — nunca borra en el destino.

10

Ejecuta el backup inicial de /var/www y /etc:

rclone copy /var/www b2-crypt:var-www \
  --progress \
  --transfers 4 \
  --checkers 8 \
  --bwlimit 50M

El flag --progress muestra ETA y throughput en tiempo real. --transfers 4 define cuántos archivos suben en paralelo. --bwlimit 50M limita a 50 MB/s para no saturar la red del servidor (ajusta según tu ancho de banda).

El primer backup puede tardar horas

En un enlace de 100 Mbit/s, transferir 100 GB toma cerca de 2h30 sin overhead. Usa tmux o screen para no perder el progreso si la sesión SSH se cae. O ejecuta con nohup ... & redirigiendo la salida a un archivo.

Programando backups diarios vía cron

Después del backup inicial, programa ejecuciones incrementales — rclone solo transfiere archivos nuevos o modificados (verifica modtime + size, o checksum con --checksum).

11

Crea un script wrapper en /usr/local/bin/backup-offsite.sh:

sudo tee /usr/local/bin/backup-offsite.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail

LOG=/var/log/rclone-backup.log
exec >> "$LOG" 2>&1

echo "=== Backup iniciado en $(date -Iseconds) ==="

rclone copy /var/www b2-crypt:var-www \
  --transfers 4 \
  --checkers 8 \
  --bwlimit 50M \
  --log-level INFO

rclone copy /etc b2-crypt:etc \
  --transfers 2 \
  --log-level INFO

echo "=== Backup finalizado en $(date -Iseconds) ==="
EOF

sudo chmod +x /usr/local/bin/backup-offsite.sh

El set -euo pipefail hace que el script aborte ante cualquier error. El exec >> redirige stdout y stderr al log de una sola vez.

12

Añade una entrada en el crontab de root para ejecutar todos los días a las 3 de la mañana:

sudo crontab -e

Añade la línea:

0 3 * * * /usr/local/bin/backup-offsite.sh

Guarda y sal. El cron lee el crontab automáticamente — no hace falta reiniciar el servicio.

Verificando integridad

El rclone check compara checksums entre origen y destino. Para el crypt, descifra los hashes del remoto y los compara con el local — cualquier corrupción en tránsito o en el storage aparece.

13

Ejecuta la verificación:

rclone check /var/www b2-crypt:var-www --one-way

El flag --one-way solo verifica que todo archivo local exista en el remoto — útil porque el crypt puede añadir metadatos que confunden checks bidireccionales. La salida 0 differences found significa que todos los archivos coinciden.

Probando el restore

Un backup no probado no es un backup. Haz un restore parcial en un directorio temporal para confirmar que toda la cadena (cifra → upload → download → descifra) está funcional.

14

Restaura un directorio de prueba:

mkdir -p /tmp/restore-test
rclone copy b2-crypt:var-www/sitio-ejemplo /tmp/restore-test --progress

Tras la descarga, compara algunos archivos con diff o md5sum contra el origen en /var/www/sitio-ejemplo. Si coinciden, la cadena está íntegra. Borra /tmp/restore-test después.

Próximos pasos

El backup offsite resuelve el caso de pérdida del servidor, pero es solo una capa — combínalo con snapshots locales frecuentes (LVM, Btrfs o ZFS) para restore rápido de errores operativos. Sugerencias para evolucionar:

  • Configura Object Lock en S3 o Application Key write-only en B2 para mitigar ransomware
  • Añade monitoreo de los jobs vía webhook (envía el estado del cron a un endpoint de healthcheck)
  • Implementa rotación de versiones con --backup-dir apuntando a carpetas por fecha
  • Documenta la contraseña del crypt en un cofre redundante (gestor personal + cofre de la empresa)

Si estás llevando esto a producción, una VPS Hostini ya viene con ancho de banda generoso y snapshots regulares en el hipervisor — buena base para combinar con la capa offsite descrita aquí.

Preguntas frecuentes

¿Conviene más usar S3 o Backblaze B2 para un backup pequeño?

Para volúmenes inferiores a 1 TB con restore esporádico, Backblaze B2 sale bastante más barato: el almacenamiento cuesta cerca de una cuarta parte de S3 Standard y el egress es gratuito hasta 3x el volumen almacenado por mes. S3 solo compensa si ya tienes el ecosistema AWS, necesitas clases de almacenamiento específicas (Glacier Deep Archive) o integración nativa con otros servicios AWS.

¿El crypt de rclone protege contra ransomware en el servidor de origen?

No directamente. El crypt cifra los datos en tránsito y en el destino, pero si el servidor de origen se ve comprometido el atacante puede ejecutar rclone delete o sync con una carpeta vacía y destruir el backup. Mitigación: usar Object Lock en S3 (modo COMPLIANCE) o Application Keys de B2 restringidas a write-only (sin deleteFiles), además de versionado del bucket.

¿Puedo restaurar un archivo específico sin descargar todo?

Sí. El rclone con crypt mantiene la estructura de directorios (con nombres cifrados, pero navegables). Usa rclone ls remoto-crypt:ruta/ para listar y rclone copy remoto-crypt:ruta/archivo.tar.gz /local/ para descargar solo lo que necesitas. El crypt descifra en stream — no hace falta descargar el backup completo.

¿Por qué rclone sync es más peligroso que copy?

El sync espeja origen en destino — los archivos que desaparecieron del origen se borran del destino. Si el disco del servidor falla y ejecutas sync apuntando a una carpeta vacía, pierdes todo en el remoto. Para backup incremental seguro usa copy (solo añade/actualiza) o sync con --backup-dir apuntando a una carpeta versionada por fecha.

¿Cómo verifico que el backup no está corrupto sin hacer un restore completo?

Usa rclone check origen: destino: para comparar checksums (MD5/SHA1 según el backend) entre archivos locales y remotos. Para un test end-to-end periódico, monta el remoto-crypt con rclone mount y abre algunos archivos al azar — si descifran y se leen sin errores, la cadena está íntegra.

¿rclone consume mucha CPU cifrando antes de subir?

En servidores modernos con AES-NI la sobrecarga es típicamente del 5-15% durante la subida — el cuello de botella suele ser el ancho de banda de red, no el crypt. En VPS de 1 vCPU con upload superior a 100 Mbit/s puede aparecer saturación; en ese caso ajusta --transfers 2 y --checkers 4 para reducir el paralelismo.

Temas:
Próximos pasos Cloud Ryzen con NVMe y protección DDoS siempre activa.Pon en producción en un VPS Hostini →
¿Te resultó útil este tutorial?
Hablar por WhatsApp