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

El 14 de agosto de 2026, la copia de seguridad terminó correctamente. Ese resultado tranquiliza, pero un trabajo terminado no demuestra que puedas restaurarlo. 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 documentado el 14 de agosto de 2026: Restic crea snapshots cifrados en un SSD USB, y después Rclone replica el repositorio a OpenDrive. La restauración que aparece abajo corresponde a esa fecha, no a una comprobación diaria.

Revisión del 23 de septiembre: aclarado qué puede propagar la réplica y añadido un ensayo aislado del límite de --size-only. Las salidas de agosto se conservan como evidencia histórica; el ensayo nuevo usa archivos ficticios, no las copias del servidor.

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.

Si lo que quieres proteger es tu galería, sigue la lista de archivos y el ensayo de recuperación de Immich. Incluye las bibliotecas externas: no basta con guardar el volcado automático.

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 réplica fuera de casa y sus límites

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 14 de agosto de 2026, el servicio de réplica terminó 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. La retención de Restic no convierte esa réplica en una copia independiente. Si borras una foto del origen, un snapshot anterior puede conservarla. Pero si desaparecen los objetos del propio repositorio y después ejecutas rclone sync, el destino puede perderlos también. La documentación de Rclone explica que sync elimina archivos del destino para igualarlo al origen.

Para cubrir ese segundo fallo hace falta una separación que el servidor no pueda borrar con las mismas credenciales: un disco desconectado o retención inmutable del proveedor, si está disponible y comprobada. Estar fuera de casa resuelve la ubicación; no demuestra esa protección. Esta guía no acredita que el remoto descrito tenga inmutabilidad.

Dos archivos iguales de tamaño, distintos por dentro

El 23 de septiembre hicimos una prueba local con dos archivos ficticios: uno contenía AAAA y el otro BBBB, ambos con salto de línea y cinco bytes. Un tercer archivo existía solo en el destino. No se usó OpenDrive ni ningún repositorio de producción.

Comprobación	Resultado observado	Qué permite concluir
rclone check --size-only --one-way	0 differences found, salida 0	Coincide el tamaño del archivo de origen; su contenido es distinto y el control no lo detecta
rclone check --download --one-way	dato.txt: contents differ, salida 1	La comparación del contenido sí detecta la diferencia
rclone sync --dry-run -v	solo-destino.txt: Skipped delete as --dry-run is set	Una sincronización real intentaría borrar el archivo exclusivo del destino; la simulación lo conservó

Aquí --one-way deja fuera del cotejo los archivos que solo están en destino. Son extractos literales de una prueba pequeña, no una certificación del backup. Rclone documenta ambas opciones de comprobación.

Para revisar un repositorio Restic, restic check comprueba su estructura; leer y verificar también todos los datos requiere --read-data. La documentación de Restic advierte del tiempo y tráfico adicionales. Después queda el examen útil: restaurar desde la copia remota a una carpeta vacía, comparar archivos y, si guardas una aplicación, arrancarla aislada con su base de datos. Ninguno de esos pasos completos se ejecutó en este ensayo.

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. La prueba del 14 de agosto 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.

Pruebas originales: 14 de agosto de 2026. Revisión y ensayo local con archivos ficticios: 23 de septiembre de 2026. No se ha repetido aquí una restauración del servidor ni se ha probado la recuperación completa de Immich.