Como montar / recuperar dados em um disco que fazia parte de uma invasão mdadm 1 em outra máquina?

13

Alguns antecedentes

  • O disco em si foi "trabalhado" por um amigo e diz-se que ainda está intacto, sem danos e ainda montável / recuperável
  • O disco fazia parte de uma invasão de software 1 no Ubuntu 12.04
  • O outro disco na raid 1 original foi formatado e usado para outra finalidade, deixando o disco atual (o item em questão) ainda tecnicamente parte de uma invasão que não existe mais

O que eu já tentei

  • Montagem básica

    • Adicionei uma entrada ao fstab, marquei o disco como ext3 / ext4 e tentei montar.
    • Ao montar o seguinte erro aparece

      wrong fs type, bad option, bad superblock on

    • E em dmesg

      EXT4-fs (sdc1): VFS: Can't find ext4 filesystem

  • Eu tentei encontrar o tipo de sistema de arquivos do disco e consegui

    $sudo file -s /dev/sdc e /dev/sdc: x86 boot sector; partition 1: ID=0x83, starthead 254, startsector 63, 1953520002 sectors, code offset 0xb8

Onde preciso de ajuda / Minhas perguntas

  • Existe uma maneira de converter o disco em ext4 sem danificar os dados?
  • Existe uma maneira simples de montar o disco do tipo de arquivo do Linux 83 e recuperar os dados?
  • Eu tenho outro disco atualmente livre no caso de ser uma possibilidade de reconstruir o ataque
  • Meu objetivo principal é recuperar os dados do disco. Estou aberto a todas as opções.

Atualizar

Saída de alguns comandos

  • fdisk -l / dev / sdc

    $fdisk -l /dev/sdc

    Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
    255 heads, 63 sectors/track, 121601 cylinders, total 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
    Disk identifier: 0x0005ed9c

    Device Boot Start End Blocks Id System
    /dev/sdc1 63 1953520064 976760001 83 Linux

  • arquivo -s / dev / sdc1

    $file -s /dev/sdc1
    /dev/sdc1: data

  • hexdump -C -n 32256 / dev / sdc (Não tenho certeza se isso pode ajudar ou não)

    $hexdump -C -n 32256 /dev/sdc'
    00000000  fa b8 00 10 8e d0 bc 00  b0 b8 00 00 8e d8 8e c0  |................|
    00000010  fb be 00 7c bf 00 06 b9  00 02 f3 a4 ea 21 06 00  |...|.........!..|
    00000020  00 be be 07 38 04 75 0b  83 c6 10 81 fe fe 07 75  |....8.u........u|
    00000030  f3 eb 16 b4 02 b0 01 bb  00 7c b2 80 8a 74 01 8b  |.........|...t..|
    00000040  4c 02 cd 13 ea 00 7c 00  00 eb fe 00 00 00 00 00  |L.....|.........|
    00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000001b0  00 00 00 00 00 00 00 00  9c ed 05 00 00 00 00 fe  |................|
    000001c0  ff ff 83 fe ff ff 3f 00  00 00 82 59 70 74 00 00  |......?....Ypt..|
    000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
    00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    00007e00
    
por Adam 15.02.2013 / 18:25

4 respostas

7

O Linux mdraid tem vários formatos de metadados . Os formatos 0.9 e 1.0 colocam os metadados no final do dispositivo de contenção, e a carga útil (o sistema de arquivos) começa no início do dispositivo e pode ser acessada diretamente sem passar pela camada de ataque. Os formatos 1.1 e 1.2 colocam os metadados no meio e no início do dispositivo de contenção, respectivamente, portanto, a carga útil está em um deslocamento.

O instalador do Ubuntu cria volumes com o formato de metadados 1.2, portanto, seus dados são iniciados após os metadados, e não no início do dispositivo.

A maneira mais simples de acessar esses dados é montar o dispositivo de ataque. Em um volume RAID-1, um único dispositivo é suficiente.

madadm -A /dev/sdc1

(Pare aqui a menos que você goste de dor.)

Você também pode acessar os dados em um deslocamento. O único ponto que posso ver para fazer isso é se você tem que trabalhar em um kernel muito antigo que não suporta os formatos 1.x mdraid. Primeiro, determine o deslocamento mdadm -E /dev/sdc1 : procure a linha Data Offset : SSS sectors . Um setor mdadm tem 512 bytes.

sectors=$(mdadm -E /dev/sdc1 | awk -F: '$1 ~ /Data offset/ {print $2}')
bytes=$(($sectors * 512))
losetup -f -o $bytes /dev/sdc1

Em desespero, com os formatos 1.x, o deslocamento de dados é armazenado nos bytes 128–135 dos metadados little-endian¹. 1.2 metadados são 4096 bytes após o início do dispositivo.

Você também pode alterar a tabela de partições para que ela comece ainda mais. Tenha muito cuidado com sua aritmética. Só faça isso se quiser continuar usando o disco a longo prazo em um sistema antigo que não pode acessar o dispositivo de invasão.

¹ Ou com o endianness da plataforma? Não tenho certeza.

    
por 16.02.2013 / 00:14
7

Isso está funcionando perfeitamente no Ubuntu 14.04:

sudo -i
mdadm --assemble --scan

Você receberá:

mdadm: /dev/md/1 has been started with 1 drive (out of 2)

Em seguida, monte e veja seus arquivos:

cd /mnt && mkdir to-restore-md1 && mount /dev/md1 to-restore-md1
ls -la to-restore-md1
    
por 24.01.2016 / 06:18
5

Para minha surpresa, eu pude recuperar os dados simplesmente usando acima .

A ajuda recebida aqui foi inestimável. Depois de tentar uma variedade de combinações sugeridas, assim como meus próprios mix-ins, o método ideal (montar e usar o disco normalmente) não parecia mais uma opção. Recorrer à recuperação de dados é a minha solução neste caso.

    
por 17.02.2013 / 21:53
3

Parece que você já zapped o superbloco mdadm. Se costumava estar lá e era o formato 1.1 ou 1.2, provavelmente o sistema de arquivos está em offset de 2048 setores. Você pode executar e2fsck /dev/sdc1?offset=2048 para forçá-lo a procurar o sistema de arquivos que começa naquele deslocamento. Se encontrar, você pode modificar sua tabela de partições para apontar para onde o sistema de arquivos realmente inicia. Você pode usar parted /dev/sdc e o comando unit s para usar unidades de setores. print da tabela, observe o setor inicial e final, em seguida rm da partição, recrie-a com mkpart e use o mesmo setor final, mas adicione o deslocamento ao setor inicial.

Se 2048 não funcionar, você também pode tentar 1985.

    
por 16.02.2013 / 20:34