SharePoint 製品とテクノロジのバックアップと復元について考える Part 2
<関連記事> SharePoint 製品とテクノロジのバックアップと復元について考える Part 1 SharePoint 製品とテクノロジのバックアップと復元について考える Part 2 |
みなさんこんにちは。
SharePoint サポートチームの荒川です。
今回も、前回に引き続き、SharePoint 製品とテクノロジのバックアップと復元について書いていきます。
第 2 回では、データのバックアップ方法についてお伝えします。
■バックアップ方法を検討する
SharePoint のバックアップと復元が一筋縄ではいかないことは、先の解説よりご理解いただけたかと思います。
しかし、そう難しく考える必要なありません。最低限行うべき作業を理解すれば、作業自体は意外とシンプルなものです。
このセクションでは、バックアップ方法について解説します。
バックアップについてはそれほど難しく考える必要は無く、基本は復元時に必要になるものを取得するという考え方になります。逆に言えば、必要が無いものは別に取らなくてもよいということにもなります。
この記事では SharePoint 製品とテクノロジのバックアップと復元に関する一般的な考え方を理解していただくことを目的としていますので、ここではあえて詳細な手順には触れません。詳細な手順については添付の参考資料よりご参照ください。
最小限のバックアップについて考える
最小限のバックアップシナリオは、コンテンツデータベースを SQL ツールを使用してバックアップする方法です。
これにより最も短時間に、最重要なコンテンツデータをバックアップできます。
殆どの場合、SharePoint の運用において最も最優先される保護対象は、ユーザーのコンテンツデータベースとなるでしょう。コンテンツデータベースはいかなる場合であっても最優先で保護されるべきデータです。最悪、コンテンツ データベースのバックアップさえ取得しておけば、時間はかかりますがファームを再構築して、再構築後の環境にコンテンツデータベースを接続することで容易にユーザー データを復元できます。
コンテンツデータベース以外のデータについては、ユーザーの運用方法により必ずしも必要ではありません。たとえば、高度な検索設定を行っておらず、障害回復後に検索インデックスのフルクロールが許容される環境では、検索アプリケーションのバックアップは必須ではありません。また、ユーザーの個人用機能を利用しておらず、障害回復後のプロファイルの再同期が許容される環境では、User Profile サービス アプリケーションのバックアップも必須ではありません。
最も簡単なバックアップシナリオについて考える
ユーザーが個人用サイトから自分用プロファイルを変更している場合や、検索用の管理プロパティマッピングを複雑に構成している場合などは、サービス アプリケーションのデータが重要になる事もあります。つまりは、コンテンツ データベース + <ユーザーの運用にとって重要なデータ> を最低限バックアップする必要があるということです。ユーザーにとって何が重要になるかすぐに判断できない場合は、すべてのデータをまとめてバックアップしてしまう方法があります。
SharePoint 標準で用意されたバックアップ ツールであるサーバーの全体管理または、SharePoint 2010 管理 PowerShell (または Stsadm コマンドラインツール) を使用することで、ユーザーの固有のカスタマイズ以外のすべてのファーム データをまとめてバックアップできます。
ファームのデータ量が多い場合にはバックアップに時間がかかるため、他の方法と併用する必要が生じますが、バックアップに要する時間が運用面での許容範囲であれば、この方法が最も簡単にすべてのデータをバックアップできる方法となります。
もちろん、バックアップしたものはコンポーネント単位で個別に復元できますし、初めから必要なコンポーネントだけを選択してバックアップすることも可能です。
なお、この方法で採取したバックアップは、既存のファームが正常稼働している場合はそのまま上書き復元が可能です。既存のファームが破損している場合は、新規ファームを手動構築した後、一部のパラメータを手動構成してから上書き復元できます。通常、データの復元だけを目的に正常稼働している既存のファームを上書き復元するケースは稀だと思います。構成ウィザードの実行に失敗して切り戻しを行う場合等、殆どの場合には新規ファームを手動構築した後で上書き復元することになるでしょう。新規ファームを手動構築した後で上書き復元する場合、代替アクセスマッピングの設定やサービス プロキシ グループの関連付けなど、一部のパラメータの再設定が必要となります。これに備えて予め後述の資料を参考に、ファームの構成設定を文書化することをお勧めします。
一般的には、SQL Server ツールによるコンテンツ データベースのバックアップと、SharePoint ツールによるファーム (サービス アプリケーション) バックアップを併用するケースが多いのではないかと思います。
バックアップ方法に関する詳細は以下の資料に詳しく書いてありますので必要に応じてご参考ください。
<参考> SharePoint Server 2010 でのバックアップと復元を計画する https://technet.microsoft.com/ja-jp/library/cc261687 バックアップ (SharePoint Server 2010) https://technet.microsoft.com/ja-jp/library/ee428315 データベースの種類と説明 (SharePoint Server 2010) https://technet.microsoft.com/ja-jp/library/cc678868.aspx ファームの構成設定を文書化する (SharePoint Server 2010) |
カスタマイズのバックアップについて考える
ユーザー独自のカスタマイズは、カスタマイズ方法によっては標準ツールのバックアップに含まれません。
ソリューションパッケージとして展開されたものはファーム バックアップに含まれますが、14 ハイブの下のテンプレート等に直接加えられた変更や Web.config ファイルに対する変更のバックアップなどはバックアップ対象になりませんので、ユーザーが個別にバックアップする必要があります。
このあたりの内容は以下の資料に詳しく書いてありますので必要に応じてご参考ください。
<参考> カスタマイズをバックアップする (SharePoint Server 2010) |
バックアップはそれほど複雑ではありません。
おおよそ、上記の方法を組み合わせることで、復元時に必要となる情報は一通り確保できると思います。
次回はいよいよ肝心要の、データの復元方法について解説する予定です。