O que foi: RAID 1 com mdadm em discos inteiros, digamos / dev / md0 de / dev / sda e sdb, GPT com uma partição em md0 e ext4 nesta partição (md0p1).
O que eu acho que acontece: depois de mudar a placa-mãe, o linux detecta problemas com o ext4 no md0p1.
Eu corro fsck em md0p1 e digo "sim" para todas as perguntas. Foram algumas somas de cheques ruins, muitas árvores podem ser mais estreitas e algumas revistas não vazias.
Parece terminar com sucesso e eu tento montar / dev / md0p1 mas tenho o mesmo erro sobre o sistema de arquivos ruim.
Eu corro fsck em md0p1 novamente, mas agora ele diz "no superblock" e números de superblocos alternativos não ajudam.
Eu reinicio e agora o mdadm não consegue encontrar o superbloco em sda e sdb. A partição GPT ainda está bem, mas não há sinais de ext4 em ambos os discos encontrados pelo testdisck (somente dados ms).
# fdisk -l
GPT PMBR size mismatch (3907028991 != 3907029167) will be corrected by w(rite).
Disk /dev/sda: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D09686A6-2428-48EC-868B-D3C8CE5E0C23
Device Start End Sectors Size Type
/dev/sda1 34 3907024064 3907024031 1,8T Microsoft basic data
Partition 1 does not start on physical sector boundary.
...
GPT PMBR size mismatch (3907028991 != 3907029167) will be corrected by w(rite).
Disk /dev/sde: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D09686A6-2428-48EC-868B-D3C8CE5E0C23
Device Start End Sectors Size Type
/dev/sde1 34 3907024064 3907024031 1,8T Microsoft basic data
Partition 1 does not start on physical sector boundary.
.
# mdadm --examine /dev/sd*
/dev/sda:
MBR Magic : aa55
Partition[0] : 3907028991 sectors at 1 (type ee)
mdadm: No md superblock detected on /dev/sda1.
...
/dev/sde:
MBR Magic : aa55
Partition[0] : 3907028991 sectors at 1 (type ee)
mdadm: No md superblock detected on /dev/sde1.
.
gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): D09686A6-2428-48EC-868B-D3C8CE5E0C23
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 8-sector boundaries
Total free space is 5070 sectors (2.5 MiB)
Number Start (sector) End (sector) Size Code Name
1 34 3907024064 1.8 TiB 0700
Command (? for help): i
Using 1
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: E11B0DE3-9ABD-47B2-9F09-E993F76FBC6F
First sector: 34 (at 17.0 KiB)
Last sector: 3907024064 (at 1.8 TiB)
Partition size: 3907024031 sectors (1.8 TiB)
Attribute flags: 0000000000000000
Partition name: ''
Então, minhas perguntas:
- é uma chance de recuperar o sistema de arquivos? Eu posso recuperar alguns arquivos acima de tudo, mas é 2 TB de lixo e muito poucos arquivos valiosos, por isso não tem sentido sem pelo menos nomes de arquivos.
- mais importante: o que estava errado? parece que fiz tudo o que foi sugerido (exceto sem backup) e perdi meus dados.
Porque a situação é estranha eu vou contar toda a história:
linux roda em SSD e a maioria dos dados (incluindo o diretório home) vive em RAID em 2 HDDs.
O RAID funciona bem desde 2011 ou 2012.
6-8 meses atrás eu atualizei o computador: mude o processador de 2 para 8 núcleos, adicione RAM e insira SSD para Windows.
Depois que este computador acabou de ligar a partir da primeira tentativa, tive que pressionar o botão de reinicialização 1-2 em 10 a 20 segundos para ligá-lo. Mas todos os outros sistemas funcionam bem.
1-2 meses atrás 2 vezes todas as aplicações começam a travar e vejo erros io no console, mas depois de reiniciar tudo funciona bem.
1 mês atrás um kubuntu atualizado para o último lançamento.
Há 2 semanas coisas ruins
o linux não iniciará - algum erro no SSD. Eu comprei outro SSD, consegui salvar a maior parte do sistema de arquivos pelo ddrescue, mas ele não iria iniciar, então eu instalo o novo OS na partição vazia no SSD. ele monta o RAID após instalar o mdadm, mas não adicionaria a partição ao / dev: era / dev / md127, mas não o md127p1. Eu fixo tabela GPT em md127 por gdisck seguiu sugestões (ele tem boa tabela GTP principal) e alinhar tabela de backup GTP que estava corrompido. fsck em md127p1 (mudou para md0p1) estava bem, eu montar com sucesso.
Funciona um ou dois dias, depois o computador se recusou a iniciar de qualquer maneira.
Eu consegui almoçar BIOS uma vez e não havia dispositivos IDE, então eu comprei uma nova placa-mãe (a antiga era asrock 900FX Extreme3, nova gigabyte 970-DS3P).
Após a mudança da placa-mãe eu executo o linux, ele inicia no modo de recuperação (/ dev / md0p1 tem problemas com o sistema de arquivos) e então foi o que escrevi no começo da minha pergunta.
O que foi feito de errado?
1. sem backup - claro. Agora eu entendi que o RAID não é um backup.
2. ignorar erros de IO? Ele trava meu SSD com o sistema, então é só rodar para instalar um novo sistema.
3. é má ideia ter partições dentro do RAID? É melhor montar o raid de sda1 e sdb1 e depois de sda e sdb?
adição:
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1,8T 0 disk <-- raid
└─sda1 8:1 0 1,8T 0 part
sdb 8:16 1 957,9M 0 disk
└─sdb1 8:17 1 956,9M 0 part
sdc 8:32 0 59,6G 0 disk
├─sdc1 8:33 0 1M 0 part
├─sdc2 8:34 0 29,8G 0 part /old
└─sdc3 8:35 0 29,8G 0 part /
sdd 8:48 0 119,2G 0 disk
└─sdd1 8:49 0 119,2G 0 part
sde 8:64 0 1,8T 0 disk <-- raid
└─sde1 8:65 0 1,8T 0 part
sr0 11:0 1 2G 0 rom