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:
Anschließen der externen Backup-HD an einen USB-Anschluss
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.
Antworten:
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).
quelle
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 /
sdx, sdy .. sind die geklonten Festplatten, aus denen sich die vg zusammensetzt.
Danach sollten Sie in der Lage sein, die lvs von der geklonten Festplatte zu mounten.
quelle
vg- zum Beispiel,vgimportclone -n orignalvgname_clone /dev/sdx /dev/sdx2 /dev/sdx5aber dies kann natürlich von Fall zu Fall sehr unterschiedlich sein.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üssendmsetup 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 entsprichtlvm.conf. Wenn Sie geklont zum Beispiel/dev/sdxin/dev/sdy, müssen Sie vorübergehend fügen/dev/sdxin diefilterimdevices { ... }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 zpvs.Dann mach:
Dadurch wird die aufgerufene Datenträgergruppe deaktiviert.
originalvgnameDa jedoch nur die doppelten Geräte sichtbar sind, wird sie auf diesen deaktiviert (das Originaloriginalvgnameist 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.Dadurch erhalten die Duplikate neue UUIDs.
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
quelle
vgscanautomatisch aktiviert. Dies bedeutet lediglich, dass die LVM-Tools zu diesem Zeitpunkt die Duplikate (und nicht das Original) sehen. Der springende Punkt ist, dass Sie nicht beide gleichzeitig aktiv haben dürfen - entweder das eine oder das andere, nicht beide. Sobald Sie in dem Zustand sind, in dem Sie nur die Duplikate sehen, können Sie sie bearbeiten.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).
quelle