Montei um RAID por software, reiniciei e o armazenamento sumiu: o arranjo não é montado no boot

Você juntou os discos, o arranjo subiu, o armazenamento apareceu, você gravou dados nele. Tudo funcionou.

Depois você reiniciou a máquina e o armazenamento sumiu.

Os discos estão bem. Os dados continuam lá. O que falta é outra coisa.

Um arranjo não está nos discos, está na instrução de montagem

Mostrar vários discos como um único armazenamento não é uma propriedade que fique nos discos. A cada boot o sistema precisa encontrar aqueles discos e juntá-los de novo.

Existe um registro que diz a ele como fazer isso. Sem esse registro o arranjo pode não ser montado. E mesmo que seja, pode subir com outro nome, o que dá no mesmo: o seu armazenamento aponta para o nome antigo e lá não há nada.

Então o problema não é "os dados se perderam", é "o caminho até os dados não foi construído no boot". Soa menos assustador, mas no momento do susto os dois parecem iguais.

A posição do próprio Proxmox

Isso merece ser dito com honestidade: o caminho embutido e suportado no Proxmox é o ZFS. Peça espelhamento de discos durante a instalação e é isso que você recebe.

O RAID por software clássico funciona, mas não é o caminho que o instalador prepara para você. Ou seja, ao escolhê-lo, garantir que os passos de montagem no boot foram feitos direito fica por sua conta.

Ainda assim há casos em que faz sentido: você já tem um arranjo e está migrando, o arranjo da sua controladora não é o que o ZFS espera, ou a memória da máquina é apertada para ZFS. Essas são razões reais. Escolher sem uma razão é criar trabalho para você mesmo depois.

A regra: um arranjo que não viu um reinício não conta como arranjo

Essa é a frase mais prática deste artigo.

Depois de montar o arranjo, reinicie de propósito uma vez, enquanto nada depende dele. O armazenamento volta? Volta com o mesmo nome? O conteúdo aparece?

Escrevemos a mesma coisa no artigo sobre alertas desta wiki: um alarme não testado não é um mecanismo, é uma esperança. Para um arranjo vale igual. Um arranjo que não sobreviveu a um reinício é um arranjo que você acha que funciona.

A armadilha da mudança de nome

Segunda armadilha comum: o arranjo é montado, mas com um nome diferente do da vez anterior.

A sua definição de armazenamento aponta para o nome antigo, então o armazenamento fica invisível de novo. Desta vez o arranjo está de pé, mas ninguém está olhando para ele.

A solução é ligar o armazenamento por identidade em vez de por nome. Nomes podem mudar, identidades não.

O que o Atlas faz

Quando o Atlas monta um arranjo ele também escreve o registro de boot, e mostra este aviso na tela: se este passo falhar, o arranjo pode não ser montado no boot e o armazenamento fica invisível.

O aviso era verdadeiro. Mas por um tempo ele se desmentia sozinho.

Para produzir o registro, a ferramenta do sistema era chamada. Foi medido, e saiu isto: quando não existe arranjo nenhum, aquela ferramenta sai com código zero e não imprime nada. Ou seja, diz "sucesso" e não te entrega nada.

Resultado: nada era escrito, mas o passo era registrado como bem-sucedido. Justamente o que o aviso tinha acabado de descrever estava acontecendo com o usuário, enquanto a tela mostrava tudo em ordem.

A correção teve duas partes. O formato esperado foi determinado medindo, não adivinhando, e se a saída não bate com esse formato o passo conta como falho. Saída vazia também é falha. E para não escrever o mesmo arranjo duas vezes, verifica-se tanto o caminho do dispositivo quanto a identidade.

A lição geral

A frase que importa aqui é esta: "o comando teve sucesso" e "o trabalho foi feito" não são a mesma coisa.

Um código de saída diz se a ferramenta rodou. Não diz se o resultado aconteceu. Se todo o propósito de um passo é produzir um efeito, o que se checa não é o estado da ferramenta e sim o efeito em si.

Nesta wiki há outros dois artigos da mesma família. No dos discos órfãos separamos uma resposta vazia de não ter obtido resposta. No do nome do servidor havia o perigo de pôr um valor padrão de aparência plausível no lugar do desconhecido. Este é o terceiro: pôr um código de saída no lugar de um resultado que nunca foi estabelecido.

Os três são faces do mesmo defeito: o programa afirma algo que não verificou.