He clonado (usando dd) el disco duro en un sistema en vivo en varios discos duros de copia de seguridad múltiples. La partición raíz en el sistema en vivo es un volumen LVM. Las copias de seguridad están destinadas a ser reemplazos directos para el original y esto significa que deben tener el mismo UUID que el maestro.
Pregunta rápida: ¿es posible montar uno de los HD de respaldo en el sistema en vivo? Cuando trato de hacerlo, LVM está comprensiblemente confundido acerca de esto debido a los mismos UUID y nombres de grupos de volúmenes. Siguiendo la pista encontrada en [esta respuesta] [1] para cambiar el nombre del grupo LVM original, he intentado:
conectar la copia de seguridad externa HD a un puerto USB
en ejecución (tenga en cuenta que la cadena 'prueba' es el nombre del grupo en este 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
En este punto, hubiera esperado poder acceder a los volúmenes lógicos individuales en /dev/test/. Correr lvdisplayproduce.
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
Sin embargo, /dev/test/no existe en absoluto y, por lo tanto, no puedo acceder a los volúmenes lógicos en /dev/test/rooty /dev/test/swap_1como sugirió lvdisplay.
Respuestas:
El objetivo de los UUID es identificar algo de forma única, y lo que estás tratando de hacer los hace no únicos. Dudo mucho que esto sea posible. He jugado un poco con
pvchange -ucambiar el UUID de un PV duplicado, pero la operación siempre fallaba.Si realmente necesita montar las copias de seguridad en el host en vivo, le sugiero que haga una copia de seguridad de los LV individualmente (es decir, cree un nuevo PV, VG y LV en el dispositivo de copia de seguridad y cree cada LV por separado).
fuente
Si desea montar los lv desde un disco clon, encontré este método útil aquí http://www.linuxquestions.org/questions/linux-hardware-18/unable-to-change-uuid-of-cloned-drive- dispositivo-izquierda-abierta-4175470893 /
sdx, sdy ... son los discos clonados que componen el vg.
Después de esto, debería poder montar los lvs fuera del disco clonado.
fuente
vg, por ejemplo,vgimportclone -n orignalvgname_clone /dev/sdx /dev/sdx2 /dev/sdx5pero obviamente esto puede ser muy diferente de un caso a otro.La respuesta de trekkerboy / modonnell @ linuxquestions es muy sencilla, use
vgimportclone.Tenga en cuenta también que después de crear el clon, debe activarlo
vgchange -a y newvgnamey limpiar los nodos de dispositivo de oldvgname condmsetup remove /dev/oldvgname/*.Como referencia, lo que sigue es un método más manual, que aparentemente se parece a un subconjunto de lo que uno puede leer en la fuente
vgimportclone.Puede hacerlo si primero puede desactivar temporalmente la administración de la copia original, agregando un patrón que coincida con el original en el
devicesfiltrolvm.conf. Por ejemplo, si se clonó/dev/sdxen/dev/sdy, hay que añadir temporalmente/dev/sdxen elfilterdentro de ladevices { ... }sección.Los dispositivos originales permanecerán en línea, pero las herramientas LVM los ignorarán. Los sistemas de archivos montados en ellos permanecerán montados y operativos, eso no está estrechamente vinculado con la administración de LVM.
Una vez que el filtro esté en su lugar, realice una nueva
vgscan, para asegurarse de que los duplicados y solo ellos estén ahora bajo la administración de LVM. Puede asegurarse de ver los/dev/sdydispositivos duplicados a través de, por ejemplopvs.Entonces hazlo:
Esto desactivará el grupo de volúmenes llamado
originalvgname, pero debido a que solo los dispositivos duplicados son visibles, lo desactivará en ellos (el originaloriginalvgnameya es invisible debido al filtro de arriba). Este paso es necesario para que pueda cambiar libremente los atributos del grupo de volúmenes ahora inactivo y sus volúmenes físicos constituyentes.Esto dará nuevos UUID a los duplicados.
Esto cambiará el nombre del grupo de volúmenes duplicados.
Después de eso, puede quitar el filtro
lvm.confy volver a escanear, y ambos conjuntos de dispositivos LVM serán visibles, con diferentes nombres y UUID.Alternativamente, si no está realmente interesado en mantener el nombre VG original y los UUID PV / VG, puede deshacerse de ellos, en su lugar, cf. /superuser/256061/lvm-and-cloning-hds
fuente
vgscanautomáticamente por lo anterior , solo significa que en ese momento las herramientas LVM ven los duplicados (y no el original). El punto es que no debe tenerlos activos al mismo tiempo, ni uno ni el otro, no ambos. Tan pronto como llegue al estado en el que solo ve los duplicados, puede operarlos.Encontré este problema ayer. Tengo la configuración del sistema de archivos (LVM (MD (sda, sdb, sdc-sincronización-solo-semanal))) en Linux, y necesitaba acceder a datos antiguos en sdc.
Resolví el problema uniendo el disco de respaldo (sdc) a una máquina virtual. Esta es una operación segura siempre que conecte el disco con "qemu ... -drive file = / dev / sdc, readonly" (o use una opción de instantánea para la configuración de copia en escritura).
fuente