E então, aconteceu: o software RAID5 na minha caixa de Linux falhou de alguma forma e agora se recusa a montar.
Uma visão geral da configuração:
/dev/sda é particionado para /boot/efi , swap e / (nessa ordem) /dev/sdb é membro do RAID (sem tabela de partições) /dev/sd[cd] tem uma única partição abrangendo toda a unidade, com sd[cd]1 sendo membro do RAID sda é 500 GB, sd[bcd] são discos de 4 TB. sd[cd]1 são particionados para o mesmo tamanho exato, sdb não sendo particionado é um pouco maior (desperdiçando algum espaço, que de outra forma seria usado para a tabela de partições). /dev/md0 , o RAID é particionado com uma única partição /dev/md0p1 abrangendo todo o disco múltiplo, que então mantém o sistema de arquivos BTRFS. (Isso foi configurado pelo instalador do Debian, e é tarde demais para mudar.) Eu comprei recentemente um quinto disco, que estava morto na chegada. Eu tive que deixar o site logo após adicionar o disco ao servidor, então eu notei esse fato não até um ou dois dias depois, mas como este novo disco não fazia parte do RAID ainda, isso não deve mudar nada.
Quando adicionei o disco recém-comprado, o servidor estava executando o kernel 4.8.7 e tudo parecia bem. Eu compilei a versão 4.8.8 do kernel e instalei, fechei o servidor com systemctl poweroff , removi o disco morto e tentei reinicializar. Como o servidor é geralmente sem cabeça, eu só pude vê-lo não voltando depois de cerca de 5 minutos de tempo de graça. Ele não reagiria ao simples pressionamento do botão liga / desliga, então eu cortei a energia, adicionei uma placa de vídeo (não tem uma interna) + monitor + teclado e foi subseqüentemente apresentado com o escudo de emergência do systemd .
Eu recebo o shell de emergência com o kernel anterior e o atual, então presumo que isso não seja a causa ou o dano já esteja feito. Atualmente estou dd ing todos os três discos RAID em /dev/null para descartar possíveis falhas de disco físico, mas como eles já estão acima de 1TB nos discos sem nenhum erro, eu assumo que o superbloco não está fisicamente danificado em nenhum dos discos. discos.
Basta falar, vamos ser mais específico. Todos os comandos a seguir são emitidos a partir do shell raiz de emergência, ou seja, com um sistema básico em execução (não o initrd).
/proc/mdstat não sabe nada sobre o RAID:
Personalities : [raid6] [raid5] [raid4]
unused devices: <none>
Isso é o que recebo com mdadm --assemble --verbose /dev/md0 : ( /dev/sde aqui é um HDD USB externo que usei para extrair esses logs)
mdadm: looking for devices for /dev/md0
mdadm: no RAID superblock on /dev/sde1
mdadm: no RAID superblock on /dev/sde
mdadm: no RAID superblock on /dev/sdd
mdadm: no RAID superblock on /dev/sdc
mdadm: no RAID superblock on /dev/sda3
mdadm: no RAID superblock on /dev/sda2
mdadm: no RAID superblock on /dev/sda1
mdadm: no RAID superblock on /dev/sda
mdadm: /dev/sdd1 is identified as a member of /dev/md0, slot 2.
mdadm: /dev/sdc1 is identified as a member of /dev/md0, slot 1.
mdadm: /dev/sdb is identified as a member of /dev/md0, slot 0.
mdadm: failed to add /dev/sdc1 to /dev/md0: Invalid argument
mdadm: failed to add /dev/sdd1 to /dev/md0: Invalid argument
mdadm: added /dev/sdb to /dev/md0 as 0
mdadm: failed to RUN_ARRAY /dev/md0: Input/output error
... com essas linhas em journalctl :
Nov 18 14:56:34 zoey kernel: md: sdc1 does not have a valid v1.2 superblock, not importing!
Nov 18 14:56:34 zoey kernel: md: md_import_device returned -22
Nov 18 14:56:34 zoey kernel: md: sdd1 does not have a valid v1.2 superblock, not importing!
Nov 18 14:56:34 zoey kernel: md: md_import_device returned -22
Nov 18 14:56:34 zoey kernel: md: bind<sdb>
Nov 18 14:56:34 zoey kernel: md/raid:md0: device sdb operational as raid disk 0
Nov 18 14:56:34 zoey kernel: md/raid:md0: allocated 3316kB
Nov 18 14:56:34 zoey kernel: md/raid:md0: not enough operational devices (2/3 failed)
Nov 18 14:56:34 zoey kernel: RAID conf printout:
Nov 18 14:56:34 zoey kernel: --- level:5 rd:3 wd:1
Nov 18 14:56:34 zoey kernel: disk 0, o:1, dev:sdb
Nov 18 14:56:34 zoey kernel: md/raid:md0: failed to run raid set.
Nov 18 14:56:34 zoey kernel: md: pers->run() failed ...
Nov 18 14:56:34 zoey kernel: md: md0 stopped.
Nov 18 14:56:34 zoey kernel: md: unbind<sdb>
Nov 18 14:56:34 zoey kernel: md: export_rdev(sdb)
Ah não, o superbloco está quebrado, e até mdadm --assemble --force não vai montar! Vamos ver o que o mdadm --examine tem a dizer:
/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : cdab20e2:45150011:f10d83fe:f0299188
Name : zoey:0 (local to host zoey)
Creation Time : Fri Sep 26 17:23:15 2014
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 7813840560 (3725.93 GiB 4000.69 GB)
Array Size : 7813770240 (7451.79 GiB 8001.30 GB)
Used Dev Size : 7813770240 (3725.90 GiB 4000.65 GB)
Data Offset : 196608 sectors
Super Offset : 8 sectors
Unused Space : before=196520 sectors, after=70320 sectors
State : clean
Device UUID : 1751c53f:c527c4cd:10e8f426:0217bf5e
Update Time : Fri Nov 18 04:02:16 2016
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 7fa86509 - correct
Events : 112125
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : cdab20e2:45150011:f10d83fe:f0299188
Name : zoey:0 (local to host zoey)
Creation Time : Fri Sep 26 17:23:15 2014
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 7813902336 (3725.96 GiB 4000.72 GB)
Array Size : 7813770240 (7451.79 GiB 8001.30 GB)
Used Dev Size : 7813770240 (3725.90 GiB 4000.65 GB)
Data Offset : 196608 sectors
Super Offset : 8 sectors
Unused Space : before=196528 sectors, after=66560 sectors
State : clean
Device UUID : 0c60e19b:daff087f:c1f09dbb:41bb80c3
Update Time : Fri Nov 18 04:02:16 2016
Checksum : 866cea0a - correct
Events : 112125
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : cdab20e2:45150011:f10d83fe:f0299188
Name : zoey:0 (local to host zoey)
Creation Time : Fri Sep 26 17:23:15 2014
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 7813902336 (3725.96 GiB 4000.72 GB)
Array Size : 7813770240 (7451.79 GiB 8001.30 GB)
Used Dev Size : 7813770240 (3725.90 GiB 4000.65 GB)
Data Offset : 196608 sectors
Super Offset : 8 sectors
Unused Space : before=196528 sectors, after=66560 sectors
State : clean
Device UUID : e80a2296:dfadb7ad:e458e491:bf1d12b0
Update Time : Fri Nov 18 04:02:16 2016
Checksum : 72340d8d - correct
Events : 112125
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : AAA ('A' == active, '.' == missing, 'R' == replacing)
mdadm --examine --scan --verbose também parece encontrar todos os discos bem:
ARRAY /dev/md/0 level=raid5 metadata=1.2 num-devices=3 UUID=cdab20e2:45150011:f10d83fe:f0299188 name=zoey:0
devices=/dev/sdd1,/dev/sdc1,/dev/sdb
Esta linha também pode ser encontrada no mdadm.conf que o instalador do Debian gerou para mim, quando eu instalei o sistema operacional pela primeira vez (eu não alterei este arquivo manualmente, já que tudo estava funcionando bem por tanto tempo):
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 UUID=cdab20e2:45150011:f10d83fe:f0299188 name=zoey:0
# This file was auto-generated on Fri, 26 Sep 2014 18:10:27 +0200
# by mkconf 3.2.5-5
A SMART também diz que está tudo bem com todos os discos, com exceção de /dev/sdc ter visto uma alta taxa de fluxo de ar em In_The_Past - mas os problemas de temperatura foram resolvidos e todos os outros valores (setores mais realocados / pendentes) = 0) estão dentro das margens aceitáveis para todas as unidades.
Eu tentei recriar o RAID em device mapper sobreposições nos dispositivos de bloco físico. No entanto, essa configuração não reconheceria a tabela de partição dentro do RAID, impossibilitando a montagem do sistema de arquivos. Você pode encontrar um texto datilografado aqui
E é aí que estou perdido. O RAID inteiro parece bem para mim, então por que o driver md se recusou a montar? E há algo que eu possa tentar que possa melhorar minhas chances de sucesso?
A solução estupidamente simples: adicione --update=devicesize ao montar.
Eu não tenho ideia de como, mas aparentemente o tamanho da partição e o tamanho que md lembrava para essa unidade não combinavam mais. Felicidades para os caras no fórum ubuntuusers alemão que resolveu meticulosamente o caso com manual edição hexadecimal antes de finalmente encontrar a opção correta para mdadm .
Tags data-recovery debian raid