32ビットUbuntuから64ビットインスタンスへのRsync
LinodeでUbuntuMaverick（10.10）32ビットVPSを実行しています。 「機能的な」バックアップにRackSpaceを使用したいのですが、CloudServerでは64ビットしか提供されていません。
理想的にはRSync/ができるようにしたいと思いますが、それがさまざまなライブラリーなどで混乱を引き起こすのではないかと思います。
これまで、ホームフォルダに対してこれを行ってきました。Sudo rsync -avzrlR --progress --perms --delete -e ssh [email protected]:/home/./ /home
しかし、/etcにあるさまざまな構成もRSyncできるようにしたいと思います。
究極の目標は、次のような、TheCheap™での本当に粗雑なフォールバックを持つことです。
RackSpaceインスタンスを生成し、バックアップを更新し、CloudFilesにイメージして、インスタンスを削除します。
Linodeで何かが壊れた場合、最新のイメージから新しいRackSpaceサーバーを生成できます。
Q： RSyncワンライナーに/etcを完全に追加できますか、それとも.conf, .ini, etc.ごとに各eとチェリーピッキングを続ける必要がありますか？
（これはおそらく間違った方法であることを認識していますが、私は勤勉になり、今のところできるだけ多くの$$を節約しようとしています。）
/ etcをRSyncワンライナーに完全に追加できますか、それとも各eとすべての.conf、.iniなどをチェリーピッキングし続ける必要がありますか？
ネームサーバーをコピーするとどうなりますか？スマートホストにメールしますか？ fstab？
両端が同じOS /ディストリビューションを実行している場合でも、バックアップをそれと同じように扱い、分離することをお勧めします。
- あなたのファイル、スクリプトプログラム（バックアップの対応するものに入る可能性があります）
- サードパーティソフトウェア（ケースバイケースでの宛先）
- インストールメディア/ベンダーパッチから変更されずに含まれているファイル（純粋にバックアップとして）
- すべての構成（例：すべての/ etc）-これは厳密にバックアップである必要があります-ただし、変更を追跡して、スタンバイマシンで必要に応じて再実装できるようにします）
/を別のディレクトリにrsyncすることができます。これにより、本番サーバーの完全バックアップが得られます。階層全体に十分なスペースが必要になります。また、/ proc、/ sysなどのマウントポイントを除外する必要があります。マウントされたファイルシステム上にある場合、-xを使用するとデータが除外されます。
セットアップする場合、この種の理想的な方法として、使用しているアプリケーションのデータと構成ディレクトリを特定し、それらを選択します。バックアップシナリオを計画するときは、失うデータの量を決定し、そこからバックアップを計画します。ログデータを失っても構わないと思いますか？
Rsyncを使用してライブデータベースをバックアップすると、問題が発生する可能性があります。私がそこで使用しているアプローチは、データベースツールを使用して回復可能なバックアップを作成し、それをコピーすることです。
--include-from=FILEを使用して、バックアップが必要なディレクトリを選択することを検討してください。 --dry-runオプションを使用して、最初の実行前に何がバックアップされるかを確認します。