LVMを構成するディスクをddでまるっとコピーするとどうなる?(前編) [Linux(LVM/RAID/Storage)]
例えば、ストレージサーバみたいなハードを使っているとして、運用系ディスク上でLVMを使っているとします。このディスクをストレージサーバが持っているような、運用系ディスクをまるっとバックアップ用ディスクにコピーしてしまう機能でコピーした場合、そのバックアップした側のディスクがどのように見えるか…というところに興味がわいたので試してみた。
とはいえ、そんな凄い環境は当然のごとく無いので、VirtualPC上で、/dev/hdb2と/dev/hdb3とを用意。
/dev/hdb2をLVMに組み込み、適当なデータを置いてみる。
ここまでで、/dev/hdb2はLVMに組み込まれた状態で稼働しているボリュームということになります。
これを/dev/hdb3にddコマンドでまるっとコピーしてみましょう。
これで、/dev/hdb2と/dev/hdb3と、同じ内容になっている「はず」。
PV UUIDが同一になっていることが判りますし、「Found duplicate PV...」と警告表示も出ていますので、物理ボリュームの情報が重複している(=複製された)ことが判ります。
つーか、/dev/hdb2を見ているはずなのに/dev/hdb3が表示されてますよ!?@@;
で、ここまでやって発見その1。ボリュームグループ内に登録されている物理ボリュームが勝手に変更されている件!
さきほどのLVM構築直後のvgdisplayコマンドでは…
でも、今再びvgdisplayしてみると…
あれれれー?/dev/hdb3になってるお?
これは、PV UUIDで管理していて、ドライブデバイス名はどうでもいい…ということなんでしょうかね?
このままの状態で、うっかりファイルシステムを再マウントしてファイルを読み書きしようものなら、運用系ではなくバックアップ系のボリュームを読み書きしてしまうかもしれない?というオペミスを引き起こしそうな雰囲気が微妙にしてきましたね。
これが、マウントされたままでコピーした状態だとどうなるでしょうか。/dev/hdb3を一旦たたき壊してからやってみましょう。
…。
…。
あれ?
間違って dd if=/dev/zero of=/dev/hda3 bs=1M count=100 とかうっかりやってしまい、テストする環境をたたき壊してしまったので、続きはまた後でね!!!!><;
とはいえ、そんな凄い環境は当然のごとく無いので、VirtualPC上で、/dev/hdb2と/dev/hdb3とを用意。
# fdisk /dev/hdb このディスクのシリンダ数は 66575 に設定されています。 間違いではないのですが、1024 を超えているため、以下の場合 に問題を生じうる事を確認しましょう: 1) ブート時に実行するソフトウェア (例. バージョンが古い LILO) 2) 別の OS のブートやパーティション作成ソフト (例. DOS FDISK, OS/2 FDISK) コマンド (m でヘルプ): p Disk /dev/hdb: 34.3 GB, 34359214080 bytes 16 heads, 63 sectors/track, 66575 cylinders Units = シリンダ数 of 1008 * 512 = 516096 bytes デバイス Boot Start End Blocks Id System /dev/hdb1 1 2000 1007968+ 83 Linux /dev/hdb2 2001 22001 10080504 83 Linux /dev/hdb3 22002 42002 10080504 83 Linux
/dev/hdb2をLVMに組み込み、適当なデータを置いてみる。
# pvcreate /dev/hdb2 Physical volume "/dev/hdb2" successfully created # vgcreate vg_test /dev/hdb2 Volume group "vg_test" successfully created # vgdisplay -v Finding all volume groups Finding volume group "vg_test" --- Volume group --- VG Name vg_test System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 9.61 GB PE Size 4.00 MB Total PE 2461 Alloc PE / Size 0 / 0 Free PE / Size 2461 / 9.61 GB VG UUID SqA0jd-h9fp-U5Pk-vox6-71Gh-6HtJ-fOAkRb --- Physical volumes --- PV Name /dev/hdb2 PV UUID moE0a3-6fLX-IRjj-3JcQ-bzC2-4mkO-9m6c5A PV Status allocatable Total PE / Free PE 2461 / 2461 # lvcreate vg_test -l 2461 -n vol00 Logical volume "vol00" created # mke2fs -j /dev/vg_test/vol00 # mkdir -p /mnt/test # mount /dev/vg_test/vol00 /mnt/test # df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/hda3 15G 1.7G 13G 12% / /dev/hda1 122M 11M 105M 10% /boot tmpfs 252M 0 252M 0% /dev/shm /dev/mapper/vg_test-vol00 9.5G 150M 8.9G 2% /mnt/test # cd /mnt/test # cp -r /etc/* .
ここまでで、/dev/hdb2はLVMに組み込まれた状態で稼働しているボリュームということになります。
これを/dev/hdb3にddコマンドでまるっとコピーしてみましょう。
# cd # umount /mnt/test # df Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/hda3 15102624 1703976 12619096 12% / /dev/hda1 124427 11126 106877 10% /boot tmpfs 257748 0 257748 0% /dev/shm # dd if=/dev/hdb2 of=/dev/hdb3 20161008+0 records in 20161008+0 records out 10322436096 bytes (10 GB) copied, 7884.98 seconds, 1.3 MB/s
これで、/dev/hdb2と/dev/hdb3と、同じ内容になっている「はず」。
# pvdisplay /dev/hdb2 Found duplicate PV moE0a36fLXIRjj3JcQbzC24mkO9m6c5A: using /dev/hdb3 not /dev/hdb2 --- Physical volume --- PV Name /dev/hdb3 VG Name vg_test PV Size 9.61 GB / not usable 248.00 KB Allocatable yes (but full) PE Size (KByte) 4096 Total PE 2461 Free PE 0 Allocated PE 2461 PV UUID moE0a3-6fLX-IRjj-3JcQ-bzC2-4mkO-9m6c5A # pvdisplay /dev/hdb3 Found duplicate PV moE0a36fLXIRjj3JcQbzC24mkO9m6c5A: using /dev/hdb2 not /dev/hdb3 Found duplicate PV moE0a36fLXIRjj3JcQbzC24mkO9m6c5A: using /dev/hdb3 not /dev/hdb2 --- Physical volume --- PV Name /dev/hdb3 VG Name vg_test PV Size 9.61 GB / not usable 248.00 KB Allocatable yes (but full) PE Size (KByte) 4096 Total PE 2461 Free PE 0 Allocated PE 2461 PV UUID moE0a3-6fLX-IRjj-3JcQ-bzC2-4mkO-9m6c5A
PV UUIDが同一になっていることが判りますし、「Found duplicate PV...」と警告表示も出ていますので、物理ボリュームの情報が重複している(=複製された)ことが判ります。
つーか、/dev/hdb2を見ているはずなのに/dev/hdb3が表示されてますよ!?@@;
で、ここまでやって発見その1。ボリュームグループ内に登録されている物理ボリュームが勝手に変更されている件!
さきほどのLVM構築直後のvgdisplayコマンドでは…
# vgdisplay -v (途中省略) --- Physical volumes --- PV Name /dev/hdb2 PV UUID moE0a3-6fLX-IRjj-3JcQ-bzC2-4mkO-9m6c5A PV Status allocatable Total PE / Free PE 2461 / 2461
でも、今再びvgdisplayしてみると…
vgdisplay -v Finding all volume groups Found duplicate PV moE0a36fLXIRjj3JcQbzC24mkO9m6c5A: using /dev/hdb3 not /dev/hdb2 Finding volume group "vg_test" (途中省略) --- Physical volumes --- PV Name /dev/hdb3 PV UUID moE0a3-6fLX-IRjj-3JcQ-bzC2-4mkO-9m6c5A PV Status allocatable Total PE / Free PE 2461 / 0
あれれれー?/dev/hdb3になってるお?
これは、PV UUIDで管理していて、ドライブデバイス名はどうでもいい…ということなんでしょうかね?
このままの状態で、うっかりファイルシステムを再マウントしてファイルを読み書きしようものなら、運用系ではなくバックアップ系のボリュームを読み書きしてしまうかもしれない?というオペミスを引き起こしそうな雰囲気が微妙にしてきましたね。
これが、マウントされたままでコピーした状態だとどうなるでしょうか。/dev/hdb3を一旦たたき壊してからやってみましょう。
…。
…。
あれ?
間違って dd if=/dev/zero of=/dev/hda3 bs=1M count=100 とかうっかりやってしまい、テストする環境をたたき壊してしまったので、続きはまた後でね!!!!><;
いままさに コピーしたディスクのpvのuuidが重複して悩んでいます。変更できないのかな?? またgoogleの旅に出てきます。
by さすらいのxen初心者 (2010-10-02 12:49)