SharePoint Server 2010 でのバックアップと復元を計画する

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

この記事では、Microsoft SharePoint Server 環境のバックアップと復旧の戦略決定、使用するツールの選定など、バックアップと復旧を計画するうえで必要な各段階について説明します。各段階は、ここに示されている順序で実行する必要はありません。また、この計画プロセスを繰り返し実行してもかまいません。

障害復旧のためにバックアップと復元を使用する方法を計画する場合、一般的なイベント、障害、エラー、および近隣や地域での緊急事態を考慮します。

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

この記事の内容

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

• 環境内での保護および復元対象を選択する

• ツールを選択する

• 戦略を決定する

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

SharePoint ファームおよびサービスのビジネス要件を定義する

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

• 目標復旧時点 (RPO): 最後にバックアップを取ってから次に障害が発生するまでに許容できる最長時間の目標値。障害が発生してもビジネスに支障が生じないデータ量がどの程度かによって決定します。

• 目標復旧時間 (RTO): データ復元プロセスにかかる最長時間の目標値。サイトまたはサービスが使用不能になってもビジネスに支障が生じない時間によって決定します。

• 目標復旧レベル (RLO): データを復元するときの復元範囲の単位 (ファーム全体、Web アプリケーション、サイト コレクション、サイト、リストまたはライブラリ、あるいはアイテム) を定義する目標。

RPO と RTO の期間が短いほど、RLO の復元単位が小さくなり、コストが増える傾向があります。

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

SharePoint 環境内での保護および復元対象を選択する

環境内のどのコンポーネントを保護し、それらをどの単位で復元できるようにするかは、ビジネス要件を考慮して決定します。

次の表は、SharePoint 環境内で保護対象にできるコンポーネント、および各コンポーネントのバックアップと復元に使用できるツールの一覧を示しています。

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

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

3リモート BLOB ストアに保存されたコンテンツを DPM で復元することはできません。

4Web.config に加えられた変更は、DPM 2010 からファイル システム バックアップを使用してバックアップできます。

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

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

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

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

9サーバーの全体管理コンテンツ データベースと、SharePoint Server 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 Server の機能と同様、これらのファイルは復旧後、必要に応じてファームへの再適用が必要になります。

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

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

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

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

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

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

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

SharePoint のバックアップと復元ツールを選択する

バックアップおよび復元に適したツールを選定するときは、使用可能な時間とリソースの範囲内でビジネスに設定した継続性要件を満たすことができるかどうかを判断する必要があります。

ツールを選ぶときに考慮すべき主なポイントは次のとおりです。

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

• 復元の完全性。

• 復元できるオブジェクトの単位。

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

• ツール管理の複雑さ。

Microsoft から入手できるバックアップおよび復元ツールで 6 時間以内にバックアップできるバックアップの種類とファーム サイズを次の表に示します。

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

テスト ハードウェア

6 時間以内に完了できるバックアップのサイズを算出するテストで使用されたハードウェアの一覧を次の表に示します。

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

• バックアップと復旧の概要 (SharePoint Server 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 のバックアップおよび復元の戦略を決定する

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

SharePoint Server 環境をサポートする IT 部門では、使用する戦略を決定するとき、環境の保護に複数のツールを使おうと考えることがよくあります。

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

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

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

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

• 小規模で頻繁に変更されビジネスに大きく影響するコンテンツ データベースを、追加的に保護するために SQL Server データベース スナップショットとして別の物理ディスクに格納する。データベースごとに 1 つのスナップショットのみが格納され、スナップショットは定期的に破棄されるので、パフォーマンスへの影響は最小限に抑えられる。データベースごとに設定されるスナップショット間隔は、以下の要因に基づく。

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

  • データベースに対する変更の標準速度。

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

  • スナップショットを格納するのに必要な領域。

  SharePoint Server では、スナップショットとその基本となるデータベースを未接続データベースとして処理できるので、スナップショットから復元する方が、標準の復元よりも高速です。ただし、スナップショットを作成することで、基本となるデータベースのパフォーマンスが低下する可能性があります。スナップショットを実装する前に、システムのパフォーマンスに及ぼす影響をテストし、スナップショットを定期的に削除して、必要な領域を削減することをお勧めします。

  注意

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

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

  • サービスの重要度。

  • データベースに対する変更の標準速度。

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

• すべての復元操作を SharePoint Server から実行する。どの復元システムを選択するかは、使用できるバックアップの種類と復元対象のオブジェクトによって決定する。

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

SharePoint のバックアップおよび復元の戦略を設計するときにパフォーマンスを計画する

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

ほとんどのバックアップ ジョブは、メンテナンスの時間内にジョブを終了するためにできるだけ多くの I/O リソースを消費するようになっています。そのため、ディスクで処理待ちが発生して、すべての I/O 要求への応答が通常よりも遅く感じられることがあります。これは一般的な動作であり、問題と見なす必要はありません。

SQL Server およびストレージの構成に関する推奨事項に従う

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

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

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

処理競合を回避する

ユーザーがシステムにアクセスしなければならない時間帯には、バックアップ ジョブを実行しないでください。

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

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

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

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

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

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

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

SQL Server のバックアップと復元のパフォーマンスを最適化する方法の詳細な推奨事項については、「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 (英語)