Estrategia de backup 3-2-1 para tu homelab: guía práctica

Estrategia de backup 3-2-1 para tu homelab: guía práctica

Estrategia de backup 3-2-1 para tu homelab: guía práctica

La regla 3-2-1 lleva décadas siendo el estándar de facto para backups, y por algo es: tres copias, dos medios, uno fuera de casa. Aquí la implementamos desde cero con herramientas reales en un homelab Proxmox.

Por Javier · Actualizado: 2026-01-04

La regla 3-2-1 de backup establece mantener 3 copias de tus datos en 2 soportes distintos, con 1 copia offsite. En un homelab, esto significa combinar disco local, NAS o servidor secundario, y almacenamiento en la nube o disco externo fuera de casa. RAID y snapshots ZFS no cuentan como backup.

Si tienes homelab pero no tienes backup real, esto va contigo

Tienes Proxmox funcionando, quizás un NAS, snapshots de ZFS por aquí y allá, y en algún momento te dijiste «ya tengo mis datos más o menos protegidos». Yo también me lo dije. Hasta que borré sin querer una VM entera y tardé un segundo en darme cuenta de que las snapshots vivían en el mismo pool que los datos. Spoiler: no había backup.

La regla 3-2-1 suena a cosa de sysadmins de empresa, pero lleva diez minutos entenderla y es perfectamente aplicable en casa sin gastar dinero en infraestructura extra. Lo que sí requiere es parar un momento a estructurar lo que ya tienes, en vez de ir añadiendo capas sin un plan claro.

En este post te cuento exactamente cómo lo tengo montado yo: qué herramientas uso, cómo está configurado el offsite y qué puntos débiles quedan aún (porque ninguna estrategia doméstica es perfecta). Si sales de aquí con un esquema concreto que puedas implementar esta semana, el post habrá cumplido su función.

Por qué importa

RAID no es backup

RAID protege contra fallo de disco, no contra borrado accidental ni ransomware. Necesitas copias reales con historial.

Tres copias, dos soportes

La regla 3-2-1 exige al menos dos medios físicos distintos: un fallo de controlador puede llevarse discos del mismo tipo a la vez.

Offsite obligatorio

Una copia en casa de un familiar o en la nube cubre lo que un incendio o robo destruiría junto con tu NAS.

Verifica la restauración

La extensión 3-2-1-1-0 exige cero errores verificados: un backup que nunca has restaurado es un backup que no existe.

RAID y snapshots no son un backup (y esto importa)

El error más habitual en cualquier homelab nuevo: montar un RAID-1 y sentirse protegido. RAID protege la disponibilidad ante el fallo físico de un disco, pero no hace nada contra un ransomware que cifra tus datos, un rm -rf accidental o el fallo del controlador que corrompe ambos discos a la vez.

Las snapshots de ZFS son potentes, pero si viven en el mismo pool que los datos originales, un fallo del pool se lleva snapshots y datos de un golpe. Son una herramienta excelente de recuperación rápida, no un sustituto del backup offsite.

La diferencia clave es esta: un backup real tiene independencia física y temporal del original. Sin eso, no es backup.

La regla 3-2-1 desglosada

El fotógrafo Peter Krogh popularizó la regla en The DAM Book (2009) para gestión de archivos fotográficos, y desde entonces se ha convertido en el estándar práctico de referencia para cualquier entorno, desde estudios hasta homelabs.

La regla tiene tres números que se traducen en tres decisiones concretas:

  • 3 copias totales — el original más dos copias. No el original y una copia: tres en total.
  • 2 soportes distintos — por ejemplo, disco interno más NAS externo. Si los dos comparten el mismo punto de fallo, no cuenta.
  • 1 copia offsite — fuera de tu ubicación física. Un incendio, una inundación o un robo se lleva todo lo que esté en casa.

Parece sencillo, pero la mayoría de los homelabs cumplen 2 de 3. Casi siempre falla el offsite.

Capa 1: backup local estructurado

El primer backup debe ser rápido de restaurar. Para eso, quieres algo en la misma red local, con historial de versiones y, si puedes, deduplicación para no comerte el almacenamiento.

Proxmox Backup Server para VMs y contenedores

Si tu homelab corre sobre Proxmox, PBS es la opción más integrada. Se distribuye bajo AGPL-3.0, es gratuito y puede instalarse como VM dentro del propio Proxmox o en hardware dedicado: una mini-PC de bajo consumo funciona perfectamente.

PBS ofrece deduplicación a nivel de bloque, compresión y cifrado en reposo. Desde la interfaz de Proxmox puedes programar backups por VM con retención configurable. Lo más útil en la práctica: restaurar una sola VM o un LXC concreto tarda segundos si el datastore está en red local.

Configuración mínima para empezar:

  1. Despliega PBS como VM (ISO disponible en proxmox.com) con un disco de datos separado del sistema.
  2. En Proxmox, añade el datastore PBS en Datacenter → Storage → Add → Proxmox Backup Server.
  3. Crea un job de backup en Datacenter → Backup → Add con la retención que necesites. Un punto de partida razonable: 7 diarios, 4 semanales, 3 mensuales.

Restic para archivos y directorios

Para datos que no son VMs — documentos, proyectos, exports de bases de datos — Restic es una opción muy sólida. CLI, open source, cifrado AES-256-CTR con autenticación HMAC-SHA256 según su propia especificación, y deduplicación por bloques.

Inicializar un repositorio local y hacer el primer backup:

restic -r /mnt/backup/restic-repo init
restic -r /mnt/backup/restic-repo backup /home/javi/proyectos

Y para listar los snapshots disponibles:

restic -r /mnt/backup/restic-repo snapshots

La contraseña del repositorio la gestiona Restic internamente. Guárdala en un gestor de contraseñas, no en el mismo servidor que estás respaldando.

Capa 2: segundo medio físico independiente

El segundo soporte tiene que ser independiente del primero en cuanto a punto de fallo. Si el primer backup va a un NAS, el segundo no puede ser otro volumen del mismo NAS: un fallo del controlador o un ransomware que llegue al NAS se lleva las dos copias a la vez.

Opciones prácticas para el segundo medio:

  • Disco externo USB conectado al servidor o al NAS, montado solo durante la ventana de backup para reducir la superficie de ataque.
  • Segundo servidor de backup en otra máquina de la red — con PBS puedes apuntar a un segundo datastore en hardware diferente.
  • Hardware sobrante reconvertido — un mini-PC con un par de discos como destino de Restic o BorgBackup funciona perfectamente y el coste de operación es mínimo.

Lo importante no es el hardware concreto: es la independencia del punto de fallo. Un evento que afecte al medio 1 no debe poder alcanzar al medio 2.

Capa 3: el offsite que casi nadie implementa

Esta es la parte que más se posterga. Pero es la que te salva cuando el problema es físico: incendio, inundación, robo. Si las tres copias están en el mismo edificio, técnicamente tienes tres copias en un solo soporte a efectos de desastre.

Opción low-tech: disco rotado en casa de un familiar

No necesitas infraestructura para cumplir el offsite. Un disco externo que rotas cada pocas semanas con un familiar o en la oficina es una copia offsite completamente válida. Es manual, es lento, pero funciona y no cuesta más allá del hardware.

Dos cosas imprescindibles antes de sacarlo de casa: cifrar el disco (LUKS, VeraCrypt o el cifrado nativo de tu NAS) y documentar el proceso de restauración por escrito, para no depender de recordar los pasos meses después cuando más falta hace.

Opción cloud: Restic con Backblaze B2 o rclone

Para un offsite automatizado, Restic soporta backends S3-compatibles de forma nativa, incluido Backblaze B2. Los precios de los servicios cloud cambian; verifica los actuales en el momento de leer esto antes de decidir.

Ejemplo con Backblaze B2:

export B2_ACCOUNT_ID=tu_account_id
export B2_ACCOUNT_KEY=tu_account_key
restic -r b2:nombre-del-bucket:restic-repo init
restic -r b2:nombre-del-bucket:restic-repo backup /home/javi/proyectos

Restic cifra los datos antes de subirlos, así que el proveedor nunca ve tus archivos en claro. Si prefieres otro proveedor, rclone actúa como capa de transporte hacia más de 40 destinos distintos:

restic -r rclone:nombre-remoto-rclone:restic-repo backup /datos

Esto te da acceso a cualquier proveedor soportado por rclone sin cambiar la forma en que usas Restic.

PBS con sync remoto

PBS incluye una función de sincronización entre datastores que permite replicar backups a un segundo PBS en otra ubicación. Si tienes un servidor en casa de un familiar o en un VPS, configuras un PBS remoto y usas Sync Jobs para automatizar la replicación offsite de VMs y contenedores sin tocar Restic.

Verificación: el paso que convierte un backup en uno de verdad

Un backup que nunca has restaurado es un backup de confianza no verificada. La extensión moderna de la regla, llamada 3-2-1-1-0, añade dos elementos: una copia inmutable (que no se puede modificar ni borrar durante un período definido) y cero errores verificados en restauración.

El «0 errores» no significa que nunca vaya a fallar: significa que tienes un proceso para comprobarlo de forma periódica. En la práctica:

  • restic check — comprueba la integridad del repositorio sin necesidad de restaurar nada.
  • restic restore a un directorio temporal — la única forma real de saber que los datos son recuperables es recuperarlos, aunque sea parcialmente.
  • PBS Verify Job — en la interfaz de PBS puedes programar verificaciones periódicas del datastore desde Datastore → Verify Jobs.

Programa una restauración de prueba al menos una vez cada pocos meses. No hace falta restaurar todo: basta con un snapshot reciente de un directorio o una VM no crítica para confirmar que el proceso funciona de extremo a extremo.

Una advertencia honesta: ninguna estrategia de backup protege contra la pérdida física total si tanto la copia principal como el offsite están en el mismo edificio. Si el offsite es un disco en casa de tus padres a dos calles, cubre incendios y robos localizados, pero no un desastre de mayor escala. Para la mayoría de los homelabs caseros, ese nivel de riesgo es aceptable. Cada uno decide su umbral.

Preguntas frecuentes

Q: ¿Vale mi RAID como segunda copia del 3-2-1?

A: El RAID protege contra el fallo físico de un disco, pero no contra borrado accidental, ransomware ni fallo del controlador. Para cumplir el 3-2-1 necesitas copias independientes con historial de versiones, no redundancia de bloques. El RAID puede ser uno de los soportes, pero nunca sustituye al backup real.

Q: ¿Las snapshots de ZFS cuentan como copia offsite?

A: Las snapshots de ZFS son muy útiles para recuperar ficheros borrados por error, pero si viven en el mismo pool que los datos originales, un fallo del pool destruye ambas cosas a la vez. Solo cuentan como copia independiente si las replicas a otro pool o servidor físicamente separado.

Q: ¿Cuánto cuesta tener una copia offsite en la nube?

A: Depende del volumen y el proveedor, y los precios cambian, así que conviene verificarlos antes de comprometerse. Backblaze B2 o servicios compatibles con S3 suelen ser de los más económicos para homelabs pequeños. Una alternativa con coste cero es un disco externo rotado en casa de un familiar, que también cumple el requisito offsite.

Q: ¿Por qué Restic y no rclone para el backup offsite?

A: rclone sincroniza ficheros entre destinos, lo cual es práctico, pero no mantiene historial de versiones: si borras un fichero por error y sincronizas, el borrado se propaga al destino. Restic, en cambio, guarda snapshots incrementales con deduplicación y cifrado AES-256, de modo que puedes recuperar versiones anteriores aunque el original ya no exista.

Q: ¿Qué pasa si el offsite también está en mi casa?

A: Si la copia 'offsite' reside en el mismo edificio que el original, un incendio, inundación o robo puede destruir ambas a la vez. La regla 3-2-1 exige una ubicación geográficamente separada; un disco en casa de un familiar o una copia cifrada en la nube cumplen ese requisito, pero dos discos bajo el mismo techo no.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *