Background : Eu tinha um sistema Ubuntu Bionic configurado e rodando usando discos 3x1tb. Os discos foram todos particionados com uma partição de cerca de 15gb e os restantes cerca de 983gb.
Partições de 15 GB de dois discos formaram md0 , uma matriz raid1 usada para swap.
Partições de 983 gb de todos os 3 discos formados md10 , um array raid10 far 2 usado para / e totalizando cerca de 1,4 tb.
O que aconteceu : um disco rígido falhou. O array RAID10 continuou independente disso. O md0 exigiu que eu adicionasse a partição restante não utilizada de 15gb, mas o sistema inicializava. Não se preocupe \ o /
O que aconteceu depois : Algumas horas depois de encomendar uma nova unidade, o sistema de arquivos foi somente leitura e, em seguida, falhou ao reinicializar. Essencialmente, um segundo disco falhou, embora inteligente, relatou uma série de erros de CRC em vez de blocos ruins.
Deve-se notar que eu também tive problemas com um stick de RAM ruim antes disso, e problemas com a estabilidade do sistema com a substituição de RAM simultânea com isso acontecendo. (Agora resolvido.)
Onde estou agora : criei uma imagem dos dois discos com o ddrescue e examinei e tentei reparar o sistema de arquivos com o testdisk. (Atualmente re-imagem dos discos para um novo começo). Essencialmente, um disco aparece bem, o outro não exibe blocos inválidos ou setores ilegíveis quando o ddrescue está copiando, mas parece ter problemas no sistema de arquivos.
O que eu acho que aconteceu é que em vez de um segundo hardware de disco falhar, a RAM incorreta causou erros no sistema de arquivos que tornaram esse disco ilegível.
Evidência
mdadm --examine nas unidades reais, sdf é 'bom', sdd 'ruim':
/dev/sdf:
MBR Magic : aa55
Partition[0] : 31997952 sectors at 2048 (type fd)
Partition[1] : 1921523712 sectors at 32000000 (type fd)
/dev/sdd:
MBR Magic : aa55
Partition[0] : 32002048 sectors at 2048 (type 83)
Partition[1] : 1921519616 sectors at 32004096 (type 83)
Duas coisas visíveis aqui, primeiramente partições sdd foram revertidas para straight linux ext4 (83) e não linux raid (fd) e segundo sdd0 parece ter ganho 4096 setores de sdd1 (a menos que eu criei as partições dessa maneira ... mas Eu duvido disso.
O Testdisk também parece confirmar primeiro um problema no sistema de arquivos:
Disk /dev/sdf - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
Partition Start End Size in sectors
1 * Linux RAID 0 32 33 1991 231 32 31997952 [zen:0]
2 P Linux RAID 1991 231 33 121601 57 56 1921523712 [zen:10]
Disk /dev/sdd - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
Partition Start End Size in sectors
1 * Linux 0 32 33 1992 41 33 32002048
Bad relative sector.
2 P Linux 1992 41 34 121601 57 56 1921519616
Eu não consegui fazer o Testdisk corrigir isso - não parece que a versão do partedmagic suporta as partições raid do Linux e suas sugestões para usar o fsck resultam em números mágicos ruins em erros de superblocos mesmo quando usando superblocos alternativos.
Aqui estão os resultados do mdadm --examine das imagens montadas como dispositivos de loop, novamente bom sdf primeiro, bad sdd second:
/dev/loop1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 152533db:4e587991:5e88fe61:7fc8bfb8
Name : zen:10
Creation Time : Wed Jun 20 10:47:05 2018
Raid Level : raid10
Raid Devices : 3
Avail Dev Size : 1921261568 (916.13 GiB 983.69 GB)
Array Size : 1440943104 (1374.19 GiB 1475.53 GB)
Used Dev Size : 1921257472 (916.13 GiB 983.68 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=4096 sectors
State : clean
Device UUID : ef11197c:7461dd9e:ad2e28f6:bad63a7b
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Aug 30 15:36:14 2018
Bad Block Log : 512 entries available at offset 16 sectors
Checksum : 93267b2f - correct
Events : 55599
Layout : far=2
Chunk Size : 512K
Device Role : Active device 1
Estado da disposição: AA. ('A' == ativo, '.' == ausente, 'R' == substituindo)
/dev/loop2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 152533db:4e587991:5e88fe61:7fc8bfb8
Name : zen:10
Creation Time : Wed Jun 20 10:47:05 2018
Raid Level : raid10
Raid Devices : 3
Avail Dev Size : 1921257472 (916.13 GiB 983.68 GB)
Array Size : 1440943104 (1374.19 GiB 1475.53 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=0 sectors
State : active
Device UUID : f70177cb:7daea233:2feafe68:e36186cd
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Aug 30 15:25:37 2018
Bad Block Log : 512 entries available at offset 16 sectors
Checksum : 3c6bebab - correct
Events : 55405
Layout : far=2
Chunk Size : 512K
Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing, 'R' == replacing)
Mais uma vez notável que o sdd1 (também conhecido como loop2) tem problemas - não há 'Used Dev Size' listado.
Eu tentei recriar o array usando as imagens e, embora pareça funcionar, o array não pode ser montado (superbloco mágico de má qualidade novamente).
Perguntas
Parece que estou certo em pensar que é um mapa de partição corrompido em sdd que é a raiz do problema?
É possível consertar isso e, em caso afirmativo, com o quê? fdisk?
Resultado desejado torna a matriz montável para que eu possa despejar o máximo possível em um disco diferente. Eu tenho um backup de / etc e / home (em teoria - não tentei restaurar ainda), mas seria útil e dar paz de espírito se eu pudesse ressuscitar este array temporariamente. Uma breve execução do photorec sugere que um grande número de arquivos também pode ser recuperado, mas ordenando quase um monte de arquivos de arquivos sem estrutura de diretórios ou nome de arquivo ...
[RESOLVIDO]
Eu coloquei novas cópias das imagens de disco que eu fiz para que nenhum dos meus ajustes anteriores pudesse atrapalhar as coisas. Na verdade, uma era uma imagem de partição e uma imagem de disco inteira, montando-as:
losetup --show -f /recovered/imgs/sdf1-md10.img
losetup -o 16386097152 /dev/loop3 /media/adrian/855c7d84-25f0-4b2f-b8fa-a5408536aaff/sdd-801485.img
A verificação de cat /proc/mdstat mostrou-os montados em um estado inativo como md127, então parei e montei a montagem como sugerido por @derobert
mdadm --stop /dev/md127
mdadm -v --assemble --force /dev/md10 /dev/loop3 /dev/loop2
E pode montar e acessar o array! \ o /
O fato importante que perdi em minha pesquisa no começo de minhas próprias tentativas é que você precisa especificar os dispositivos para - montar se você estiver remontando a matriz em um novo sistema - nem percebeu que era possível para começar.