Eu tenho um backup de todos os dados importantes. No final é necessária uma restauração. Mas quero primeiro tentar algo antes de seguir esse caminho e é uma boa situação para aprender algo sobre todas as coisas que usei aqui.
Eu tenho um controlador mpt sas com 8 canais SATA conectado a duas baias de disco internas de 2,5 "configuradas. Duas delas foram usadas para unidades SSD, que são usadas apenas para armazenar volumes lvm em cache.
6 Discos de 1 TB são usados para partes de dados na partição 3 configurada como um soft array RAID5.
Dois deles foram usados para bootparts na partição 1 e rootparts para partição 2. Ambos os bootparts são um RAID1 simples com ext3 fs. Ambas as partes de inicialização são um RAID1 que é criptografado com luks e possui um lvm vg xenrootdg com vários lvs. Todas as 6 partes de dados são usadas como RAID5 conforme descrito. O volume raid é luks criptografado e nestes um lvm com um vg xendatadg. Somente no volume RAID5 há problemas para ativá-los.
O principal problema foram múltiplas falhas de energia no gabinete de 4 discos que contém 4 dos seis discos de 1 TB. Um novo disco foi adicionado por causa de um disco removido, talvez perto do fim o novo disco tenha sido ressincronizado. Isso não é exatamente conhecido.
Eu poderia iniciar o volume após a primeira falha e iniciar uma ressincronização. Mas o problema ocorre novamente e esses volumes RAID falharam novamente.
No momento da segunda falha, o sistema não conseguiu ler setores de um disco especial e o RAID5 ficou degradado devido a um erro de leitura permanente registrado de algum setor de um dos discos com falha.
Enquanto isso, os discos foram registrados novamente pelo kernel com um novo nome (por exemplo, foram renomeados de sde para sdk e assim por diante).
Após a reinicialização do sistema, verifiquei qual disco foi registrado como falha e os encontrei comparando o número de série. Adicionar o disco a /dev/zero não apresentou nenhum problema, então tentei ressincronizar novamente, mas o mesmo problema ocorre.
Agora percebi que poderia ser um problema com a alimentação do compartimento do disco, então removi todos os discos e pelo menos os conectei nas portas SATA existentes na placa-mãe. Adicionei mais discos ao controlador sas para poder fazer um backup nas partições agora usando dd.
Consegui copiar todas as partições relacionadas para dois novos discos, portanto a leitura não foi um problema.
Também apenas máx. de 3 volumes dentro do lvm vg estava em uso. Portanto, a maioria dos lvs ainda deve estar em estado limpo porque não foi modificado depois que removi o primeiro disco nº 2 (sdl3).
Eu verifiquei o smartctl para que não haja nenhum problema permanente em um disco registrado (nenhum erro irrecuperável e nenhum setor realocado mostrado).
Mas não consigo iniciar o volume RAID5, embora deva haver discos suficientes.
Eu tenho 5 discos (#0,1,3,4,5) e o disco removido ainda existente #2. Além disso, o novo disco de substituição nº 2 está lá, mas é mostrado como sobressalente. Deve ser possível aumentar o volume com #0,1,3,4,5, que são 5 dos 6 volumes disponíveis. Mas tudo o que eu tento, pelo menos o número 3, me causa mais problemas porque nunca é aceito como parte do volume.
Por causa do sdX, o exame pode ser alterado aqui na ordem mostrada da função do dispositivo. Aqui está uma pequena lista do momento:
#0 sdc3 #1 sdk3 #3 sda3 #4 sdg3 #5 sdf3
removido #2 sdl3 novo #2 marcado como #S sdb3
root@newxen:~# mdadm -E /dev/sdc3
/dev/sdc3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : 1142cc76:b224395c:8fb15126:fd1801fe
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 00:02:32 2024
Checksum : bae896cd - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 0
Array State : AARA.A ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdk3
/dev/sdk3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : 701ed2ed:13a03708:da9cc185:9c9ce3e2
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:26:32 2024
Checksum : 223defb1 - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 1
Array State : .A...A ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdl3
/dev/sdl3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : 1b34e8d5:f3df3e52:307a06a0:38c265e4
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jan 15 13:36:40 2024
Checksum : 7023234b - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 2
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sda3
/dev/sda3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x83
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Recovery Offset : 0 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : fa9d44c6:bb18bc8c:04ed5943:13a6ddfb
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 00:02:32 2024
Checksum : 55c99a69 - correct
Events : 243265
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 3
Array State : AAAA.A ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdg3
/dev/sdg3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x8b
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Recovery Offset : 0 sectors
Unused Space : before=260904 sectors, after=1200 sectors
State : clean
Device UUID : 63a171d2:dad103ed:ff18efc4:d31bc05d
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:22:01 2024
Bad Block Log : 512 entries available at offset 72 sectors - bad blocks present.
Checksum : a5b990c1 - correct
Events : 244946
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 4
Array State : .AA.AA ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdf3
/dev/sdf3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : d6e11e48:e1258598:f9d5251c:795c8308
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:26:32 2024
Checksum : c8dc31e3 - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 5
Array State : .A...A ('A' == active, '.' == missing, 'R' == replacing)
Here the replacing disc
root@newxen:~# mdadm -E /dev/sdb3
/dev/sdb3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x9
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 7720024847 (3681.19 GiB 3952.65 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=5810804111 sectors
State : clean
Device UUID : 1be91027:ca00bcc9:7e21dd61:76cdf787
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:26:32 2024
Bad Block Log : 512 entries available at offset 16 sectors - bad blocks present.
Checksum : f892a18d - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : spare
Array State : .A...A ('A' == active, '.' == missing, 'R' == replacing)
Situação agora:
root@newxen:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md128 : inactive sda3[3](S) sdb3[6](S) sdf3[5](S) sdc3[0](S) sdg3[2](S) sdk3[1](S)
8633067263 blocks super 1.2
...
root@newxen:~# mdadm --detail /dev/md128
/dev/md128:
Version : 1.2
Raid Level : raid0
Total Devices : 6
Persistence : Superblock is persistent
State : inactive
Working Devices : 6
Name : newxen:128 (local to host newxen)
UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Events : 248741
Number Major Minor RaidDevice
- 8 163 - /dev/sdk3
- 8 99 - /dev/sdg3
- 8 83 - /dev/sdf3
- 8 35 - /dev/sdc3
- 8 19 - /dev/sdb3
- 8 3 - /dev/sda3
Se eu verificar a data mais recente e o estado da matriz, quero dizer, no início, 15 de janeiro 13:36:40, sdl3 foi configurado com falha e removido (o que fiz manualmente) com AAAAAA, mas deve estar limpo em 16 de janeiro 00:02:32 sda3 com AAAA.A parece limpo em 16 de janeiro 00:02:32 sdc3 com AARA.A parece limpo em 16 de janeiro 10:22:01 sdg3 com .AA.AA parece não estar limpo em 16 de janeiro 10:26:32 sdk3 com .A. ..A parece não estar limpo 16 de janeiro 10:26:32 sdf3 com .A...A parece limpo 16 de janeiro 10:26:32 sdb3 com .A..A parece não estar limpo
Deveria ser possível montar o volume raid com as peças existentes sda3 sdc3 sdg3 sdk3 sdf3 talvez por estar no array sdb3.
Tentei métodos diferentes, mas nenhum deles me trouxe de volta a um volume de ressincronização.
mdadm --assemble --scan --verbose
...
mdadm: /dev/sda3 is identified as a member of /dev/md128, slot 3.
mdadm: /dev/sdl3 is identified as a member of /dev/md128, slot 2.
mdadm: /dev/sdf3 is identified as a member of /dev/md128, slot 5.
mdadm: /dev/sdg3 is identified as a member of /dev/md128, slot 4.
mdadm: /dev/sdk3 is identified as a member of /dev/md128, slot 1.
mdadm: /dev/sdc3 is identified as a member of /dev/md128, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md128, slot -1.
mdadm: ignoring /dev/sdk3 as it reports /dev/sdl3 as failed
mdadm: ignoring /dev/sdf3 as it reports /dev/sdl3 as failed
mdadm: device 12 in /dev/md128 has wrong state in superblock, but /dev/sdb3 seems ok
mdadm: no uptodate device for slot 1 of /dev/md128
mdadm: added /dev/sdl3 to /dev/md128 as 2
mdadm: added /dev/sda3 to /dev/md128 as 3 (possibly out of date)
mdadm: added /dev/sdg3 to /dev/md128 as 4 (possibly out of date)
mdadm: no uptodate device for slot 5 of /dev/md128
mdadm: added /dev/sdb3 to /dev/md128 as -1
mdadm: added /dev/sdc3 to /dev/md128 as 0
mdadm: /dev/md128 assembled from 2 drives and 1 spare - not enough to start the array.
...
root@newxen:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md128 : inactive sdf3[5](S) sdb3[6](S) sdc3[0](S) sdk3[1](S) sdg3[2](S) sdl3[4](S)
8633067263 blocks super 1.2
...
root@newxen:~# mdadm --detail /dev/md128
/dev/md128:
Version : 1.2
Raid Level : raid0
Total Devices : 6
Persistence : Superblock is persistent
State : inactive
Working Devices : 6
Name : newxen:128 (local to host newxen)
UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Events : 248741
Number Major Minor RaidDevice
- 8 179 - /dev/sdl3
- 8 163 - /dev/sdk3
- 8 99 - /dev/sdg3
- 8 83 - /dev/sdf3
- 8 35 - /dev/sdc3
- 8 19 - /dev/sdb3
Portanto, parece que o antigo sdl3 removido e substituído pelo sdb3 causa alguns problemas. Então parei o md128 novamente e tentei ativá-lo manualmente sem eles:
root@newxen:~# mdadm --assemble /dev/md128 /dev/sdc3 /dev/sdk3 /dev/sda3 /dev/sdg3 /dev/sdf3 --verbose
mdadm: looking for devices for /dev/md128
mdadm: /dev/sdc3 is identified as a member of /dev/md128, slot 0.
mdadm: /dev/sdk3 is identified as a member of /dev/md128, slot 1.
mdadm: /dev/sda3 is identified as a member of /dev/md128, slot 3.
mdadm: /dev/sdg3 is identified as a member of /dev/md128, slot 4.
mdadm: /dev/sdf3 is identified as a member of /dev/md128, slot 5.
mdadm: ignoring /dev/sdk3 as it reports /dev/sdc3 as failed
mdadm: ignoring /dev/sdg3 as it reports /dev/sdc3 as failed
mdadm: ignoring /dev/sdf3 as it reports /dev/sdc3 as failed
mdadm: no uptodate device for slot 1 of /dev/md128
mdadm: no uptodate device for slot 2 of /dev/md128
mdadm: added /dev/sda3 to /dev/md128 as 3 (possibly out of date)
mdadm: no uptodate device for slot 4 of /dev/md128
mdadm: no uptodate device for slot 5 of /dev/md128
mdadm: added /dev/sdc3 to /dev/md128 as 0
mdadm: /dev/md128 assembled from 1 drive - not enough to start the array.
root@newxen:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md128 : inactive sdk3[1](S) sdf3[5](S) sdg3[2](S) sdc3[0](S)
3818443872 blocks super 1.2
...
root@newxen:~# mdadm --detail /dev/md128
/dev/md128:
Version : 1.2
Raid Level : raid0
Total Devices : 4
Persistence : Superblock is persistent
State : inactive
Working Devices : 4
Name : newxen:128 (local to host newxen)
UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Events : 248741
Number Major Minor RaidDevice
- 8 163 - /dev/sdk3
- 8 99 - /dev/sdg3
- 8 83 - /dev/sdf3
- 8 35 - /dev/sdc3
Então eu me pergunto se sda3 não é mostrado nos detalhes.
Tentei também usar sdl3 em vez de sdb3 e tentei adicionar novamente as partes que faltavam, mas nada realmente ajudou. Então acho que devo zerar os superblocos e recriar o ataque com a opção --assume-clean. Na minha opinião, deveria estar na ordem correta. Na melhor das hipóteses, talvez devesse estar sem sdb3 e sdl3 porque não tenho certeza se o sdb3 já chegou ao estado de sincronização antes do primeiro problema ocorrer. Existe uma maneira de verificar isso?
Então, se não existir outra opção, eu faria (esta ordem está correta?)
mdadm --create --verbose --force --assume-clean /dev/md128 --level=5 --raid-devices=6 /dev/sdc3 /dev/sdk3 missing /dev/sda3 /dev/sdg3 /dev/sdf3
Outra solução poderia ser presumir que o disco sdb3 está quase sincronizado.
mdadm --create --verbose --force --assume-clean /dev/md128 --level=5 --raid-devices=6 /dev/sdc3 /dev/sdk3 /dev/sdb3 /dev/sda3 /dev/sdg3 /dev/sdf3
Como posso verificar?:
echo check >> /sys/block/md128/md/sync_action and then check dmesg carefully?
Outra coisa que gostaria de saber é em que sectores devo estar preparado para problemas depois de concluída a reconstrução? Alguma sugestão de como posso identificá-los?
Adicionados mais detalhes: é difícil encontrar informações detalhadas. Portanto, seria bom se alguém pudesse confirmar ou corrigir minhas ideias.
Enquanto isso, os testes de descriptografia devem ser concluídos. Nenhuma permutação da ordem dos dispositivos precisa ser bem trabalhada.
Portanto, foi possível colocar o array RAID em funcionamento pela maneira como os dados em si parecem ainda misturados e ainda inutilizáveis. Por causa disso, não posso descriptografar os dados luks neles no momento.