Meu servidor está configurado com raid1. Algumas noites atrás, o sda caiu completamente e os dados foram corrompidos. Substituí o drive, clonei a tabela de partições e adicionei os respectivos arrays. Ao adicionar sda3 (MD2), a ressincronização continuou falhando devido ao sdb ter erros de E/S. Copiei todos os arquivos que pude salvar de sdb3 para sda3, reconfigurei o raid e substituí o sdb por uma nova unidade. Agora estou adicionando as partições sdb aos arrays. Minha preocupação é a seguinte:
cat /proc/mdstat
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md3 : active raid1 sda4[0]
1822442815 blocks super 1.2 [2/1] [U_]
md2 : active raid1 sda3[1]
1073740664 blocks super 1.2 [2/1] [_U]
md1 : active raid1 sdb2[2] sda2[0]
524276 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sdb1[2] sda1[3]
33553336 blocks super 1.2 [2/2] [UU]
Tanto md0 quanto md1 eram exibidos como [U_] antes da sincronização. Por que md2 seria exibido como [_U]? Temo perder os dados ao adicionar o sdb3. Meu pensamento aqui é que o primeiro slot ([U_]) é visto como primário pelo mdadm e o segundo slot ([_U]) como secundário, daí o medo de que os dados sejam removidos para corresponder ao sdb3.
Por favor, avise.
Obrigado.
Responder1
Eu não ficaria preocupado. Eu suspeito que o que aconteceu aqui foi que o md3 foi criado usando um comando como
mdadm --create /dev/md3 -l 1 -n 2 /dev/sda4 /dev/sdb4
e o outro foi
mdadm --create /dev/md2 -l 1 -n 2 /dev/sdb3 /dev/sda3
Observe que seus outros dois arrays (md0 e md1) também possuem a ordem sdb,sda.
Se você quiser ser superparanóico, vá em frente e faça backup de seus arquivos em uma unidade externa, mas suspeito que quando você finalmente conseguir fazer isso
mdadm /dev/md2 -a /dev/sdb3
a recuperação prosseguirá sem problemas à medida que a nova partição (/dev/sdb3) for sincronizada com a partição existente (/dev/sda3). A posição na lista não tem importância. O RAID do software Linux lembra o que era válido e qual é a partição mais recente (sincronizada de forma incompleta).