Eu clonei (usando dd) o disco rígido em um sistema live em vários discos rígidos múltiplos de backup. A partição raiz no sistema live é um volume LVM. As cópias de backup devem ser substitutas do original e isso significa que elas precisam ter o mesmo UUID que o mestre.
Pergunta rápida: é possível montar um dos HDs de backup no sistema ao vivo? Quando tento fazer isso, o LVM fica compreensivelmente confuso sobre isso devido aos mesmos UUIDs e nomes de grupos de volumes. Seguindo a dica encontrada em [this answer] [1] para primeiro renomear o grupo LVM original, tentei:
conectando o HD de backup externo a uma porta USB
em execução (observe que a string '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
Neste ponto, eu esperava ter sido capaz de acessar os volumes lógicos individuais em /dev/test/ . Executar lvdisplay produz.
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/ não existe e, portanto, não consigo acessar os volumes lógicos em /dev/test/root e /dev/test/swap_1 como sugerido pelo lvdisplay.
O ponto principal dos UUIDs é identificar de maneira única alguma coisa, e o que você está tentando fazer torna-os não exclusivos. Eu duvido muito que isso seja possível. Eu brinquei com pvchange -u para alterar o UUID de um PV duplicado, mas a operação sempre falhava.
Se você realmente precisar montar os backups no host ao vivo, sugiro que faça o backup dos LVs individualmente (ou seja, crie um novo PV, VG e LVs no dispositivo de backup e dd cada LV separadamente).
A resposta de trekkerboy / modonnell @ linuxquestions é mais direta, use vgimportclone .
Note também que depois de criar o clone, você tem que ativá-lo com vgchange -a y newvgname , e você tem que limpar os nós de dispositivo do oldvgname com dmsetup remove /dev/oldvgname/* .
Para referência, o que segue é um método mais manual, que aparentemente se assemelha a um subconjunto do que se pode ler na fonte de vgimportclone .
Você pode fazer isso primeiro se for possível desativar temporariamente o gerenciamento da cópia original, adicionando um padrão correspondente ao original no filtro devices em lvm.conf . Por exemplo, se você clonou /dev/sdx em /dev/sdy , precisará adicionar temporariamente /dev/sdx à filter na seção devices { ... } .
Os dispositivos originais permanecerão on-line, mas as ferramentas do LVM os ignoram. Sistemas de arquivos montados neles permanecerão montados e operacionais, que não estão strongmente acoplados ao gerenciamento do LVM.
Depois que o filtro estiver no lugar, faça um novo vgscan , para certificar-se de que as duplicatas e apenas elas estejam agora sob o gerenciamento do LVM. Você pode ter certeza de ver os dispositivos /dev/sdy duplicados por meio de, por exemplo, pvs .
Então faça:
vgchange -a n originalvgname
Isso desativará o grupo de volumes chamado originalvgname , mas como somente os dispositivos duplicados estarão visíveis, ele será desativado neles (o originalvgname original já estará invisível devido ao filtro acima). Essa etapa é necessária para que você possa alterar livremente os atributos do grupo de volumes inativo e de seus volumes físicos constituintes.
pvchange -u physicaldevice
vgchange -u originalvgname
Isso fornecerá novos UUIDs às duplicatas.
vgrename originalvgname newvgname
Isso renomeará o grupo de volumes duplicados.
Depois disso, você pode remover o filtro de lvm.conf e redigitalizar novamente, e ambos os 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 VG e os UUIDs PV / VG originais, é possível descartá-los, em vez disso, cf. link
Eu encontrei esse problema ontem mesmo. Eu tenho configuração de sistema de arquivos (LVM (MD (sda, sdb, sdc-sync-única-semanal-base))) no Linux e precisava acessar dados antigos em sdc.
De alguma forma, resolvi 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 snapshot para configuração copy-on-write).