Backup del homelab: la regla 3-2-1 aplicada de verdad

Mi copia de seguridad tardó esta madrugada menos de un minuto. Ese dato suena tranquilizador hasta que uno recuerda que un backup rápido también puede estar copiando nada. Por eso, antes de escribir esta guía, restauré un fichero del último snapshot y comparé su hash con el original.

La regla 3-2-1 cabe en una frase: tres copias de los datos, en dos soportes distintos y una fuera de casa. Aplicada a un homelab doméstico tiene más esquinas. Un snapshot en el mismo SSD no es otra copia; RAID tampoco. Y duplicar 20 TB de películas que se pueden volver a obtener quizá no sea la mejor manera de gastar disco y subida.

Aquí explico el sistema que corre hoy en mi mini PC: Restic crea snapshots cifrados en un SSD USB, y después Rclone replica el repositorio a OpenDrive. No es una arquitectura de catálogo. Tiene cables, límites de ancho de banda y una restauración ejecutada el 14 de agosto de 2026.

Qué merece una copia y qué no

Yo separo datos irrepetibles de datos voluminosos recuperables. En el primer grupo entran las fotos, bases de datos, configuraciones, claves y el contenido del blog. En el segundo están las cachés, imágenes Docker descargables y buena parte de la biblioteca multimedia.

Copiar todo sin pensar tiene una consecuencia muy doméstica: la primera subida no termina nunca, el servicio remoto ocupa una barbaridad y, cuando hace falta recuperar un fichero pequeño, hay que rebuscar dentro de toneladas que no importaban. Ya cometí esa torpeza con copias tar enormes. Restic las sustituyó porque deduplica, cifra y permite sacar un fichero sin desenvolver media casa.

Mi lista práctica queda así:

Datos	Copia local	Copia fuera de casa	Motivo
Fotos y base de datos de Immich	Sí	Sí	Son irrepetibles y la base guarda el contexto
Configuración de servicios	Sí	Sí	Reconstruir a mano es lento y propenso a olvidos
Documentos, proyectos y claves	Sí	Sí	Pérdida de alto impacto con poco volumen
Películas y series recuperables	No por defecto	No por defecto	Mucho volumen; priorizo los datos personales
Cachés y capas de Docker	No	No	Se regeneran y solo inflan el repositorio

La copia previa de la base de Immich es importante. El servicio de Restic ejecuta primero un volcado de PostgreSQL. Copiar solo las carpetas de fotos mientras la base está escribiendo puede dejar piezas de momentos distintos; parece una copia hasta el día de restaurarla.

La implementación real

El temporizador del Beelink lanza el backup cada madrugada. El 14 de agosto vi esta ejecución en systemd:

restic-backup-beelink.service
Active: inactive (dead) since Fri 2026-08-14 03:35:30 UTC
Process: 1579488 ExecStartPre=/usr/local/bin/immich_db_dump.sh (code=exited, status=0/SUCCESS)
Process: 1582645 ExecStart=/usr/local/bin/restic_backup_beelink.sh (code=exited, status=0/SUCCESS)
CPU: 1min 14.478s

La palabra inactive aquí no significa avería: es un servicio oneshot. Arranca, hace el trabajo y termina. Lo que miro es el código 0/SUCCESS, la hora del snapshot y el resultado de una restauración.

El repositorio local está en /media/SDDEXT/backups/restic/beelink, sobre un SSD externo. Restic toma /, aplica un fichero de exclusiones y conserva siete copias diarias, cuatro semanales y tres mensuales. No publico el contenido de las exclusiones ni rutas con secretos; sí la forma del comando:

restic -r "$REPO" --password-file "$PWFILE" backup / \
  --exclude-file=/etc/restic-beelink-excludes.txt --exclude-caches

La contraseña no vive en el script. Está en un fichero legible por root. Parece un detalle menor, pero una copia cifrada con la clave pegada al lado y permisos alegres es una puerta con la llave puesta.

El último snapshot y su tamaño, consultados directamente al repositorio, dieron esto:

ID        Time                 Host          Tags        Paths
--------------------------------------------------------------
094175a2  2026-08-14 03:34:55  beelink-zalo              /
--------------------------------------------------------------
1 snapshots

Snapshots processed:  1
Total Blob Count:  553428
Total Uncompressed Size:  66.259 GiB
Total Size:  46.208 GiB
Compression Ratio:  1.43x
Compression Space Saving:  30.26%

Son datos del snapshot más reciente, no el tamaño total acumulado de toda la política de retención. Esa distinción evita vender el ahorro de deduplicación como si fueran gigabytes mágicamente desaparecidos.

La prueba que importa: restaurar

Elegí /etc/hostname porque es pequeño, no contiene secretos y existe tanto en la máquina viva como en la copia. Restauré el fichero a un directorio temporal, calculé SHA-256 en ambos y ejecuté cmp:

restoring <Snapshot 094175a2 of [/] at 2026-08-14 03:34:55.120406584 +0000 UTC by root@beelink-zalo> to /tmp/restic-restore-check.Mo6fdO
Summary: Restored 2 / 1 files/dirs (13 B / 13 B) in 0:00
live_sha256  9b62af763d4e4351f67a94f1702146e29cf4aae9fa8d14142462df14f916e3b0
restored_sha256  9b62af763d4e4351f67a94f1702146e29cf4aae9fa8d14142462df14f916e3b0
cmp  IDENTICAL

Esto demuestra que ese fichero se recupera idéntico desde el snapshot local. No demuestra por sí solo que podría reconstruir Immich entero. Para eso hace falta un simulacro mayor: base de datos, biblioteca y permisos. Mi manía es empezar con pruebas pequeñas frecuentes y reservar una restauración completa para una ventana en la que pueda parar servicios sin jugar con las fotos familiares.

La tercera copia está realmente fuera

Después del backup local, otro temporizador sincroniza el repositorio cifrado a OpenDrive. Lo limita a una transferencia y 550 Kbit/s. Lo hice así a propósito: cuando dejé dos subidas compitiendo por el enlace, el montaje remoto se quedó sin aire y Plex empezó a esperar. El servidor no hacía ruido, pero la interfaz se arrastraba y el LED del switch parecía una feria.

El servicio de réplica terminó hoy a las 05:29:06 UTC con status=0/SUCCESS. Además comparé el origen y el destino mediante Rclone:

2026/08/14 09:33:10 NOTICE: OpenDrive root 'backups/restic/beelink': 0 differences found
2026/08/14 09:33:10 NOTICE: OpenDrive root 'backups/restic/beelink': 23 matching files

Esa comprobación usó --size-only y profundidad limitada. Sirve para verificar la réplica inmediata de la estructura superior, no sustituye a restic check ni a una restauración desde el remoto. Escribir el límite de cada prueba resulta menos vistoso, pero evita convertir un «parece bien» en una garantía que el comando no ofrece.

Snapshot, RAID y sincronización no son sinónimos

Un snapshot protege muy bien contra un borrado torpe si sigue en el mismo sistema de almacenamiento. No protege contra la muerte física de ese sistema. RAID mantiene el servicio cuando falla un disco; si borras una carpeta, cifra los archivos un ransomware o un comando apunta donde no debe, replica el problema con eficacia impecable.

La sincronización remota también puede propagar un borrado. Por eso la retención la gestiona Restic dentro del repositorio. Rclone replica objetos cifrados, mientras los snapshots conservan estados anteriores según la política diaria, semanal y mensual.

Para una casa normal, yo montaría las capas en este orden:

1. Primero, una copia automática en otro disco. Un USB sirve si no se queda olvidado y si el trabajo genera alertas.
2. Después, una restauración probada. Empieza por un fichero, sigue con una carpeta y termina con el servicio que más dolería perder.
3. Por último, una copia fuera de casa. Puede ser nube, otro NAS en casa de un familiar o un disco rotado físicamente. Debe estar cifrada antes de salir.

No hace falta comprar un segundo NAS el primer día. Un disco externo bien automatizado es mejor que un diagrama perfecto pendiente de montar. Cuando el volumen crece, la guía de mejores NAS caseros ayuda a calcular discos y bahías; para saber lo que añade a la factura está la calculadora de consumo 24/7. RAID, capacidad y consumo son decisiones distintas, aunque las tiendas intenten meterlas en la misma caja.

Qué cambiaría mañana si empezara de cero

Mantendría Restic y reduciría antes el conjunto de datos. También documentaría la restauración el mismo día que creo el primer snapshot. En mi rack pequeño, el SSD USB queda detrás del Beelink con un cable demasiado largo enrollado sobre sí mismo; al tocar la carcasa después del backup está templada, no caliente. Funciona, pero no es una separación física muy heroica: una sobretensión podría llevarse host y disco a la vez. La copia remota es la que rompe ese destino compartido.

La regla 3-2-1 no se cumple por tener tres carpetas llamadas backup. Se cumple cuando hay copias en soportes y lugares distintos, con historial, cifrado y una ruta de vuelta que has recorrido. Hoy recuperé un fichero idéntico. El siguiente examen serio es levantar la base de Immich en un entorno vacío; hasta hacerlo, no voy a llamarlo desastre resuelto.

Comandos y restauración ejecutados el 14 de agosto de 2026 en el Beelink N100 de Homelabista. Las rutas sensibles y credenciales se han omitido; las salidas publicadas son literales.