Ist es möglich, gleichzeitig 2 LVM-Volumes zu mounten, die exakte Kopien voneinander sind (gleiche UUIDs)?

Ich habe die Festplatte in einem Live-System (mit dd) auf mehrere Backup-Festplatten geklont. Die Root-Partition im Live-System ist ein LVM-Volume. Die Sicherungskopien sind als Ersatz für das Original gedacht. Dies bedeutet, dass sie dieselbe UUID wie der Master haben müssen.

Kurze Frage: Ist es möglich, eine der Backup-Festplatten auf dem Live-System zu mounten? Wenn ich das versuche, ist LVM verständlicherweise aufgrund der gleichen UUIDs und Volumengruppennamen verwirrt. Nach dem Hinweis in [dieser Antwort] [1], die ursprüngliche LVM-Gruppe zuerst umzubenennen, habe ich versucht:

1. Anschließen der externen Backup-HD an einen USB-Anschluss

2. Wird ausgeführt (Beachten Sie, dass die Zeichenfolge 'test' der Gruppenname auf diesem System ist.)

# 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

Zu diesem Zeitpunkt hätte ich erwartet, auf die einzelnen logischen Volumes unter zugreifen zu können /dev/test/. Laufen lvdisplayproduziert.

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

Gibt es jedoch /dev/test/überhaupt nicht und daher kann ich nicht auf die logischen Volumes bei /dev/test/rootund /dev/test/swap_1wie von lvdisplay vorgeschlagen zugreifen.

Der Sinn von UUIDs besteht darin, etwas eindeutig zu identifizieren, und was Sie versuchen, macht sie nicht eindeutig. Ich bezweifle sehr, dass dies möglich ist. Ich habe herumgespielt, um pvchange -udie UUID einer duplizierten PV zu ändern, aber der Vorgang ist immer fehlgeschlagen.

Wenn Sie die Sicherungen wirklich auf dem Live-Host bereitstellen müssen, empfehle ich, die LVs einzeln zu sichern (dh eine neue PV, VG und LVs auf dem Sicherungsgerät zu erstellen und jede LV separat zu erstellen).

Wenn Sie die lvs von einer Klondiskette mounten möchten, fand ich diese nützliche Methode hier http://www.linuxquestions.org/questions/linux-hardware-18/unable-to-change-uuid-of-cloned-drive- Gerät-links-offen-4175470893 /

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

sdx, sdy .. sind die geklonten Festplatten, aus denen sich die vg zusammensetzt.

vgchange -ay orignalvgname_clone

Danach sollten Sie in der Lage sein, die lvs von der geklonten Festplatte zu mounten.

Die Antwort von trekkerboy / modonnell @ linuxquestions ist am einfachsten zu verwenden vgimportclone.

Beachten Sie auch, dass Sie den Klon nach dem Erstellen mit aktivieren vgchange -a y newvgnameund die Geräteknoten von oldvgname mit bereinigen müssen dmsetup remove /dev/oldvgname/*.

Als Referenz folgt eine manuellere Methode, die anscheinend einer Teilmenge dessen ähnelt, was man in der Quelle von lesen kann vgimportclone.

Sie können dies tun, wenn Sie die Verwaltung der Originalkopie zunächst vorübergehend deaktivieren können, indem Sie dem devicesFilter in ein Muster hinzufügen, das dem Original entspricht lvm.conf. Wenn Sie geklont zum Beispiel /dev/sdxin /dev/sdy, müssen Sie vorübergehend fügen /dev/sdxin die filterim devices { ... }Abschnitt.

Die Originalgeräte bleiben online, werden jedoch von den LVM-Tools ignoriert. Auf ihnen gemountete Dateisysteme bleiben gemountet und betriebsbereit, was nicht eng mit der LVM-Verwaltung verbunden ist.

vgscanFühren Sie nach dem Einsetzen des Filters einen neuen aus , um sicherzustellen, dass die Duplikate und nur diese jetzt unter LVM-Verwaltung stehen. Sie können sicherstellen, dass Sie die doppelten /dev/sdyGeräte über z pvs.

Dann mach:

vgchange -a n originalvgname

Dadurch wird die aufgerufene Datenträgergruppe deaktiviert. originalvgnameDa jedoch nur die doppelten Geräte sichtbar sind, wird sie auf diesen deaktiviert (das Original originalvgnameist aufgrund des obigen Filters bereits unsichtbar). Dieser Schritt ist erforderlich, damit Sie die Attribute der jetzt inaktiven Datenträgergruppe und ihrer physischen Bestandteile frei ändern können.

pvchange -u physicaldevice
vgchange -u originalvgname

Dadurch erhalten die Duplikate neue UUIDs.

vgrename originalvgname newvgname

Dadurch wird die duplizierte Datenträgergruppe umbenannt.

Danach können Sie den Filter entfernen lvm.confund erneut scannen. Beide Sätze von LVM-Geräten werden unter verschiedenen Namen und UUIDs angezeigt.

Wenn Sie nicht daran interessiert sind, den ursprünglichen VG-Namen und die PV / VG-UUIDs beizubehalten, können Sie diese alternativ entsorgen, vgl. /superuser/256061/lvm-and-cloning-hds

Ich bin erst gestern auf dieses Problem gestoßen. Ich habe eine Dateisystemkonfiguration (LVM (MD (SDA, SDB, SDC-Synchronisierung nur wöchentlich))) unter Linux und musste auf alte Daten auf SDC zugreifen.

Ich habe das Problem etwas gelöst, indem ich eine Sicherungsdiskette (SDC) an eine VM angeschlossen habe. Dies ist ein sicherer Vorgang, solange ich die Festplatte mit "qemu ... -drive file = / dev / sdc, readonly" anhänge (oder eine Snapshot-Option für die Copy-on-Write-Konfiguration verwende).