É possível recuperar um volume lógico parcial do LVM?

Question

Plano de fundo

É uma VM VirtualBox do Ubuntu 12.04 com 5 HDDs virtuais (VDI). OBSERVE que esta é apenas uma VM de teste, portanto, não é bem planejada com antecedência:

1. ubuntu.vdi para / (/ dev / mapper / ubuntu-root AKA / dev / ubuntu / root) e / home (/ dev / mapper / ubuntu-home)
2. weblogic.vdi - / dev / sdb (montado em / bea para weblogic e outras coisas)
3. btrfs1.vdi - / dev / sdc (parte da configuração btrfs -m raid1 -d raid1)
4. btrfs2.vdi - / dev / sdd (parte da configuração btrfs -m raid1 -d raid1)
5. more.vdi - / dev / sde (adicionou este disco virtual porque faltava inodes e não foi fácil descobrir o que excluir para liberar inodes, então eu adicionei o novo HDD virtual, PV criado, adicionado ao grupo de volume existente ubuntu, cresceu o volume lógico da raiz para contornar o problema do inode -_-)

O que aconteceu?

Última sexta-feira, antes de terminar eu queria liberar algum espaço em disco na caixa, por algum motivo eu pensei que o more.vdi era inútil e tentou separá-lo da VM, eu cliquei em delete (deveria ter clicado em manter arquivos maldito!) por engano quando desanexar. Infelizmente eu não tenho backup para isso. Tarde demais.

O que tentei

Tentei recuperar (usar testdisk e photorec) os arquivos vdi, mas ele demorou muito e recuperou muitos arquivos .vdi que eu não queria (grande, preencheu o disco, droga!). Eu finalmente desisti. Felizmente, a maioria dos dados está em volumes separados de partição ext4 e btrfs.

Por curiosidade, eu ainda tentei montar os volumes lógicos e ver se é possível pelo menos recuperar o / var e / etc

Eu tentei usar o cd de recuperação do sistema para inicializar e ativar os grupos de volume, eu consegui:

Couldn't find device with uuid xxxx.
Refusing activation of the partial LV root. Use --partial to override.
1 logical volume(s) in volume group "ubuntu" now active.
I was able to mount home LV but not root LV.

Eu estou querendo saber se é possível acessar a raiz LV mais. Sob o capô, os dados (em LV root - /) foram distribuídos para more.vdi (PV), eu sei que é quase impossível recuperar.

Mas ainda estou curioso sobre como os caras do administrador de sistemas / DevOps lidam com esse tipo de situação; -)

Obrigado antecipadamente.

    

Answer 1

[ EDITAR : Se você não estiver familiarizado com o LVM, leia esta visão geral ou pelo menos a página da Wikipedia sobre isso .]

O LVM divide seus volumes físicos em fatias chamadas "Physical Extents" (PE). Você pode verificar quais Volumes Lógicos têm PEs alocados nos PVs que você ainda tem emitindo este comando:

pvdisplay -m

Qual saída é algo assim (mostrando apenas um PV aqui):

--- Physical volume ---
  PV Name               /dev/sda3
  VG Name               htpcvg
  PV Size               929.27 GiB / not usable 18.71 MiB
  Allocatable           yes 
  PE Size               32.00 MiB
  Total PE              29736
  Free PE               1190
  Allocated PE          28546
  PV UUID               7SfjbY-3dy4-UDeB-iSEL-3R9Y-vvnv-O7m9jr

  --- Physical Segments ---
  Physical extent 0 to 28545:
    Logical volume      /dev/htpcvg/home
    Logical extents     29430 to 57975
  Physical extent 28546 to 29735:
    FREE

Com esta informação você pode saber quanto de seus LVs está armazenado naquele PV.

Então, se essa informação mostrar que você tem algumas extensões de seus LVs 'disponíveis, você pode ativar o VG que os contém com este outro comando (edit VolGroupName): [ EDITAR : Por favor, leia a página do manual ]

vgchange -a y --partial VolGroupName

Isso deve tornar seus LVs "disponíveis", mas com falhas de qualquer maneira (você não conseguirá ler PEs ausentes, obviamente). Por segurança, você também pode tornar os seus LVs desativados somente leitura com lvchange -p r --partial /path/to/logical/volume

Agora, dado que você provavelmente não será capaz de montar os sistemas de arquivos que residem em seus LVs parciais, você deve copiar o que sobrou deles com ddrescue :

ddrescue -n /dev/mapper/yourVG-yourLV /file/for/the/dump ddrescue.log

E, em seguida, faça algumas análises forenses sobre esse despejo. Aqui você tem muitas opções. Photorec é apenas um.

    

Answer 2

1 coisa para as futuras gerações.

O parcial não carrega os LVs que eram parciais.

Além disso, ele substituirá sua configuração e você ainda receberá erros críticos para o seu fs. Para carregar os LVs quebrados, você deve primeiro substituir a unidade ou a peça quebrada / com falha / desativada, por exemplo, com a imagem de loop montada do nfs.

Faça o dump da configuração do VG, compare-a com as configurações de backup e adicione os spans de trabalho exceto o quebrado. Verifique o tamanho dos segmentos para correlacionar com a quantidade de spans. Lembre-se de que a imagem deve ser maior que a anterior.

Você pode então pvcreate-lo e atribuir as extensões ao LV quebrado.

Depois disso, faça o e2fsck (porque o superbloco será quebrado devido a um intervalo quebrado) no LV quebrado. em seguida, redimensione-o para novo tamanho menor usando resize2fs e você pode remover com segurança o loop de extensão, primeiro reduzindo o tamanho de lv para fs (hoje em dia você pode fazer isso em um comando sem resize2fs), e depois vgreduce para expulsar o loop de seu LV.

Depois disso, você pode montar com segurança os dados de backup e backup de LV e até mesmo reinicializar o sistema para executá-lo.

Não use / dev / ioerror (como sugerido em algum lugar on-line), embora seu LV esteja corrompido com o superblock corrompido, assim como não permitirá corrigir erros além do limite de LV e, por fim, falhar o fsck o tempo todo. Suplemente apenas o dispositivo de loop ou até mesmo um dispositivo real, se você quiser.