Copias de seguridad de tus datos

Esta guía trata de la única copia que de verdad te salva: la que sale del NAS.

Todo lo demás que hace LGM-OS por tus datos vive dentro del mismo equipo. El RAID aguanta que se rompa un disco, no que se rompa el equipo. Los snapshots deshacen un borrado, no un incendio, un robo, una sobretensión que se lleve los discos por delante ni un ransomware que cifre lo que el NAS tiene montado. La copia de la configuración (nas-config-*.tar.gz) devuelve el panel a como estaba, y ni un solo archivo tuyo.

1. La regla 3-2-1 aplicada a este NAS

3 copias de cada dato · en 2 soportes distintos · con 1 fuera del edificio.

En un NAS doméstico se traduce en algo muy concreto:

Los snapshots no cuentan como copia: comparten los discos con el original. Cuentan como historial, que es otra cosa igual de útil pero para otro problema.

Si puedes, sube la apuesta a 3-2-1-1-0: una de las copias desconectada (un disco USB que se guarda en un cajón o fuera de casa y solo se conecta para copiar — es lo único que un ransomware no puede alcanzar) y 0 errores, es decir, restauraciones de prueba que se hacen y se apuntan (sección 6).

2. Qué copiar

No todo merece salir del NAS: la copia externa suele ser el recurso más caro y más lento que tienes. Ordena por lo que pasaría si desapareciera.

Dos detalles que se olvidan siempre:

• Incluye la configuración del NAS. Descarga un nas-config-*.tar.gz (Panel de control → Copia de la configuración de seguridad) a una carpeta que entre en la copia externa, o programa la tarea de configuración hacia esa carpeta. Sin ella, recuperar el equipo es reconstruir a mano usuarios, permisos y comparticiones.
• Para de escribir antes de copiar los datos de una app. Una base de datos copiada en caliente puede restaurarse corrupta. Detén el contenedor (o usa su propio volcado programado) y copia después. Para archivos normales no hace falta.

Y ojo con la papelera de red: vive dentro de la propia carpeta compartida, así que se copia con ella. Programa una tarea «Vaciar papelera antigua» (Panel de control → Tareas programadas) para que lo que borraste hace meses no siga viajando a tu copia externa.

3. A dónde copiar

La app maneja tres tipos de destino: local (una ruta del NAS, típicamente un disco USB montado), remoto por SSH (rsync contra otro servidor) y nube (Google Drive, OneDrive, Dropbox, Box, pCloud, MEGA, WebDAV, Amazon S3, Wasabi, MinIO y Backblaze B2).

Un patrón que funciona muy bien y no cuesta dinero: copia recíproca. Tu NAS copia en casa de tu hermano y el suyo copia en la tuya. Cada uno pone disco y luz, nadie paga cuota, y las dos copias están a kilómetros de distancia.

Copias en la nube

Copias de seguridad → Destinos → Nuevo destino → Nube. Hay dos formas de conectar, según el proveedor:

• Con tu cuenta (Google Drive, OneDrive, Dropbox, Box, pCloud). El panel te da un enlace, entras con tu cuenta en la web del proveedor y pegas de vuelta la dirección a la que te redirige. El NAS guarda el permiso, no tu contraseña.
• Con claves (S3, Wasabi, MinIO, Backblaze B2, WebDAV, MEGA). Pegas la clave de acceso y la secreta que te da el servicio. En S3 y B2, el nombre del cubo es el primer tramo de la carpeta de destino: micubo/LGM-OS.

Cómo se guardan las versiones. En un disco o por SSH, cada copia reutiliza los archivos que no cambiaron mediante enlaces duros, y así una versión diaria ocupa solo lo que cambió. En la nube no hay enlaces duros, así que funciona distinto: actual/ es un espejo de tus carpetas y, cada vez que un archivo se reemplaza o se borra, la versión anterior se aparta a una carpeta con la fecha de la copia previa. No se pierde nada, pero una versión antigua contiene solo los archivos que cambiaron después, no la foto completa de ese día.

Antes de empezar: mira lo que ocupan tus carpetas. Subir 2 TB por una fibra doméstica de 300 Mb de subida son unos quince días a pleno rendimiento. Lo sensato es empezar copiando solo lo irreemplazable (documentos, fotos) y dejar fuera lo que se puede volver a descargar.

Lo que todavía NO hace (y por qué se dice aquí)

• Cifrado del destino. Cifrar obligaría a empaquetar cada versión entera, y eso rompe justo lo que hace útil a esta copia: las versiones incrementales con enlaces duros y la restauración de archivos sueltos. Si el destino no es tuyo, cifra el disco en el otro extremo (LUKS) o usa una carpeta ya cifrada en la nube.

Sobre la privacidad del destino: el transporte va cifrado cuando copias por SSH, pero los archivos que llegan son legibles para quien administre ese equipo. Si el destino no es tuyo, cifra el disco de destino (LUKS en el otro extremo, o el propio disco USB) y guarda esa contraseña fuera del NAS (gestor de contraseñas, papel en un cajón).

4. Cada cuánto

La pregunta útil no es «cada cuánto copio» sino cuánto trabajo estoy dispuesto a perder. Esa es la frecuencia.

Programa las copias fuera de tus horas de uso y no todas a la vez: una copia externa a la misma hora que un scrub deja el NAS lento durante horas. Un buen reparto es copia a las 03:00 y scrub un domingo al mes a las 05:00.

Y algo que nadie hace hasta que le pasa: activa las alertas (Panel de control → Alertas, SMTP o webhook). Una tarea de copia que lleva tres meses fallando en silencio es exactamente igual de útil que no tener copia. La pestaña de estado de la app avisa además cuando no hay ninguna copia configurada, cuando la última falló, cuando una tarea lleva demasiado sin ejecutarse, cuando está desactivada o cuando su destino no está disponible.

5. Configurar una copia paso a paso

La app Copias de seguridad separa dos cosas, y merece la pena entender por qué:

• Destinos — dónde se guarda: el disco USB o el servidor remoto. Se definen una vez y se prueban con el botón «Probar conexión», que no dice solo si funciona: enseña paso a paso qué comprobación falla (la carpeta, los permisos, la clave, el rsync del otro lado) y qué orden ejecutar para arreglarlo. Pruébalos antes de fiarte, y otra vez cuando cambies algo: un USB desconectado o un servidor apagado es mejor descubrirlo ahí que a las tres de la mañana.
• Tareas — qué se copia y cuándo: carpetas de origen, destino, horario y cuánto se conserva (por número de versiones o por antigüedad en días).

Cada ejecución deja una versión restaurable en el destino y una entrada en el historial (con fecha, tamaño y el error exacto si falló).

5.1 A un disco USB o a otro pool (destino local)

1. Conecta el disco. Si viene de Windows, formatéalo desde Almacenamiento (ext4/Btrfs) o déjalo en NTFS/exFAT: LGM-OS lo monta igual, pero **NTFS y exFAT no guardan permisos ni propietarios de Linux**, así que lo que restaures llegará sin ellos. Para copias serias usa un disco con formato Linux.
2. Crea un destino de tipo local con la ruta donde está montado el disco, y pruébalo: la prueba escribe de verdad en esa carpeta, que es la única forma de saber que se puede.
3. Crea la tarea: nombre, carpetas de origen, ese destino, horario y versiones a conservar.
4. Lánzala a mano una vez y mira que termine. Comprueba después el tamaño en el destino: si son 4 GB de una carpeta de 400, revisa qué carpetas elegiste como origen.

5.2 A otro servidor por SSH (destino remoto)

Aquí está el 90 % de las dudas, así que va con todo el detalle. Llamaremos NAS a tu equipo y servidor remoto al que recibe la copia.

Paso 1 — Obtén la clave pública del NAS

En la app Copias de seguridad, al crear un destino remoto, el NAS genera su propia pareja de claves SSH y te muestra la pública. Es una sola línea, parecida a esta:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB4o…9c2K nas@lgm-os

La privada se queda en el NAS, en /etc/nas/ssh, un directorio que solo puede leer root: ni el panel ni ninguna ruta de la API pueden mostrarla, porque el proceso que atiende la web corre sin privilegios. Cópiala tal cual, entera y en una sola línea: si al pegarla se parte en dos, la autorización no funcionará.

Paso 2 — Crea el usuario que recibirá la copia (en el servidor remoto)

No uses root ni tu usuario personal. Un usuario dedicado y sin contraseña de acceso:

sudo adduser --disabled-password --gecos "" copias
sudo install -d -m 750 -o copias -g copias /copias/nas    # carpeta destino

Paso 3 — Autoriza la clave (en el servidor remoto)

La app te da esta misma orden ya montada con tu clave, lista para copiar y pegar en una sesión SSH del servidor remoto abierta con el usuario que recibirá la copia:

mkdir -p ~/.ssh && chmod 700 ~/.ssh \
  && echo 'ssh-ed25519 AAAA…' >> ~/.ssh/authorized_keys \
  && chmod 600 ~/.ssh/authorized_keys

Si prefieres hacerlo desde otra cuenta con sudo, el equivalente es:

sudo install -d -m 700 -o copias -g copias /home/copias/.ssh
sudo -u copias tee -a /home/copias/.ssh/authorized_keys >/dev/null
# pega aquí la línea completa de la clave pública y pulsa Enter y luego Ctrl+D
sudo chmod 600 /home/copias/.ssh/authorized_keys

Los permisos no son un detalle estético: si .ssh no es 700 o authorized_keys no es 600, OpenSSH ignora la clave sin explicar por qué y verás un «Permission denied (publickey)» desconcertante.

Recomendado — limita lo que esa clave puede hacer, añadiendo opciones al principio de la misma línea, antes de ssh-ed25519:

restrict,from="203.0.113.10" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB4o…9c2K nas@lgm-os

• restrict desactiva reenvío de puertos, agente, X11 y terminal interactiva. rsync sigue funcionando (requiere OpenSSH 7.2 o posterior; Debian 11 y 12 lo cumplen de sobra).
• from="…" acepta esa clave solo desde tu IP pública. Si tu IP es dinámica, admite tu nombre DDNS (from="micasa.duckdns.org") o quita la opción.

Nivel avanzado, si el servidor remoto no es tuyo del todo: rrsync encierra la clave en un único directorio y en modo solo escritura, de modo que ni siquiera puede leer el resto del disco. En Debian 12 viene con el paquete rsync en /usr/bin/rrsync (en versiones anteriores, comprimido en /usr/share/doc/rsync/scripts/):

command="/usr/bin/rrsync -wo /copias/nas",restrict ssh-ed25519 AAAA…

Ten en cuenta que con -wo (solo escritura) la copia entra pero no puedes restaurar por esa misma vía: la restauración se hace desde el servidor remoto o quitando esa restricción temporalmente. Es un intercambio consciente, no un olvido.

Paso 4 — Comprueba la huella del servidor remoto

La primera conexión te pedirá aceptar la huella del servidor. Aceptarla a ciegas es aceptar cualquier equipo que se ponga en medio, así que obtén la de verdad ejecutando en el servidor remoto:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Compara esa cadena SHA256:… con la que te muestre el NAS al probar el destino. Coinciden o no la aceptes.

Paso 5 — Prueba la conexión y guarda

Usa el botón de probar del destino en la app: comprueba que el NAS entra, que la carpeta existe y que puede escribir en ella. Si prefieres verlo desde la consola del NAS, hazlo como `root` y apuntando a la clave gestionada, que es la que usarán las copias (el proceso privilegiado es quien ejecuta rsync, no el usuario de servicio):

sudo ssh -i /etc/nas/ssh/id_ed25519 -p 22 copias@servidor.example.com 'touch /copias/nas/.prueba && echo ok'

Qué significa cada fallo típico:

Paso 6 — Crea la tarea de copia

Nombre, carpetas de origen, ese destino remoto, horario y cuánto se conserva. Si el equipo de destino no es tuyo, cifra allí el disco que recibe la copia (LUKS): el panel todavía no cifra la copia en origen, y lo dice. Primera ejecución a mano: la copia inicial manda todo y puede tardar horas o días según la línea de subida. Las siguientes son incrementales (rsync solo manda lo que cambió) y duran minutos. Si la primera copia por internet es inviable, hazla en local: lleva el NAS o un disco USB al sitio del servidor remoto, copia por red local y luego cambia el destino a la conexión remota — rsync verá que casi todo ya está y solo enviará las diferencias.

5.3 Retención: la copia no es un espejo

Un detalle que decide si sobrevives a un ransomware o no. Si la copia se limita a reflejar el origen, un archivo que se borra (o se cifra) hoy en el NAS se borra (o se cifra) esta noche también en la copia.

Defensas, de menos a más:

1. Versiones conservadas en la tarea: cada ejecución deja una versión y solo se borran las más antiguas cuando se supera el número que hayas fijado. Con 7 versiones diarias tienes una semana para darte cuenta de que algo se rompió; con 1 versión, ninguna. Cuenta el espacio: N versiones ocupan más que una, aunque las partes que no cambian se compartan entre ellas.
2. Snapshots en el destino: si el servidor remoto es otro NAS con ZFS o Btrfs, que haga sus propios snapshots del directorio de copias. Es la protección más barata y la más eficaz.
3. Una copia desconectada: el disco USB del cajón. Nada que no esté enchufado se puede cifrar.

6. Probar que la copia sirve (la única parte que no es opcional)

Una copia no verificada no es una copia: es una carpeta grande en la que confías por fe. Los tres indicadores que no demuestran nada son la tarea en verde, el tamaño del destino y «rsync no dio error».

La única prueba válida es restaurar de verdad y abrir el archivo restaurado.

Y si el disco de destino está cifrado (LUKS), la prueba incluye abrirlo con su contraseña: un disco cifrado cuya clave nadie recuerda es espacio ocupado, no una copia.

Plan de pruebas

Restauración de prueba (mensual)

Desde la app: elige la tarea, la versión que quieras recuperar y una carpeta de destino nueva — nunca encima del original, porque si algo sale mal querrás poder comparar los dos. La restauración corre como tarea, con su progreso, igual que la copia.

Luego abre unos cuantos archivos: una foto que se ve, un PDF que abre, un vídeo que reproduce. Un archivo de 4 MB que existe pero no abre es un archivo perdido. Y borra después la carpeta de pruebas, que ocupa lo mismo que lo restaurado.

Restauración completa de una carpeta (trimestral)

Restaura desde la app una carpeta entera a /mnt/<pool>/prueba-restauracion y compárala con el original. Desde la consola del NAS:

# 1. Comparar con el original: no debe listar diferencias
sudo diff -qr /mnt/tanque/documentos /mnt/tanque/prueba-restauracion

# 2. Verificación fuerte (compara contenido, no fechas ni tamaños)
sudo rsync -avnc --delete /mnt/tanque/documentos/ /mnt/tanque/prueba-restauracion/

# 3. Borrar la carpeta de pruebas cuando termines
sudo rm -rf /mnt/tanque/prueba-restauracion

En el paso 2, -c compara checksums (lento pero honesto) y -n no cambia nada: si esa orden no lista archivos, el contenido es idéntico bit a bit. Ojo con el espacio: la prueba duplica temporalmente lo que restaures, así que elige una carpeta que quepa.

Un matiz importante si restauras una versión antigua: las diferencias con el original de hoy son normales (es lo que cambió desde entonces). Para esta comparación usa la última versión, o compara solo archivos que sepas que no has tocado.

Apunta el resultado

Dos líneas por prueba, donde quieras, pero apúntalas:

2026-07-25 · Restaurados 4 archivos de la copia remota · abren bien · 3 min
2026-07-25 · Restauración completa de «documentos» (38 GB) · diff sin diferencias · 41 min

El dato que casi nadie mide es el tiempo de restauración. Saber que recuperar 2 TB por internet son cuatro días cambia decisiones: puede que quieras la copia local además de la remota, o un disco que puedas ir a buscar en coche.

Qué hacer si la prueba falla

Falla la prueba, no el día del desastre: es exactamente para lo que sirve. Revisa los orígenes de la tarea (¿faltaba una carpeta?), los permisos del destino, el historial por si llevaba semanas fallando en silencio y, si el disco de destino está cifrado, que la contraseña sea la que crees. Corrige, vuelve a copiar y vuelve a probar.

7. Lo que esta copia no cubre

Con honestidad, para que no te pille por sorpresa:

• Un archivo corrupto que se copia corrupto. rsync copia lo que hay. Contra esto están los checksums de ZFS/Btrfs y los scrubs programados, que detectan la corrupción en el origen antes de que se propague.
• Lo que no elegiste como origen. Una carpeta compartida nueva no entra sola en ninguna tarea: cuando crees una, añádela a la tarea que le corresponda o se quedará fuera de la copia sin que nadie te avise.
• El tiempo de subida. Una línea doméstica de 300 Mbps de bajada suele tener 30 de subida: unos 10 GB por hora en el mejor caso. Dimensiona la primera copia con eso en la cabeza.
• Las contraseñas y el 2FA. La copia de configuración no lleva la clave de firma de sesiones (se regenera) y tus códigos TOTP están en tu móvil, no en el NAS. Guarda los códigos de recuperación en otro sitio.

8. La copia a la nube falla

Lo primero: el mensaje del error, en la app Copias de seguridad, dice ahora qué contestó la nube (sin espacio, permiso caducado, dirección equivocada…). Ese texto es el diagnóstico; lo de abajo es para los casos que se repiten.

Nextcloud y otros WebDAV: usa una contraseña de aplicación, no la de tu cuenta (Ajustes → Seguridad → Dispositivos y sesiones). Si el servidor está detrás de un proxy con límite de tamaño de subida, ese límite manda sobre cualquier ajuste del NAS.

Ver también

• Recuperación de desastres — qué hacer cuando ya ha pasado.
• Guía de administración — snapshots, scrubs, alertas.