Linuxバックアップを新しいハードウェアに復元する
サーバーのバックアップを新しいハードウェアに復元するための this serverfaultの質問の指示に従うことを検討していました。私はプロセス全体に少し混乱していて、本当に答えたいいくつかの具体的な質問があります。
定義されたバックアップ手順に従った場合、これは明らかに物理ドライブを取り出してターゲットマシンに入れることと同じでしょうか？
異なるハードウェアデバイスではどうなりますか？元のマシンに存在しないハードウェアは、ターゲットマシンでのバックアップの復元後に手動でセットアップする必要がありますか？
クリーンなベアインストールを実行し、古いシステムの完全バックアップでコピーする場合の問題は何ですか？
MBRとパーティションテーブルをコピーすることが重要なステップであるのはなぜですか？
最後に、新しいハードウェアに移行するときに、インストールされているすべてのプログラムと構成（Apache、バインドなどを含む）を保持し、インストーラーでOSとドライバーの問題に対処してもらいたいと思います。これはまったく実行可能ですか？
ありがとう
定義されたバックアップ手順に従った場合、これは明らかに物理ドライブを取り出してターゲットマシンに入れることと同じでしょうか？
かなり。新しいシステムが同じタイプのドライブを受け入れる場合は、おそらくドライブを移動するだけで、ほとんどの作業は他の作業なしで機能します。
異なるハードウェアデバイスではどうなりますか？元のマシンに存在しないハードウェアは、ターゲットマシンでのバックアップの復元後に手動でセットアップする必要がありますか？
たぶん、ほとんどの主要なディストリビューションの一部としてストックカーネルを使用する場合、ほとんどのハードウェアは通常、箱から出してすぐにサポートされることを覚えておいてください。ドライブをあるボックスから別のボックスに移動すると、おそらく問題なく動作します。
Linuxの場合、GUIのないサーバーで最も壊れやすいのはストレージです。したがって、古いボックスがIDEで、新しいボックスがSCSIまたはSATAの場合、新しいパーティションを反映するようにfstab、ブートローダーなどを変更する必要があります。
デスクトップに使用されるシステムは、ビデオ/サウンド/ Wi-Fiデバイスのサポートが不十分になる傾向があるため、少し注意が必要ですが、それでもシステムは非常に簡単に起動できます。これらを使用するソフトウェアの構成を調整する必要があります。デバイス。
MBRとパーティションテーブルをコピーすることが重要なステップであるのはなぜですか？
そうではなく、新しいシステムのパーティションを同一にするためだけにあります。ファイルをコピーした後、新しいパーティション構造を反映するように、新しいドライブを好きなように完全に修復し、新しいシステムでブートローダーとfstabを調整することができます。
ハードドライブにすでにターゲットOSが正常にインストールされている場合は、通常、ハードドライブの上に復元して再起動できますが、grub.confと/ etc/fstabにドライブラベルが付いていないことを確認する必要があります。そこにUUIDがあります（ある場合は、後で再度復元する必要がある場合に備えて、通常はデバイス名を指定する方が簡単です）。復元から/ bootを除外します（上記を回避するために/ etc/fstabも除外します）。
システムがすでに起動可能である場合は、GRUBを再度インストールする必要はありません。完全にインストールされていない新しいハードドライブの場合は、どこにあるかを確認する必要があります。カーネルなので、単純なgrub-install hd0（または任意のハードドライブ）で実行できます。
次に、再起動して指を交差させます。
私の知る限り、サーバーを別のサーバー（Physical-to-VistualまたはVistual-to-Physical）に復元する場合の唯一の問題は、システムの起動です。システムが起動すると、すべてが以前と同じになり、すべてのアプリケーションとサーバーが正しく機能するはずです。
システムを起動するために、カーネル内のストレージ（SCSI、RAID、ext4などのファイルシステムなど）に主に関連する必要なドライバーを構築できます。このソリューションでは、カーネルを再コンパイルする必要がありますが、これは簡単ではないかもしれません。
別の解決策は、Initial RAM diskまたはInitRDを使用することです。必要なドライバー（カーネルモジュール）をリストし、これらのドライバーを含むinitrdを作成できます。それでも、このソリューションにはある程度の洞察が必要です。
あなたが私と同じくらい怠け者なら：Dあなたは次の手順を使うことができます：
宛先（バックアップを復元する場所）に、取得したバックアップまたはイメージにできるだけ類似したディストリビューションをインストールします。念のため、Centos 5.3のバックアップがある場合は、Centos 5.3をインストール先にインストールするか（Centos 5.3がない場合）Centos5.4をインストールする必要があります。 RHEL5.4でも可能です。ただし、Slackware13.1またはDebian5.3は適切でない可能性があります。
- 必要なのはカーネルとinitrdだけです。したがって、バックアップされたシステムのように、それらに影響を与えるもの（カーネルとinitrd）を保持する必要があります。たとえば、同じファイルシステム（ext4、XFSなど）と同じソフトウェアRAID（RAID 0、RAID 1、RAID 5）を使用する必要があります。
カーネルと新しくインストールされたシステムのinitrdのコピーを保持します。例として、次のコマンドを使用して、/ mnt/external_storageにマウントされた外部ストレージの/ bootから圧縮tarファイルを作成するだけで十分です。tarczvf/ mnt/external_storage/new_boot.tar.gz/boot
- バックアップまたはイメージを宛先に復元します。
インストールされたシステムからコピーされた/ bootを復元します。
- LiveCDを使用して起動する
- 復元されたシステムのルートファイルシステムをマウントします。例：mkdir -p/mnt/restored;マウント/ dev/sda1/mnt/restored
- インストールされたシステムから/ bootのコピーを含むメディアをマウントします。例：mount/dev/sdb1/mnt/external_storage
- インストールされたシステムからコピーされた/ bootを復元します。例：cd/mnt/restored; tar xzvf /mnt/external_storage/new_boot.tar.gz
必要に応じて、liloまたはgrubの構成を調整します。
- 復元されたシステムの/etc/blkid.tabが存在する場合はクリーンアップします。例：> /mnt/restored/etc/blkid.tab
- ファイルシステムをアンマウントして再起動します。例：cd /; umount/mnt/restored; umount/mnt/external_storage;リブート
上記の手順は、私たちが1年間仕事で使用しているものです。
そのスレッドで説明されている手順は、通常 Bare-Metal Restore と呼ばれます。名前が示すように、それは空のハードディスクから始めて元のシステム（多くの場合完全に新しいハードウェア上）を復元することを意味します。これにはいくつかの利点があります。特に、他の方法では見落とす可能性のある、よりエキゾチックなディレクトリ内のファイルを含め、オリジナルの正確なコピーを取得できることです。ただし、ベアメタル復元にはいくつかの欠点もあります。
- バックアップメディアにより多くのスペースが必要になります。バックアップテープは、オペレーティングシステムの同一のコピー20個で詰まる可能性があり、夜間のバックアップ実行は、ほとんどの場合、必要に応じてCDから簡単に再インストールできるものをコピーすることで構成されます。
- 新しいサーバーは古いマシンと同じではない可能性があります。おそらく、古いハードウェアにSCSIが搭載されていたSATAがあり、グラフィックカードが古いカーネルには新しすぎるかもしれません。 Zoredacheが言うように、今日のストックカーネルでこの問題が発生することはめったにありませんが、ベアメタル復元を行う最初の理由は、システムが非ストックの自己コンパイルカーネルを実行していることでした...
- 復元の開始時に実行中のオペレーティングシステムがないため、プロセスをジャンプスタートするために2番目のシステムが必要です。最近では、これはほとんどの場合、必要なすべてのツールを備えたUSBまたはライブCDですが、その目的でレスキューフロッピーを作成し、必要なときに機能することを期待して指を交差させていた時代を覚えています。
または、すべてのホームディレクトリやアプリケーションディレクトリなど、OS以外のディレクトリのみを復元することもできます。次に、システムの復元は2つの部分からなるプロセスになります。1。新しいマシンにオペレーティングシステムをインストールします。できれば Kickstart のような自動インストール方法を使用し、次に2.必要なユーザーディレクトリとアプリケーションディレクトリを復元します。バックアップメディアから。これにより、ベアメタルの欠点は回避されますが、独自の欠点があります。バックアップディレクトリを定義できる必要があります。新しいサーバーでは、これは問題ではないかもしれませんが、システムが、会社にもういないその人によってかつてセットアップされた古い部分であり、過去2年間、誰もあえて触れていない場合、それは深刻な問題。