Entendendo o comportamento do LVM2 em caso de falha de disco?

2

Eu tenho um grupo LVM2 usando o seguinte comando para uma configuração 5x4TB:

pvcreate /dev/sd{b,c,d,e,f}
vgcreate vg0 /dev/sd{b,c,d,e,f}
lvcreate -l 100%FREE -n lvol1 vg0

Agora que criei esse monstro, tenho algumas dúvidas sobre isso: na configuração padrão que é linear, o que acontece se /dev/sdb falhar?

  • Devo me despedir de todo o /dev/sdb data ou o LVM está colocando os arquivos em todo o dispositivo em vez de tentar preencher os primeiros bytes?

  • Como posso saber qual arquivo está em qual dispositivo? Se eu perder um disco, gostaria de saber onde os dados são perdidos para poder restaurá-lo, se possível.

Nota:

  • Eu segui o Manual do Gentoo para a criação do LVM .
  • Eu entendo perfeitamente que o RAIDx (e o LVM, no meu entender) não fornece backup; eles só podem, no máximo, adicionar resiliência contra falhas de disco. Eu tenho alguma experiência com (software) RAID5 e falha de disco: felizmente, apenas um de cada vez falhou. No entanto, não tenho experiência com o LVM e é por isso que estou fazendo essas perguntas.
por NoDataFound 29.04.2018 / 22:42

3 respostas

0

O LVM não coloca nenhum arquivo. O LVM cria um grande dispositivo lógico cujos dados são distribuídos por vários dispositivos físicos.

É como ter uma partição de 1GiB, formatá-la, criar dados no sistema de arquivos e, em seguida, sobrescrever o intervalo de 250MiB a 500MiB com zeros.

Se houvesse menos de 250 MiB de dados no sistema de arquivos, há uma chance de que fsck possa restaurar a maior parte ou a totalidade dele. Você pode facilmente tentar.

    
por 29.04.2018 / 22:47
0

what happens if /dev/sdb fails?

Seu lvol1 não funcionará mais. Perder uma unidade significa perder 5 unidades no valor de dados. O volume terá uma grande quantidade de dados faltando (todo o disco foi eliminado) e, muito provavelmente, qualquer sistema de arquivos que você esteja usando em cima disso não vai gostar nem um pouco.

Você não deve esperar que fsck recupere nada. Isso pode acontecer, mas fsck não é uma ferramenta de recuperação de dados, ela é usada principalmente para consertar apenas pequenas inconsistências, não magicamente trabalhar em torno de centenas de gigabytes de dados perdidos. Às vezes o fsck está perfeitamente feliz em fornecer a você um sistema de arquivos consistente (ainda que estranhamente vazio).

Se você usa fsck , ou qualquer outra coisa, faça isso com um instantâneo ou uma sobreposição para poder desfazer quaisquer alterações feitas. (Mandatos de recuperação de dados trabalhando em modo somente leitura ou copy-on-write).

Como o LVM é linear (por padrão, de qualquer forma), photorec e outras ferramentas ainda poderão localizar dados (não fragmentados, não criptografados) nas outras unidades.

Embora o LVM seja distribuído em várias unidades, talvez seja melhor criar vários volumes menores. Volumes que não estavam localizados na unidade perdida sobreviverão. Sistemas de arquivos menores também evitam um problema com fsck , que tende a ser muito dependente de recursos e leva muito tempo, dependendo do tamanho do sistema de arquivos.

O uso de unidades não particionadas vem com o risco de, inadvertidamente, criar uma tabela de partição de qualquer maneira - sobrescrevendo outros metadados no processo. Você deve sempre usar uma tabela de partições.

Em qualquer caso, se você não quiser perder seus dados, faça backups.

Se você não quiser restaurar backups após cada falha de unidade, use também o RAID.

    
por 29.04.2018 / 22:58
0

lvdisplay --maps dirá onde as extensões físicas correspondentes a um determinado LV ou a um intervalo específico dele estão localizadas. pvdisplay --maps apresenta as mesmas informações de um ponto de vista centrado em PV.

Por exemplo, se pvdisplay --maps indicar que um PV com falha abrange, digamos, extensões lógicas 1000 ... 4000 de um LV específico, e o tamanho de extensão desse VG for 4 MiB, você saberá que se o O PV falha completamente, seu LV teria um grande "buraco" inacessível nele, começando em um ponto 4000 MiB do começo do LV e continuando até o ponto 16000 MiB desde o começo daquele LV.

Normalmente, em situações como essa, será mais fácil restaurar todo o LV: dessa forma, você pode ter certeza de que todos os arquivos estão em um estado consistente. Por exemplo, se o arquivo A contiver referências a itens no arquivo B, talvez você deseje restaurar ambos dos backups, mesmo que apenas um deles esteja na área danificada.

Mas se você precisar (ou seja, descobrir que não tem backups que podem ser usados e está com problemas graves), use lvchange ou vgchange com --activationmode partial para ativar um LV mesmo que tenha partes faltando, para que você possa montá-lo para recuperar o que resta. Isso deve ser feito apenas para fins de recuperação de dados.

Como no seu caso /dev/sdb seria o primeiro PV no grupo de volume, ele também armazenaria a primeira parte do LV - que é onde muitos metadados críticos do sistema de arquivos daquele LV provavelmente acabariam, então fsck iria vomitar muitos erros em você. Como frostschutz disse, photorec poderia muito bem encontrar qualquer arquivo não fragmentado das partes restantes do LV. Mas confiar nisso é uma estratégia ruim.

Você precisará pensar nos backups e no tempo que uma restauração completa levaria. Se a restauração de todo o LV após uma falha no disco exigir muito tempo, você precisará adicionar redundância ao sistema para evitar isso. Normalmente, isso significa obter mais discos e colocar seus dados em algum tipo de matriz RAID.

Mas, mesmo que você configure um array RAID, não se esqueça dos backups. O RAID pode tornar as falhas de disco fáceis de lidar, mas não é de nenhuma ajuda no caso de um usuário / sysadmin "oops". O RAID não é um backup.

    
por 29.04.2018 / 23:21