A unidade usb3.0 externa para o mdadm reconhecendo o ataque interno na inicialização

Question

Não tenho certeza se isso é relacionado a hardware ou software, mas estou postando aqui na esperança de que alguém possa me apontar na direção certa.

Propósito do hardware: Home NAS e host KVM.

SO: Servidor Ubuntu 14.04 instalado no SSD interno.

Raid Interno: 4 x 2TB 3,5 "HDD no software mdadm RAID 5 formatado ext4.

O servidor também contém uma placa PCI-Express USB3.0, à qual uma unidade USB2.0 portátil é conectada para backup de dados valiosos, baseado em cron. Servidor tem funcionado bem por 3 anos nesta configuração, nunca quebrou o suor.

Alteração recente: unidade USB2.0 portátil substituída por uma unidade USB3.0 portátil - ntfs formatados pelo Seagate Backup Plus Slim de 2TB . Essa unidade executa sem falha quando conectada a uma estação de trabalho e, se conectada à placa USB3.0 no servidor após a inicialização, ela pode ser montada e acessada manualmente.

Problema: Na inicialização, todas as unidades são reconhecidas pelo BIOS. O / S inicializa a partir do SSD interno, mas trava após a inicialização do GRUB, informando que o RAID interno em / mnt / raidmount (meu ponto de montagem) não pôde ser inicializado.

dmesg | cauda revela um erro de superbloco ruim em / dev / md0. No entanto, quando a unidade de disco rígido USB3.0 externa é desconectada e o servidor é reinicializado, tudo ocorre perfeitamente, o mdadm carrega a invasão e eu posso acessar todos os dados nela sem problemas. Isso sugere que não há problema com o RAID, mas, por algum motivo, ele não está se apresentando corretamente no SO quando a unidade USB3.0 está conectada.

Pensando que isso pode ser um problema com fonte de alimentação insuficiente para o arranjo RAID (USB3.0 consome mais energia que USB2.0) Eu atualizei o PSU de 300W para 450W, mas o problema persiste.

Não encontrei exemplos disso através do Google, e estou preso ao que tentar em seguida. Eu planejo eventualmente atualizar o sistema operacional do servidor para 16.04 e substituir o RAID ext4 por um sistema de arquivos ZFS para melhor correção de erros, mas a menos que eu possa fazer o backup do conteúdo do RAID para o disco rígido externo, não poderei continuar. p>     

Answer 1

Eu encontrei a resposta para minha própria pergunta. Meu problema foi causado por duas coisas:

1. Ubuntu alterando a atribuição de letra de unidade na inicialização quando a unidade USB é conectada

Sem a unidade USB conectada, o Ubuntu atribuiu os discos em meu sistema da seguinte forma:

/dev/sda : RAID disk 1
/dev/sdb : RAID disk 2
/dev/sdc : RAID disk 3
/dev/sdd : RAID disk 4
/dev/sde : Operating System disk

Com a unidade USB conectada na inicialização, o Ubuntu atribuiu os discos da seguinte forma:

/dev/sda : USB connected drive
/dev/sdb : RAID disk 1
/dev/sdc : RAID disk 2
/dev/sdd : RAID disk 3
/dev/sde : RAID disk 4
/dev/sdf : Operating System disk

2. mdadm.conf referenciando especificamente as letras da unidade

Meu arquivo mdadm.conf no /etc/mdadm/mdadm.conf tinha a seguinte entrada:

DEVICE /dev/sd[abcd]

Isso estava forçando o mdadm a usar as primeiras quatro letras de unidade para reunir a matriz RAID durante a inicialização, que falhou quando a unidade USB foi conectada porque / dev / sda1 foi alocado para a unidade USB em vez da primeira unidade na matriz RAID. Como o mdadm usa os superblocos em cada disco para armazenar as informações de associação do array RAID, dizer ao mdadm quais drives usar normalmente não é necessário - o mdadm irá simplesmente procurar todas as unidades disponíveis e reunir o RAID sozinho. / p>

Em vez disso, meu arquivo mdadm.conf deve ter incluído a linha:

DEVICE partitions

Que diz ao mdadm para fazer a varredura de todas as partições em todas as unidades para os superblocos que ele usa para identificar os membros do RAID. Isso é mais robusto, permitindo que o Ubuntu atribua letras de unidade como achar melhor e deixando o mdadm para fazer seu trabalho de unir o RAID de forma desinibida.

Fazer essa alteração simples fez com que o problema desaparecesse.