Sklonowałem (używając dd) dysk twardy w systemie na żywo na kilka kopii zapasowych. Partycja root w systemie na żywo jest woluminem LVM. Kopie zapasowe mają być zamiennymi zamiennikami oryginału, co oznacza, że muszą mieć ten sam identyfikator UUID co wzorzec.
Szybkie pytanie: czy można zamontować jeden z zapasowych dysków HD w systemie na żywo? Kiedy próbuję to zrobić, LVM jest co do niej zrozumiały z powodu tych samych UUID i nazw grup woluminów. Po wskazówkach zawartych w [tej odpowiedzi] [1], aby najpierw zmienić nazwę oryginalnej grupy LVM, próbowałem:
podłączenie zewnętrznej kopii zapasowej HD do portu USB
działa (zwróć uwagę, że ciąg „test” to nazwa grupy w tym systemie)
# 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
W tym momencie spodziewałbym się, że będę mógł uzyskać dostęp do poszczególnych woluminów logicznych pod /dev/test/
. Uruchamianie lvdisplay
produkuje.
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
Jednak w /dev/test/
ogóle nie istnieje i dlatego nie mogę uzyskać dostępu do woluminów logicznych pod /dev/test/root
i /dev/test/swap_1
jak sugeruje lvdisplay.
Odpowiedzi:
Istotą UUID jest unikatowa identyfikacja czegoś, a to, co próbujesz zrobić, czyni je niepowtarzalnymi. Bardzo wątpię, czy jest to możliwe. Bawiłem się z,
pvchange -u
aby zmienić UUID duplikatu PV, ale operacja zawsze kończyła się niepowodzeniem.Jeśli naprawdę potrzebujesz zamontować kopie zapasowe na hoście na żywo, sugeruję, aby wykonać kopię zapasową LV indywidualnie (tj. Utworzyć nową PV, VG i LV na urządzeniu do tworzenia kopii zapasowych i dd każdą LV osobno).
źródło
Jeśli chcesz zamontować lv z dysku klonowania, znalazłem tę przydatną metodę tutaj http://www.linuxquestions.org/questions/linux-hardware-18/unable-to-change-uuid-of-cloned-drive- device-left-open-4175470893 /
sdx, sdy .. to sklonowane dyski, które tworzą vg.
Następnie powinieneś móc zamontować lvs ze sklonowanego dysku.
źródło
vg
- na przykład,vgimportclone -n orignalvgname_clone /dev/sdx /dev/sdx2 /dev/sdx5
ale oczywiście może się to bardzo różnić w zależności od przypadku.Odpowiedź trekkerboy / modonnell @ linuxquestions jest najprostsza, użyj
vgimportclone
.Zauważ również, że po utworzeniu klonu musisz go aktywować za pomocą
vgchange -a y newvgname
i musisz wyczyścić węzły urządzeń oldvgname za pomocądmsetup remove /dev/oldvgname/*
.Dla porównania poniżej przedstawiono bardziej ręczną metodę, która najwyraźniej przypomina podzbiór tego, co można przeczytać w źródle
vgimportclone
.Możesz to zrobić, jeśli możesz tymczasowo dezaktywować zarządzanie oryginalną kopią, dodając do
devices
filtra wzór pasujący do oryginałulvm.conf
. Na przykład, jeśli sklonowany/dev/sdx
w/dev/sdy
, trzeba tymczasowo dodać/dev/sdx
dofilter
wdevices { ... }
sekcji.Oryginalne urządzenia pozostaną w trybie online, ale narzędzia LVM je zignorują. Zamontowane na nich systemy plików pozostaną zamontowane i będą działać, co nie jest ściśle powiązane z zarządzaniem LVM.
Po zainstalowaniu filtra zrób nowy
vgscan
, aby upewnić się, że duplikaty i tylko one są teraz zarządzane przez LVM. Możesz upewnić się, że widzisz zduplikowane/dev/sdy
urządzenia za pośrednictwem nppvs
.Następnie wykonaj:
Spowoduje to dezaktywację wywoływanej grupy woluminów
originalvgname
, ale ponieważ widoczne są tylko zduplikowane urządzenia, dezaktywuje je na nich (oryginałoriginalvgname
jest już niewidoczny z powodu powyższego filtra). Ten krok jest konieczny, abyś mógł swobodnie zmieniać atrybuty nieaktywnej grupy woluminów i składowych woluminów fizycznych.To da nowe UUID do duplikatów.
Spowoduje to zmianę nazwy zduplikowanej grupy woluminów.
Następnie możesz usunąć filtr
lvm.conf
i ponownie przeskanować, a oba zestawy urządzeń LVM będą widoczne pod różnymi nazwami i identyfikatorami UUID.Alternatywnie, jeśli tak naprawdę nie jesteś zainteresowany zachowaniem oryginalnej nazwy VG i identyfikatorów UUID PV / VG, możesz je zamiast tego pozbyć, por. /superuser/256061/lvm-and-cloning-hds
źródło
vgscan
, oznacza to po prostu, że w tym momencie narzędzia LVM widzą duplikaty (a nie oryginalne). Chodzi o to, że nie możesz mieć ich aktywnych jednocześnie - ani jednego, ani drugiego, a nie obu. Jak tylko znajdziesz się w stanie, w którym widzisz tylko duplikaty, możesz na nich operować.Problem ten spotkałem wczoraj. Mam konfigurację systemu plików (LVM (MD (sda, sdb, sdc-syncing-only-weekly-base))) w Linuksie i potrzebowałem dostępu do starych danych na sdc.
W pewnym stopniu rozwiązałem ten problem, dołączając dysk kopii zapasowej (sdc) do maszyny wirtualnej. Jest to bezpieczna operacja, o ile podłączam dysk z „qemu ... -drive file = / dev / sdc, readonly” (lub użyj opcji migawki do konfiguracji kopiowania przy zapisie).
źródło