解決策 1:
では、これらの厄介な間違いを犯さずにすべてのドライブをバックアップし、すべての /proc およびその他の一時フォルダーをフィルターで除外したいとお考えですか?
次のように、ルート フォルダーをファイル システム内の別のフォルダーにマウントすることもできます。
$ cd /mnt
$ mkdir drive
$ mount --bind / drive
これにより、一時的とは見なされないドライブ上のすべてのファイル (/proc または /sys フォルダーなど) が得られます。
これでルート フォルダーがきれいに表示されたので、標準の cp を使用してバックアップ ドライブにコピーするだけです。 または rsync .次のようなもの:
cp -R /mnt/drive /mnt/backupdrive
これにより、前述の問題の両方が解決されます:
- バックアップ ディスクがドライブ内にマウントされていないため、再帰にはなりません (視点)
- 重要なファイルをすべて取得しているため、重要なファイルを見逃すことはありません
参照:man mount(8)
解決策 2:
Linux ではすべてがファイルです。 rsync を介して可能ですが、(せいぜい) 回避するのが難しいことに注意する必要があります。
特にデータベースの場合は、レプリケーションについて最初に考える必要があります。また、プライマリ サーバーの前にプロキシ/ロード バランサをセットアップすることをお勧めします。これにより、移行中にプライマリ サーバーとミラー サーバーを簡単に切り替えることができます。
ハードウェア レベルでは、別の側に同じ数のイーサネット ポート、同じ hdd レイアウトなどを備えたミラーのようなサーバーを配置するのが最善の状況です。異なるものはすべて、システム構成の変更が必要であることを意味します。
つまり、2 つの eth ポートがある場合、ネットワーク構成、ファイアウォールなどが両方のサーバーのインターフェース名と一致することを確認する必要があります。異なる場合は、rsync の後に構成を変更するか、2 番目のデバイス名を変更する必要があります。 (宛先) サーバー。
パーティションレイアウトも同様です。プライマリ サーバーと同じパーティションを作成する必要がありますが、最初から作成すると UUID が異なるため、fstab、grub、mdadm (soft-raid が関係している場合) などを変更する必要があります。 .
ただし、(rsync を実行する前に) 事前に停止しないと一貫性が失われる可能性があるデータベースなど、問題が発生する可能性がある多くのこともあります。
最善の戦略は、最初にハードウェアとファイル システム (パーティション) を準備し、プライマリ サーバーの構成と一致させることです。次に、中間システム (一時的に ssh-server がインストールされたライブ CD など) を介して空のパーティションをマウントします。次のように、空の /proc、/dev、/sys を作成し、残りを rsync します。
rsync -avz -H --delete /etc /bin (...and so on) destserver:/mnt/yourrootfs/
次に、デバイスに grub をインストールし、起動可能にするための構成、ネットワーク構成の変更、fstab および前述のその他の作業を行う必要があります。
また、新しいシステム (プライマリ サーバーで使用しているのと同じバージョン) をインストールしてから、電源を切り、別の一時的なシステム (ライブ cd など) を介してマウントし、/proc 以外のものを置き換えることもできます。 rsync を使用した sys、/dev、および /boot。
しかし、それはあくまでも一般的な考え方です。このサーバーに実際にあるもの、構成、ネットワーク、およびハードウェアの設定によっては、状況が複雑になる場合があります。結局のところ、ダウンタイムを気にせずにこれを行うのは非常に難しいか、不可能かもしれません。
解決策 3:
あなたが実際に欲しいのは復元です。何をするにしても、定期的に復元テストを行う必要があります。
Linode にはバックアップ サービスがあります。スナップショットは、事前に定義された限られたスケジュールで、または API を使用して取得できます。
スナップショット ベースのバックアップの利点は、コピーの作成中にデータが変更されないため、特定の時点を提供できることです。スナップショットは、別のホスト (この場合は新しい Linode) に簡単に復元することもできます。