Não tenho certeza se essa é a comunidade a ser perguntada, mas achei que daria uma chance:
Nosso servidor que executa um RAID10 de 14 unidades através de um controlador rocketraid 2470 recusou-se a montar. Nosso objetivo não é necessariamente recuperar um RAID em funcionamento, mas obter o máximo de dados possível.
Talvez como consequência da falha de montagem, ao encerrar o servidor, ele ficava preso nos loops de inicialização. Então, eu estou atualmente executando o Ubuntu 16.04.1 de um USB. Eu determinei que 2 dos 14 discos são defeituosos e determinei quais são. Usando este guia , determinei quais e tentei remontar sem eles. No entanto, continuo com um erro:
ubuntu@ubuntu:~$ sudo mdadm --assemble --verbose --force /dev/md0 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/sdi1 /dev/sdj1 /dev/sdk1 /dev/sdl1 /dev/sdm1 /dev/sdn1 /dev/sdo1 /dev/sdp1
mdadm: looking for devices for /dev/md0
mdadm: /dev/sdc1 is identified as a member of /dev/md0, slot 0.
mdadm: /dev/sdd1 is identified as a member of /dev/md0, slot 1.
mdadm: /dev/sde1 is identified as a member of /dev/md0, slot 2.
mdadm: /dev/sdf1 is identified as a member of /dev/md0, slot 3.
mdadm: /dev/sdg1 is identified as a member of /dev/md0, slot 4.
mdadm: /dev/sdh1 is identified as a member of /dev/md0, slot 5.
mdadm: /dev/sdi1 is identified as a member of /dev/md0, slot 6.
mdadm: /dev/sdj1 is identified as a member of /dev/md0, slot 7.
mdadm: /dev/sdk1 is identified as a member of /dev/md0, slot 8.
mdadm: /dev/sdl1 is identified as a member of /dev/md0, slot 9.
mdadm: /dev/sdm1 is identified as a member of /dev/md0, slot 10.
mdadm: /dev/sdn1 is identified as a member of /dev/md0, slot 11.
mdadm: /dev/sdo1 is identified as a member of /dev/md0, slot 12.
mdadm: /dev/sdp1 is identified as a member of /dev/md0, slot 13.
mdadm: added /dev/sdd1 to /dev/md0 as 1
mdadm: added /dev/sde1 to /dev/md0 as 2
mdadm: added /dev/sdf1 to /dev/md0 as 3
mdadm: added /dev/sdg1 to /dev/md0 as 4
mdadm: added /dev/sdh1 to /dev/md0 as 5
mdadm: added /dev/sdi1 to /dev/md0 as 6
mdadm: added /dev/sdj1 to /dev/md0 as 7
mdadm: added /dev/sdk1 to /dev/md0 as 8
mdadm: added /dev/sdl1 to /dev/md0 as 9
mdadm: added /dev/sdm1 to /dev/md0 as 10
mdadm: added /dev/sdn1 to /dev/md0 as 11 (possibly out of date)
mdadm: added /dev/sdo1 to /dev/md0 as 12 (possibly out of date)
mdadm: added /dev/sdp1 to /dev/md0 as 13 (possibly out of date)
mdadm: added /dev/sdc1 to /dev/md0 as 0
mdadm: /dev/md0 assembled from 11 drives - not enough to start the array.
Aqui está a saída de uma chamada mdadm --examine.
ubuntu@ubuntu:~$ sudo mdadm --examine /dev/sd[c-p]1 | egrep 'Events | /dev/sd'
Events : 21988
Events : 21988
Events : 21988
Events : 21988
Events : 21988
Events : 21988
Events : 21988
Events : 21988
Events : 21988
Events : 21988
Events : 21988
Events : 560
Events : 21944
Events : 560
Portanto, está claro que as últimas três unidades estão desatualizadas. É possível que as unidades 11 e 13 nunca estivessem realmente ativas, mas como elas eram apenas parceiras em uma invasão 1, a matriz não foi afetada até agora. Espero que, se eu puder remontar com a 12ª unidade, poderei recuperar a maioria dos dados. Alguém sabe o que posso fazer sobre isso? Eu também tentei sem as unidades "inativas", mas ainda não está montando a unidade 12. Eu sei que posso tentar usar --run, mas não tenho certeza se vou perder dados dessa maneira. Eu também estou hesitante em zerar o superbloco porque eu sempre ouvi que era uma opção de último recurso.
Note que, como estou executando isso em um USB, o usual cat /proc/mdstat não retorna a matriz. Além disso, eu não sei a estrutura da matriz (se eu fizesse isso seria muito mais fácil).
Agradecemos antecipadamente pela ajuda.