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

適用対象:2016 2019 Subscription Edition SharePoint in Microsoft 365

通常、バックアップと復元の計画は、SharePoint Server環境を展開する前に利用できるようにする必要があります。 その後、データを保護するためには、SharePoint Serverの変更に応じてバックアップと復元の計画を維持して更新する必要があります。

バックアップと回復の計画に関連するステージには、SharePoint Server 環境のバックアップと回復の戦略の決定と、使用するツールの決定が含まれます。 記述されている順序で各段階を実施する必要はなく、プロセスを反復する場合もあります。

障害復旧のためにバックアップと復元を計画する場合、一般的なイベント、障害、エラー、および近隣や地域での緊急事態を考慮します。 この記事のセクションでは、バックアップと復元の計画で対処する必要があるステージについて説明します。 各ステージは、優れたバックアップを使用してSharePoint Server ファームを復元する最終目標に向けたステップです。 段階は必要に応じてカスタマイズすることができます。 すべてのバックアップと復元の計画は動的であり、現在の SharePoint Server 環境が反映されている必要があります。

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

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

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

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

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

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

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

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

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

次の表は、SharePoint 環境内で保護対象にできるコンポーネント、および各コンポーネントのバックアップと復元に使用できるツールを示しています。 お気づきのように、どちらの表も似ていますが、各 SharePoint Server 版用に特定のバックアップ コンポーネントが示されています。

バックアップと復元の対象となる SharePoint Server 2016 のコンポーネント

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

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

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

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

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

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

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

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

(9) サーバーの全体管理 コンテンツ データベースと、SharePoint Server 2016 ファームの構成データベースは、同じコンピューターで同じファームに対する完全ファーム バックアップの一環としてのみ復元できます。

詳細については、「アナウンス: 強化されたセキュリティで Server 2016 のワークロードを保護する」を参照してください。

バックアップと復元の対象となる SharePoint 2013 のコンポーネント

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

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

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

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

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

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

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

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

(9) サーバーの全体管理 コンテンツ データベースと、SharePoint 2013 ファームの構成データベースは、同じコンピューターで同じファームに対する完全ファーム バックアップの一環としてのみ復元できます。

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

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

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

カスタマイズを保護する

SharePoint サイトのカスタマイズは、以下の範囲で行われます。

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

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

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

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

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

• Web.config ファイルに対する変更。

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

ワークフローを保護する

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

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

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

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

  • XML 定義ファイル (。ACTIONS ファイル) は、15\TEMPLATE{LCID}\Workflow ディレクトリに格納されます。

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

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

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

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

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

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

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

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

SharePoint Serverのバックアップと復元には SQL Server Reporting Services データベースは含まれません。 SharePoint Server では SQL Server ツールを使用する必要があります。 詳細については、「Reporting Services のバックアップおよび復元操作」を参照してください。

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

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

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

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

• 復元の完全性。

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

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

• ツール管理の複雑さ。

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

• SharePoint Server のバックアップと回復の概要

• SQL Server でのデータベースのバックアップおよび復元

• DPM の概要

SharePoint のバックアップおよび復元の戦略を決定する

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

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

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

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

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

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

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

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

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

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

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

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

    注:

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

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

  • サービスの重要度。

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

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

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

その他のツールについては、ビジネス継続性戦略の一環となるものを使用してください。 環境全体のサイト コレクションでのごみ箱とバージョン管理の使用方法を検討してください。 詳細については、「SharePoint Server で高可用性および障害復旧を計画する」を参照してください。

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

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

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

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

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

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 Enterprise を使用している場合は、バックアップ圧縮を使用することをお勧めします。 詳細については、「バックアップの圧縮 (SQL Server)」を参照してください。

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

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

SQL Server のバックアップと復元のパフォーマンスを最適化する方法の詳細な推奨事項については、「SQL Server におけるバックアップと復元のパフォーマンスの最適化」を参照してください。

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

ディスク バックアップ デバイスで RAID (Redundant Array of Independent Disks) を使用するかどうかを慎重に検討してください。 たとえば、RAID 5 は書き込みのパフォーマンスが低く、ディスクが 1 つの場合とほぼ同じ速度です (RAID 5 がパリティ情報を維持するためです)。 バックアップ デバイスに RAID 10 を使用すると、バックアップがより高速になる場合があります。 バックアップで RAID を使用する方法の詳細については、「SQL Server の I/O スループットを最大限引き出すための RAID の構成」を参照してください。

関連項目

概念

SharePoint Server のバックアップと回復の概要

その他のリソース

データの保護と回復