大災害の計画

私は、ウェブデザインと開発も行う小さなマーケティング会社で働いています。Hostgatorの専用サーバーですべてのWebデザインおよび開発顧客をホストしています。RAID 1構成のハードドライブを備えた専用サーバーがあります。また、cPanelを介して自動化され、自動FTPソフトウェアによってローカルにダウンロードされる毎週のバックアップも行います。

今日、Hostgatorに何らかの壊滅的な障害が発生した場合にどうするかについて話し合いました。サーバーが爆発した、Hostgatorが深刻なネットワークの問題を抱えている、FBIが有名な「私たちが見るすべてのサーバーを奪取する」などのレイドなどを行った可能性があります。次に、それを次のレベルに上げ、Hostgatorが長期間停止し、ローカルバックアップにアクセスできなかった場合はどうすればよいかと考えました。これは私が時間の延長peiodのためにダウンしている当社のサーバーのオッズを知っているなどにより、火災、洪水、である可能性がありそして地元のファイルが同時にアクセス不能にされ、リモートですが、それが取るすべてはちょうどである2悪いことが起こると、それは我々が立つ場所です。（パンクしたタイヤを手に入れて、スペアがパンクしたり行方不明になったりしたことがある場合、2つの悪いことが同時に起こりやすいことがわかっています）。

言うまでもなく、「最悪の場合のシナリオ」タイプのイベントに備えたいと思っています。これにより、ほぼ確実に廃業することになります。私の2つの質問は次のとおりです。

1. Hostgatorによる長期にわたる停止に備えて、私たちは何ができますか？理想的なシナリオには、クライアントのWebサイトがあり、できれば電子メールをすぐに実行できるようになります。

2. 重要なデータが失われないように、堅牢なバックアップ計画には何が含まれますか？理想的なソリューションは自動化されます。

回答ではコストは問題ではないと想定できますが、ソリューションが手頃な価格であるほど良いといえます。

次のことをお勧めします。

1. メインサーバーのコンテンツ全体と構成を、異なるデータセンターの完全に独立したネットワーク上のセカンダリバックアップサーバーに自動的にミラーリングします。RSync、FXP、cPanel voodoo、または同期を自動化する任意の方法を使用します。

2. Hostgatorサーバーが応答しなくなった場合、DNSフェールオーバースイッチングを使用して、トラフィックをバックアップサーバーに自動的にルーティングします。

これは、最悪の事態が発生した場合に、手動での介入と多くのスクランブルとパニックを必要とする「コールド」バックアップではなく、常に「ホット」バックアップを待機していることを意味します。また、あなたのクライアントがあなたのサイトがあなたの前にダウンしたことを決して知らないことを意味します。

DNS Made Easyなどのプロバイダーを使用して、フェイルオーバーDNSをセットアップできます。ホスティングしているドメインごとに、バックアップサーバーごとに1つずつ、最大5つのバックアップIPアドレスを設定します。それが終わったら...

1. DNS Made Easyは、2〜4分ごとにプライマリサーバーをチェックし、応答を検出しない場合、トラフィックをセカンダリIPアドレスにルーティングします。

2. DNS Made Easyは、引き続きプライマリサーバーをチェックします。起動すると、トラフィックを最初のサーバーに再ルーティングします。または、必要に応じてバックアップを維持し、問題を診断してプライマリサーバーを修正します。

もちろん、このソリューションは運用コストを引き上げるので、なんらかの形でクライアントに引き継ぐ必要がありますが、ダウンタイムが原因でビジネスが停止する業界にいる場合は、大幅に冗長なサーバーを購入する価値があります。そのため、会社を救うことができます。

それ以上：

複製、複製、複製

独立したバックアップがあればあるほど良い。リモートバックアップは、外部ハードドライブ、Dropbox、gitリポジトリ、およびリモートFTPアカウントにミラー化されたローカルハードドライブに保存します。チャンスはありません。できる限り複製します。手動バックアップから復元する必要がある場合は、1つを選択するよりも5つを選択する方が適切です。パラノイアは過小評価されています。

バックアップの手動復元の練習

バックアップの1つから復旧しようとしたことがない場合、それらが機能することをどのように確認しますか？自動手順が失敗した場合に何が起こるかを確認するには、緊急訓練を行う価値があります。

• Cloudflareは、サーバーがダウンしたときにサイトを維持するためのセキュリティおよびキャッシュ機能を提供します。（サイトをミラーリングし、サーバーから直接ではなく、グローバルに分散されたキャッシュから提供します。）
• Codeguard。Webサイトコードの自動バックアップとロールバックを提供します（FTPのみ）。
• サイト自動バックアップ。cPanelバックアップを介して、Webサイトコード、電子メールデータ、およびMySQL情報の自動バックアップとロールバックを提供します。これはHostgatorによって実行されるため、サイトをホストする場合も必ずしも適切ではありませんが、他の人には役立つ可能性があることに注意してください。

特にCloudflareは、ダウンタイムを回避し、一般にサイトの応答性を改善するのに役立つようです。

災害復旧は、特に複数のサーバー、サイト、およびデータベースを扱う場合、大きなタスクになる可能性があります。選択したソリューションで考慮すべき2つの重要な項目は、目標復旧時間（RTO）と目標復旧ポイント（RPO）です。

RTOは、基本的に、サイトがバックアップされるまでにかかる時間を予測しています。1〜2分（またはそれ以下）のRTOがある場合は、Nickが提案した、ファイルとデータのセカンダリデータセンターへのリアルタイムレプリケーションとDNSの自動フェールオーバーを伴うソリューションを検討する必要があります。両方のデータセンターで有料サービスまたはハードウェアを使用して実行する（BIG-IP Global Traffic Managerなど）F5 Networksから。これにはコストがかかりますが、「ダウンタイムのコストはいくらですか？」という質問に答えることに大きく依存します。RTOが数時間または数日である場合、サーバーのオンライン化、DNSの切り替えなど、より多くの手動の関与が必要な災害復旧手順を検討できます。

RPOは基本的に、バックアップが実行される頻度と、災害発生時にどれだけのデータを失っても構わないかということです。コンテンツやデータの変更が頻繁に発生する場合は、RPOが数分または数時間である可能性が高く、リアルタイムレプリケーションまたは高頻度のバックアップを処理している可能性があります。コンテンツがそれほど頻繁に変更されない場合、または数日間データを失うことを必ずしも気にしない顧客がいる場合、バックアップの頻度は低くなります。

私が述べたように、私はニックが言わなければならなかったことの多くに同意します。他の選択肢として、RackspaceやAmazonなどの大規模なクラウドベースのプロバイダーのクラウドベースのサービスを利用することも検討できます。特に、これらのプロバイダーはどちらも、大規模なインフラストラクチャを備えており、これらのプロバイダーで発生したあらゆる災害を処理できます。クラウドサイトまたはクラウドサーバー（Rackspaceで使用される用語）のようなものを使用すると、同様に拡張できるという利点があり、物理的なハードウェアの側面を必ずしも心配する必要がありません。

Rackspaceには、クラウドサーバー、物理サーバー、クラウドファイルをソリューションの一部として組み合わせて、インフラストラクチャを混在させることができるカスタムオプションも用意されています。ハイブリッドアプローチは、すべてのアプローチに適合する1つのサイズを取りたくない場合、顧客のニーズに応じて検討する必要がある場合があります。

役に立つ場合は、Rackspaceサイトにも災害復旧専用のページがあります。こちらのページをご覧ください。（記録のために、私はRackspaceと提携していませんが、過去に彼らのサービスを使用しました）。

これがお役に立てば幸いです。

編集：クラウドソリューションを評価している場合、これが役立つかもしれないと思った。インフラストラクチャおよびサービスとしてのガートナーのマジッククアドラントレポートおよびWebホスティングは、他のソリューションプロバイダーについての洞察を提供します。

別のホスティング会社の別の施設でサーバーを完全に複製することが最も明白な解決策のようです。

ファイルは、rsyncやunisonなどのツールと同期を保つことができます。SQLバックアップもrsyncedでき、スクリプトによってスレーブデータベースにアップロードできます。

ソースコードリポジトリ（SVNまたはGIT）を使用して、すべてのコードのバージョン管理を実行していることを確認してください。SVNまたはGITを使用していますか？

Project Lockerなどのサードパーティのリポジトリでアカウント（無料または有料）を取得できます。作業中にすべてのコードをバージョン管理する場合、基本的にはすべてを3番目の場所にあるリポジトリにバックアップします。 。これにより、すべての作業を一度に失う可能性がさらに低下します（ほぼゼロ）。

SVNのコミット/チェックアウトは、コマンドラインを使用するか、Versions（Macの場合）やTortoiseSVN（Windowsの場合）などのクライアントを使用して実行できます。