Empezar hoy con un NVMe y pasar a RAID más adelante es un plan razonable para un servidor doméstico, pero la ruta de migración segura no consiste en «hacer clic en Convertir JBOD a RAID». El hilo de origen de febrero de 2026 recomendaba un flujo controlado de copia de seguridad → crear una matriz nueva → restaurar → verificar, en lugar de asumir que ZimaOS podía transformar en el mismo lugar el almacenamiento existente de un solo disco.
El ZimaOS actual ha mejorado las herramientas de migración desde aquella publicación. En Ajustes > Migración de datos ahora se pueden mover imágenes de Docker, datos de aplicaciones de Docker y bases de datos de usuario de ZimaOS entre espacios de almacenamiento. Esto facilita la migración del estado de las aplicaciones, pero aun así no convierte un disco único ya utilizado en una configuración RAID 1/5 redundante sin una matriz de destino independiente.
El usuario de origen empezó con un NVMe y un disco USB para copias de seguridad
El sistema utilizaba la eMMC integrada para ZimaOS, un SSD NVMe configurado como almacenamiento JBOD y un disco duro USB para copias de seguridad. El usuario quería añadir más almacenamiento NVMe posteriormente y trasladarlo todo a RAID 1 o RAID 5.
Esta es precisamente la situación en la que resulta importante conservar una copia de seguridad independiente y verificada, porque cambiar la topología de almacenamiento puede implicar inicializar discos nuevos y, finalmente, borrar la configuración antigua de un solo disco.
No asumas que un JBOD de un solo disco puede convertirse en el mismo lugar
La respuesta de la comunidad indicaba que la interfaz de almacenamiento de ZimaOS no ofrecía un flujo compatible para convertir un JBOD de un solo disco → RAID. En su lugar, recomendaba crear una matriz nueva con unidades sin usar.
La documentación pública actual de Almacenamiento admite añadir unidades a ciertas configuraciones RAID existentes, especialmente para ampliar RAID 5, pero eso es distinto de convertir en el mismo lugar un espacio de almacenamiento no redundante de un solo disco en RAID.
Haz copias de seguridad de algo más que las carpetas compartidas habituales
Antes de cambiar el almacenamiento, protege:
- archivos compartidos normales;
- datos de aplicaciones de Docker;
- carpetas personalizadas montadas mediante bind mount;
- bases de datos de las aplicaciones;
- definiciones Compose/YAML de aplicaciones personalizadas;
- configuraciones importantes que no se recrean automáticamente.
Una copia de seguridad debe verificarse abriendo realmente archivos representativos o realizando una restauración de prueba, no solo comprobando que la tarea aparece como completada.
Crea la nueva matriz RAID antes de borrar el disco antiguo
La arquitectura de migración más segura consiste en dejar intacto el NVMe original mientras se crea la nueva matriz con las unidades añadidas. Así, el almacenamiento original sigue siendo otra fuente de recuperación hasta que se haya validado la nueva matriz.
El ZimaOS actual gestiona la creación de matrices desde Ajustes > Almacenamiento. Usa el flujo actual de configuración de almacenamiento de ZimaOS en lugar de repetir procedimientos manuales antiguos con mdadm.
Elige RAID 1 o RAID 5 según el número de unidades y el crecimiento previsto
RAID 1 es un espejo sencillo de dos unidades. RAID 5 empieza con tres unidades y sacrifica la capacidad de una unidad a cambio de tolerancia ante el fallo de un solo disco.
La documentación actual de ZimaOS presenta RAID 5 como una opción para bibliotecas en crecimiento e indica que se pueden añadir unidades con el tiempo. Esto puede hacer que RAID 5 resulte atractivo si esperas ampliar el conjunto después de la migración inicial.
La Migración de datos actual puede mover datos gestionados por ZimaOS
La documentación actual de IceWhale indica que Ajustes > Migración de datos puede mover:
- imágenes de Docker;
- datos de aplicaciones de Docker;
- bases de datos de usuario, como Galería, Descargas, Documentos, Multimedia y Copia de seguridad.
Usa el flujo actual de Migración de datos de ZimaOS después de crear el almacenamiento de destino.
Los bind mounts personalizados aún requieren verificación manual
Las categorías de migración integradas no garantizan que todas las rutas de host personalizadas de cada conjunto Compose se reescriban automáticamente. Comprueba las aplicaciones que monten carpetas inusuales fuera de las ubicaciones estándar gestionadas por ZimaOS.
Después de la migración, revisa la asignación de volúmenes de cada aplicación importante y confirma que la carpeta del lado del host apunta al nuevo almacenamiento.
Verifica la nueva matriz RAID antes de reutilizar el NVMe original
Confirma que:
- la RAID indique un estado correcto;
- los recursos compartidos importantes contengan los archivos esperados;
- las aplicaciones de Docker se inicien y sus bases de datos estén intactas;
- los permisos funcionen desde los clientes habituales;
- las tareas de copia de seguridad apunten al origen y destino previstos.
Solo entonces deberías borrar o reutilizar el NVMe original.
Conserva la copia de seguridad USB después de pasar a RAID
RAID protege la disponibilidad cuando falla un disco miembro. No protege contra borrados accidentales, ransomware, corrupción de aplicaciones, robos ni la pérdida del servidor completo.
La copia de seguridad USB del plan original sigue siendo útil después de la migración a RAID y puede formar parte de una estrategia 3-2-1 más amplia.
Preguntas frecuentes sobre pasar de JBOD a RAID
¿El ZimaOS actual puede mover AppData entre espacios de almacenamiento?
Sí. La herramienta actual de Migración de datos incluye los datos de aplicaciones de Docker y las imágenes de Docker.
¿Eso significa que un disco JBOD único puede convertirse en RAID 1 en el mismo lugar?
No. Mover datos y cambiar la topología de almacenamiento son operaciones distintas.
¿Cuándo se debe borrar el disco original?
Solo después de verificar la nueva matriz, los archivos, el estado de las aplicaciones, los permisos y las copias de seguridad.
