LVMとクローンHD
Linuxを使用して、私はいくつかのバックアップレベルを持っています。それらの1つは、ラップトップハードディスクの外部USBディスクへのセクターごとの定期的なコピー（ddを使用）です。はい、リモートrsyncのような他のバックアップもあります。
このアプローチ（ディスクdd）は、LVMボリュームのないHDDのクローンを作成するときに問題ありません。これは、いつでも外部ディスクを接続して、_/dev/sdb*_ではなく_/dev/sda*_をマウントするだけでパーティションをマウントできるためです。些細で便利です。
今日、私はすべてのハードディスク（_/boot_を含む）をLVMに移動しました。すべてが正常に動作します。数日間ストレスを感じてから、セクターごとに外付けハードディスクにコピーします。
今、私は問題を抱えていると思います。
将来、外部USB HDDを接続してファイルを回復すると、OSは同じ名前と同じUUIDを持つ重複したLVM構成を検出します。 vgrename（LVMの名前は、内部HDDまたは外部HDDのどちらに変更されますか？）を実行しても、複製されたUUIDは変更されません。 名前とUUIDを変更するコマンドはありますか？理想的には、HDDのクローンを作成してから、LVMグループ名とそのUUIDを変更しますが、その方法がわかりません。
別の関連する問題は...
以前は、外部ディスクを使用してラップトップを起動し、BIOSブートメニューを使用して、GRUBエントリを手動で変更して_/dev/sdb_ではなく_/dev/sda_から起動しました。しかし今は私の現在のGRUB構成はLVM論理ボリュームから直接起動します。次のようになります：set root='(LVM-root)' in my _grub.cfg_。だから... 何が起こっているのか重複したボリュームで発生しますか？
なにか提案を？
外付けハードディスクを再パーティション化し、バックアップ戦略をddからrsyncに変更できると思いますが、このディスクにもWindowsがインストールされているため、物理的な「実際の」コピーが必要です。
1年後にこの問題を閉じます。私は答えを 私の個人的なウェブサイト に書きました。それが他の誰かに役立つことを願っています。
Rsyncから外部ディスク、リモートコンピューター上のrsync + ZFSまで、いくつかのレベルのバックアップを使用しています。私が行うバックアップの1つは、ラップトップのハードディスクから接続された外部USBへの「dd」です（バックアップ手順の間のみ接続されます）。たとえば、ラップトップを旅行に持っていく前にこれを行います。
この手順は何年もの間うまくいきました。ラップトップでLVMを使い始めるまで。
コンピューターでLVMを使用している場合は、
dd（LiveCDから起動）を使用してハードディスクをコピーし、コンピューターが正常に動作しているときに外付けハードディスクを接続します。後で、データが破損し、すべてが失われます。あらゆる修理を超えたファイルシステム!!!。なぜ？。外付けハードディスクを接続すると、OSは両方のディスクで同じLVM構成を認識し、マルチパスリンクを介してアクセスできる両方のディスクが同じであると素朴に想定するため、読み取りと書き込みが両方のディスクに分散され、両方が破損します。ライブデータとバックアップの両方をゴミ箱に捨てます！。
これは私に一度起こりました。データを失いました。数日前に他のバックアップを持っていたので、それほど重要なものを失うことはありませんでしたが、それは非常に煩わしく、バックアップ戦略の欠陥を露呈しました。
解決策：バックアップディスクのLVM構成が異なることを確認してください。問題は...どうやってやるの？
Superuser.com（Stack Exchange）に質問を投稿しましたが、良い回答が得られませんでした。そこで、独自の手順を開発し、1年以上のバトルテストを行った後、ここに投稿して元の質問を閉じます。
何か問題が発生した場合、コンピュータが自動的に起動しないことを確認してください。私の場合、電源を入れ直してもラップトップは自動的に起動しません。さらに、ハードディスクは暗号化されているため、パスワードを要求されます。
手順を完了する前にバックアップディスクを接続した状態で再起動すると、両方のディスクが破損する可能性があるため、これが必要です。
ライブCDから起動します。データを回復できると期待している場合は、ライブパーティションから「dd」を実行することはできません:-)。
将来的に試すことは、コンピューターの使用中にLVMスナップショットを使用してバックアップを実行できるようにすることですが、LVMの重複の問題があり、ここでは回避しようとしています。別のオプションは、データをライブで外付けハードディスクにミラーリングするようにLVMを再構成し、同期が完了した後にミラーリングを解除することです。しかし、それは危険に聞こえ、WindowsパーティションやLVMボリュームに保持していないデータをバックアップしません。
LiveCDを起動した後、外付けUSBハードディスクを接続します。
「root」としてログインし、
vgchange -a nを実行します。このコマンドは、両方のディスクのLVMを無効にします。確かに、私はコマンドを数回実行します。
/dev/sdaがソース（内蔵ハードディスク）であり、/dev/sdbが宛先（USB外付けハードディスク）であることを確認してください。たとえば、dd if=/dev/sdb of=/dev/nullを実行して、どのハードディスクLEDが点滅するかを確認します。どのディスクがどれであるかが確実な場合は、
dd if=/dev/sda of=/dev/sdb bs=65536を使用してコピーを実行します。私の構成では、バックアップには4時間かかります。私の内蔵ハードディスクは500GBで、USBは35MB /秒でコピーしています。私は寝ている間、夜にこれをします。外部USBハードディスクは、AT最小、内部ハードディスクと同じ大きさである必要があります。それは明らかですよね？
このコピーが完了すると、内蔵ハードディスクの正確なクローンが作成されます。バックアップが完了しました。しかし、すでに説明したように、内蔵ハードディスクの操作中にこのハードディスクをコンピュータに接続すると、問題が発生します。 LVM構成を変更する必要があります。
ここで、「dd」が完了したら、「sync」を実行して、外部UDBハードディスクを取り外します。
pvchange --uuid /dev/sda*を実行します。このコマンドは、内蔵ハードディスク内のすべての物理ボリュームのUUIDを変更します。このコマンドは、LVMの物理ボリュームではないパーティションがある場合でも、自動的かつ安全にスキップされるため、安全です。システムは、パーティションタイプと、LVMの作成時に「pvcreate」を実行したため、どのパーティションが物理ボリュームであるかを認識します。
vgchange -u LVMを実行します。このコマンドは、LVMボリュームグループのUUIDを変更します。ちなみに私のボリュームグループは「LVM」と呼ばれています。
vgscanを実行します。このコマンドは、内部ハードディスク（現在接続されている唯一のハードディスク）をスキャンし、そこにLVMボリュームグループを見つけます。
vgrename LVM LVM2を実行して、ボリュームグループの名前を変更します。次に、外付けUSBハードディスクを接続します。
もう一度「vgscan」して、今度は外部USBハードディスクでボリュームグループを見つけます。これで、2つのボリュームグループができました。 1つは内蔵ハードディスクで「LVM2」と呼ばれ、もう1つはUSB外付けハードディスクで「LVM」と呼ばれます。
外付けUSBハードディスクのボリュームグループの名前を
vgrename LVM LVM_BACKUPに変更します。そして、内蔵ハードディスクのボリュームグループの名前を元の名前
vgrename LVM2 LVMに戻します。これで完了です。
vgdisplay -vで状況を確認できます。論理ボリュームのUUIDは両方のボリュームグループで同じであることがわかりますが、それでも問題は発生しないようで、変更方法がわかりません。
外付けUSBハードディスクを取り外し、安全な場所に保管し、コンピューターを再起動して、LiveCDを取り出し、ビジネスに戻ります。
以前の回答の1つに同意します。ディスク全体でddを実行することは、ここでは優れたソリューションではありません。 ddで立ち往生している理由が別のOSのバックアップに関係している場合は、それらの他のOSパーティションにのみddを使用し、Linuxパーティションにrsyncを使用できます。
問題の一部は、ファイルシステムを起動してマウントしているときにディスク全体のddを実行すると、バックアップの一貫性を確保する方法がないことです。 10回のうち9回動作する可能性がありますが、どのような負荷がかかっても、結果のバックアップが破損する可能性があります。これが発生しないようにする唯一の方法は、すべてのファイルシステムをアンマウントし、ddが実行されている間ずっとすべてのボリュームグループを非アクティブ化することです。 /がLVMからマウントされている場合はあまり便利ではありません。
いずれにせよ、このアプローチに固執することを主張する場合、複製されたvgの名前を変更するために探しているツールは「vgimportclone」と呼ばれます。デバイスレベルのスナップショットでの使用を目的としていますが、ddでも機能します。
問題を注意深く研究すると、正しいアプローチは次のようになると思います。
外付けHDを接続します。
2番目のHDのLVM管理を非アクティブ化します： "vgchange -a n/dev/LVM2"。
「dd」を使用してハードディスクのクローンを作成します。
物理ボリュームごとに、「pvchange -u/dev/hdb *」を使用して、クローンディスクの新しいUUIDを生成します。
「vgchange-uLVM」を使用してVGUUIDを変更します。これにより、VGの1つのUUIDが変更されます。これは、オリジナルまたはクローンである可能性があります。それは問題ではありません。違うだけで十分です。
クローンディスクのVGの名前を「LVM」から「LVM2」に「vgrename」で変更します。新しいVGを「発見」するための以前の「vgscan」なしでこれが機能するかどうかはわかりません。
これはうまくいくでしょうか？.
いくつかの理由から、ほとんどの場合、ddがバックアップに最適なオプションだとは思いません。誰かが言及した1つのオプションは、LVMのミラーリングを使用することです。外付けドライブを切断すると、再接続すると、ddのように空のセクターを含むすべてを100％コピーしなくても、再同期されます。しかし、個人的には、rsyncを使用して外部ドライブにコピーする方がより良い/簡単だと思います。 faaaaaarが最速であるだけでなく、バックアップは追加の手順をまったく必要とせずにすぐに使用できます。これを外付けドライブのLVMスナップショットと組み合わせると、複数のポイントインタイムコピーがあり、それらすべてを特別な手間をかけずにいつでも使用できます。