Monté un RAID por software, reinicié y el almacenamiento no está: la matriz no se ensambla al arrancar

Uniste los discos, la matriz se levantó, el almacenamiento apareció, escribiste datos en él. Todo funcionó.

Después reiniciaste la máquina y el almacenamiento no está.

Los discos están bien. Los datos siguen ahí. Lo que falta es otra cosa.

Una matriz no está en los discos, está en la instrucción de ensamblaje

Mostrar varios discos como un único almacenamiento no es una propiedad que resida en los discos. En cada arranque el sistema tiene que encontrar esos discos y volver a unirlos.

Existe un registro que le dice cómo. Sin ese registro la matriz puede no ensamblarse. Y aunque se ensamble, puede volver con otro nombre, lo cual viene a ser lo mismo: tu almacenamiento apunta al nombre viejo y allí no hay nada.

Así que el problema no es "se perdieron los datos", es "el camino a los datos no se construyó al arrancar". Suena menos aterrador, pero en el momento del susto ambos se sienten igual.

La postura del propio Proxmox

Esto merece decirse con honestidad: el camino integrado y soportado en Proxmox es ZFS. Pide un espejo de discos durante la instalación y eso es lo que obtienes.

El RAID por software clásico funciona, pero no es el camino que el instalador prepara para ti. Es decir, si lo eliges, asegurarte de que los pasos de ensamblaje al arranque se hicieron bien queda de tu parte.

Aun así hay casos en que tiene sentido: ya tienes una matriz y la estás migrando, la disposición de tu controladora no es la que ZFS espera, o la memoria de la máquina va justa para ZFS. Esas son razones reales. Elegirlo sin una razón es crearte trabajo para más adelante.

La regla: una matriz que no ha visto un reinicio no cuenta como matriz

Es la frase más práctica de este artículo.

Después de montar la matriz, reinicia una vez a propósito, mientras nada dependa de ella. ¿Vuelve el almacenamiento? ¿Vuelve con el mismo nombre? ¿Se ve el contenido?

Lo mismo escribimos en el artículo sobre avisos de esta wiki: una alarma sin probar no es un mecanismo, es una esperanza. Con una matriz pasa igual. Una matriz que no ha sobrevivido a un reinicio es una matriz que crees que funciona.

La trampa del cambio de nombre

Segunda trampa frecuente: la matriz se ensambla, pero con un nombre distinto al de la vez anterior.

Tu definición de almacenamiento apunta al nombre viejo, así que el almacenamiento vuelve a ser invisible. Esta vez la matriz está en pie, pero nadie la está mirando.

La solución es enganchar el almacenamiento por identidad en vez de por nombre. Los nombres pueden cambiar, las identidades no.

Qué hace Atlas

Cuando Atlas monta una matriz también escribe el registro de arranque, y muestra este aviso en pantalla: si este paso falla, la matriz puede no ensamblarse al arrancar y el almacenamiento se vuelve invisible.

El aviso era cierto. Pero durante un tiempo se desmentía a sí mismo.

Para producir el registro se llamaba a la herramienta del sistema. Se midió, y salió esto: cuando no hay ninguna matriz, esa herramienta termina con código cero y no imprime nada. Es decir, dice "correcto" y no te entrega nada.

Resultado: no se escribía nada, pero el paso se registraba como correcto. Justo lo que el aviso acababa de describir le estaba pasando al usuario, mientras la pantalla mostraba que todo iba bien.

La corrección tuvo dos partes. El formato esperado se determinó midiendo en lugar de adivinar, y si la salida no coincide con ese formato el paso cuenta como fallido. Una salida vacía también es un fallo. Y para no escribir dos veces la misma matriz se comprueban tanto la ruta del dispositivo como la identidad.

La lección general

La frase que importa aquí es esta: "el comando tuvo éxito" y "el trabajo se hizo" no son lo mismo.

Un código de salida te dice si la herramienta se ejecutó. No te dice si el resultado se produjo. Si todo el propósito de un paso es producir un efecto, lo que hay que comprobar no es el estado de la herramienta sino el efecto mismo.

En esta wiki hay otros dos artículos de la misma familia. En el de los discos huérfanos se separó una respuesta vacía de no haber obtenido respuesta. En el del nombre del servidor estaba el peligro de poner un valor por defecto de aspecto plausible en el lugar de lo desconocido. Este es el tercero: poner un código de salida en el lugar de un resultado que nunca se estableció.

Los tres son caras del mismo fallo: el programa afirma algo que no verificó.