Recuperación de desastres

Qué cubre cada mecanismo

RAID no es backup: protege de fallos de disco, no de borrados, ransomware ni incendios. La copia que sale del equipo se configura y se prueba siguiendo backups.md; esta guía es lo que se hace cuando ya ha pasado algo.

Antes de que pase nada

Cinco minutos hoy, horas menos de angustia el día malo:

1. Una copia externa configurada y probada restaurando (backups.md).
2. Un nas-config-*.tar.gz reciente dentro de esa copia externa (no solo en el NAS).
3. Alertas por correo o webhook activas (Panel de control → Alertas): un disco que falla o una copia que lleva un mes fallando tienen que avisarte.
4. Apuntado en algún sitio fuera del NAS: nombres de los pools, nombre del servidor, dominio DDNS y los códigos de recuperación del 2FA.

Disco de datos fallido

1. Recibirás una alerta (Pool X en estado DEGRADED o SMART crítico).
2. Identifica el disco en Almacenamiento → Salud (número de serie y estado por disco).
3. Conecta el disco nuevo. Si el equipo admite intercambio en caliente puedes hacerlo sin apagar; si no, apaga (Panel de control → Apagar y reiniciar), sustituye y arranca.
4. Almacenamiento → Salud → Discos de los pools → «Reemplazar» en el disco averiado, y elige el de repuesto. La operación corre como tarea en segundo plano: el resilver (ZFS) o la copia (Btrfs) puede tardar horas, y el pool sigue en uso mientras tanto.
5. Vigila el progreso en Almacenamiento (línea «scan») hasta que el pool vuelva a estar sano. No quites otro disco durante el proceso: es el momento de menos redundancia.

Si prefieres la consola, el equivalente es zpool replace <pool> <disco-viejo> /dev/sdX en ZFS y btrfs replace start <devid> /dev/sdX /mnt/<pool> en Btrfs.

Reinstalar el sistema conservando los datos

Cuando muere el disco del sistema pero los discos de datos están intactos. Los pools viven en los discos de datos; el sistema es reemplazable:

1. Instala LGM-OS en un disco de sistema nuevo (install.sh o la ISO).
2. Restaura la configuración: Panel de control → Copia de la configuración → «Restaurar desde archivo…» con tu último nas-config-*.tar.gz, y reinicia el servicio. Vuelven los usuarios, los grupos y las carpetas compartidas con sus permisos; la clave de firma de sesiones se regenera (todo el mundo tendrá que volver a entrar).
3. Importa los pools:
• ZFS: zpool import -f <pool> (o zpool import para listarlos).
• Btrfs: los mount units restaurados montan por etiqueta automáticamente; si no: mount /dev/disk/by-label/<pool> /mnt/<pool>.
4. Reaplica servicios desde la UI (SMB/NFS/WebDAV se reescriben al guardar).

Desastre total del equipo

El NAS ya no existe: incendio, inundación, robo, sobretensión que se llevó placa y discos, o un ransomware que cifró todo lo que el NAS tenía montado. Los datos no están en el equipo, están en tu copia externa, y el procedimiento consiste en reconstruir el NAS alrededor de ella.

Requisito: una copia externa reciente y probada. Si nunca has restaurado desde ella, hoy te enteras de si sirve. Es exactamente el escenario que backups.md intenta evitar.

Orden de trabajo

1. Hardware. No tiene que ser idéntico al anterior. Necesitas discos de datos con al menos la capacidad de lo que vas a restaurar y un disco para el sistema.

2. Instala LGM-OS. Arranca la ISO y responde las cuatro preguntas (nombre del servidor, red, usuario de consola y disco del sistema). Al terminar, entra en https://<ip>:5000 y crea el administrador en el asistente de primer acceso.

3. Restaura la configuración. Recupera el nas-config-*.tar.gz desde la copia externa (está entre los archivos copiados; si la copia es un disco USB, conéctalo y cógelo de ahí) y súbelo en Panel de control → Copia de la configuración → «Restaurar desde archivo…». Después:

sudo systemctl restart nas-backend

Vuelven usuarios, grupos, carpetas compartidas con sus permisos, servicios, red, tareas programadas y alertas. Todavía no hay datos ni pools: eso es lo siguiente.

4. Crea los pools con los mismos nombres. Almacenamiento → «Crear pool». Es importante que el nombre coincida con el de antes: las carpetas compartidas, las exportaciones y las apps referencian rutas /mnt/<pool>/…, y con otro nombre habría que rehacerlas una a una.

5. Recrea las carpetas compartidas desde el Panel de Control (siguen definidas tras el paso 3: basta con guardarlas para que se creen en el volumen nuevo con sus permisos).

6. Restaura los datos con la app Copias de seguridad. Los destinos y las tareas volvieron con la configuración del paso 3, así que la app ya sabe dónde está tu copia. Dos avisos antes de empezar:

• Si el destino es remoto, el NAS nuevo tiene una clave SSH nueva: autorízala en el servidor remoto igual que la primera vez (paso 3 de backups.md) o no podrá ni leer la copia.
• Si el destino es un disco USB, conéctalo y comprueba que el destino aparece como disponible.

Después, para cada tarea: elige la versión que quieras (normalmente la última buena) y la carpeta de destino. Empieza por lo irreemplazable — documentos y fotos — y deja la colección multimedia para el final: así tienes lo importante disponible en horas aunque el resto tarde días. Si la tarea iba cifrada, necesitas la contraseña de cifrado; sin ella no hay restauración posible.

Si prefieres (o necesitas) hacerlo a mano desde la consola, por ejemplo con un disco USB montado en /mnt/usb-copia:

sudo rsync -aHAX --numeric-ids --info=progress2 \
     /mnt/usb-copia/<ruta-de-la-versión>/documentos/ /mnt/tanque/documentos/

Cuidado con las barras finales: origen/ copia el contenido de esa carpeta dentro del destino; sin la barra copiaría la carpeta entera dentro.

Si el destino remoto se autorizó con rrsync -wo (solo escritura), esa clave no puede leer: restaura desde el propio servidor remoto o retira temporalmente esa restricción de su authorized_keys.

7. Reaplica los servicios (SMB/NFS/WebDAV) guardándolos desde la UI y comprueba desde un PC que las comparticiones se ven y se escribe en ellas.

8. Apps Docker. Reinstálalas desde el Centro de Paquetes y, antes de arrancarlas, restaura sus datos sobre /var/nas/apps/<app>/. Arrancar una app con la base de datos vacía y restaurarla después suele terminar mal.

9. Acceso externo. El certificado de Let's Encrypt no se restaura: se vuelve a emitir solo desde Panel de Control → Acceso remoto en cuanto el dominio apunte a la nueva IP (revisa el DDNS y el reenvío de puertos del router nuevo).

10. Vuelve a dejar las copias en marcha. Comprueba que los destinos están disponibles y que las tareas quedan activas y con horario. Un NAS restaurado sin copia externa es un desastre a medio recuperar: el siguiente te pilla igual que este.

11. Prueba la copia. Ejecuta una tarea a mano y restaura un par de archivos de la versión que acabe de crear. Cierra el círculo el mismo día, no «cuando tenga un rato».

Cuánto tarda

Orientativo, para que dimensiones expectativas y decidas por dónde empezar:

Que la restauración por red sea tan lenta es la razón de tener también una copia local (o una que puedas ir a buscar en coche): la copia remota es tu seguro contra el incendio, la local es la que te devuelve al trabajo el mismo día.

Restaurar archivos desde un snapshot

• ZFS: los snapshots son visibles en /mnt/<pool>/<dataset>/.zfs/snapshot/<nombre>/ — copia lo que necesites sin tocar nada más. rollback desde la UI revierte el dataset entero (destruye snapshots posteriores).
• Btrfs: «Restaurar» crea /mnt/<pool>/restaurado-<fecha> con el contenido del snapshot; copia lo que necesites y borra esa carpeta (es un subvolumen: btrfs subvolume delete).

Copia de la configuración

Descárgala a mano desde Panel de control → Copia de la configuración, o automatízala: Panel de control → Tareas programadas → tipo «backup» hacia /mnt/<pool>/backups (p. ej. semanal). Guarda esa carpeta dentro de la copia externa: es lo primero que necesitarás en el escenario anterior.

Qué lleva el nas-config-*.tar.gz

• state/ — todo el estado de /var/nas/state: usuarios y grupos, carpetas compartidas con sus permisos por usuario y grupo, SMB, NFS, WebDAV, SSH, firewall, red, pools registrados, tareas programadas, alertas, notificaciones, App Store, SNMP, portal de acceso, SAI y auto-bloqueo de IPs. Esto es lo que se restaura.
• etc/ — copia de los ficheros generados (smb.conf, exports, nftables, sshd, htpasswd) solo como referencia: la restauración no los sobrescribe, se reescriben solos al reaplicar los servicios desde la UI.

Qué NO lleva, a propósito

Solo secretos del equipo y estado de usar y tirar; nunca configuración:

Cualquier otra clave de estado entra en la copia por defecto, incluidas las de funciones futuras: la tabla es la única excepción y backend/tests/test_backup_state.py falla si alguien añade estado nuevo sin decidir de qué lado cae. Antes era al revés — una lista de doce ficheros a incluir — y las carpetas compartidas se perdían en silencio en cada restauración.

Restaurar

Panel de control → Copia de la configuración → «Restaurar desde archivo…». Solo se aceptan entradas state/<clave>.json del propio formato (se rechaza cualquier ruta que salga del directorio de estado) y las claves protegidas de la tabla se ignoran aunque vengan dentro del archivo. Después: systemctl restart nas-backend y reaplica los servicios desde la UI.

⚠️ Esta copia no incluye tus datos: para eso están los snapshots (dentro del equipo) y la copia externa (fuera de él).

Lo que sigue sin cubrirse

Con la copia externa configurada, el desastre total deja de ser un callejón sin salida. Aun así, conviene saber dónde están los límites:

• Lo ocurrido desde la última copia se pierde. Si copias de madrugada y el equipo arde a las 20:00, se va el trabajo del día. Sube la frecuencia de lo que no puedas repetir.
• Lo que no estaba en ninguna tarea no está. Una carpeta compartida creada después de configurar las copias no entra sola: revisa los orígenes de tus tareas de vez en cuando.
• No hay imagen del disco de sistema (bare metal): LGM-OS se reinstala desde la ISO y se restaura la configuración. Es rápido, pero no es un «clonar y arrancar».
• Si la copia estaba junto al NAS, el desastre se la llevó también. Una copia en un USB permanentemente conectado al equipo no sobrevive a un incendio, un robo ni a un ransomware. Por eso una de las copias tiene que estar fuera.
• Sesiones y 2FA: la clave de firma se regenera y todo el mundo vuelve a entrar; los códigos TOTP están en el móvil de cada usuario. Guarda los de recuperación aparte.
• Claves y certificados del equipo son nuevos: hay que reautorizar la clave SSH del NAS en el destino de copia y reemitir el certificado de Let's Encrypt.