Cómo resolver errores de almacenamiento tras tocar firmware o drivers NVMe/RAID

Inicio » Windows » Cómo resolver errores de almacenamiento tras tocar firmware o drivers NVMe/RAID

Cuando empiezas a jugar con RAID, NVMe, firmware y drivers, es fácil que todo funcione perfecto en la BIOS pero luego Windows no vea nada o aparezcan errores raros al instalar o clonar el sistema. Muchos de los fallos que la gente achaca a “disco roto” o “NVMe incompatible” vienen en realidad de una mezcla envenenada de modo RAID/AHCI en la UEFI, drivers que no cargan y firmware desactualizado.

En este artículo vamos a desgranar, con calma pero con lenguaje de la calle, cómo resolver errores de almacenamiento tras toquetear firmware o drivers en NVMe y RAID. Verás casos reales de usuarios que han perdido arrays, problemas típicos al migrar de SATA a NVMe, líos con el modo RAID de la placa y, al mismo tiempo, revisaremos los errores clásicos al formatear SSD NVMe (sistemas de archivos, TRIM, alineación, etc.) que pueden disparar síntomas muy parecidos a un fallo físico.

Por qué los problemas no siempre son del disco: la capa lógica

Una buena parte de las averías que parecen físicas tienen su origen en la capa lógica de almacenamiento: firmware, drivers y compatibilidad con BIOS/UEFI. En HDD, SSD y NVMe, esta capa actúa como cerebro intermedio entre el sistema operativo y el hardware real, y cuando algo falla ahí, todo lo demás se tambalea.

El firmware de una unidad de almacenamiento es un pequeño software interno que gobierna cómo se accede a la NAND o a los platos, cómo se organiza la caché, qué políticas de energía siguen los chips y qué estrategias de corrección de errores se aplican. En un NVMe moderno, este firmware decide cómo se gestionan las colas de I/O, la caché SLC dinámica y el control térmico; cualquier bug aquí puede provocar picos de latencia, caídas de rendimiento o incluso pérdida de datos silenciosa.

En discos duros clásicos, el firmware se encarga sobre todo del posicionamiento del cabezal, remapeo de sectores defectuosos y reintentos de lectura. Un firmware mal ajustado puede disparar reintentos excesivos que se traducen en cuelgues, tiempos de respuesta absurdos y, a veces, en unidades que “desaparecen” del sistema durante unos segundos y vuelven a aparecer.

En SSD y NVMe la cosa se complica: la controladora depende de un Flash Translation Layer (FTL), wear leveling, garbage collection y caché SLC. Si el firmware tiene un fallo en alguno de esos módulos, pueden darse casos de corrupción silenciosa, bloqueos aleatorios, pérdida de rendimiento brutal tras cierto volumen de escritura o incompatibilidades con chipsets y BIOS concretas.

Drivers NVMe/RAID y relación con BIOS/UEFI

Además del firmware interno, el segundo pilar son los drivers de almacenamiento y la configuración de BIOS/UEFI. Un ajuste erróneo aquí hace que el sistema operativo vea cosas que no debería, o que no vea lo que realmente interesa: el volumen RAID lógico.

En SATA, la mayoría de placas permiten elegir entre modo AHCI o RAID para el controlador. Si el fabricante deja RAID activado por defecto, todos los SSD SATA conectados se exponen como dispositivos RAID, aunque no los estés usando en un array real. Además, algunos controladores RAID integrados pueden intentar crear arreglos automáticamente o marcar discos como “miembros potenciales”, complicando aún más el diagnóstico.

En NVMe la situación se ha ido pareciendo cada vez más a la de SATA: algunas placas permiten crear arrays RAID NVMe desde la UEFI y presentan al sistema operativo un único volumen lógico. Aquí pueden entrar en conflicto el driver genérico de NVMe del sistema operativo (como stornvme.sys en Windows) y los drivers propietarios del fabricante del chipset o del RAID (por ejemplo, los paquetes RAID de AMD o Intel RST).

Cuando la BIOS está en modo RAID, lo normal es que el sistema vea un “controlador RAID” que a su vez expone un volumen lógico. Sin embargo, si el entorno de instalación de Windows o la herramienta de clonación no cargan el driver correcto, el sistema puede detectar los NVMe físicos por separado (a través del driver genérico) pero no el array RAID lógico que has creado en el firmware.

Un ejemplo típico: usuario con procesador Threadripper de segunda generación que borra sus antiguos volúmenes RAID SATA, activa RAID para NVMe, monta dos Samsung 980 Pro en una tarjeta DIMM.2, crea un RAID 1 desde la UEFI… y al arrancar las herramientas de clonación o un instalador limpio de Windows 10, solo ve los dos NVMe individuales, nunca el volumen RAID. Aunque instala el paquete RAID_CC de AMD, el volumen sigue sin aparecer porque el entorno de instalación continúa usando el driver NVMe estándar que reclama la clase de dispositivo CC_010802 en lugar del driver RAID.

En la vista de controladores UEFI aparecen dispositivos AMD con VID 1022 y DID 43BD/7917, además de la controladora Samsung con VID 144D. Los drivers RAID de AMD (como rcbottom.sys) están preparados para engancharse a determinados IDs PCI de la controladora RAID, pero si Windows decide asignar antes el driver NVMe genérico a la clase 010802, el volumen lógico no se presenta como tal y el instalador solo ve discos sueltos. En ese caso, la clave suele estar en:

• Cargar manualmente el driver RAID correcto durante la instalación.
• Verificar en la UEFI que el modo de almacenamiento y el RAID NVMe están configurados como indica el fabricante.
• Comprobar que el firmware de la placa base está en una versión con soporte estable para RAID NVMe.

En otros escenarios, como algunos equipos OEM, el problema es justo el contrario: la BIOS se actualiza vía Windows Update, se activa o cambia el modo RAID en el controlador SATA y, de repente, todos los SSD aparecen como RAID sin que el usuario haya tocado nada. En estos casos, suele bastar con entrar en la BIOS, revisar si el controlador SATA está en RAID y cambiarlo a AHCI, seguido de una actualización de drivers desde la web del fabricante del equipo (sobre todo chipset, almacenamiento y BIOS).

Errores frecuentes al migrar de SATA a NVMe con RAID

Migrar un sistema ya instalado desde un RAID 1 de SSD SATA M.2 a un RAID 1 de NVMe suena bien en teoría, pero en la práctica acumula muchas posibilidades de que algo se rompa por el camino. Los pasos más habituales son borrar los volúmenes RAID antiguos, activar RAID para NVMe, insertar los nuevos NVMe, crear el array y clonar o reinstalar.

El problema aparece cuando las herramientas de clonación o el instalador de Windows no reconocen el volumen RAID NVMe y solo ven los discos individuales. Si además pruebas diferentes drivers, cambias modos en la BIOS y mezclas SATA RAID con NVMe RAID, es muy fácil acabar con una configuración incoherente donde el firmware de la placa crea que hay un array, pero el sistema operativo no tiene un driver capaz de verlo.

Algo parecido puede suceder en placas con soporte para tecnologías tipo Intel RST o RSTe. Un usuario con una Z370 AORUS, dos NVMe WD SN580 y un SSD SATA clásico (por ejemplo un Samsung 850 EVO) intenta habilitar los NVMe desde el “grupo de almacenamiento” de Windows, los combina mal, borra uno, se queda con el otro, juega a activar/desactivar CSM, Secure Boot y el modo RST de Intel, e incluso intenta inyectar drivers Intel RST manualmente durante la instalación, sin éxito. El resultado: el NVMe aparece en BIOS y en el gestor de almacenamiento, pero no como dispositivo arrancable ni en la administración de discos.

En ese caso concreto, la solución no tenía nada que ver con compatibilidades PCIe ni con versiones de CPU o chipset, sino con el propio grupo de almacenamiento de Windows. Conectar de nuevo el segundo NVMe, borrar por completo las configuraciones de grupo de almacenamiento para que ambos volvieran al estado “en bruto” y, solo entonces, abrir la administración de discos permitió ver finalmente las dos unidades NVMe como discos normales, listos para particionar, formatear e instalar Windows.

Elección de drivers: genéricos vs propietarios

En el mundo SATA y NVMe siempre surge la duda: ¿uso el driver genérico del sistema operativo o instalo el driver del fabricante (AMD, Intel, Samsung, etc.)? La respuesta no es universal; depende de si estás usando RAID, del chipset y de la estabilidad de cada versión.

Los drivers SATA/AHCI genéricos de Windows suelen ser bastante estables y suficientes para la mayoría de equipos domésticos. Sin embargo, algunos drivers propietarios (como los de Intel RST) añaden funciones de gestión avanzada, monitorización y, por supuesto, soporte para arreglos RAID. La contrapartida es que pueden introducir latencia extra o presentar bugs específicos en ciertas combinaciones de hardware.

En NVMe, el driver estándar de Windows (stornvme.sys) funciona muy bien en la mayoría de casos: soporta colas, TRIM y las funciones básicas de la especificación. Los drivers específicos del fabricante pueden mejorar ligeramente el rendimiento en cargas muy concretas, aportar herramientas de monitorización propietarias o afinar tiempos de espera, pero no siempre son más estables o rápidos. Muchos entornos profesionales se quedan deliberadamente con el driver genérico para reducir complejidad.

Cuando entra en juego un volumen RAID NVMe gestionado por el chipset, entonces sí es imprescindible usar el driver RAID adecuado (AMD RAID, Intel RST, etc.) y asegurarse de que el entorno de instalación lo carga antes que cualquier driver genérico. De lo contrario, verás únicamente los NVMe físicos y tendrás errores a la hora de instalar o clonar el sistema.

En Linux la lógica es similar, pero el ecosistema cambia: el soporte NVMe y RAID suele estar integrado en el kernel y se usan herramientas como mdadm, nvme-cli, smartctl, parted o gdisk. Las diferencias gordas en compatibilidad llegan más por la versión del kernel y de la BIOS que por drivers propietarios, ya que la mayoría de controladoras están soportadas de serie.

Configuración de BIOS/UEFI, chipset y topología

La BIOS/UEFI no solo define si el controlador está en AHCI o RAID; también determina cómo se reparten las líneas PCIe, qué puertos SATA se deshabilitan al usar M.2 y qué unidades son arrancables. En placas modernas, ocupar ciertas ranuras M.2 puede anular uno o varios puertos SATA, o compartir ancho de banda con la GPU.

Un fallo típico es pensar que “si la unidad sale en la BIOS, ya está todo bien”. La realidad es que puedes ver un NVMe listado en la UEFI, pero que el firmware no tenga un módulo de soporte de arranque NVMe suficientemente moderno, o que el modo de arranque (Legacy vs UEFI, CSM activado o no) bloquee la detección del disco como opción de arranque en ciertas combinaciones.

La versión de la BIOS también influye: muchas primeras versiones de firmware de placas base tenían errores al gestionar NVMe, RAID NVMe o combinaciones de ambos. Actualizar a la última versión estable del fabricante puede corregir desapariciones aleatorias de discos, errores al retomar desde suspensión o problemas al instalar sistemas operativos recientes.

Por eso, cuando una unidad aparece en la pantalla de información de la BIOS pero no como destino de instalación o como opción de arranque, conviene revisar:

• Modo de arranque (UEFI puro, Legacy, CSM activado o desactivado).
• Modo del controlador de almacenamiento (AHCI, RAID, RST, RAID NVMe).
• Interacciones del chipset: líneas PCIe compartidas, puertos SATA deshabilitados, ranuras M.2 con limitaciones.
• Versión de BIOS y notas de la versión sobre soporte NVMe/RAID.

Un cambio aparentemente inocente, como activar un modo RAID propietario “por probar”, puede dejar tu instalación actual de Windows inservible hasta que vuelvas al modo original o reinstales con los drivers adecuados.

Errores al formatear NVMe que se confunden con fallos de firmware o RAID

Más allá de los problemas puros de drivers y BIOS, hay errores clásicos al formatear SSD NVMe que generan síntomas muy parecidos a los de un fallo de firmware o de RAID. Un formateo mal planteado puede bajar el rendimiento a la mitad, provocar cuelgues en determinadas cargas o acortar la vida útil de la unidad.

El primer error habitual es escoger un sistema de archivos poco adecuado. Usar FAT32 o exFAT en particiones grandes por comodidad es mala idea: FAT32 limita el tamaño máximo de archivo a 4 GB y carece de funciones como permisos granulares, cuotas o snapshots. exFAT está pensado para compatibilidad entre sistemas, no para servir de sistema de archivos principal en un NVMe de escritorio o servidor.

En Windows, lo más equilibrado es NTFS, que soporta volúmenes grandes, cifrado BitLocker, compresión y buen rendimiento general. En macOS, APFS saca partido del TRIM, los clones instantáneos y el cifrado por volumen, y está diseñado desde cero para SSD. En Linux, Ext4 o XFS con journaling activado dan una mezcla de estabilidad y rendimiento, mientras que Btrfs o ZFS aportan snapshots y verificación de integridad a cambio de un mayor uso de memoria y una gestión algo más delicada.

Otro patinazo muy común es no respetar la alineación de particiones. En NVMe la primera partición debe empezar típicamente en el sector 2048 (1 MiB) para que las operaciones de lectura/escritura se alineen con los bloques internos de la NAND. Si no se respeta esto, muchas escrituras terminan afectando a dos bloques físicos en lugar de uno, lo que aumenta la latencia y acelera el desgaste.

Para cuidarse de este problema, en Windows puedes usar diskpart: tras seleccionar el disco, crear la partición primaria con un alineamiento de 1024 KiB. En Linux, parted o gdisk permiten indicar inicios en múltiplos de 1MiB. Así te aseguras de que el sistema de archivos aprovecha bien la estructura interna del NVMe y evitas escribir doble sin necesidad.

TRIM, tamaño de clúster y herramientas de formateo

TRIM es fundamental para la salud de un NVMe, y sin embargo muchos usuarios lo desactivan “por seguridad” o lo pierden al montar la unidad tras un RAID o una controladora que no lo soporta. Sin TRIM, el SSD acaba llenándose de bloques sucios que deben limpiarse en el peor momento posible, generando el famoso “write cliff”: al principio todo va rapidísimo, pero la velocidad de escritura cae en picado con el uso.

En Windows, se puede comprobar el estado de TRIM con el comando fsutil behavior query DisableDeleteNotify; el valor 0 indica que TRIM está habilitado. En macOS, APFS lo activa de serie en SSD originales, y para unidades de terceros puede forzarse con trimforce enable. En Linux, TRIM se puede aplicar en tiempo real montando con la opción discard o programar ejecuciones periódicas de fstrim mediante systemd.

Otra decisión que impacta directamente en el rendimiento es el tamaño de clúster o tamaño de bloque lógico al formatear. Un clúster grande (por ejemplo, 64 KiB) acelera transferencias secuenciales de archivos enormes (edición de vídeo, backups gigantes), pero penaliza las IOPS y la eficiencia con archivos pequeños. Un clúster pequeño (4-8 KiB) se adapta mejor a bases de datos, sistemas operativos y entornos de muchos ficheros pequeños.

Elegir el tamaño de clúster sin pensar en el uso real de la unidad puede traducirse en una unidad NVMe potentísima sobre el papel que se siente “perezosa” bajo ciertas cargas. Herramientas como CrystalDiskMark o fio permiten probar diferentes configuraciones y ver el impacto antes de dejar una configuración definitiva.

También hay que tener cuidado con las herramientas de formateo. Utilidades muy antiguas o poco actualizadas pueden no soportar del todo NVMe o GPT, no enviar comandos TRIM correctamente o confundir el tamaño de la unidad, produciendo particiones corruptas o inaccesibles. Es preferible usar:

• En Windows: administración de discos, diskpart o software oficial del fabricante del SSD.
• En macOS: versiones recientes de Disk Utility o la línea de comandos diskutil con soporte completo de APFS.
• En Linux: parted, gdisk y nvme-cli combinados con mkfs apropiados (ext4, xfs, etc.).

Buenas prácticas de respaldo y diagnóstico antes de tocar firmware o RAID

Antes de empezar a cambiar firmware, modo RAID, drivers NVMe o formatear, lo más sensato es asumir que algo puede salir mal y preparar el terreno. Formatear, recrear arrays o flashear firmware implica un riesgo real de pérdida de datos, y la recuperación en NVMe es bastante más delicada que en discos mecánicos tradicionales.

La estrategia ideal pasa por clonar la unidad completa sector a sector, ya sea con herramientas hardware o software de imagen bit a bit (dd en Linux, Macrium Reflect en Windows, etc.). Una vez creada la copia, hay que montarla en otro equipo o como unidad secundaria y comprobar que los archivos importantes se leen bien.

Si la unidad original empieza a mostrar signos de agotamiento (sectores reasignados, mensajes SMART preocupantes, bloqueos frecuentes), lo mejor es priorizar el respaldo y dejar de usarla para experimentos. Seguir intentando formatear, crear RAID o actualizar firmware en una unidad moribunda puede agravar los fallos y hacer aún más difícil la posible recuperación en laboratorio.

En el diagnóstico profesional se suele seguir un enfoque escalonado: primero se verifica BIOS y firmware de la placa, luego se prueba con drivers alternativos de almacenamiento, se aísla la unidad en otro sistema con hardware distinto y, solo cuando se descartan problemas lógicos, se sospecha de daño físico real en el NVMe o SSD.

Un almacenamiento puede dar errores muy serios sin estar físicamente roto: un RAID mal configurado, un firmware defectuoso o un driver equivocado son suficientes para que el sistema operativo deje de arrancar, las unidades desaparezcan o el rendimiento caiga a niveles ridículos. Comprender esta capa lógica y tratarla con cuidado es lo que marca la diferencia entre una migración suave y varios días peleando con pantallas de instalación que no ven tu RAID o con NVMe que solo existen en la BIOS.

Cuando se afrontan cambios de firmware, drivers NVMe/RAID o migraciones desde SATA a NVMe, todo resulta mucho más manejable si se siguen unos principios claros: copias de seguridad previas, firmware y BIOS al día, elección razonada de driver genérico o propietario, verificación del modo RAID/AHCI, formateos con particiones alineadas y TRIM activo. Siguiendo esta receta, la probabilidad de encontrarte con discos fantasma, arrays invisibles o errores de instalación se reduce drásticamente y tus unidades NVMe podrán rendir a tope durante mucho más tiempo.