LVM と HD のクローン作成

以前の回答の1つに同意します-ディスク全体で dd を実行することは、ここでは優れたソリューションではありません。 dd で立ち往生している理由が別の OS のバックアップに関係している場合は、それらの他の OS パーティションにのみ dd を使用し、Linux パーティションには rsync を使用できます。

問題の一部は、ファイルシステムを起動してそこからマウントしている間にディスク全体の dd を実行すると、バックアップの一貫性を保証する方法がないことです。 10 回のうち 9 回は機能する可能性がありますが、負荷がかかると、結果のバックアップが破損する可能性があります。これが起こらないようにする唯一の方法は、すべてのファイルシステムをアンマウントし、dd の実行中はすべてのボリュームグループを無効にすることです。 / が LVM からマウントされている場合、あまり便利ではありません。

いずれにせよ、このアプローチに固執する場合、複製された vg の名前を変更するために探しているツールは「vgimportclone」と呼ばれます。これはデバイスレベルのスナップショットでの使用を意図していますが、dd でも機能します。

1年ぶりに本号を閉じます。答えは個人サイトに書きました。他の誰かに役立つことを願っています.

<ブロック引用>

外部ディスクへの rsync から、リモートコンピューター上の rsync+ZFS まで、いくつかのレベルのバックアップを使用しています。私が行うバックアップの 1 つは、時々、ラップトップのハードディスクから接続された外部 USB への「dd」です (バックアップ手順の間だけ接続されます)。たとえば、ラップトップを旅行に持っていく前にこれを行います。

この手順は何年もの間うまくいきました。ラップトップで LVM を使い始めるまで。

コンピュータで LVM を使用している場合は、dd を使用してハードディスクをコピーします (LiveCD からの起動) そして、コンピュータが正常に動作している間に外付けハードディスクを接続すると、後でデータが破損し、修復できないほどすべてのファイルシステムが失われます!!!.

どうして？。外付けハードディスクを接続すると、OS は両方のディスクで同じ LVM 構成を認識し、単純に両方のディスクが同じであり、マルチパスリンクを介してアクセスできると想定するため、読み取りと書き込みが両方のディスク間で分散され、両方が取り返しのつかないほど破損します。ライブデータとバックアップの両方を破棄します!

これは私に一度起こりました。データを失いました。数日前に別のバックアップをとっていたので、重要なものは何も失われませんでしたが、非常に煩わしく、バックアップ戦略の欠陥が露呈しました.

解決策:バックアップディスクの LVM 構成が異なることを確認します。問題は...どうやってそれを行うのですか?

superuser.com (Stack Exchange) に質問を投稿しましたが、良い回答が得られませんでした。そこで、私は独自の手順を開発し、1 年以上のバトルテストを行った後、ここに投稿して元の質問を閉じます。

何か問題が発生した場合、コンピュータが自動的に起動しないことを確認してください。私の場合、電源をオフにして再度オンにしても、ラップトップは自動的に起動しません。さらに、ハードディスクは暗号化されているため、パスワードを要求されます。

手順を完了する前にバックアップディスクを接続した状態で再起動すると、両方のディスクが破損する可能性があるため、これが必要です。
Live CD から起動します。データを回復できると期待する場合は、ライブパーティションから "dd" を実行することはできません :-)

将来的には、LVM スナップショットを使用して、コンピューターの使用中にバックアップを実行できるようにすることをお勧めしますが、LVM の重複の問題が発生するため、ここで回避しようとしています。もう 1 つのオプションは、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/s でコピーしています。夜、寝ている間にこれを行います。

外付け USB ハードディスクは、少なくとも内蔵ハードディスクと同じ大きさでなければなりません。当たり前ですよね？
このコピーが完了すると、内蔵ハードディスクの正確なクローンが作成されます。バックアップが完了しました。しかし、すでに説明したように、内蔵ハードディスクで作業しているときにこのハードディスクをコンピュータに接続すると、問題が発生します。 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 を取り出して、業務に戻ります。