SharePoint 製品とテクノロジのバックアップと復元について考える Part 3
<関連記事> SharePoint 製品とテクノロジのバックアップと復元について考える Part 1 SharePoint 製品とテクノロジのバックアップと復元について考える Part 2 SharePoint 製品とテクノロジのバックアップと復元について考える Part 3 |
みなさんこんにちは。
SharePoint サポートチームの荒川です。
今回も、前回に引き続き、SharePoint 製品とテクノロジのバックアップと復元について書いていきます。
第 3 回では、データの復元方法についてお伝えします。
データの復元方法については、必ず一度は検証してみることをお勧めします。
計画しているバックアッププランが有事の際に期待どおり機能するかどうか確かめておくことは非常に重要です。
■復元方法を検討する
バックアップを正しく計画するには、復元方法についても理解する必要があります。
このセクションでは、復元方法について解説します。
この記事では SharePoint 製品とテクノロジのバックアップと復元に関する一般的な考え方を理解していただくことを目的としていますので、ここではあえて詳細な手順には触れません。詳細な手順については添付の参考資料よりご参照ください。
Web サーバーで障害が発生した場合
Web サーバーで障害が発生した場合、被害を受けたのが Web サーバーだけであれば、ファームから破損した Web サーバーを取り除き、新しい Web サーバーに SharePoint をインストールしてファームに再度追加すればユーザー固有のカスタマイズ以外の必要なデータ (IIS Web サイト等) は自動的に追加され、利用できるようになります。一般的な Web サーバー障害発生時の復旧手順の概要は次のとおりです。
ヒント：Web サーバーを冗長構成することで、障害発生時のダウンタイムを最小限に留めることが可能です。
1. 破損した Web サーバーをファームから取り除く。(全体管理サイトから削除する or 取り除く Web サーバー上で構成ウィザードを実行する)
2. 新しい Web サーバーを準備する。(OS インストール済みのイメージからベアメタル回復することで復旧時間を短縮)
3. 新しい Web サーバーに SharePoint をインストールする。
4. 新しい Web サーバーの SharePoint 更新プログラムをファームの他のサーバーと一致させる。
5. 新しい Web サーバーを既存のファームに接続する。
6. 必要に応じてカスタマイズを再適用する。
このシナリオでは、すでに取得済みのファームバックアップを使用することはありません。
<参考> サーバーをファームから削除する (SharePoint Server 2010) |
検索サーバーで障害が発生した場合
検索サーバー (クロール コンポーネント、クエリ コンポーネント、検索管理コンポーネント) で障害が発生した場合も、Web サーバーと同様にファームから破損したサーバーを取り除き、新しいサーバーに SharePoint をインストールしてファームに再度追加すれば問題ありません。Web サーバーと異なる点として、ファームからのサーバーの削除の他、検索トポロジからのコンポーネント削除が必要となります。
ヒント：検索トポロジを冗長構成することで、障害発生時のダウンタイムを最小限に留めることが可能です。
1. 破損した Web サーバーをファームから取り除く。(全体管理サイトから削除する or 取り除く Web サーバー上で構成ウィザードを実行する)
2. 検索トポロジから破損したコンポーネントを取り除く。
3. 新しい検索サーバーを準備する。(OS インストール済みのイメージからベアメタル回復することで復旧時間を短縮)
4. 新しい検索サーバーに SharePoint をインストールする。
5. 新しい検索サーバーの SharePoint 更新プログラムをファームの他のサーバーと一致させる。
6. 新しい検索サーバーを既存のファームに接続する。
7. 検索トポロジに新しいコンポーネントを追加する。
このシナリオでは、すでに取得済みのファームバックアップを使用することは基本的にありませんが、ファームの最後のクエリ コンポーネントで障害が発生した際にクロール済みのインデックスをより早く復元する目的で、検索のバックアップを使用することが可能です。
<参考> 検索トポロジを管理する |
その他のアプリケーションサーバーで障害が発生した場合
その他のアプリケーションサーバーで障害が発生した場合も、基本的には Web サーバーと同様です。サーバーの復旧後に、必要に応じて各種サービスを有効にします。アプリケーション サーバーが破損した場合であっても、ファームの構成データとしてのサービスアプリケーションが破損しているわけではないため、サーバの復旧後に必要に応じてサービスを構成することで、アプリケーション サーバーを復旧できます。
ヒント：必要に応じてアプリケーションサーバーを冗長構成することで、障害発生時のダウンタイムを最小限に留めることが可能です。
1. 破損したアプリケーション サーバーをファームから取り除く。(全体管理サイトから削除する or 取り除く Web サーバー上で構成ウィザードを実行する)
2. 新しいアプリケーション サーバーを準備する。(OS インストール済みのイメージからベアメタル回復することで復旧時間を短縮)
3. 新しいアプリケーション サーバーに SharePoint をインストールする。
4. 新しいアプリケーション サーバーの SharePoint 更新プログラムをファームの他のサーバーと一致させる。
5. 新しいアプリケーション サーバーを既存のファームに接続する。
6. 必要に応じてサービスの再構成を行う。
このシナリオでは、すでに取得済みのファームバックアップを使用することはありません。
データベースサーバーで障害が発生した場合
データベースサーバーで障害が発生した場合は、ファームを再構築した後、最新のファーム バックアップからデータを復元する必要があります。
コンテンツデータベースの復旧モードを完全に設定されていた場合、必要に応じて SQL Server の最新のトランザクション ログが適用されたコンテンツ データベースを差し替えることが可能です。
ヒント：データベースサーバーの破損は影響範囲が大きいため、必要に応じてクラスタ化やデータベースミラーリングによるデータの保護を検討します。
1. ファームの各 SharePoint サーバー上で構成ウィザードを実行して既存のファームから切断する。(データベースに接続できない場合自動的に切断する選択肢になる。)
2. SQL Server を再構築して利用可能な状態にする。
3. ファームの各 SharePoint サーバー上で構成ウィザードを実行して新しいサーバー ファームを作成する。
4. 新しいサーバー ファームに最新のファーム バックアップを復元する。
5. 必要に応じてカスタマイズを再適用する。
6. 必要に応じて SQL Server の最新のトランザクション ログが適用されたコンテンツ データベースを差し替える。
<参考> ファームを復元する (SharePoint Server 2010) |
更新プログラムの適用に失敗して切り戻しを行う場合
SharePoint の更新プログラムは個別にアンインストールできないため、切り戻しを行うには SharePoint の再インストールが必要になります。
SharePoint のアンインストール時に、対象のサーバーは既存のファームから切断されます。
更新プログラムの適用時、SharePoint 製品構成ウィザードの実行前であれば、対象の SharePoint サーバーのみをファームから切断して再インストール後に再接続することで復旧が可能ですが、SharePoint 製品構成ウィザードの実行中に障害が発生した場合、すべてのデータベースを削除した後、データベース サーバーで障害が発生した場合と同様にファームを再構築する必要があります。
ヒント：SharePoint 2010 では更新プログラムの段階的な適用がサポートされているため、障害発生時の影響範囲を少なくすることが可能です。
<参考> SharePoint Server 2010 のソフトウェア更新プログラムの展開 |
1. ファームの各 SharePoint サーバーをで SharePoint アンインストールして既存のファームから切断する。
2. SQL Server で既存の SharePoint データベースをすべて削除する。
3. ファームの各 SharePoint サーバーに SharePoint をインストールする。
4. ファームの各 SharePoint サーバーの SharePoint 更新プログラムをバックアップ時のものと一致させる。
5. ファームの各 SharePoint サーバー上で構成ウィザードを実行して新しいサーバー ファームを作成する。
6. 新しいサーバー ファームに最新のファーム バックアップを復元する。
7. 必要に応じてカスタマイズを再適用する。
更新プログラムの適用に失敗して切り戻しを行わず続行する場合
更新プログラムのインストールに成功して製品構成ウィザードで失敗する場合、状況によってはコンテンツデータベース以外のファーム データを新規に構築した後、最新のバックアップを基にコンテンツ データベースのみを個別にアップグレードすることでダウンタイムを最小限に留めることが可能です。
ヒント：このシナリオに備えて、更新プログラム適用前には通常のファームバックアップの他、コンテンツ データベースのバックアップの取得をお勧めします。コンテンツ データベースのアップグレード自体に失敗する場合は、通常の切り戻しを行う必要があります。
1. ファームの各 SharePoint サーバー上で構成ウィザードを実行して既存のファームから切断する。
2. SQL Server で既存の SharePoint データベースをすべて削除する。
3. ファームの各 SharePoint サーバー上で構成ウィザードを実行して新しいサーバー ファームを作成する。
4. 新しいサーバー ファームに最新のコンテンツ データベースを接続してデータベースをアップグレードする。
5. 必要に応じてカスタマイズを再適用する。
いかがでしょうか。このように、バックアップを復元するシナリオは多岐にわたります。勿論、複雑な復元シナリオを考えるのが面倒な場合や、シンプルな検証環境、デモンストレーション環境では、毎回ファームを再構築してもよいですが運用環境においてダウンタイムを最小限に留めたい場合には、必要に応じて最適な復元シナリオを選択する必要があります。
復元方法に関する詳細は以下の資料に詳しく書いてありますので必要に応じてご参照ください。
<参考> 復旧 (SharePoint Server 2010) |