私の職場では、ソース コードを保存し、リビジョン管理ソフトウェア (svn) をホストするために Linux ボックスを使用しています。プロジェクト管理用の「trac」、コード レビュー用の fisheye や crucible などの他の製品もそこにインストールしています。このボックスが故障した場合、ダウンタイムをほぼゼロにして、すべてのサービス、ソフトウェア、ユーザー アカウントなどを稼働させたままにしておきたいです。どのようなソリューションを求めているのでしょうか。
役に立つヒント:
- ソリューションのコストは問題ではありません。ただし、サブスクリプションよりも 1 回限りのコストのほうがよいと思います。
- バックアップの維持と復元の両方で、管理作業を最小限に抑えたい。
- 夜間と週末はボックスをアイドル状態にします。
- 数マイル離れた別の施設がありますが、2 つの建物間の接続は比較的遅いです (ただし、夜間は高速です)。火災などの場合に備え、オフサイトで復元オプションを希望します。
- バックアップを購入し、実行して、必要なときにすぐに使用できるようにしておきたい。「クラッシュ後に新しいボックスを購入して...」ではなく
- ボックスは特別なものではなく、Ubuntu Linux がインストールされている標準的なデスクトップです。高性能な用途には使用しません。
誰か解決策を知っていますか? 私は Linux やサーバー関連のことに詳しくないので、回答とともに基本的な説明をお願いします。
ありがとう！
答え1
実際には、相互に関連しているものの、異なる 3 つの事柄について話していることになります。
- フォールト トレランス (ダウンタイムを最小限に抑えながら、実行を継続したり、バックアップを取得したりするには)
- データのバックアップ (誰かがリポジトリを rm -rf したらどうすればいいですか)
- 災害復旧（オフィスが地球上から消滅したらどうすればいいか）
これらは、3 つの異なるが相互に関連するプロセスとして考える必要があります。最大 1 時間のダウンタイムで本当に必要なのはフォールト トレランスであると思われるため、フォールト トレランスについて最も詳しく説明します。
フォールト トレランスについて考慮すべき事項:
- 新しい機器を入手するにはどれくらい時間がかかりますか?
- 箱を再構築するのにどれくらい時間がかかりますか?
- データの検証と復元にはどれくらい時間がかかりますか?
これらの時間の合計に 30% を掛けます (緊急時には、思ったほどスムーズに進むことはありません)。その合計が許容できるダウンタイムよりも大きい場合は、高可用性の設定を検討する必要があります。それよりも小さい場合は、見積もりが外れ、予想よりも長くダウンする可能性があるリスクを負うかどうかはあなた次第です。
解決策としては、できることはたくさんあります。しかし、どの場合でも、非常にデスクトップをサーバー クラスのマシンに置き換えることをお勧めします。コンポーネントの品質は高く、24 時間 365 日稼働するように構築されているため、ハードウェアにはすでに十分な冗長性が組み込まれています (優れた RAID カード、冗長 PSU など)。
- 2 番目のサイトにスタンバイ サーバーを設定し、x 時間ごとにデータを rsync することができます。x は、レプリケーション間でサーバーがダウンした場合に失っても構わないデータの量です。rsync は、差分と変更されたファイルのみを送信するため、最初の同期後はデータ パイプが非常に小さくなります。また、サーバーを CNAME 経由でアクセスするように設定して、ポイント先を交換するだけですぐに使用できるようにします。
- 上記と同じ操作を行いますが、スタンバイ サーバーをプライマリ ロケーションに配置します。
- SAN/NASと2台のサーバーを用意し、アクティブ/アクティブクラスタまたはアクティブ/パッシブクラスタでセットアップします。
バックアップはシナリオの非常に重要な部分でもあります。オフサイトに保存されたポイント イン タイム バックアップに代わるものはないということを覚えておいてください。個人的には、テープにバックアップし、それを Iron Mountain のような会社にオフサイトに保存してもらうのが最善の選択肢だと今でも思っています。あなたの規模の環境であれば、ArcServ、BackupExec、NetBackup などの「大規模な」バックアップ ソリューションで十分でしょう。また、少なくとも四半期ごとにバックアップをテストしてください。必要なバックアップが不良であることが判明することほど最悪なことはありません。
災害復旧とは、実際には、座って、どこで作業するか、どこから交換用機器を入手するかを計画し、適切なオフサイト バックアップがあることを確認することです。DR とは、最悪の事態が発生したときのために、上記のすべての要素を統合した行動計画にまとめることだと私は考えています。
答え2
環境を仮想化すれば、イメージを復元するだけで済みます。
答え3
データの量、メイン システムの複雑さ、実行したい管理の量に応じて、さまざまなオプションがあります。
仮想化されたボックスのサイズが比較的小さい (数 GB) 場合は、XenServer が適しています。たとえば、私たちが実行している社内アプリケーション サーバーのサイズはわずか 3 GB です。簡単に停止してバックアップを作成し、そのバックアップを別のシステムに転送できます。ただし、XenServer に精通していない場合は、習得に時間がかかる可能性があります。
R1Soft の CDP サーバー バックアップ ソフトウェアも使用していますが、これは迅速な復旧にはあまり適していません。障害が発生したサーバーの完全なベアメタル復元には最適ですが、1 時間以内のバックアップと復旧には適していません。
私はクライアントのために次のようなことをしました。CDP バックアップ ソフトウェアを使用して、プライマリ システムをコールド スペアにクローンします。これにより、スペアがプライマリ システムと同一であることが保証されます。その後、1 時間ごとのスナップショットが CDP サーバーに保存されます。CDP サーバーは非常に効率的なバックアップ アルゴリズムを使用するため、ライブ サーバーへの影響はほとんどありません。
障害が発生した場合は、CDP サーバーからコールド スペアにデータを復元できます。
この方法や rsync ベースの方法の問題点は、ソフトウェアが同期された状態を保つために、ホット スペアとコールド スペアの両方を確実に管理する必要があることです。片方で OS アップデートを実行して、もう片方で実行することを忘れることは避けたいものです。
1 つの推奨事項は、サーバー上で可能な限り標準化された構成を使用するようにすることです。これにより、コールド スタンバイ システムへのデータの復元/同期に対する構成/更新の変更の影響が軽減されます。
また、私は自分のデータ（つまり追加したもの）をシステムから十分に分離しておくことを好みます。LVM を使用する場合は、LVM スナップショット メソッドも機能する可能性があります。
検討すべきオプションは多数ありますが、最適なオプションは社内の専門知識、システム管理にかかる時間、データの使用パターンによって異なります。
また、データ量が非常に少ない場合は、デスクトップ レベルのバックアップ/リカバリ ツールを検討することをお勧めします。私はそれらにはあまり詳しくありません。
http://www.r1soft.com/ CDP サーバー ソフトウェア
http://www.citrix.com/XenServer
答え4
ここでは、rsync + cron のような単純なもので十分なようです。