Gente por favor me ajude - eu sou um novato com uma grande dor de cabeça na mão (situação perfeita de tempestade).
Eu tenho um disco rígido de 3 TB no meu ubuntu 11.04 configurado como invasão de software 5. Os dados foram copiados semanalmente em outro disco separado do disco rígido do computador até que isso falhou completamente e foi jogado fora. Alguns dias atrás, tivemos uma queda de energia e, após a reinicialização, minha caixa não montou o ataque. Na minha infinita sabedoria entrei
mdadm --create -f...
comando em vez de
mdadm --assemble
e não percebeu a farsa que eu havia feito até depois. Iniciou a matriz degradada e prosseguiu com a construção e sincronização, o que levou cerca de 10 horas. Depois que voltei, vi que o array estava funcionando com êxito, mas o ataque não é
Quero dizer, as unidades individuais estão particionadas (tipo de partição f8), mas o md0dispositivo não está. Percebendo horrorizado o que fiz, estou tentando encontrar algumas soluções. Apenas rezo para que --createnão sobrescreva todo o conteúdo do driver rígido.
Alguém poderia me ajudar com isso - os dados que estão no disco são muito importantes e únicos ~ 10 anos de fotos, documentos, etc.
É possível que especificar os discos rígidos participantes na ordem errada possa mdadmsubstituí-los? quando eu faço
mdadm --examine --scan
Eu recebo algo como ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0
Curiosamente, o nome costumava ser 'raid' e não o host hame com: 0 anexado.
Aqui estão as entradas de configuração 'higienizadas':
DEVICE /dev/sdf1 /dev/sde1 /dev/sdd1
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST <system>
MAILADDR root
ARRAY /dev/md0 metadata=1.2 name=tanserv:0 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b
Here is the output from mdstat
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[0] sdf1[3] sde1[1]
1953517568 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
fdisk shows the following:
fdisk -l
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bf62e
Device Boot Start End Blocks Id System
/dev/sda1 * 1 9443 75846656 83 Linux
/dev/sda2 9443 9730 2301953 5 Extended
/dev/sda5 9443 9730 2301952 82 Linux swap / Solaris
Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000de8dd
Device Boot Start End Blocks Id System
/dev/sdb1 1 91201 732572001 8e Linux LVM
Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00056a17
Device Boot Start End Blocks Id System
/dev/sdc1 1 60801 488384001 8e Linux LVM
Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ca948
Device Boot Start End Blocks Id System
/dev/sdd1 1 121601 976760001 fd Linux raid autodetect
Disk /dev/dm-0: 1250.3 GB, 1250254913536 bytes
255 heads, 63 sectors/track, 152001 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/dm-0 doesn't contain a valid partition table
Disk /dev/sde: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x93a66687
Device Boot Start End Blocks Id System
/dev/sde1 1 121601 976760001 fd Linux raid autodetect
Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe6edc059
Device Boot Start End Blocks Id System
/dev/sdf1 1 121601 976760001 fd Linux raid autodetect
Disk /dev/md0: 2000.4 GB, 2000401989632 bytes
2 heads, 4 sectors/track, 488379392 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000
Disk /dev/md0 doesn't contain a valid partition table
Por sugestões, eu limpei os superblocos e recriei a matriz com a --assume-cleanopção, mas sem sorte alguma.
Existe alguma ferramenta que me ajude a reviver pelo menos alguns dos dados? Alguém pode me dizer o que e como o mdadm --create faz quando sincronizado para destruir os dados, para que eu possa escrever uma ferramenta para desfazer o que foi feito?
Após a recriação do ataque, corro fsck.ext4 / dev / md0 e aqui está a saída
root @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41.14 (22-Dez-2010) fsck.ext4: superbloco inválido, tentando blocos de backup ... fsck.ext4: número mágico ruim em super- bloquear ao tentar abrir / dev / md0
O superbloco não pôde ser lido ou não descreve um sistema de arquivos ext2 correto. Se o dispositivo é válido e realmente contém um sistema de arquivos ext2 (e não swap ou ufs ou algo mais), o superbloco está corrompido e você pode tentar executar o e2fsck com um superbloco alternativo: e2fsck -b 8193
Por sugestão de Shanes, tentei
root@tanserv:/home/mushegh# mkfs.ext4 -n /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
122101760 inodes, 488379392 blocks
24418969 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
14905 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
e execute fsck.ext4 com todos os blocos de backup, mas todos retornaram o seguinte:
root@tanserv:/home/mushegh# fsck.ext4 -b 214990848 /dev/md0
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Invalid argument while trying to open /dev/md0
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Alguma sugestão?
Saudações!
fonte
Respostas:
Ok - algo estava me incomodando sobre o seu problema, então eu iniciei uma VM para mergulhar no comportamento que deveria ser esperado. Vou entender o que estava me incomodando em um minuto; primeiro deixe-me dizer o seguinte:
Faça backup dessas unidades antes de tentar qualquer coisa !!
Você já pode ter causado danos além do que a ressincronização fez; você pode esclarecer o que quis dizer quando disse:
Se você executou um
mdadm --misc --zero-superblock, deve ficar bem.De qualquer forma, vasculhe alguns discos novos e pegue as imagens atuais exatas deles antes de fazer qualquer coisa que possa fazer mais gravação nesses discos.
Dito isto, parece que os dados armazenados nessas coisas são surpreendentemente resistentes a ressincronizações rebeldes. Continue lendo, há esperança, e este pode ser o dia em que atingi o limite de respostas.
O melhor cenário
Criei uma VM para recriar seu cenário. As unidades têm apenas 100 MB, então eu não esperaria uma eternidade em cada ressincronização, mas, caso contrário, essa seria uma representação bastante precisa.
Construiu o array da maneira mais genérica e padrão possível - blocos de 512k, layout simétrico à esquerda, discos em ordem alfabética. Nada de especial.
Por enquanto, tudo bem; vamos criar um sistema de arquivos e colocar alguns dados nele.
Está bem. Temos um sistema de arquivos e alguns dados ("dados"
datafilee 5 MB de dados aleatórios com esse hash SHA1randomdata) nele; vamos ver o que acontece quando fazemos uma recriação.A ressincronização terminou muito rapidamente com esses pequenos discos, mas ocorreu. Então aqui está o que estava me incomodando antes; sua
fdisk -lsaída. Não ter um quadro de partição nomddispositivo não é um problema, é esperado. Seu sistema de arquivos reside diretamente no dispositivo de bloco falso, sem tabela de partição.Sim, sem mesa de partição. Mas...
Sistema de arquivos perfeitamente válido, após uma ressincronização. Então isso é bom; vamos verificar nossos arquivos de dados:
Sólido - sem corrupção de dados! Mas isso é exatamente com as mesmas configurações, então nada foi mapeado de maneira diferente entre os dois grupos RAID. Vamos deixar isso de lado antes que tentemos quebrá-lo.
Dando um passo atrás
Antes de tentarmos resolver isso, vamos falar sobre por que é difícil quebrar. O RAID 5 funciona usando um bloco de paridade que protege uma área do mesmo tamanho que o bloco em todos os outros discos da matriz. A paridade não está apenas em um disco específico, é girada em torno dos discos uniformemente para distribuir melhor a carga de leitura nos discos em operação normal.
A operação XOR para calcular a paridade é assim:
Portanto, a paridade é espalhada entre os discos.
Uma ressincronização geralmente é feita ao substituir um disco morto ou ausente; isso também é feito
mdadm createpara garantir que os dados nos discos estejam alinhados com a aparência da geometria do RAID. Nesse caso, o último disco na especificação da matriz é aquele que é 'sincronizado' - todos os dados existentes nos outros discos são usados para a sincronização.Portanto, todos os dados no disco 'novo' são apagados e reconstruídos; construindo novos blocos de dados a partir de blocos de paridade para o que deveria estar lá ou construindo novos blocos de paridade.
O legal é que o procedimento para essas duas coisas é exatamente o mesmo: uma operação XOR nos dados do restante dos discos. O processo de ressincronização nesse caso pode ter em seu layout que um determinado bloco deve ser um bloco de paridade e pensar que está construindo um novo bloco de paridade, quando na verdade está recriando um bloco de dados antigo. Portanto, mesmo que pense que está construindo isso:
... pode ser apenas reconstruindo a
DISK5partir do layout acima.Portanto, é possível que os dados permaneçam consistentes, mesmo que a matriz tenha sido construída incorretamente.
Jogando um macaco nas obras
(não uma chave inglesa; o macaco inteiro)
Teste 1:
Vamos fazer a matriz na ordem errada!
sdcentãosddentãosdb..Ok, está tudo bem. Nós temos um sistema de arquivos?
Não! Por que é que? Porque enquanto os dados estão todos lá, estão na ordem errada; o que antes era 512KB de A, depois 512KB de B, A, B e assim por diante, agora foi embaralhado para B, A, B, A. O disco agora parece uma bobagem no verificador do sistema de arquivos, não será executado. A saída de
mdadm --misc -D /dev/md1nos dá mais detalhes; Se parece com isso:Quando deve ficar assim:
Então, está tudo muito bem. Substituímos um monte de blocos de dados por novos blocos de paridade neste período. Recrie, com a ordem correta agora:
Legal, ainda existe um sistema de arquivos lá! Ainda tem dados?
Sucesso!
Teste 2
Ok, vamos mudar o tamanho do pedaço e ver se isso nos deixa quebrados.
Sim, sim, é mangueira quando configurada assim. Mas podemos nos recuperar?
Sucesso de novo!
Teste 3
Este é o que eu pensei que mataria dados com certeza - vamos fazer um algoritmo de layout diferente!
Assustador e ruim - ele acha que encontrou algo e quer fazer alguma correção! Ctrl+ C!
Ok, crise evitada. Vamos ver se os dados ainda estão intactos após ressincronizar com o layout errado:
Sucesso!
Teste 4
Vamos também provar que o zeramento do superbloco não é prejudicial rapidamente:
Sim, não é grande coisa.
Teste 5
Vamos jogar tudo o que temos nele. Todos os 4 testes anteriores, combinados.
Avante!
O veredito?
Uau.
Portanto, parece que nenhuma dessas ações corrompeu os dados de forma alguma. Fiquei bastante surpreso com esse resultado, francamente; Eu esperava chances moderadas de perda de dados na alteração do tamanho do bloco e alguma perda definitiva na alteração do layout. Eu aprendi algo hoje.
Então .. Como obtenho meus dados?
O máximo de informações que você tiver sobre o sistema antigo seria extremamente útil para você. Se você conhece o tipo de sistema de arquivos, se possui alguma cópia antiga
/proc/mdstatcom informações sobre a ordem da unidade, algoritmo, tamanho do pedaço e versão dos metadados. Você tem os alertas de email do mdadm configurados? Se sim, encontre um antigo; caso contrário, verifique/var/spool/mail/root. Verifique~/.bash_historyse a sua compilação original está lá.Então, a lista de coisas que você deve fazer:
ddantes de fazer qualquer coisa !!fscko md ativo e atual - você pode ter acabado de construir na mesma ordem de antes. Se você conhece o tipo de sistema de arquivos, isso é útil; use essafsckferramenta específica . Se alguma das ferramentas oferecer alguma correção, não deixe, a menos que tenha certeza de que eles realmente encontraram o sistema de arquivos válido! Se umafsckoferta for consertar algo para você, não hesite em deixar um comentário para perguntar se isso realmente está ajudando ou está prestes a destruir dados./proc/mdstat, pode apenas imitar o que ele mostra; caso contrário, você estará no escuro - tentar todas as diferentes ordens de unidade é razoável, mas verificar todos os tamanhos de bloco possíveis com todas as ordens possíveis é inútil. Para cada um,fscké preciso ver se você tem algo promissor.Então é isso. Desculpe o romance, fique à vontade para deixar um comentário, se tiver alguma dúvida, e boa sorte!
nota de rodapé: menos de 22 mil caracteres; 8k + tímido do limite de comprimento
fonte
Se você tiver sorte, poderá ter algum sucesso ao recuperar seus arquivos com um software de recuperação que pode ler uma matriz RAID-5 quebrada. Recuperação de Assunção Zero é uma que eu tive sucesso antes.
No entanto, não tenho certeza se o processo de criação de uma nova matriz foi destruído e todos os dados, portanto esse pode ser um esforço de última chance.
fonte
Eu tive um problema semelhante:
após uma falha de uma matriz RAID5 de software, dispensei
mdadm --createsem dar--assume-cleane não consegui mais montar a matriz. Após duas semanas de escavação, finalmente restaurei todos os dados. Espero que o procedimento abaixo economize o tempo de alguém.Longa história curta
O problema foi causado pelo fato de
mdadm --createcriar uma nova matriz diferente da original em dois aspectos:Como foi mostrado na brilhante resposta de Shane Madden ,
mdadm --createnão destrói os dados na maioria dos casos! Depois de encontrar a ordem da partição e o deslocamento dos dados, eu poderia restaurar a matriz e extrair todos os dados dela.Pré-requisitos
Eu não tinha backups dos superblocos RAID, então tudo que eu sabia era que era um array RAID5 em 8 partições criadas durante a instalação do Xubuntu 12.04.0. Possui um sistema de arquivos ext4. Outro conhecimento importante foi uma cópia de um arquivo que também foi armazenado na matriz RAID.
Ferramentas
O CD ao vivo do Xubuntu 12.04.1 foi usado para fazer todo o trabalho. Dependendo da sua situação, você pode precisar de algumas das seguintes ferramentas:
versão do mdadm que permite especificar o deslocamento de dados
bgrep - pesquisando dados binários
hexdump, e2fsck, mount e uma calculadora hexadecimal - ferramentas padrão do repos
Comece com o backup completo
A nomeação de arquivos de dispositivos, por exemplo,
/dev/sda2/dev/sdb2etc., não é persistente; portanto, é melhor anotar os números de série de suas unidades fornecidos porEm seguida, conecte um disco rígido externo e faça backup de todas as partições do seu array RAID desta maneira:
Determinar o layout RAID5 original
Vários layouts são descritos aqui: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Para descobrir como as faixas de dados foram organizadas na matriz original, você precisa de uma cópia de um arquivo de aparência aleatória que você sabe que foi armazenado na matriz. O tamanho padrão do bloco atualmente usado por
mdadmé de 512 KB. Para uma matriz de N partições, você precisa de um arquivo de tamanho pelo menos (N + 1) * 512 KB. Um jpeg ou vídeo é bom, pois fornece substrings relativamente únicos de dados binários. Suponha que nosso arquivo seja chamadopicture.jpg. Lemos 32 bytes de dados nas posições N + 1, começando de 100k e incrementando em 512k:Em seguida, pesquisamos ocorrências de todas essas cadeias de caracteres em todas as nossas partições brutas, portanto, no total (N + 1) * N comandos, desta forma:
Esses comandos podem ser executados em paralelo para diferentes discos. A digitalização de uma partição de 38 GB levou cerca de 12 minutos. No meu caso, todas as cadeias de 32 bytes foram encontradas apenas uma vez entre todas as oito unidades. Ao comparar as compensações retornadas pelo bgrep, você obtém uma imagem como esta:
Vemos um layout simétrico esquerdo normal , que é o padrão para
mdadm. Mais importante, agora sabemos a ordem das partições. No entanto, não sabemos qual partição é a primeira na matriz, pois elas podem ser deslocadas ciclicamente.Observe também a distância entre as compensações encontradas. No meu caso, era 512KB. O tamanho do pedaço pode realmente ser menor que essa distância; nesse caso, o layout real será diferente.
Localizar tamanho original do pedaço
Usamos o mesmo arquivo
picture.jpgpara ler 32 bytes de dados em intervalos diferentes um do outro. Sabemos de cima que os dados no deslocamento 100k estão/dev/sdh2, no deslocamento 612k está em/dev/sdb2e em 1124k está em/dev/sdd2. Isso mostra que o tamanho do pedaço não é maior que 512 KB. Verificamos que não é menor que 512 KB. Para isso, despejamos a bytestring no deslocamento 356k e observamos em qual partição está:Está na mesma partição que o deslocamento 612k, o que indica que o tamanho do pedaço não é 256KB. Eliminamos tamanhos menores de pedaços da mesma maneira. Acabei com pedaços de 512 KB sendo a única possibilidade.
Encontre a primeira partição no layout
Agora sabemos a ordem das partições, mas não sabemos qual partição deve ser a primeira e qual deslocamento de dados RAID foi usado. Para encontrar essas duas incógnitas, criaremos uma matriz RAID5 com layout de bloco correto e um pequeno deslocamento de dados e procuraremos o início do nosso sistema de arquivos nessa nova matriz.
Para começar, criamos uma matriz com a ordem correta de partições, que encontramos anteriormente:
Verificamos que o pedido é obedecido emitindo
Agora, determinamos as compensações das seqüências de caracteres N + 1 conhecidas na matriz RAID. Eu corro um script por uma noite (o Live CD não pede senha no sudo :):
Saída com comentários:
Com base nesses dados, vemos que a terceira string não foi encontrada. Isso significa que o pedaço em
/dev/sdd2é usado para paridade. Aqui está uma ilustração das posições de paridade na nova matriz:Nosso objetivo é deduzir de qual partição iniciar a matriz, a fim de mudar os blocos de paridade para o lugar certo. Como a paridade deve ser deslocada duas partes para a esquerda, a sequência da partição deve ser deslocada duas etapas para a direita. Portanto, o layout correto para esse deslocamento de dados é
ahbdcefg:Neste ponto, nossa matriz RAID contém dados na forma correta. Você pode ter sorte, pois o deslocamento de dados RAID é o mesmo da matriz original e provavelmente será capaz de montar a partição. Infelizmente esse não foi o meu caso.
Verificar consistência dos dados
Verificamos que os dados são consistentes em uma faixa de pedaços extraindo uma cópia do
picture.jpgarray. Para isso, localizamos o deslocamento da string de 32 bytes em 100k:Subtraímos 100 * 1024 do resultado e usamos o valor decimal obtido no
skip=parâmetro fordd. Ocount=é o tamanhopicture.jpgem bytes:Verifique se
extract.jpgé o mesmo quepicture.jpg.Encontrar deslocamento de dados RAID
Uma nota lateral: o deslocamento de dados padrão para a
mdadmversão 3.2.3 é 2048 setores. Mas esse valor foi alterado ao longo do tempo. Se a matriz original usou um deslocamento de dados menor do que o atualmdadm, entãomdadm --createsem--assume-cleanpoderá sobrescrever o início do sistema de arquivos.Na seção anterior, criamos uma matriz RAID. Verifique quais dados RAID compensaram, emitindo para algumas das partições individuais:
2048 setores de 512 bytes é 1 MB. Como o tamanho do pedaço é de 512 KB, o deslocamento atual dos dados é de dois pedaços.
Se, nesse ponto, você tiver um deslocamento de duas partes, provavelmente ele é pequeno o suficiente e você poderá pular este parágrafo.
Criamos uma matriz RAID5 com o deslocamento de dados de um bloco de 512 KB. Iniciar um pedaço anterior desloca a paridade um passo para a esquerda, assim compensamos deslocando a sequência da partição um passo para a esquerda. Portanto, para deslocamento de dados de 512 KB, o layout correto é
hbdcefga. Usamos uma versãomdadmque suporta deslocamento de dados (consulte a seção Ferramentas). É compensado em kilobytes:Agora, procuramos um superbloco ext4 válido. A estrutura do superbloco pode ser encontrada aqui: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Verificamos o início da matriz em busca de ocorrências do número mágico
s_magicseguidas pors_statees_errors. As sequências de caracteres a serem procuradas são:Comando de exemplo:
O número mágico inicia 0x38 bytes no superbloco, portanto, subtraímos 0x38 para calcular o deslocamento e examinar todo o superbloco:
Este parece ser um superbloco válido.
s_log_block_sizeo campo em 0x18 é 0002, o que significa que o tamanho do bloco é 2 ^ (10 + 2) = 4096 bytes.s_blocks_count_loem 0x4 são 03f81480 blocos que são 254GB. Parece bom.Agora, examinamos as ocorrências dos primeiros bytes do superbloco para encontrar suas cópias. Observe o byte invertido em comparação com a saída hexdump:
Isso se alinha perfeitamente às posições esperadas dos superblocos de backup:
Portanto, o sistema de arquivos inicia no deslocamento 0xdc80000, ou seja, 225792KB desde o início da partição. Como temos 8 partições, sendo uma por paridade, dividimos o deslocamento por 7. Isso gera um deslocamento de 33030144 bytes em todas as partições, o que corresponde exatamente a 63 blocos RAID. E como o deslocamento de dados RAID atual é de um pedaço, concluímos que o deslocamento de dados original era de 64 blocos, ou 32768KB. Mudar
hbdcefga63 vezes para a direita fornece o layoutbdcefgah.Finalmente construímos a matriz RAID correta:
Voilà!
fonte
Eu tive uma questão semelhante. Formatei e reinstalei minha unidade OS / boot com uma instalação limpa do Ubuntu 12.04, depois executei o comando mdadm --create ... e não consegui montá-lo.
Ele disse que não tinha um superbloco ou partição válido.
Além disso, quando parei o ataque mdadm, não consegui mais montar o dispositivo comum.
Consegui reparar o superbloco com mke2fs e e2fsck:
Então correu:
Isso restaurou o superbloco para que eu pudesse montar e ler a unidade.
Para fazer o array funcionar sem destruir o superbloco ou partições que usei build:
Depois de verificar os dados, adicionarei a outra unidade:
fonte
Estou apenas atualizando algumas das informações fornecidas anteriormente. Eu tinha uma matriz RAID5 de 3 discos funcionando bem quando minha placa-mãe morreu. A matriz mantinha / dev / md2 como partição / home 1.2TB e / dev / md3 como partição / var 300GB.
Eu tinha dois backups de coisas "importantes" e um monte de coisas aleatórias que peguei de várias partes da internet pelas quais eu realmente deveria ter passado e despejado seletivamente. A maioria dos backups foi dividida em arquivos .tar.gz de 25 GB ou menos, e também foi copiada uma cópia separada do / etc.
O restante do sistema de arquivos foi mantido em dois pequenos discos RAID0 de 38 GB.
Minha nova máquina era semelhante ao hardware antigo, e eu a coloquei em funcionamento simplesmente conectando todos os cinco discos e selecionando um kernel genérico antigo. Portanto, eu tinha cinco discos com sistemas de arquivos limpos, embora não pudesse ter certeza de que os discos estavam na ordem certa e precisava instalar uma nova versão do Debian Jessie para ter certeza de que eu poderia atualizar a máquina quando necessário e resolver outros problemas. problemas
Com o novo sistema genérico instalado em dois discos Raid0, comecei a reunir as matrizes. Eu queria ter certeza de que tinha os discos na ordem certa. O que eu deveria ter feito era emitir:
Mas eu não fiz. Parece que o mdadm é bastante inteligente e, devido a um uuid, pode descobrir quais unidades vão aonde. Mesmo que o BIOS designe / dev / sdc como / sda, o mdadm o reunirá corretamente (embora YMMV).
Em vez disso, emiti:
mdadm --create /dev/md2 without the --assume-cleane permiti que a ressincronização em / dev / sde1 fosse concluída. O próximo erro que cometi foi trabalhar em / dev / sdc1 em vez da última unidade no / dev / md2, / sde1. Sempre que o mdadm acha que há um problema, é a última unidade que é expulsa ou ressincronizada.Depois disso, o mdadm não conseguiu encontrar nenhum superbloco e o e2fsck -n também não.
Depois de encontrar esta página, realizei o procedimento de tentar encontrar a sequência para as unidades (concluída), verificar dados válidos (verificados 6 MB de um arquivo de 9 MB), colocar os discos na sequência correta, cde, agarrar o uuid's do / md2 e / md3 do antigo /etc/mdadm.conf e tentou montar.
Bem,
/dev/md3comecei emdadm --misc -D /dev/md3mostrou três partições íntegras e os discos na ordem certa./dev/md2também parecia bom, até que tentei montar o sistema de arquivos.O sistema de arquivos se recusou a ser montado e o e2fsck não conseguiu encontrar nenhum superbloco. Além disso, ao procurar por superblocos, conforme descrito acima, a contagem total de blocos encontrada como a880 0076 ou a880 0076 ou 5500 1176 não correspondia ao tamanho da capacidade do disco de 1199.79 relatou meu mdadm. Também nenhum dos locais dos "superblocos" está alinhado com os dados nas postagens acima.
Eu fiz backup de todo o / var e me preparei para limpar os discos. Para ver se era possível limpar apenas / md2, (eu não tinha mais nada a perder neste momento), discordo o seguinte:
Tudo parecia ok, exceto pela mudança para o uuid. Então, depois de mais algumas verificações, escrevi 600 GB de dados de backup em / dev / md2. Em seguida, desmontou e tentou montar novamente a unidade:
Você está brincando comigo? e os meus 600 GB no arquivo?
Ah - facilmente consertado. uma linha não comentada em /etc/mdadm.conf
Yippie!
fonte