est-il possible de monter simultanément 2 volumes LVM qui sont des copies exactes les uns des autres (mêmes UUID)?

J'ai cloné (à l'aide de dd) le disque dur d'un système actif sur plusieurs disques durs de sauvegarde multiples. La partition racine dans le système en direct est un volume LVM. Les copies de sauvegarde sont destinées à être des remplacements directs pour l'original et cela signifie qu'elles doivent avoir le même UUID que le maître.

Question rapide: est-il possible de monter l'un des HD de sauvegarde sur le système live? Lorsque j'essaie de le faire, LVM est naturellement confus à ce sujet en raison des mêmes UUID et noms de groupe de volumes. En suivant le conseil trouvé dans [cette réponse] [1] pour renommer d'abord le groupe LVM d'origine, j'ai essayé:

1. connexion de la sauvegarde externe HD à un port USB

2. en cours d'exécution (notez que la chaîne «test» est le nom du groupe sur ce système)

# 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

À ce stade, je m'attendais à pouvoir accéder aux volumes logiques individuels sous /dev/test/. La course lvdisplayproduit.

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

Cependant, /dev/test/n'existe pas du tout et donc je ne peux pas accéder aux volumes logiques sur /dev/test/rootet /dev/test/swap_1comme lvdisplay l'a suggéré.

L'intérêt des UUID est d'identifier de manière unique quelque chose, et ce que vous essayez de faire les rend non uniques. Je doute fortement que cela soit possible. J'ai joué avec pvchange -upour changer l'UUID d'un PV dupliqué, mais l'opération a toujours échoué.

Si vous avez vraiment besoin de monter les sauvegardes sur l'hôte en direct, je vous suggère de sauvegarder les LV individuellement (c'est-à-dire de créer un nouveau PV, VG et LV sur le périphérique de sauvegarde et dd chaque LV séparément).

Si vous voulez monter les LV à partir d'un disque clone, j'ai trouvé cette méthode utile ici http://www.linuxquestions.org/questions/linux-hardware-18/unable-to-change-uuid-of-cloned-drive- appareil-gauche-ouvert-4175470893 /

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

sdx, sdy .. sont les disques clonés qui composent le vg.

vgchange -ay orignalvgname_clone

Après cela, vous devriez pouvoir monter les lvs sur le disque cloné.

La réponse de trekkerboy / modonnell @ linuxquestions est très simple à utiliser vgimportclone.

Notez également qu'après avoir créé le clone, vous devez l'activer avec vgchange -a y newvgnameet vous devez nettoyer les nœuds de périphérique de oldvgname avec dmsetup remove /dev/oldvgname/*.

Pour référence, ce qui suit est une méthode plus manuelle, qui ressemble apparemment à un sous-ensemble de ce que l'on peut lire dans la source de vgimportclone.

Vous pouvez le faire si vous pouvez d'abord désactiver temporairement la gestion de la copie originale, en ajoutant un motif correspondant à l'original dans le devicesfiltre dans lvm.conf. Par exemple, si vous avez cloné /dev/sdxdans /dev/sdy, vous devez ajouter temporairement /dev/sdxdans l' filterintérieur de la devices { ... }section.

Les appareils d'origine resteront en ligne, mais les outils LVM les ignoreront. Les systèmes de fichiers montés sur eux resteront montés et opérationnels, ce qui n'est pas étroitement associé à la gestion LVM.

Une fois le filtre en place, effectuez une nouvelle opération vgscanpour vous assurer que les doublons et seuls ceux-ci sont désormais sous gestion LVM. Vous pouvez vous assurer que vous voyez les /dev/sdyappareils en double via par exemple pvs.

Alors fais:

vgchange -a n originalvgname

Cela désactivera le groupe de volumes appelé originalvgname, mais comme seuls les périphériques en double sont visibles, cela le désactivera sur eux (l'original originalvgnameest déjà invisible à cause du filtre ci-dessus). Cette étape est nécessaire pour que vous puissiez ensuite modifier librement les attributs du groupe de volumes désormais inactif et ses volumes physiques constitutifs.

pvchange -u physicaldevice
vgchange -u originalvgname

Cela donnera de nouveaux UUID aux doublons.

vgrename originalvgname newvgname

Cela renommera le groupe de volumes dupliqué.

Après cela, vous pouvez supprimer le filtre lvm.confet effectuer une nouvelle analyse, et les deux ensembles de périphériques LVM seront visibles, sous différents noms et UUID.

Alternativement, si vous n'êtes pas réellement intéressé à conserver le nom VG d'origine et les UUID PV / VG, vous pouvez les éliminer à la place, cf. /superuser/256061/lvm-and-cloning-hds

J'ai rencontré ce problème hier. J'ai la configuration du système de fichiers (LVM (MD (sda, sdb, sdc-syncing-only-hebdomadaire)))) sur Linux, et j'avais besoin d'accéder aux anciennes données sur sdc.

J'ai quelque peu résolu le problème en attachant un disque de sauvegarde (sdc) à une machine virtuelle. Il s'agit d'une opération sûre tant que j'attache le disque avec "qemu ... -drive file = / dev / sdc, en lecture seule" (ou j'utilise une option d'instantané pour la configuration de copie sur écriture).