Caso práctico: Migración crítica de OpenMediaVault 5 a OMV 8 sin pérdida de datos en arrays Intel RST

Al administrar infraestructura de almacenamiento en red en entornos institucionales o empresariales, los saltos generacionales de software representan un desafío de alta criticidad. Mantener un servidor sobre versiones obsoletas como OpenMediaVault 5.6.26 (basado en Debian 10 Buster) expone la infraestructura a riesgos de seguridad por falta de parches oficiales.

En este artículo documentamos la arquitectura, el análisis de hardware y el procedimiento paso a paso implementado para migrar un servidor de producción a OpenMediaVault 8 (Debian 13), preservando volúmenes híbridos configurados bajo Intel Rapid Storage Technology (Intel RST) sin alterar los datos existentes.

1. Auditoría del Hardware y Situación Inicial

El nodo de almacenamiento contaba con la siguiente configuración física:

• Placa base: ASUS TUF B365M-PLUS GAMING.
• Procesador y memoria: Intel Core i5-9400F con 8 GB de RAM DDR4.
• Almacenamiento de sistema: 1 SSD SATA Samsung de 128 GB.
• Almacenamiento de datos: 5 discos Western Digital Purple de 4 TB (SATA).

Descubrimiento del esquema de almacenamiento

Al auditar los discos en el sistema previo, se detectaron tres particularidades críticas:

1. RAID por BIOS (Intel RST): Los arreglos de redundancia no fueron creados vía software tradicional en Linux (mdadm nativo), sino mediante el controlador Intel RST a nivel de BIOS.
2. Volúmenes en espejo: Existía un arreglo RAID 1 (espejo) completamente vacío y otro espejo no montado con aproximadamente 246 GB de archivos archivados.
3. Punto único de fallo: Un quinto disco operaba de forma independiente (sin espejo) albergando 958 GB de datos activos y carpetas compartidas críticas.

2. Decisiones de Arquitectura y Mitigación de Riesgos

¿Por qué evitar la actualización en cascada (5 → 6 → 7 → 8)?

Realizar tres actualizaciones consecutivas de distribución (dist-upgrade) en Debian acarrea una alta probabilidad de conflictos de dependencias, paquetes huérfanos y posibles corrupciones en los metadatos de configuración de OMV. Se optó por una instalación en limpio de OMV 8 en una unidad de arranque independiente, conservando la unidad SSD original intacta como plan de contingencia inmediata (rollback).

Restricciones de líneas PCIe y puertos SATA

La placa ASUS TUF B365M-PLUS GAMING tiene una restricción documentada en su manual de hardware: la ranura M.2_1 comparte carriles con el puerto SATA6G_1. Si se instala un SSD en formato M.2 SATA, el primer puerto SATA queda inhabilitado automáticamente.

Dado que los 6 puertos SATA estaban ocupados (1 SSD de sistema + 5 discos WD Purple), instalar un M.2 SATA habría desconectado uno de los discos de los arreglos. La solución consistió en utilizar una unidad SSD M.2 NVMe (KIOXIA de 256 GB), permitiendo operar los carriles PCIe de manera independiente sin anular ningún puerto SATA.

3. Plan de Contingencia y Preparación de Datos

Para eliminar el punto único de fallo del disco suelto de 958 GB, se clonó su estructura completa hacia el espejo RAID 1 que se encontraba vacío utilizando rsync:

# Copia completa preservando propietarios, permisos y atributos extendidos
rsync -avhHAX --progress /srv/dev-disk-by-uuid-disco-suelto/ /srv/dev-disk-by-uuid-espejo-vacio/

# Verificación en modo dry-run para confirmar integridad y ausencia de diferencias
rsync -avhHAX --dry-run --delete /srv/dev-disk-by-uuid-disco-suelto/ /srv/dev-disk-by-uuid-espejo-vacio/

El resultado arrojó cero discrepancias, asegurando que la información quedó duplicada y protegida bajo redundancia física.

4. Proceso de Despliegue e Instalación

• Aislamiento físico de unidades: Durante la instalación de OMV 8 en el SSD NVMe, se desconectaron físicamente los cables SATA de los 5 discos de datos, eliminando cualquier riesgo de sobreescritura accidental.
• Preservación del modo SATA en BIOS: Se mantuvo el modo del controlador SATA en RAID / Intel RST. Cambiar el controlador a AHCI habría provocado que el kernel de Linux no interpretara los metadatos imsm de los arreglos existentes.
• Identificación por números de serie: Se documentaron los números de serie (serial number) de cada unidad física, evitando depender de identificadores dinámicos como /dev/sda o /dev/sdb.

5. Reconexión, Detección de Volúmenes y Montaje

Con OMV 8 instalado, se apagó el equipo, se reconectaron los cinco discos WD Purple y se verificó el ensamble automático a nivel de kernel:

cat /proc/mdstat

La salida confirmó el ensamble automático de los arreglos bajo metadatos Intel ([UU] en estado íntegro). En entornos Intel RST bajo Linux, es normal que los contenedores imsm figuren como inactive mientras los volúmenes derivados permanecen operativos.

Mapeo por UUID

Los identificadores de dispositivo md pueden cambiar entre reinicios. Por ello, la integración en el sistema de archivos de OMV se realizó exclusivamente mediante sus identificadores universales únicos (UUID):

Los tres sistemas de archivos se montaron directamente en la interfaz de OMV 8 sin formatear, reconociendo el árbol de directorios intacto.

6. Configuración de Servicios y Despliegue de Docker

• Samba (SMB/CIFS): Creación de recursos compartidos diferenciados (buzón público, carpetas de infraestructura y respaldos restringidas con limpieza de ACLs heredadas).
• Automatización de Respaldos: Creación de un usuario dedicado en el sistema para recibir copias de seguridad remotas hacia un directorio aislado.
• Capa de Contenedores: Despliegue de Docker y Portainer mediante el plugin omv-extras.
• Despliegue de Base de Datos: Se levantó una instancia de MariaDB 11.8 junto a phpMyAdmin, apuntando sus volúmenes persistentes al arreglo principal en espejo.

7. Próximos Pasos de Seguridad y Mantenimiento

1. Gestión de privilegios mínimos en motor SQL: Configurar usuarios con permisos granulares para las aplicaciones cliente.
2. Tareas programadas de volcado: Implementar scripts periódicos con mariadb-dump.
3. Estrategia de respaldo 3-2-1: Sincronización periódica de datos críticos hacia una ubicación remota (offsite).
4. Sincronización horaria (NTP): Asegurar la zona horaria en America/La_Paz para garantizar la coherencia de logs y auditoría.

Conclusión

Migrar un sistema de almacenamiento en producción no tiene por qué involucrar pérdidas de tiempo ni riesgos de datos si se planifica la arquitectura física y lógica. Utilizar unidades NVMe para aislar el sistema operativo, preservar la configuración del firmware (Intel RST) y apoyarse en la consistencia de los UUIDs garantiza un servidor robusto, moderno y listo para años de operación continua.