バックアップと災害復旧とは

サブプロセスの「バックアップ」と「災害復旧」は、混同されたり、プロセス全体と同義であると間違われることがあります。バックアップとは、ファイルのコピーを作成するプロセスです。災害復旧は、停止後にコピーを使用してアプリケーション、データ、およびITリソースへのアクセスを迅速に再確立するための計画・プロセスです。この計画には、主要なデータセンターが再び機能するまで、冗長なサーバーとストレージ・システムへの切り替えが含まれる場合があります。

単にデータのコピーを持っているだけでは、企業が事業を継続できることにはなりません。事業継続性を確保するには、堅牢でテスト済みのバックアップと災害復旧計画が必要です。

組織には、バックアップや障害復旧を怠るわけにはいきません。誤って削除したデータを回復するのに数時間かかる場合、従業員やパートナーは稼働停止状態となり、お客様のテクノロジーに依存するビジネスクリティカルなプロセスを完了できなくなります。また、災害後にビジネスをオンラインに戻すのに数日かかってしまう場合、顧客を永久に失うことになります。どちらの場合も、多大な時間と費用が失われる可能性があることを考えると、バックアップと災害復旧への投資は全面的に正当化できます。

いくつかの重要な用語を理解しておくと、戦略的意思決定に役立ち、バックアップおよび災害復旧ソリューションをより適切に評価できるようになります。

• 目標復旧時間（RTO）とは、障害発生後に通常の業務オペレーションを回復するために要する時間です。RTOを設定する際には、損失を許容できる時間と、その時間が収益に与える影響を考慮する必要があります。RTOは、ビジネスの種類によって大きく異なる場合があります。たとえば、公共図書館でカタログシステムを失った場合、システムが復旧するまで数日間は手動で継続できるでしょう。しかし、大手オンライン小売業者が在庫システムを失った場合、たとえ10分間のダウンタイムでも、それに伴う収益の損失は許容できないものでしょう。

• 目標復旧時点（RPO）：とは、災害で失った場合でも許容できるデータの量を指します。障害によるデータ損失を防ぐため、リモート・データ・センターへの継続的なデータのコピーが必要な場合もあります。あるいは、5分や1時間のデータを失っても許容範囲内と判断する場合もあるでしょう。
  
  
• フェイルオーバーは、タスクをバックアップ・システムに自動的にオフロードする災害復旧プロセスで、ユーザーにとってシームレスな手法です。プライマリ・データ・センターからセカンダリ・サイトにフェイルオーバーし、すぐに引き継ぐ準備ができている冗長システムを使用するような場合があります。
  
  
• フェイルバックは、元のシステムに切り替える災害復旧プロセスです。災害が過ぎ去り、プライマリ・データ・センターが復旧して稼働すると、シームレスにフェールバックできるようになります。
  
  
• 復元とは、バックアップデータをプライマリ・システムまたはデータ・センターに転送するプロセスです。復元プロセスは、災害復旧ではなくバックアップの一部と見なされます。

災害復旧プロセスおよび災害復旧環境の管理の代替案を検討する際に、最後にもう1つの用語が役立つかもしれません。

• 災害復旧サービス（DRaaS）は、災害復旧に対する管理されたアプローチです。サードパーティーが、災害復旧用に使用されるインフラストラクチャーをホストおよび管理します。一部のDRaaS製品では、災害復旧プロセスを管理するためのツールや、組織がこれらのプロセスを管理できるようにするツールを提供する場合があります。

主要な概念を理解したら、それらをワークロードに適用します。多くの組織では、各ワークロードのビジネスにおける重要性を反映して、複数のRTOとRPOを定めています。

大手銀行にとって、オンライン・バンキング・システムは重要なワークロードである場合があり、時間とデータの損失を最小限に抑える必要があります。ただし、銀行員の時間追跡アプリケーションはそれほど重要ではありません。災害が発生した場合、ビジネスに大きな悪影響を与えることなく、数時間または1日にわたってアプリケーションが停止することを許容する場合があります。ワークロードをティア1、ティア2、またはティア3として定義すると、災害復旧計画のフレームワークを作成しやすくなります。

災害復旧計画を設計する次のステップは、展開オプションを評価することです。災害復旧機能やバックアップ・データをオンプレミスで保持する必要がありますか？パブリック・クラウドまたはハイブリッド・クラウド・アプローチからメリットが得られますか？

クラウドベースのバックアップと災害復旧ソリューションは、あらゆる規模の組織の間でますます人気が高まっています。多くのクラウド・ソリューションはデータを保管するためのインフラストラクチャーを提供し、場合によってはバックアップや災害復旧プロセスを管理するためのツールも提供します。

クラウドベースのバックアップまたは災害復旧サービスを選択することで、インフラストラクチャーへの多額の資本投資や環境の管理コストを回避できます。加えて、迅速な拡張性と、地域的な災害が発生した場合にデータを安全に保つために必要な地理的距離を確保できます。

クラウドベースのバックアップと災害復旧のソリューションは、オンプレミスとクラウドベースの両方の本番環境をサポートできます。例えば、本番環境を自社のデータ・センターに維持し、バックアップまたは複製データのみをクラウドに保管するようにすることができます。

ハイブリッド・アプローチでは、本番環境を移動せずに、拡張性と地理的距離の利点を得ることができます。クラウドからクラウドへのモデルでは、本番環境と災害復旧の両方がクラウド内に配置されますが、物理的に十分な隔離を確保するために別のサイトに配置されます。

場合によっては、特定のバックアップまたは災害復旧プロセスをオンプレミスに保持することで、データを取得し、ITサービスを迅速に復旧できます。厳格なデータ・プライバシーやデータ主権の規制を遵守する必要がある場合には、一部の機密データをオンプレミスに保持することも魅力的に思えるかもしれません。

災害復旧の場合、オンプレミス環境に完全に依存する計画には困難が伴います。自然災害や停電が発生した場合、プライマリ・システムとセカンダリ・システムの両方を含むデータ・センター全体が影響を受けます。そのため、ほとんどの災害復旧ストラテジーでは、プライマリ・データ・センターから少し離れたセカンダリ・サイトが採用されています。

パフォーマンス、規制遵守、セカンダリ・サイトへの物理的アクセスなどの要素のバランスをどのように取るかに応じて、他のサイトを町全体、国または地域、または全世界に配置することができます。

どのデプロイメント・オプションを選択するかに応じて、バックアップと災害復旧に採用するテクノロジーとプロセスの種類に対して、場合によってはいくつかの代替手段があります。

従来の磁気テープ・ストレージは何十年も前から使用されていますが、バックアップ計画では現在でも使用できます。テープ・ソリューションを使用すると、大量のデータを確実かつコスト効率よく保管できます。

テープはバックアップには有効ですが、通常はディスク・ベースのストレージによる高速アクセスが必要となる災害復旧には使用されません。また、オフサイトの保管庫からテープを物理的に取得する必要がある場合、数時間、場合によっては数日の可用性を失う可能性があります。

スナップショット・ベースのバックアップは、ある時点のアプリケーションやディスクの状態をキャプチャします。最後のスナップショット以降に変更されたデータのみを書き込むことで、この方法はストレージ・スペースを節約しつつデータを保護するのに役立ちます。

スナップショット・ベースの複製は、バックアップや災害復旧に使用できます。データの完全性は、最新のスナップショットの完全性に比例します。1時間ごとにスナップショットを作成する場合、1時間分のデータを失うことを許容する必要があります。

多くの組織は、バックアップだけでなく災害復旧のためにも継続的複製を推進しています。この方法では、ディスクまたはアプリケーションの最新のコピーが別の場所またはクラウドに継続的に複製されるため、ダウンタイムが最小限に抑えられ、より詳細なリカバリ・ポイントが得られます。