Obrigado por ler este tópico e agradeço antecipadamente por qualquer ajuda que você possa fornecer.
Então foi isso que aconteceu ... Eu notei que meu array MDADM RAID 5 com drives ordenou: / dev / sd [EFGHIABCDKJ] 1 relatou um drive com falha - / dev / sdb1. Eu parei o array e executei smartctl -t long / dev / sdb1 e recebi um passe.
Então eu adicionei o / dev / sdb1 de volta ao / dev / md0 com o mdadm --add. No processo de reconstrução, / dev / sdh1 ficou offline (o cabo de dados deve ter sido solto enquanto eu estava movendo de FL para MI) e agora o estado da matriz está degradado. Eu verifiquei as duas unidades usando o smartctl novamente e recebi 2 passagens.
Eu li conselhos em algum fórum sobre o uso de mdadm -C / dev / md0 / dev / sd [efghiabcdkj] 1, mas a matriz ressincronizada com a ordem de unidade desarrumada (sd [abcdefghijk] 1 em oposição a sd [efghiabcdkj] 1 ). Tentei mdadm -Af / dev / md0 mas recebi uma mensagem de erro de superbloco ausente.
Entrei em outro post dizendo que eu deveria fazer o mdadm -C --assumir-clean / dev / md0 / dev / sd [efigia MISSING cdkj] 1 e depois adicionar / dev / sdb1 e depois mdadm --assemble / dev / md0 --resync = update mas eu tinha um flashdrive plugado no meu servidor que foi atribuído / dev / sdi1 (OPPS) ... Enfim, eu puxei o plugue rapidamente, parei o sistema, removi o pen drive e repeti os passos. / p>
================================================================================ fdisk -l reports: Disk /dev/hda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 3187 25599546 7 HPFS/NTFS /dev/hda2 3188 60801 462784455 5 Extended /dev/hda5 3188 9561 51199123+ 7 HPFS/NTFS /dev/hda6 9562 28045 148472698+ 83 Linux /dev/hda7 28046 28835 6345643+ 82 Linux swap / Solaris /dev/hda8 28836 60801 256766863+ 83 Linux Disk /dev/sda: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 182402 1465138552+ 83 Linux Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 182402 1465138552+ fd Linux raid autodetect Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdc1 * 1 182402 1465138552+ 83 Linux Disk /dev/sdd: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdd1 * 1 182402 1465138552+ 83 Linux Disk /dev/sde: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sde1 * 1 182401 1465136001 83 Linux Disk /dev/sdf: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdf1 * 1 182401 1465136001 83 Linux Disk /dev/sdg: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdg1 * 1 182401 1465136001 83 Linux Disk /dev/sdh: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdh1 * 1 182401 1465136001 83 Linux Disk /dev/sdi: 1500.3 GB, 1500301910016 bytes 16 heads, 63 sectors/track, 2907021 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System /dev/sdi1 * 1 2907021 1465138552+ 83 Linux Disk /dev/sdj: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdj1 * 1 182402 1465138552+ 83 Linux Disk /dev/sdk: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdk1 * 1 182402 1465138552+ 83 Linux Disk /dev/md0: 0 MB, 0 bytes 2 heads, 4 sectors/track, 0 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk /dev/md0 doesn't contain a valid partition table ================================================================================
Então eu estou supondo que eu inserir o flashdrive bagunçou o número de cabeças em todas as outras unidades, exceto a unidade que não foi atribuída o primeiro mdadm -C porque sua atribuição foi tomada pelo flashdrive.
Portanto, a linha final é ... agora a ressincronização está concluída (o diskstats mostra as leituras, mas não as gravações no disco) e eu não consigo montar o array. Eu recebo uma mensagem "VFS: Não é possível encontrar o sistema de arquivos ext3 no dev md0".
Status atual: o R-Studio relata alguns dados, o testdisk ainda está analisando minha partição, abortei o Raid Reconstructor fazendo com que os relatórios demorassem 20 dias para serem concluídos ...
Alguma sugestão de como posso recuperar meus dados? Quaisquer sugestões que você possa oferecer serão muito apreciadas, pois estou iniciando um novo emprego e não posso me dar ao luxo de parecer desorganizado, apesar da má execução dos eventos na semana passada. Obrigado ... J
eu tive um caso parecido e acabei de usar o comando exatamente com o mesmo parâmetro que usei para criar o raid com o parâmetro --assume-clean e isso funcionou para mim
a ordem do disco é vital se as letras da sua unidade (sd [a-l]) ficarem confusas, por ex. meu unpluggin e repluggin em ordem diferente, você pode usar
mdadm -E /dev/sd[a-l]1
para examinar o número "RaidDevice". isso informa a ordem na qual especificar os discos quando invocar mdadm -C ...
Anteriormente, tive problemas semelhantes com a mesma configuração. md RAIDs parecem ser muito robustos. Recriei meu RAID várias vezes com as unidades na ordem incorreta e observei o mesmo erro que você faz todas as vezes. A ordem original das unidades foi perdida devido a uma tentativa de recuperação anterior com falha.
Mas você pode tentar recriar o RAID com uma ordem diferente até que finalmente acerte. Embora com esse número de unidades, você pode levar muito tempo para encontrar a ordem correta.
Uma das coisas mais importantes que aprendi com esse desastre é que os nomes das unidades (sda, sdb, ...) podem mudar. Como quando eu substituí uma unidade, os nomes de todas as outras unidades também mudaram. Isso levou a muita confusão. Uma das etapas mais importantes é obter os números de série das unidades com smartctl e observar quais nomes são atribuídos a quais unidades. Isso deve ajudar a evitar confusão durante o processo de recuperação.
Demorei vários dias para recuperar meus dados e já tinha praticamente desistido de receber algo de volta. Mas finalmente consegui a ordem correta do driver e o RAID foi montado corretamente e tudo estava intacto. Nunca desista de recuperar um md RAID.
Tags data-recovery raid5