互いに正確にコピーされた2つのLVMボリューム（同じUUID）を同時にマウントすることは可能ですか？

ライブシステムのハードドライブを（ddを使用して）いくつかの複数のバックアップハードドライブに複製しました。ライブシステムのルートパーティションはLVMボリュームです。バックアップコピーは、元のコピーのドロップイン置換を目的としています。つまり、バックアップコピーはマスターと同じUUIDを持つ必要があります。

簡単な質問：バックアップHDの1つをライブシステムにマウントすることは可能ですか？同じようにしようとすると、LVMは同じUUIDとボリュームグループ名が原因で、これについて混乱しています。最初に元のLVMグループの名前を変更するための[この回答] [1]にあるヒントに従って、私は試しました：

1. 外部バックアップHDをUSBポートに接続する

2. 実行中（文字列 'test'はこのシステムのグループ名です）

# 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

この時点で、の下にある個々の論理ボリュームにアクセスできたはず/dev/test/です。ランニングがlvdisplay生み出す。

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

しかし、/dev/test/全てに存在しないので、私はで論理ボリュームにアクセスすることはできません/dev/test/rootと/dev/test/swap_1示唆しlvdisplayを通り。

UUIDの重要なポイントは、何かを一意に識別することであり、ユーザーが実行しようとしていることにより、一意ではなくなります。これが可能であることを私は強く疑います。pvchange -u複製されたPVのUUIDを変更するために遊んでみましたが、操作は常に失敗しました。

ライブホストにバックアップをマウントする必要がある場合は、LVを個別にバックアップすることをお勧めします（つまり、バックアップデバイスで新しいPV、VG、LVを作成し、各LVを個別にddします）。

クローンディスクからlvをマウントする場合は、この便利な方法をここで見つけましたhttp://www.linuxquestions.org/questions/linux-hardware-18/unable-to-change-uuid-of-cloned-drive- device-left-open-4175470893 /

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

sdx、sdy ..は、vgを構成するクローンディスクです。

vgchange -ay orignalvgname_clone

この後、クローンディスクからlvsをマウントできるはずです。

trekkerboy / modonnell @ linuxquestionsの答えは最も簡単vgimportcloneです。

また、クローンを作成した後vgchange -a y newvgname、でそれをアクティブ化する必要があり、でoldvgnameのデバイスノードをクリーンアップする必要があることにも注意してくださいdmsetup remove /dev/oldvgname/*。

参考までに、以下はより手動の方法であり、明らかにのソースで読み取ることができるもののサブセットに似ていvgimportcloneます。

最初に元のコピーの管理を一時的に無効にできる場合は、元の一致するパターンをのdevicesフィルターに追加することで実行できますlvm.conf。あなたはクローン化された場合たとえば、/dev/sdxに/dev/sdy、あなたは一時的に追加する必要があります/dev/sdxにfilter内devices { ... }のセクション。

元のデバイスはオンラインのままですが、LVMツールはそれらを無視します。それらにマウントされたファイルシステムはマウントされた状態で動作し続けますが、これはLVM管理と密接に結び付いていません。

フィルターを設定したら、新しいvgscanを実行して、複製とそれらのみがLVM管理下にあることを確認します。重複する/dev/sdyデバイスが表示されることを確認するには、などを使用しますpvs。

次に行います：

vgchange -a n originalvgname

これにより、というボリュームグループが非アクティブになりoriginalvgnameますが、重複するデバイスのみが表示されるため、それらのデバイスでは非アクティブになります（originalvgname上のフィルターにより、元のデバイスはすでに非表示になっています）。このステップは、現在非アクティブなボリュームグループとその構成要素である物理ボリュームの属性を自由に変更できるようにするために必要です。

pvchange -u physicaldevice
vgchange -u originalvgname

これにより、複製に新しいUUIDが付与されます。

vgrename originalvgname newvgname

これにより、複製されたボリュームグループの名前が変更されます。

その後、フィルターを削除してlvm.conf再スキャンすると、LVMデバイスの両方のセットが異なる名前とUUIDで表示されます。

または、元のVG名とPV / VG UUIDを保持することに実際に関心がない場合は、代わりにそれらを破棄できます。/superuser/256061/lvm-and-cloning-hds

昨日この問題に遭遇しました。Linuxにfilesystem（LVM（MD（sda、sdb、sdc-syncing-only-weekly-basis）））構成があり、sdcの古いデータにアクセスする必要がありました。

VMにバックアップディスク（sdc）を接続することで問題を多少解決しました。これは、「qemu ... -drive file = / dev / sdc、readonly」を使用してディスクを接続する（または、コピーオンライト構成のスナップショットオプションを使用する）限り、安全な操作です。