Eu tinha uma matriz raid5 em / dev / md0 criada com o mdadm e estava funcionando bem por cerca de um ano. Consistia em três HDDs de 1 TB cada. Alguns dias atrás, houve uma falha de energia e falha no no-break. Não foi a primeira vez, infelizmente.
O sistema operacional está em um disco SSD separado ( / dev / sda ) que não faz parte do array raid, então é inicializado, mas não pode mais montar o array. Às vezes, / dev / md0 não existe. Também fiz algo que poderia piorar as coisas. Eu corri fsck /dev/sdb -y , que escreveu muitas e muitas vezes no disco.
Eu tenho medo de não recuperar meus arquivos. Você pode me ajudar a resolver esse problema?
Obrigado.
monte / dev / md0 / mnt / raid5
mount: /dev/md0: can't read superblock
syslog:
Feb 25 15:59:53 pve kernel: [ 365.559378] EXT4-fs (md0): unable to read superblock
Feb 25 15:59:53 pve kernel: [ 365.560118] EXT4-fs (md0): unable to read superblock
Feb 25 15:59:53 pve kernel: [ 365.560216] EXT4-fs (md0): unable to read superblock
Feb 25 15:59:53 pve kernel: [ 365.560310] FAT-fs (md0): unable to read boot sector
cat / proc / mdstat
Personalities : [raid6] [raid5] [raid4]
unused devices: <none>
fdisk -l
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x75633c0d
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 1950353407 1950351360 930G fd Linux raid autodetect
Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F397C12B-1549-45EA-97EA-6A41B713B58F
Device Start End Sectors Size Type
/dev/sdc1 2048 1950353407 1950351360 930G Linux RAID
Disk /dev/sdd: 931.5 GiB, 1000203804160 bytes, 1953523055 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcced27e3
Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 1950353407 1950351360 930G fd Linux raid autodetect
às vezes fdisk -l
-bash: /sbin/fdisk: Input/output error
syslog:
Feb 25 16:03:25 pve kernel: [ 577.221547] ata1.00: SRST failed (errno=-16)
Feb 25 16:03:25 pve kernel: [ 577.232569] ata1.00: reset failed, giving up
Feb 25 16:03:25 pve kernel: [ 577.232640] ata1.00: disabled
Feb 25 16:03:25 pve kernel: [ 577.232643] ata1.01: disabled
Feb 25 16:03:25 pve kernel: [ 577.232658] ata1: EH complete
Feb 25 16:03:25 pve kernel: [ 577.232683] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 25 16:03:25 pve kernel: [ 577.232697] sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 05 13 a0 38 00 00 08 00
Feb 25 16:03:25 pve kernel: [ 577.232702] blk_update_request: I/O error, dev sda, sector 85172280
Feb 25 16:03:25 pve kernel: [ 577.232784] Buffer I/O error on dev dm-6, logical block 9255, lost sync page write
Feb 25 16:03:25 pve kernel: [ 577.232928] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 25 16:03:25 pve kernel: [ 577.232936] sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 02 88 6a 10 00 00 68 00
Feb 25 16:03:25 pve kernel: [ 577.232941] blk_update_request: I/O error, dev sda, sector 42494480
Feb 25 16:03:25 pve kernel: [ 577.232948] EXT4-fs error (device dm-6): kmmpd:176: comm kmmpd-dm-6: Error writing to MMP block
sudo mdadm --examine / dev / sdb1
mdadm: No md superblock detected on /dev/sdb1.
sudo mdadm --examine / dev / sdc1
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 34c11bda:11bbb8c9:c4cf5f56:7c38e1c3
Name : pve:0
Creation Time : Sun Jun 5 21:06:33 2016
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 1950089216 (929.88 GiB 998.45 GB)
Array Size : 1950089216 (1859.75 GiB 1996.89 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : active
Device UUID : be76ecf7:b0f28a7d:718c3d58:3afae9f7
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Feb 20 14:48:51 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : ffbc1988 - correct
Events : 2901112
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
sudo mdadm --examine / dev / sdd1
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x9
Array UUID : 34c11bda:11bbb8c9:c4cf5f56:7c38e1c3
Name : pve:0
Creation Time : Sun Jun 5 21:06:33 2016
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 1950089216 (929.88 GiB 998.45 GB)
Array Size : 1950089216 (1859.75 GiB 1996.89 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : active
Device UUID : 7b9ed6e0:ffad7603:b226e752:355765a8
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Feb 20 14:48:51 2017
Bad Block Log : 512 entries available at offset 72 sectors - bad blocks present.
Checksum : 19b6f3da - correct
Events : 2901112
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
Obrigado a todos por ter recuperado os dados.
Corri sudo mdadm --verbose --assemble --force /dev/md0 /dev/sdc1 /dev/sdd1 para montar o array dos dois HDDs restantes e funcionou!
Em seguida, gravei o sdb e adicionei-o novamente à matriz com sudo mdadm --manage /dev/md0 --add /dev/sdb1 e vou comprar um novo para substituí-lo em breve. Também estou procurando soluções de backup.
Se você deu erros de entrada / saída, eu acho que você tem um ou mais discos defeituosos. Você precisa verificar os atributos SMART de todos os discos pelo comando smartctl -a /dev/sdx . Verifique status e Update Time de cada disco pelo comando mdadm --examine /dev/sdx1 . Escolha um disco pior que tenha mais atributos inteligentes ruins e o mais antigo Update Time e remova-o do array.
Se você tem dois discos defeituosos, você precisa escolher menos disco ruim e ele deve ser recuperado para o novo disco pelo programa ddrecovery . Remova este disco defeituoso e insira o novo disco recuperado no mesmo local.
Em seguida, você poderá restaurar o array RAID 5 com um disco perdido (por exemplo sdc ) pelo comando:
mdadm --verbose --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 missing /dev/sdd1
Certifique-se de que o parâmetro chunk seja o mesmo dos discos bons.
Além disso, você tem um disco sda ruim, que não é um membro da matriz RAID 5.
Seja cuidadosamente com cada comando. Há apenas uma maneira de restaurar sua matriz RAID.
Leia este pelo exemplo.
A execução do fsck foi a ideia certa, mas acho que você o executou no dispositivo errado. Tente executar o fsck em / dev / md0 usando um superbloco de backup. Este link lhe dará algumas dicas sobre como encontrar o backup e o reparo quando Você faz. Em particular, executar dumpe2fs é sua melhor aposta para encontrar o tamanho do bloco do sistema de arquivos. Mesmo que o primeiro backup esteja corrompido, o ext4 terá criado outros.
Você tem vários problemas.
Primeiro, você diz que / dev / sda é o disco do seu sistema, não faz parte de um array RAID, com o sistema operacional nele. Bem, veja o snippet exato do syslog que você nos mostrou:
Feb 25 16:03:25 pve kernel: [ 577.232702] blk_update_request: I/O error, dev sda, sector 85172280
Feb 25 16:03:25 pve kernel: [ 577.232941] blk_update_request: I/O error, dev sda, sector 42494480
Dois erros de E / S durante gravações, relatados em um milissegundo um do outro, em dois locais diferentes, no disco do sistema. Seu disco do sistema está tendo sérios problemas; obtê-lo substituído imediatamente . Pode valer a pena substituir o cabeamento também, enquanto você está nisso. Na minha experiência, os erros de E / S são geralmente indicativos de problemas de cabeamento ou de disco (embora o HBA possa estar com falha). Espera que os dados no disco do sistema sejam corrompidos, pelo menos em algum grau, como resultado desse problema.
Em segundo lugar, fsck /dev/sdb -y muito provavelmente rabiscou todos os seus dados RAID na tentativa de compreender os dados parciais do sistema de arquivos e escrever automaticamente o que acha que parecia certo. Eu sugeriria fisicamente desconectar esse disco, removê-lo do sistema e colocá-lo em algum lugar seguro por enquanto. Trate-a como morta.
Felizmente, você tem sorte; o sistema ainda está falando com todos os três discos, e os metadados parecem sadios nos dois discos dos três que ainda contêm metadados md.
Pegue três novos discos e use ddrescue para copiar tudo que puder dos dois discos restantes para dois novos. Desconecte os discos antigos e configure-os com o que costumava ser / dev / sdb (certifique-se de controlar qual disco é qual), e conecte os dois novos discos junto com o terceiro novo, em branco, um.
Alimente a matriz resultante ao mdadm e ore a sua divindade escolhida para que o md possa entender a situação resultante. Se você tiver sorte, será capaz de restaurar a maioria dos dados para condições legíveis agora que não há erros de leitura (desde que você trouxe novos discos). Mais uma vez, pode haver alguma corrupção em alguns lugares.
Terceiro, descubra o que causou a falha da UPS e corrija-a, e configure backups regulares para que, se o pior acontecer, pelo menos você tenha um backup que possa ser restaurado na nova mídia. Considere este incidente como uma experiência de aprendizado ilustrando por que o RAID não é um backup .
Tags mdadm