é possível montar simultaneamente 2 volumes LVM que são cópias exatas um do outro (mesmos UUIDs)?

Eu clonei (usando dd) o disco rígido em um sistema ativo em vários discos rígidos de backup múltiplos. A partição raiz no sistema ativo é um volume LVM. As cópias de backup devem substituir o original e isso significa que elas precisam ter o mesmo UUID do mestre.

Pergunta rápida: é possível montar um dos HDs de backup no sistema ativo? Quando tento fazer isso, o LVM está compreensivelmente confuso sobre isso devido aos mesmos nomes de UUIDs e grupos de volumes. Seguindo a dica encontrada em [esta resposta] [1] para renomear o grupo LVM original, tentei:

1. conectar o HD de backup externo a uma porta USB

2. em execução (observe que a cadeia 'test' é o nome do grupo neste sistema)

# vgrename test test-live
Volume group "test" successfully renamed to "test-live"
vgscan --mknodes
Reading all physical volumes.  This may take a while...
Found duplicate PV qWUadGaM2MU1UAJ5Spp8upD6fbddk7Zb: using /dev/dm-3 not /dev/dm-0
Found volume group "test" using metadata type lvm2
# vgchange -ay
Found duplicate PV qWUadGaM2MU1UAJ5Spp8upD6fbddk7Zb: using /dev/dm-3 not /dev/dm-0
2 logical volume(s) in volume group "test" now active

Nesse ponto, eu esperava ter conseguido acessar os volumes lógicos individuais abaixo /dev/test/. Correr lvdisplayproduz.

Found duplicate PV qWUadGaM2MU1UAJ5Spp8upD6fbddk7Zb: using /dev/dm-3 not /dev/dm-0

  --- Logical volume ---
  LV Name                /dev/test/root
  VG Name                test
  LV UUID                UuKUH3-yzPo-CbOz-tU4B-W6om-qdMn-0XSNZU
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                126.48 GiB
  Current LE             32378
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1

  --- Logical volume ---
  LV Name                /dev/test/swap_1
  VG Name                test
  LV UUID                OGJhJu-QByo-6AzG-sk1x-jh3e-dU9L-sHk91t
  LV Write Access        read/write
  LV Status              available
  # open                 2
  LV Size                3.90 GiB
  Current LE             999
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:2

No entanto, /dev/test/ele não existe e, portanto, não consigo acessar os volumes lógicos em /dev/test/roote /dev/test/swap_1como sugerido pelo lvdisplay.

O objetivo principal dos UUIDs é identificar algo de maneira exclusiva, e o que você está tentando fazer os torna não exclusivos. Eu duvido muito que isso seja possível. Eu brinquei com pvchange -upara mudar o UUID de um PV duplicado, mas a operação sempre falhava.

Se você realmente precisar montar os backups no host ativo, sugiro que você faça backup dos LVs individualmente (por exemplo, crie um novo PV, VG e LVs no dispositivo de backup e adicione cada LV separadamente).

Se você deseja montar os lvs a partir de um disco clone, encontrei este método útil aqui http://www.linuxquestions.org/questions/linux-hardware-18/unable-to-change-uuid-of-cloned-drive- device-left-open-4175470893 /

vgimportclone -n orignalvgname_clone   /dev/sdx [/dev/sdy....]

sdx, sdy .. são os discos clonados que compõem a vg.

vgchange -ay orignalvgname_clone

Após isso, você poderá montar os lvs do disco clonado.

A resposta de trekkerboy / modonnell @ linuxquestions é mais direta, use vgimportclone.

Observe também que, depois de criar o clone, você deve ativá-lo vgchange -a y newvgnamee limpar os nós de dispositivo do oldvgname dmsetup remove /dev/oldvgname/*.

Para referência, o que se segue é um método mais manual, que aparentemente se assemelha a um subconjunto do que se pode ler na fonte vgimportclone.

Você pode fazer isso se conseguir primeiro desativar temporariamente o gerenciamento da cópia original, adicionando um padrão correspondente ao original no devicesfiltro lvm.conf. Por exemplo, se você clonado /dev/sdxem /dev/sdy, você tem que adicionar temporariamente /dev/sdxpara o filterdentro da devices { ... }seção.

Os dispositivos originais permanecerão online, mas as ferramentas LVM os ignorarão. Os sistemas de arquivos montados neles permanecerão montados e operacionais, o que não está diretamente associado ao gerenciamento do LVM.

Depois que o filtro estiver no lugar, faça um novo vgscanpara garantir que as duplicatas e somente elas estejam agora sob gerenciamento do LVM. Você pode ter certeza de ver os /dev/sdydispositivos duplicados via, por exemplo pvs.

Então faça:

vgchange -a n originalvgname

Isso desativará o grupo de volumes chamado originalvgname, mas como apenas os dispositivos duplicados estão visíveis, o desativará (o original originalvgnamejá está invisível por causa do filtro acima). Esta etapa é necessária para que você possa alterar livremente os atributos do grupo de volumes agora inativo e seus volumes físicos constituintes.

pvchange -u physicaldevice
vgchange -u originalvgname

Isso dará novos UUIDs para as duplicatas.

vgrename originalvgname newvgname

Isso renomeará o grupo de volumes duplicado.

Depois disso, você pode remover e filtrar lvm.confnovamente o filtro , e os dois conjuntos de dispositivos LVM estarão visíveis, sob diferentes nomes e UUIDs.

Como alternativa, se você não estiver realmente interessado em manter o nome original do VG e os UUIDs PV / VG, poderá descartá-los. /superuser/256061/lvm-and-cloning-hds

Encontrei esse problema ontem. Eu tenho a configuração do sistema de arquivos (LVM (MD (sda, sdb, sdc-syncing-only-semanais-base))) no Linux e precisava acessar dados antigos no sdc.

Resolvi um pouco o problema anexando o disco de backup (sdc) a uma VM. Esta é uma operação segura, desde que eu conecte o disco com "qemu ... -drive file = / dev / sdc, readonly" (ou use uma opção de captura instantânea para configuração de cópia na gravação).