Backup 3-2-1: protege tu homelab de desastres (guía real, sin tonterías)

Tabla de contenido

Voy a empezar por el final: perdí datos. No una vez, dos veces.

Primera vez, 2022: un disco del NAS palmó. Pensaba que RAID 1 era backup. No lo es. Perdí 6 meses de fotos familiares porque el segundo disco falló 48 horas después del primero (RAID failure correlacionado, mismo lote de discos).

Segunda vez, 2024: actualización de Proxmox que se fue al carajo. Recreé las VMs desde cero, pero perdí configuraciones de servicios que no había documentado. 3 días de trabajo para volver a tener todo funcionando.

Ahora tengo un sistema de backups que funciona. No es perfecto, pero llevo 14 meses sin perder un solo byte. Te voy a contar exactamente qué hago, con qué herramientas, y cuánto me cuesta (tiempo y dinero).

Qué es el backup 3-2-1 (la regla de oro)
#

La estrategia 3-2-1 dice:

3 copias de tus datos (el original + 2 backups)
2 medios diferentes (disco local + nube, o disco + NAS, etc.)
1 copia fuera de casa (nube, casa de un amigo, oficina)

Esto te protege de:

Fallo de hardware (disco roto, NAS muerto)
Desastres físicos (incendio, inundación, robo)
Ataques de ransomware (si una copia está offline/immutable)
Errores humanos (borrado accidental, rm -rf /)

No es paranoia. Es realismo. Los discos fallan. Todos. Siempre. Solo es cuestión de tiempo.

Mi setup actual de backups
#

Tengo varios niveles, dependiendo de lo crítico que sea el dato.

Nivel 1: datos críticos (fotos, documentos, código)
#

Original: Mac mini M1 (disco interno NVMe)
Backup 1: Synology DS1621+ vía Time Machine (local, cada hora)
Backup 2: Backblaze B2 vía Restic (nube, cada noche a las 02:00)

Nivel 2: configuraciones de servicios (Docker, VMs, scripts)
#

Original: servers varios (Unraid, Proxmox, K3s)
Backup 1: Synology DS1621+ vía scripts cron + rsync
Backup 2: Gitea privado (configs en Git, pusheadas automáticamente)

Nivel 3: media (Plex, películas, series)
#

Original: Synology DS1621+ (8TB usado)
Backup 1: disco externo 12TB WD Elements (rotación mensual)
Backup 2: NO. Media es reemplazable. Si se pierde, se vuelve a conseguir.

Nivel 4: bases de datos (PostgreSQL, SQLite)
#

Original: containers Docker en Unraid
Backup 1: dump SQL cada noche, guardado en Synology
Backup 2: Backblaze B2 (dumps comprimidos)

Sí, es mucho. Pero lo tengo todo automatizado. Cero intervención manual día a día.

Por qué RAID no es backup
#

RAID protege de fallos de disco. Eso es todo. No protege de:

Borrado accidental (borras un archivo, se borra en el RAID)
Corrupción de datos (fichero roto, replicado en el RAID)
Ransomware (cifran tus datos, los del RAID también)
Fallos del controlador RAID (adiós todos los discos)
Desastres físicos (incendio, el RAID arde también)

RAID es disponibilidad, no backup. Tu servidor puede seguir corriendo si falla un disco, pero tus datos no están más seguros.

Yo tengo RAID en mi Synology (SHR, que es RAID 5 mejorado). Me da tranquilidad de que un disco muerto no me tira abajo el NAS. Pero los backups verdaderos están en Backblaze, fuera de mi casa, fuera de mi control físico.

Herramientas que uso (y por qué)
#

Time Machine (macOS → Synology)
#

Para mi Mac, Time Machine es imbatible en facilidad. Lo configuras una vez, se olvida que existe, y funciona.

El Synology hace de destino Time Machine vía SMB. Cada hora, backups incrementales. Si la cago con un archivo, lo recupero en 30 segundos.

Ventaja: integración nativa, recuperación granular (archivo por archivo o sistema completo)
Desventaja: solo macOS, dependes de que Synology funcione

Restic (Mac/Linux → Backblaze B2)
#

Restic es mi backup serio. Es open source, cifrado end-to-end, deduplicación, snapshots incrementales.

Configuración inicial:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# Instalar
brew install restic  # macOS
# o
sudo apt install restic  # Linux

# Inicializar repositorio en Backblaze B2
export B2_ACCOUNT_ID="tu_account_id"
export B2_ACCOUNT_KEY="tu_account_key"
export RESTIC_REPOSITORY="b2:tu-bucket:backup-mac"
export RESTIC_PASSWORD="contraseña-segura-aqui"

restic init

Script de backup diario (~/bin/backup-restic.sh):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/bin/bash
export B2_ACCOUNT_ID="..."
export B2_ACCOUNT_KEY="..."
export RESTIC_REPOSITORY="b2:homelab-backups:mac-mini"
export RESTIC_PASSWORD_FILE="$HOME/.restic-password"

# Backup de directorios importantes
restic backup \
  ~/Documents \
  ~/Pictures \
  ~/Code \
  ~/clawd \
  --exclude-file=$HOME/.restic-exclude \
  --tag daily

# Borrar snapshots antiguos (retención: 7 daily, 4 weekly, 6 monthly)
restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

# Verificar integridad (una vez por semana)
if [ $(date +%u) -eq 7 ]; then
  restic check
fi

Archivo de exclusiones (~/.restic-exclude):

1
2
3
4
5
6
node_modules/
.git/
*.DS_Store
.cache/
.npm/
Library/Caches/

Cron para ejecutarlo cada noche a las 02:00:

0 2 * * * /Users/luis/bin/backup-restic.sh >> /Users/luis/logs/restic.log 2>&1

Ventaja: cifrado, deduplicación (ahorra espacio), snapshots eficientes, open source
Desventaja: línea de comandos pura, tienes que montarlo tú

Restic me cuesta unos 8 USD/mes en Backblaze (100GB de datos tras deduplicación).

BorgBackup (alternativa a Restic)
#

Usé Borg antes de Restic. Es igual de bueno, quizás más rápido. Cambié porque Restic tiene soporte nativo de B2 y la sintaxis me gusta más.

Si prefieres Borg:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# Inicializar repo
borg init --encryption=repokey /mnt/backup/borg-repo

# Backup
borg create /mnt/backup/borg-repo::$(date +%Y%m%d-%H%M%S) \
  ~/Documents ~/Pictures ~/Code

# Retención
borg prune /mnt/backup/borg-repo \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6

Ambos (Restic y Borg) son excelentes. Usa el que te convenza más.

Proxmox Backup Server (PBS)
#

Para mis VMs en Proxmox, uso Proxmox Backup Server. Es un servidor dedicado (VM en uno de los nodos) que recibe backups de todas las demás VMs.

Configuración en Proxmox:

Datacenter > Storage > Add > Proxmox Backup Server
Server: IP del PBS, puerto 8007
Datastore: nombre del datastore en PBS
Credentials: API token generado en PBS

Luego, en cada VM: Backup > Backup now, o Schedule para automatizar.

PBS hace backups incrementales muy eficientes (solo bloques cambiados). Una VM de 40GB tarda 3 minutos en backup completo inicial, luego incrementales de segundos.

Estos backups viven en el Synology (PBS guarda en NFS montado desde el NAS). Y de ahí, otro script sube los backups más críticos a Backblaze.

Ventaja: integración perfecta con Proxmox, extremadamente rápido
Desventaja: solo para VMs Proxmox, necesitas montar un servidor PBS

Scripts custom para Docker Compose
#

Cada stack de Docker importante (n8n, Vaultwarden, Gitea, PostgreSQL) tiene un script de backup.

Ejemplo para PostgreSQL:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
#!/bin/bash
# backup-postgres.sh

CONTAINER_NAME="postgres-main"
BACKUP_DIR="/mnt/nas/backups/postgres"
DATE=$(date +%Y%m%d-%H%M%S)

# Dump de la base de datos
docker exec $CONTAINER_NAME pg_dumpall -U postgres | gzip > $BACKUP_DIR/postgres-$DATE.sql.gz

# Borrar backups antiguos (más de 30 días)
find $BACKUP_DIR -name "postgres-*.sql.gz" -mtime +30 -delete

# Subir a B2 (vía rclone)
rclone copy $BACKUP_DIR/postgres-$DATE.sql.gz b2:homelab-backups/postgres/

Cron diario a las 03:00:

0 3 * * * /home/luis/scripts/backup-postgres.sh

Mismo patrón para otros servicios. Dump/export → NAS local → B2.

Rclone (sincronización a B2)
#

Rclone es una navaja suiza para mover datos entre storages. Lo uso para subir backups al cloud.

Configuración de B2:

1
2
3
4
rclone config

# Elegir B2, seguir wizard
# Resultado: remote llamado "b2"

Sincronizar directorio completo:

1
rclone sync /mnt/nas/backups/configs b2:homelab-backups/configs --progress

La diferencia entre sync y copy:

copy: copia archivos nuevos/modificados, no borra nada en destino
sync: espejo exacto (borra archivos en destino que no existen en origen)

Uso copy para backups (nunca borrar automáticamente en cloud). Uso sync para sincronizar configs que gestiono activamente.

Backblaze B2: mi storage en la nube
#

Probé AWS S3, Google Cloud Storage, Wasabi. Me quedé con Backblaze B2 por:

Precio: $6/TB/mes (mucho más barato que S3)
Sin costes de egress (descargar datos es gratis, solo pagas subida/almacenamiento)
API compatible S3 (funciona con Restic, Rclone, casi todo)
No te clavan con APIs (AWS te cobra por cada request, B2 es plano)

Tengo 150GB en B2 (tras deduplicación), me cuesta 9 USD/mes. Es ridículamente barato para la tranquilidad que da.

Alternativas si B2 no te convence:

Wasabi: $6.99/TB/mes, sin egress fees, pero mínimo 90 días de retención
AWS S3 Glacier Deep Archive: $1/TB/mes, pero tardan horas en recuperar datos
Hetzner Storage Box: €3.81/TB/mes (1TB mínimo), basado en Europa

Estrategia de retención (cuánto tiempo guardar backups)
#

No puedes guardar backups para siempre. El coste crece, el storage se llena, y la mayoría de backups antiguos no sirven.

Mi política:

Backups diarios: retener 7 días
Backups semanales: retener 4 semanas
Backups mensuales: retener 6 meses
Backups anuales: retener 2 años

Esto cubre:

Recuperación de cambios recientes (última semana)
Revertir cambios de hace 1 mes si algo se rompió gradualmente
Auditorías o datos históricos (6 meses a 2 años)

Restic gestiona esto automáticamente con restic forget --keep-daily=7 --keep-weekly=4 --keep-monthly=6 --keep-yearly=2.

Testing de recuperación (o no sirve de nada)
#

Un backup que no has probado es un backup roto. Lo aprendí cuando intenté recuperar una VM y el backup estaba corrupto.

Ahora, cada trimestre, hago un drill de recuperación:

Elijo un servicio al azar (por ejemplo, Gitea)
Levanto una VM/container nueva
Intento restaurar desde backup
Verifico que funciona (puedo hacer login, ver datos)
Borro la VM de prueba

Si falla, arreglo el proceso de backup antes de que lo necesite de verdad.

También uso restic check una vez al mes para verificar integridad del repositorio. Tarda unos 10 minutos para 150GB.

Qué backup y qué no
#

No todo necesita backup. Hay que ser realista.

SÍ backup:

Fotos familiares (irremplazables)
Documentos personales/empresariales (contratos, facturas, etc.)
Código fuente de proyectos propios
Configuraciones de servicios (docker-compose, scripts, etc.)
Bases de datos (clientes, pedidos, datos de negocio)

NO backup (o backup light):

Media descargable (películas, series) → si se pierde, se descarga otra vez
Containers Docker → se recrean desde imagen
VMs de prueba/desarrollo → efímeras, no importan
Logs antiguos (más de 30 días) → pierden valor con el tiempo

Mi regla: si recrearlo me lleva más de 30 minutos, merece backup.

Costes reales de mi setup
#

Hardware:

Synology DS1621+ (ya lo tenía) - 0 EUR/mes
Disco externo 12TB WD Elements - 220 EUR one-time (amortizado, ~6 EUR/mes)

Cloud:

Backblaze B2 (150GB) - 9 USD/mes
Dominio + Tailscale (acceso remoto) - 0 EUR (Tailscale free tier)

Tiempo:

Configuración inicial - 8 horas (weekend completo)
Mantenimiento mensual - 15 minutos (revisar logs, drill trimestral aparte)

Total: menos de 15 EUR/mes para proteger 300GB de datos críticos + TBs de configs/VMs.

Automatización completa (cron + scripts)
#

Todo está en cron. Si depende de que me acuerde, no funciona.

Crontab actual en el Mac mini:

# Restic a B2 (datos críticos)
0 2 * * * /Users/luis/bin/backup-restic.sh >> /Users/luis/logs/restic.log 2>&1

# PostgreSQL dumps
0 3 * * * /Users/luis/bin/backup-postgres.sh

# Configs de Docker (push a Git)
0 4 * * * /Users/luis/bin/backup-docker-configs.sh

# Verificación Restic (domingos)
0 5 * * 0 /Users/luis/bin/restic-check.sh

# Notificación semanal de estado (lunes, 09:00)
0 9 * * 1 /Users/luis/bin/backup-status-report.sh

El script backup-status-report.sh me envía un mensaje a Telegram con:

Tamaño actual de backups en B2
Último snapshot exitoso de Restic
Espacio usado en Synology
Alertas si algún backup tiene más de 48h

Si algo falla, me entero al día siguiente. No es perfecto (idealmente sería notificación inmediata), pero es suficiente.

Errores comunes que yo cometí
#

Error 1: Confiar en un solo backup local
Pensé que Time Machine en el NAS era suficiente. Si el NAS se quema, adiós datos. Necesitas copia fuera de casa.

Error 2: No cifrar backups en cloud
Mis primeros backups a B2 iban sin cifrar. Mala idea. Restic cifra todo por defecto. Usa cifrado siempre.

Error 3: No documentar cómo restaurar
Sabía que tenía backups, pero no había probado restaurarlos. Cuando lo necesité, tardé 2 horas en recordar cómo usar Restic restore. Ahora tengo un README con comandos exactos.

Error 4: Guardar passwords de backup en el mismo sitio que los datos
Tenía la password de Restic en un archivo en el Mac. Si el Mac se quema, pierdo la password y los backups son inútiles. Ahora la tengo en Vaultwarden (mi gestor de passwords self-hosted, que también está en B2).

Error 5: No rotar discos externos
Tenía un disco externo de backup que vivía siempre conectado al NAS. Un ransomware habría cifrado también el backup. Ahora uso dos discos, uno conectado, uno guardado en casa de mis padres. Los roto cada mes.

Plan de recuperación ante desastres
#

Si mañana se quema mi casa (toco madera), esto es lo que haría:

Mac mini + datos personales: comprar Mac nuevo, restaurar desde B2 con Restic
VMs Proxmox: descargar backups de PBS desde Synology (que está en B2), recrear VMs
Configuraciones Docker: clonar repos de Gitea, levantar stacks con docker-compose
Media (Plex): dejar para el final, no es crítico, restaurar del disco externo si existe

Tiempo estimado: 2 días para tener todo crítico funcionando. 1 semana para volver al 100%.

Sin backups, sería 1 mes o más, recreando todo desde cero, perdiendo datos irremplazables.

Alternativas más simples (si esto te agobia)
#

Mi setup es para homelabs complejos. Si tienes 2-3 servicios, puedes simplificar:

Plan básico:

Time Machine (o Déjà Dup en Linux) → disco externo
Backblaze Personal Backup (todo el Mac/PC por $9/mes, ilimitado)
Configs importantes → Git repo privado (GitHub/GitLab gratis)

Esto te da 3-2-1 sin scripts ni comandos raros. No es tan flexible, pero funciona.

Plan intermedio:

Synology/QNAP NAS con Hyper Backup
Hyper Backup → B2 o Glacier
Snapshots de VMs en Proxmox

La mayoría de NAS traen software de backup decente. Úsalo.

Herramientas que no uso (y por qué)
#

Duplicati: probé, me pareció lento y la UI web se colgaba. Restic es más rápido.

Crashplan: era bueno, se volvió caro para múltiples máquinas.

Acronis: bueno pero caro. Para homelab, open source me vale.

Syncthing: sincronización, no backup. Si borras un archivo, se borra en todos lados.

Google Drive / Dropbox: útil para sync diario, pero no es backup (cambios se replican, borrados también).

Conclusión: backups o perder datos (no hay término medio)
#

La pregunta no es “si” vas a perder datos. Es “cuándo”. Discos mueren. Errores humanos ocurren. Ransomware existe. Incendios pasan.

Backups 3-2-1 no es paranoia. Es lo mínimo responsable si tienes datos que no puedes recrear.

Mi consejo:

Empieza simple: Time Machine + Backblaze Personal
Crece a medida que tu homelab crece: Restic, scripts, automatización
Prueba la recuperación AHORA, no cuando lo necesites
Si no has probado restaurar, no tienes backups

Perdí datos dos veces. No va a pasar una tercera. Tú puedes evitar la primera.

Qué es el backup 3-2-1 (la regla de oro)#

Mi setup actual de backups#

Nivel 1: datos críticos (fotos, documentos, código)#

Nivel 2: configuraciones de servicios (Docker, VMs, scripts)#

Nivel 3: media (Plex, películas, series)#

Nivel 4: bases de datos (PostgreSQL, SQLite)#

Por qué RAID no es backup#

Herramientas que uso (y por qué)#

Time Machine (macOS → Synology)#

Restic (Mac/Linux → Backblaze B2)#

BorgBackup (alternativa a Restic)#

Proxmox Backup Server (PBS)#

Scripts custom para Docker Compose#

Rclone (sincronización a B2)#

Backblaze B2: mi storage en la nube#

Estrategia de retención (cuánto tiempo guardar backups)#

Testing de recuperación (o no sirve de nada)#

Qué backup y qué no#

Costes reales de mi setup#

Automatización completa (cron + scripts)#

Errores comunes que yo cometí#

Plan de recuperación ante desastres#

Alternativas más simples (si esto te agobia)#

Herramientas que no uso (y por qué)#

Conclusión: backups o perder datos (no hay término medio)#