これが私の状況です:
/dev/sda
で使用可能なブロックの数の違いは10MB未満ですが、宛先サーバーの配列は何らかの理由で数メガバイト小さくなっています。私がしたいこと:
fsck
を実行します。/
パーティションの空き領域であるためです。/
パーティションのサイズを調整して、コピー時に、宛先ディスクのほんのわずかに小さいサイズに収まるようにサイズが変更されるようにします。私の質問:
/dev/sda
のサイズの差(バイト単位)を計算してから、e2resize
を使用して/
パーティションのサイズを非破壊的に縮小する必要がありますソース側宛先側のスペースに収まるように?dd
を実行する必要があります。ソースから宛先まで(ssh
を介して)/dev/sda
、またはで同等のパーティションレイアウトを作成する必要があります。宛先と各でdd
を実行しますpartition?一度にパーティションを処理するとブートローダーの問題が発生しますが、一度にパーティションを処理しない場合、宛先が可能な限り多くのバイトを書き込んだら、dd
はデータの転送を停止することを知る必要がありますhold(ソースのパーティションレイアウト内の他のすべてのパーティションの論理的に「右側」にある最後のブロックの/
パーティションの最後を「閉じる」ことを願っています)。いくつかのその他。詳細:
これは厄介ですが、実行可能です。
ここでは、/
が/dev/sda3
にあり、/boot
が/dev/sda1
にあると仮定します。
古いサーバー上のファイルシステムを可能な最小サイズに縮小します。
oldserver # resize2fs -M /dev/sda3
新しいサーバーのディスクを、同じサイズの/boot
、スワップスペース、および新しい/
パーティション(およびその他必要なもの)でパーティション化します。
newserver # parted /dev/sda
/
および/boot
ファイルシステムをコピーします。
oldserver # dd if=/dev/sda1 | ssh root@newserver "dd of=/dev/sda1"
oldserver # dd if=/dev/sda3 | ssh root@newserver "dd of=/dev/sda3"
新しいサーバーのパーティションは古いサーバーのパーティションよりもわずかに小さいため、この最後に偽のNo space left on device
メッセージが表示されます。ただし、手順1でファイルシステムを縮小したので、これは問題ではありません。
新しいサーバー上のファイルシステムのサイズをパーティションのサイズに変更します。
newserver # resize2fs /dev/sda3
GRUBを新しいディスクにインストールします。
newserver # mount /dev/sda3 /mnt
newserver # mount /dev/sda1 /mnt/boot
newserver # mount -o bind /dev /mnt/dev
newserver # mount -o proc proc /mnt/proc
newserver # chroot /mnt /bin/bash
newserver(chroot) # grub-install /dev/sda
newserver(chroot) # exit
残りの修正(IPアドレスなど)を終了します。
パーティションの空き領域をコピーしないようにする方法はおそらく見つかりますが、すべてをコピーするよりも調査に時間がかかる可能性があります...
新しいサーバーで新しいファイルシステムをmkfs
してから、古いサーバーからrsync
します。これは再起動可能で一貫性があり、各ファイルは簡単に個別に検証できます。ファイルシステムの未使用のセクション(フォレンジックコピーではない)を破棄する場合、この方法を使用しない理由はわかりません。 GRUBを再実行する必要がありますが、それは難しいことではありません。
ファイルシステムに対応した生のコピーを説明するには時間がかかるので、rsyncソリューションが機能しない理由についてコメントしない限り、入力する必要はありません。
本当にブロックデバイスレベルでデータを転送したい場合は、ダウンタイムが最小限のサーバーを移行するために使用していた非常に便利なトリックを1つ考えることができます。
重要なのは、データパーティションがミラーの唯一のアクティブな半分であるソースサーバー上に劣化したミラーを作成し、 [〜#〜] aoe [〜#〜を介して2番目のサーバーから宛先パーティションをエクスポートすることです。 ] (両方のサーバーが同じブロードキャストドメインにあると思います)。次に、ソースサーバーで、ネットワークブロックデバイスを劣化したミラーに接続して、再構築を開始します。再構築が完了するまで待ち、ミラーを停止し、AOEエクスポートされたデバイスを削除して問題ありません。
もう少し詳細が続きます(簡潔にしようと思います)。
コンポーネント:
mdadm
buildモード(メタデータなしのアドホックミラー);vblade
ブロックデバイスをAOEネットワークデバイスとしてエクスポートする場合。aoe-tools
AOEネットワークブロックデバイスをインポートします。宛先サーバーにパーティションテーブルを作成してから、宛先に合うようにソースパーティションを縮小する必要があります。 GRUBを新しいMBRに簡単にインストールできます。新しく作成されたパーティションテーブル上でパーティションだけを同期すると、エラーが発生しにくくなります。
受信側では、vblade
ツールを使用してパーティションをエクスポートする必要があります。ソースサーバーでは、aoe-tools
をインストールした後にエクスポートされたデバイスを確認できます(aoe-discover
を実行してから/dev/ether/
を確認してください。デバイス)。
次に、sourceドライブを使用してソースサーバー上にraid1デバイスを構築する必要があります。
mdadm --build /dev/md0 -n2 -l1 --force /dev/sda
この後、新しく構築されたミラーを調べることができます。
mdadm --detail /dev/md0
cat /proc/mdstat
この時点で、エクスポートされた宛先パーティションをこのミラーに安全にアタッチできます。
mdadm /dev/md0 --add /dev/ether/eX.Y
次に、同期の進行状況を監視します。
watch -n5 cat /proc/mdstat
同期が完了したら、ミラーを停止します。ソースサーバーでmdadm --stop /dev/md0
、宛先サーバーでvblade
プロセスを終了し、2番目のサーバーでGRUB)をインストールし、IPアドレスを変更します。 、など。
実際、このトリックを使用すると、同期されたボックスを再起動するだけでダウンタイムが発生し、ほぼライブのボックス間でサーバーを移動できます。
パフォーマンス上の理由から、リンクのMTUを増やすこともお勧めします(または、可能であれば、ジャンボフレームを有効にして別のVLAN)を設定します)。
AOEの代わりにnbd-server
/nbd-client
(またはラフにしたい場合はiSCSI)のようなものを使用することもできますが、AOE(vblade
+ aoe-tools
)非常にシンプルなインターフェイスと優れたパフォーマンス(TCP/IPオーバーヘッドなし)を備えています。