ライブサーバーを移行する

私は問題があります、私は通常のサービス（httpd、mail、sql）を備えた実行中のサーバーを持っています、そして私は完全なデータ損失を防ぐために本当に高速でなければならないようです（私のRAIDアレイは失敗したので、私は単一に依存していますhdd now）。

HowtoForgeのhowtoで構築されたシステム全体で、Squeezeのシステムを読むと、簡単にできるように見えますか？（仮想）ユーザーを新しいボックスに移行します。

これは非常に具体的な問題であることは本当にわかっていますが、移行プロセス全体の重要なポイントを教えてください。せいぜいどこに集中する必要があるのですか？プロセスをどのように開始しますか？

いくつかの背景情報：

• 2つのサーバーは互いに200km離れているため、移行はインターネット経由で行う必要があります
• 両方のサーバーはDebian、古いサーバーはEtch、新しいサーバーはSqueezeになります
• 重要なサービスはメールです。ウェブサイトはしばらく停止することがあります
• RAIDは、RAID 1の2つのディスク（両方のマシン）を意味します
• 古いボックスは、ホストされているすべてのドメインのDNS1です

私の（本当に）基本的なアウトライン：

• 古いシステムと同様のシステムを構築する（同じような仮想メール構造、同じ暗号化タイプで保存されたパスワード、古いシステムにはわからないため）
• すべてを確認できるドメインを1つ作成します（dns、email、wwwは問題ありません）
• 古いドメインが何も実行しなくなるまでドメインを移行します

私の死角：

• SqueezeでRAID-1を実行する方法についての簡単な説明が見つかりません（Lennyのハウツーで十分ですか？）
• 必要なときに特定のユーザー権限で特定のフォルダー（ユーザーのメールフォルダーなど）をコピーする方法は？（rsyncはこれを行いますか？）
• 新しいマシンでDNSをセットアップする方法（古いマシンはDNS1）（新しいマシンもDNSである必要があり、移行されたドメインはDNS1として自身を使用する必要がありますか？）
• DNS更新時間のために電子メールの損失を防ぐにはどうすればよいですか（新しいマシンをMXとして設定する必要がありますか？）

基本的なアウトラインは多かれ少なかれ正確です。

squeezeインストーラーはソフトウェアRAIDを正常に実行します。相違点の1つは、squeezeがデフォルトでgrub2を使用することです。lennyはgrub-legacy（0.9と思う）を使用しました。これにより、特にgrubが障害発生時に両方のディスクから確実に起動するように、grubの管理が多少異なります。いつでもgrub-legacyに戻すことができます。これは、この問題に直面したときに最後にやったことです。ただし、いずれかのディスクに障害が発生した場合にリブートできることを確認するために、実行していることは何でもテストしてください。

データをコピーするには、rsyncを使用してください。同じuid / gidsで正しいアカウントを最初に設定してから、rsyncを設定しますが、後でいつでも修正できます。rsync -avPHAXはすべてを取得する必要があります（-aは-H [ard links] -A [CLs]および-X [tended attributes]を除くほとんどのものを取得するため、これは便利です。

効果的なアップグレードを同時に行っていることを考えると、微妙な方法でサービスが中断する準備をしてください。構成はわずかに変更されます。最近似たようなことをしたので、私は似たような移行を行い、事後しばらくして最終ホストをアップグレードすることを望んでいると思います。すべてを移行し、同時にアップグレードを管理することは巨大なタスクになりました。

追加の問題点に合わせて更新：

DNSについては、すべてのDNS ホスティングを新しいマシンに1ステップで移動します。記録はそのままにしておきますが、更新はすぐに設定します（10分程度）。これにより、各ドメインの移動が完了すると、DNSレコードを新しいマシンに移動できます。DNSを移動するには、ホストしているドメインのwhoisレコードを更新する必要がある場合がありますので、注意してください。実際には、他の何かを開始する前に、すべてのドメインの更新をすぐに設定します。結果がひどくキャッシュされて問題が発生することより悪いことはありません。

電子メールの損失について：メールを新しいサーバーに移動するときは、DNSレコードが更新されてプライマリMXが新しいサーバーを指すようにし、古いサーバーがドメインの中継を許可するように構成されていることを確認します。古いサーバーと新しいサーバーの両方に最新のDNSビューがある限り、古いサーバーのメールサービスはプライマリMXではなく、新しいプライマリにメールを転送します。メールは配信の短い遅延にも対処します-したがって、両方のマシンへのすべての電子メールアクセスをシャットダウンまたはファイアウォールし、すべてを一度に移動し、新しいマシンでテストしてから、MXレコードを移動して新しいマシンでメールを開くことができます。SMTPは停止に対処するように設計されており、比較的短い停止（4時間未満と思われます）でも一時的なエラー通知は生成されません。

追加して更新：

別の可能性は、新しいサーバー上にVMを作成し、古いサーバー全体をこの新しいVMのディスクイメージにrsyncすることです。その後、VMを起動してIPアドレスなどを更新し、このVM内に元のサーバーの完全に機能するレプリカを作成できます。潜在的にはるかに少ない労力ですが、KVMやVirtualboxなどのVMスタックに精通していない場合、それは価値がないかもしれません。