A matriz MD raid5 parece ter parado de funcionar repentinamente. Os sintomas são um pouco semelhantes aosesse assuntonisso estou recebendo erros falando sobre dispositivos insuficientes para iniciar o array, porém, no meu caso, a contagem de eventos em todas as três unidades é igual. É um array raid 5 que deve ter 2 unidades ativas e uma paridade, no entanto mdadm --examine em cada unidade mostra dois deles tendo sua função listada como sobressalente e apenas uma como unidade ativa.
eu tenteimdadm --stop /dev/md1seguido pelamdadm --assemble /dev/md1(incluindo tentativas com os sinalizadores --force e --run).
Os dados SMART não indicam nenhum problema com as unidades (e as contagens atuais de setores pendentes e realocados são zero), tentei oguia raid.wiki.kernel.orgvinculado abaixo por Frostschutz através das etapas que envolvem a configuração de dispositivos de sobreposição mapeados.
Eu teria então assumido que a execução do comando a seguir criaria um array raid que eu poderia tentar montar somente leitura e ver se isso resultava em um sistema de arquivos legível ou apenas uma bagunça distorcida (ou seja, para determinar se meu palpite de sdf1 é a paridade a unidade estava correta ou se eu deveria tentar novamente com sde1) - mas em vez disso ele mostra o erro abaixo (também tentei com os dispositivos de loop associados conformeperder-up --lista, com o mesmo resultado).
mdadm --create /dev/md2 --assume-clean --level=5 --chunk=64K --metadata=1.2 --data-offset=261888s --raid-devices=3 faltando /dev/mapper/sdh1 / dev/mapeador/sdf1
mdadm: super1.x cannot open /dev/mapper/sdh1: Device or resource busy
mdadm: /dev/mapper/sdh1 is not suitable for this array.
mdadm: super1.x cannot open /dev/mapper/sdf1: Device or resource busy
mdadm: /dev/mapper/sdf1 is not suitable for this array.
mdadm: create aborted
Além disso, enquantomdadm --detail /dev/md1anteriormente fornecia a saída (mais) abaixo, agora dá:
/dev/md1:
Version : 1.2
Raid Level : raid0
Total Devices : 3
Persistence : Superblock is persistent
State : inactive
Working Devices : 3
Name : bob:1 (local to host bob)
UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Events : 373364
Number Major Minor RaidDevice
- 253 11 - /dev/dm-11
- 253 10 - /dev/dm-10
- 253 9 - /dev/dm-9
Além disso, noteistatus do dmsetupfornece as mesmas informações para todas as três sobreposições e tem um número que parece suspeito, pois pode se referir ao tamanho do array raid original (16 TB) em vez de uma unidade individual (8 TB) - não tem certeza se é como deveria ser?
sde1: 0 15627528888 snapshot 16/16777216000 16
sdh1: 0 15627528888 snapshot 16/16777216000 16
sdf1: 0 15627528888 snapshot 16/16777216000 16
Não tenho certeza de como progredir a partir deste ponto ao tentar criar o dispositivo, montar e inspecionar o sistema de arquivos para confirmar se adivinhei o dispositivo de paridade correto ou não, usando a sobreposição para evitar que algo seja gravado nas unidades reais.
ATUALIZAR: De acordo com a sugestão de Frostschutz abaixo, o array estava de alguma forma em algum tipo de estado onde --stop precisava ser emitido antes de poder fazer qualquer coisa com as unidades subjacentes. Eu havia descartado essa possibilidade anteriormente, poisgato /proc/mdstatestava mostrando o array como inativo, o que eu presumi que significava que não poderia ser o que estava prendendo as unidades, mas esse não era de fato o caso (eu também havia executado --stop anteriormente, mas parece que algo estava feito depois de acionar seu retorno a um estado ininterrupto). Depois de obter a ordem correta da unidade (não na primeira tentativa, feliz por estar usando sobreposições), o array passou em uma verificação fsck sem erros relatados eagora está funcionando como se nada tivesse acontecido.
O resultado da execução de outros comandos de diagnóstico:
gato /proc/mdstat:
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md1 : inactive sdh1[1](S) sde1[3](S) sdf1[0](S)
23440900500 blocks super 1.2
mdadm --detail /dev/md1:
/dev/md1:
Version : 1.2
Raid Level : raid0
Total Devices : 3
Persistence : Superblock is persistent
State : inactive
Working Devices : 3
Name : bob:1 (local to host bob)
UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Events : 373364
Number Major Minor RaidDevice
- 8 113 - /dev/sdh1
- 8 81 - /dev/sdf1
- 8 65 - /dev/sde1
linhas que aparecem no dmesg ao tentarmdadm --assemble /dev/md1:
md/raid:md1: device sdh1 operational as raid disk 1
md/raid:md1: not enough operational devices (2/3 failed)
md/raid:md1: failed to run raid set.
md: pers->run() failed ..
e amdadm --examinaré
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Name : bob:1 (local to host bob)
Creation Time : Mon Mar 4 22:10:29 2019
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 15627267000 (7451.66 GiB 8001.16 GB)
Array Size : 15627266688 (14903.32 GiB 16002.32 GB)
Used Dev Size : 15627266688 (7451.66 GiB 8001.16 GB)
Data Offset : 261888 sectors
Super Offset : 8 sectors
Unused Space : before=261808 sectors, after=312 sectors
State : clean
Device UUID : e856f539:6a1b5822:b3b8bfb7:4d0f4741
Internal Bitmap : 8 sectors from superblock
Update Time : Sun May 30 00:22:45 2021
Bad Block Log : 512 entries available at offset 40 sectors
Checksum : 9b5703bc - correct
Events : 373364
Layout : left-symmetric
Chunk Size : 64K
Device Role : spare
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Name : bob:1 (local to host bob)
Creation Time : Mon Mar 4 22:10:29 2019
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 15627267000 (7451.66 GiB 8001.16 GB)
Array Size : 15627266688 (14903.32 GiB 16002.32 GB)
Used Dev Size : 15627266688 (7451.66 GiB 8001.16 GB)
Data Offset : 261888 sectors
Super Offset : 8 sectors
Unused Space : before=261800 sectors, after=312 sectors
State : clean
Device UUID : 7919e56f:2e08430e:95a4c4a6:1e64606a
Internal Bitmap : 8 sectors from superblock
Update Time : Sun May 30 00:22:45 2021
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : d54ff3e1 - correct
Events : 373364
Layout : left-symmetric
Chunk Size : 64K
Device Role : spare
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Name : bob:1 (local to host bob)
Creation Time : Mon Mar 4 22:10:29 2019
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 15627267000 (7451.66 GiB 8001.16 GB)
Array Size : 15627266688 (14903.32 GiB 16002.32 GB)
Used Dev Size : 15627266688 (7451.66 GiB 8001.16 GB)
Data Offset : 261888 sectors
Super Offset : 8 sectors
Unused Space : before=261800 sectors, after=312 sectors
State : clean
Device UUID : 0c9a8237:7e79a439:d4e35b31:659f3c86
Internal Bitmap : 8 sectors from superblock
Update Time : Sun May 30 00:22:45 2021
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 6ec2604b - correct
Events : 373364
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 1
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
Responder1
Parece estranho. Você pode ter quemdadm --create com sobreposiçõespara este (com deslocamento de dados correto, tamanho do bloco e ordem da unidade). E talvez com a primeira unidade faltando, já que parece ter falhado primeiro...
Basicamente, não há como recuperar por meios convencionais, uma vez que uma unidade nem se lembra mais de sua função de dispositivo. Ambos dizem que são "sobressalentes", então não se sabe se a unidade era a função 0, ou a função 2, ou nada (algumas configurações do raid5 realmente usam peças sobressalentes por algum motivo). Portanto, não está claro se existem dados úteis sobre eles e, em caso afirmativo, em que ordem eles estariam. Você mesmo precisa determinar.
Enquanto você faz isso, verifique também os dados SMART e use ddrescueprimeiro se alguma dessas unidades realmente tiver setores realocados ou pendentes que possam ter contribuído para a falha do ataque.