バックアップと復元を計画する (SharePoint Foundation 2010)

適用先: SharePoint Foundation 2010

この記事では、Microsoft SharePoint Foundation 環境のバックアップと復旧の戦略決定、使用するツールの選定など、バックアップと復旧を計画するうえで必要な各段階について説明します。記述されている順序で各段階を実施する必要はなく、プロセスを反復する場合もあります。

障害復旧のためにバックアップと復元を使用する方法を計画するときは、一般的なイベント、障害、エラーに加えて、ローカルの緊急時や地域の緊急時を考慮する必要があります。

Microsoft SharePoint Foundation のバックアップと復旧の詳細については、「バックアップと復元の概要 (SharePoint Foundation 2010)」を参照してください。

この記事の内容

• ビジネス要件を定義する

• 環境内の保護対象と復元対象を選択する

• ツールを選択する

• 戦略を決定する

• バックアップと復元のパフォーマンスの改善を計画する

ビジネス要件を定義する

ビジネス要件を定義するには、環境内の各フォームおよびサービスについて次の内容を決定します。

• 復旧ポイント目標 (RPO) とは、利用可能な最新のバックアップから、障害が発生する可能性のあるポイントまでの最長時間に関する目標値です。障害が発生した場合に、ビジネス上失われても構わないデータ量によって決定されます。

• 復旧時間目標 (RTO) とは、データ復旧プロセスに要する最長時間に関する目標値です。ビジネス上、サイトまたはサービスが利用不可能となっても構わない時間によって決定されます。

• 復旧レベル目標 (RLO) とは、ファーム全体、Web アプリケーション、サイト コレクション、サイト、リストまたはライブラリ、アイテムなど、データの復旧が可能なレベルを定義する目標値です。

RPO と RTO が短いほど、また RLO の粒度が細かいほど、コストが高くなる傾向があります。

SharePoint Foundation 2010 環境のバックアップと復旧の戦略を計画するときに役立つワークシートを「SharePoint 2010 Products backup and recovery planning workbook (英語)」(https://go.microsoft.com/fwlink/?linkid=184385&clcid=0x411) (英語) からダウンロードできます。

環境内の保護対象と復元対象を選択する

ビジネス要件は、環境内で保護対象となるコンポーネントと、それらに必要な復旧単位を決定するのに役立ちます。

SharePoint 環境内で保護対象となるコンポーネントと、各コンポーネントのバックアップと復元に利用可能なツールを、次の表に示します。

1単一のサイト コレクションが 1 つのデータベースに格納されている場合は、サイト コレクションの復旧にファーム レベルおよびデータベース レベルのバックアップと復元を使用できます。

2サイト コレクション、サイト、リスト、および構成を復元する場合は、SharePoint Foundation の未接続データベース復旧でファーム レベルおよびデータベース レベルのバックアップを使用できます。

3リモート BLOB ストアに保存されたコンテンツは DPM を使用して復元できません。

4Web.config への変更は、DPM 2010 からファイル システムのバックアップを使用すると、バックアップできます。

5IIS 構成は、DPM 2010 からベア メタル バックアップを使用すると、復旧できます。

6DPM 2010 では、ベア メタル バックアップと SharePoint Foundation のバックアップの組み合わせを使用して、このアイテムを復旧できます。オブジェクトとしてバックアップおよび復旧することはできません。

7完全に信頼できるソリューション パッケージは構成データベースに格納され、サンドボックス ソリューションはコンテンツ データベースに格納されます。これらはファームまたはコンテンツ データベースの復旧の一部として復旧できます。

8構成設定はファームレベルのバックアップから復旧できます。詳細については、「ファームを復元する (SharePoint Foundation 2010)」を参照してください。

9SharePoint Foundation 2010 ファームのサーバーの全体管理コンテンツ データベースと構成データベースは復旧できますが、同じコンピューターで構成された同じファームへの完全ファーム回復手順の一部としてのみ復旧できます。

SharePoint コンテンツ データベース内の復旧対象を選択する

コンテンツ データベース内からは、サイト コレクション、サイト、リストとライブラリを復旧できます。

バックアップと復元のツールでは、コンテンツ データベース内のコンテンツをさまざまなレベルで復旧できます。コンテンツ データベース内からのオブジェクトの復旧は、コンテンツ データベース全体の復旧よりも、常に複雑になります。

カスタマイズを保護する

SharePoint サイトのカスタマイズには、次のものを含めることができます。

• マスター ページ、ページ レイアウトおよびカスケード スタイル シート。これらのオブジェクトは、Web アプリケーションのコンテンツ データベースに格納されます。

• Web パーツ、サイトまたはリストの定義、カスタム列、新しいコンテンツの種類、カスタム フィールド、カスタム アクション、コード化されたワークフロー、ワークフローの操作と条件。

• サードパーティのソリューション、およびそれらに関連付けられたバイナリ ファイルとレジストリ キー (IFilters など)。

• 標準 XML ファイルに対する変更。

• カスタムのサイト定義 (Webtemp.xml)。

• Web.config ファイルへの変更。

カスタマイズの展開方法、および Web.config ファイルの変更方法によって、カスタマイズのバックアップと復旧に利用できるツールが大幅に異なります。復旧の可能性を最大限にするには、ソリューション パッケージを使用してカスタマイズを展開し、サーバーの全体管理または SharePoint API とオブジェクト モデルを使用して Web.config ファイルを構成することをお勧めします。

ワークフローを保護する

ワークフローは、バックアップおよび復旧できるカスタマイズの特殊なケースです。バックアップおよび復旧の計画では、ご使用の環境に当てはまる次のいずれかのシナリオに対処するようにしてください。

• 宣言型ワークフロー (Microsoft SharePoint Designer 2010 で作成されたものなど) は、展開先サイト コレクションのコンテンツ データベースに保存されます。コンテンツ データベースのバックアップによってこれらのワークフローが保護されます。

• カスタムの宣言型ワークフロー アクションのコンポーネントは、次の 3 つの場所にあります。

  1. アクティビティの Visual Studio アセンブリは、グローバル アセンブリ カタログ (GAC) に保存されます。

  2. XML 定義ファイル (.ACTIONS ファイル) は、14\TEMPLATE\{LCID}\Workflow ディレクトリに保存されます。

  3. アクティビティを許可された種類として指定する XML エントリは、そのアクティビティが使用される Web アプリケーションの Web.config ファイルに保存されます。

  ファームのワークフローでカスタムのアクションを使用する場合は、ファイル バックアップ システムを使用してこれらのファイルと XML エントリを保護する必要があります。Web パーツやイベント レシーバーといった SharePoint Foundation の機能と同様、これらのファイルは復旧後、必要に応じてファームへの再適用が必要になります。

• Visual Studio を使用して作成されるワークフローのように、カスタム コードに依存するワークフローは、2 つの場所に保存されます。ワークフローの Visual Studio アセンブリはグローバル アセンブリ カタログ (GAC) に保存され、XML 定義ファイルは Features ディレクトリに保存されます。これは、Web パーツ、イベント レシーバーなど、SharePoint Foundation の他の種類の機能と同じです。ワークフローがソリューション パッケージの一部としてインストールされている場合は、コンテンツ データベースをバックアップすると、これらのワークフローが保護ざれます。

• ワークフローが展開されるサイト コレクション以外のサイト コレクションとやり取りするカスタム ワークフローを作成する場合は、双方のサイト コレクションをバックアップしてワークフローを保護する必要があります。こうしたワークフローには、別のサイト コレクションの履歴リストまたはその他のカスタム リストに書き込むものがあります。ファーム内のすべてのサイト コレクションとそれらに関連付けられたすべてのワークフローをバックアップするには、ファーム バックアップの実行で十分です。

• まだ展開されていないワークフローは、他のデータ ファイルと同様に、個別にバックアップおよび復元を行う必要があります。新しいワークフローを開発していて、そのワークフローを SharePoint Foundation ファームにまだ展開していない場合は、Windows バックアップまたは別のファイル システム バックアップをアプリケーションを使用してワークフロー プロジェクト ファイルの保存先フォルダーをバックアップしてください。

サービス アプリケーションを保護する

SharePoint Foundation 環境のサービス アプリケーションは、サービス設定と 1 つ以上のデータベースの両方で構成される場合と、サービス設定のみで構成される場合があります。データベースのみを復元してもサービス アプリケーション全体を復元することはできません。ただし、サービス アプリケーションのデータベースを復元した後で、サービス アプリケーションを準備することはできます。詳細については、「サービス アプリケーションを復元する (SharePoint Foundation 2010)」を参照してください。

SQL Server Reporting Services データベースを保護する

SharePoint Foundation のバックアップと復旧には、SQL Server Reporting Services データベースは含まれません。SQL Server 2008 R2 Express ツールを使用する必要があります。詳細については、「Reporting Services インストールのバックアップおよび復元操作」(https://go.microsoft.com/fwlink/?linkid=186642&clcid=0x411) を参照してください。

ツールを選択する

バックアップと復元に適切なツールを選択するには、時間とリソースの予算内で設定されている継続性のビジネス要件を満たすことができるかどうかを判断する必要があります。

ツールの選択時には、次の要素を検討します。

• バックアップの速度: データベースのメンテナンス時間内に実行できるか。ハードウェア上でバックアップ システムをテストして、ニーズを満たしていることを確認する必要があります。

• 復旧の完全性。

• オブジェクトの復旧可能レベル。

• サポートされるバックアップの種類 (完全、差分、増分)。

• ツール管理の複雑さ。

次の表では、6 時間以内にバックアップできるバックアップの種類とファームのサイズを、Microsoft のバックアップと復旧のツールごとに比較しています。

1バックアップのサイズは、次に示すテスト用ハードウェアで指定したサイズを合計したシステムをバックアップすることによって決定されています。

テスト用ハードウェア

6 時間のメンテナンス ウィンドウで完了できるバックアップのサイズを決定するためのテストでは、次に示すハードウェアが使用されました。

Microsoft SharePoint Foundation で使用できるバックアップおよび復元システムの詳細については、以下の技術情報を参照してください。

• バックアップと復元の概要 (SharePoint Foundation 2010)

• SQL Server でのデータベースのバックアップおよび復元 (https://go.microsoft.com/fwlink/?linkid=186643&clcid=0x411)

• 「Data Protection Manager 2010 概要」(https://go.microsoft.com/fwlink/?linkid=186655&clcid=0x411)

戦略を決定する

ビジネス要件、復旧ニーズ、および選択したツールに基づいて、環境に適したバックアップと復元の戦略を決定し、文書化します。

SharePoint Foundation 環境をサポートする IT 部門は、多くの場合、戦略の策定時に、環境の保護に複数のツールを使用することを決定します。

たとえば、DBA で管理されるデータベースを持つ環境では、以下のリストにある戦略を使用できます。

• すべてのデータベースを SQL Server 2008 R2 Express でバックアップする。設定されるバックアップ間隔は、以下の要因に基づく。

  • コンテンツまたはサービスの重要度。

  • バックアップが環境のパフォーマンスに及ぼす影響。

• サイズが小さく、急速に変化し、ビジネスに多大な影響を及ぼすコンテンツ データベースは、独立した物理ディスクに格納される SQL Server 2008 R2 Express データベース スナップショットでさらに保護します。データベースごとに 1 つのスナップショットだけを格納し、スナップショットを定期的に破棄することで、パフォーマンスへの影響を最小限にします。データベースごとに設定するスナップショットの間隔は、次の要素に基づいて決定します。

  • コンテンツまたはサービスの重要度。

  • データベースの標準的な変更速度。

  • スナップショットが環境のパフォーマンスに及ぼす影響。

  • スナップショットの格納に必要な容量。

  スナップショットからの復旧は、標準の復旧よりも高速に実行されます。スナップショットは、その基になるデータベースと共に、SharePoint Foundation で未接続データベースとして扱うことができるからです。ただし、スナップショットを作成することによって、基になるデータベースのパフォーマンスが低下することがあります。スナップショットを実装する前に、スナップショットがシステムのパフォーマンスに及ぼす影響をテストすることと、スナップショットを定期的に破棄して必要な容量を減らすことをお勧めします。

  注意

  RBS を使用していて、使用している RBS プロバイダーがスナップショットをサポートしていない場合、バックアップにスナップショットを使用できません。たとえば、FILESTREAM プロバイダーはスナップショットをサポートしていません。

• サービス アプリケーションの保護に SharePoint Foundation バックアップを使用する。バックアップ間隔は以下の要因に基づいて設定する。

  • サービスの重要度。

  • データベースが変更される標準的な頻度。

  • バックアップがデータベースのパフォーマンスに及ぼす影響。

• すべての復元処理は、SharePoint Foundation によって実行されます。使用する復元システムの選択は、利用可能なバックアップの種類と復元されるオブジェクトによって決まります。

その他のツールは、ビジネス継続性の戦略の一部とする必要があります。環境全体に渡って、サイト コレクションにおけるごみ箱とバージョン管理の使用方法を検討します。詳細については、「BCM (Business Continuity Management) を計画する (SharePoint Foundation 2010)」を参照してください。

バックアップと復元のパフォーマンスの改善を計画する

バックアップと復元の戦略を計画するときには、バックアップと復元によるシステム パフォーマンスへの影響を軽減するために、次の推奨事項を検討してください。

仕様では、ほとんどのバックアップ ジョブは、保守に使用可能な時間内にジョブを終了するために、消費できるだけの I/O リソースを消費します。したがって、ディスクのキュー処理が実行されたり、すべての I/O 要求への応答が通常よりも遅くなったりすることがあります。これは一般的な動作であり、問題と見なす必要はありません。

SQL Server および保存領域の構成に関する推奨事項に従う

SharePoint Foundation 環境の SQL Server 2008 R2 Express およびストレージの構成に関する一般的な推奨事項に従います。詳細については、「SQL Server とストレージ (SharePoint Foundation 2010)」を参照してください。

SQL Server とバックアップ場所の間の遅延を最小限に抑える

一般に、バックアップにはネットワーク ドライブではなくローカル ディスクを使用することをお勧めします。複数のサーバーをバックアップする場合は、両方のサーバーから書き込みができる直接接続したコンピューターを用意してください。ネットワーク ドライブと、SQL Server 2008 R2 Express を実行しているコンピューターとの間の遅延が 1 ミリ秒以下であれば、良好なパフォーマンスが得られます。ファームに複数のサーバーがある場合 (SQL Server 2008 R2 Express を実行しているコンピューターを含む)、SharePoint ファームのバックアップ場所には、UNC ネットワーク パスを使用する必要があります。

処理競合を回避する

ユーザーがシステムへのアクセスを必要とする時間帯にバックアップ ジョブを実行しないでください。

I/O ボトルネックを回避するには、別のディスクにメインのバックアップを実行してから、テープにコピーします。

すべてのデータベースが同時にバックアップされないように、バックアップをずらして行うことを検討してください。

SharePoint Foundation のバックアップでは、SQL Server 2008 R2 Express のバックアップが使用されます。バックアップで圧縮を使用する場合は、SQL Server 2008 R2 Express が過負荷にならないように注意してください。たとえば、一部のサードパーティのバックアップ ツールはバックアップ中にデータの圧縮を行うので、SQL Server のパフォーマンスに影響することがあります。圧縮プロセスを減速して SQL Server への影響を制御するために利用できるツールがあります。

SQL Server のバックアップと復元の最適化に関する推奨事項に従う

SQL Server 2008 Enterprise を実行している場合は、バックアップの圧縮を使用することをお勧めします。詳細については、「バックアップの圧縮 (SQL Server)」(https://go.microsoft.com/fwlink/?linkid=179525&clcid=0x411) を参照してください。

SQL Server 2008 R2 Express のバックアップを使用している場合、復旧時間を最小限にするために、完全バックアップ、差分バックアップ、およびトランザクション ログ バックアップ (完全復旧モデルの場合) を組み合わせて使用します。差分データベース バックアップは、通常、完全データベース バックアップよりも高速に作成でき、データベースを復旧するために必要なトランザクション ログの量が少なくなります。

SQL Server 2008 で完全復旧モデルを使用する場合は、保守の問題を回避するために、バックアップ中に切り捨てのオプションを使用することをお勧めします。

SQL Server 2008 R2 Express のバックアップと復元のパフォーマンスを最適化する方法の詳細な推奨事項については、「SQL Server におけるバックアップと復元のパフォーマンスの最適化」(https://go.microsoft.com/fwlink/?linkid=126630&clcid=0x411) を参照してください。

バックアップ ドライブの書き込みパフォーマンスが十分であることを確認する

ディスク バックアップ デバイスで RAID (Redundant Array of Independent Disks) を使用するかどうかを慎重に検討してください。たとえば、RAID 5 は書き込みのパフォーマンスが低く、ディスクが 1 つの場合とほぼ同じ速度です (RAID 5 はパリティ情報を維持することが理由です)。バックアップ デバイスに RAID 10 を使用すると、バックアップがより高速になる場合があります。バックアップで RAID を使用する方法の詳細については、「Configure RAID for maximum SQL Server I/O throughput (英語)」(https://go.microsoft.com/fwlink/?linkid=126632&clcid=0x411) (英語) を参照してください。

関連するコンテンツ

See Also

Other Resources

Resource Center: Architecture Design for SharePoint Server 2010 (英語)