SharePoint Server カスタマイズのバックアップ・移行について


こんにちは SharePoint サポートの森 健吾 (kenmori) です。

今回の投稿では、SharePoint Server オンプレミス製品において、カスタマイズを含むバックアップの方法について、SharePoint のソリューション開発を実施されたことのない運用管理者に理解できるレベルを目指して概要をご説明します。

公式サイトの情報について

下記 Technet 記事は、基本的に様々なカスタマイズ ソリューションに合わせて全体を網羅する形で記載があります。

タイトル : SharePoint 2013 でカスタマイズをバックアップする
アドレス : http://technet.microsoft.com/ja-jp/library/ee748642(v=office.15).aspx

タイトル : SharePoint 2013 でのバックアップと復元を計画する
アドレス : http://technet.microsoft.com/ja-jp/library/cc261687(v=office.15).aspx

基本的に上記の通りです。SharePoint のソリューション開発者にとっては開発用語が理解でき、わかりやすい内容だと思います。ただし管理者はこれらの用語が理解しづらく、自身の環境がどの条件にあるのかわかりにくいかもしれません。本投稿では理解するために必要な知識を補足しようと考えています。

本投稿は、細かなポイントを列挙するよりも、上記バックアップに関連する資料を読み解くために、最初に理解しておきたいポイントを明確します。SharePoint のバックアップ・復元を理解する上での最初の足掛かりにしていただけますと幸いです。

 

SharePoint のバックアップが含むデータについて

SharePoint には様々なバックアップ方法がありますが、基本的にファーム、データベース、サイトコレクション単位のバックアップにおいても採取できる情報は、データベース内の情報のみです。

例えば、SharePoint の通常の Web フロント エンド サーバーの動作を想像してみましょう。データベース内に含まれたコンテンツを Web フロント エンド サーバー上に含まれたスキーマ情報やロジックで変換し、HTML データなどをブラウザーに返します。

上図を見て、データだけがバックアップ・復元された状況を想像してみましょう。

SharePoint 標準のモジュールは、インストーラーによってすべてのファイルが構成されているため、別サーバーに移行する際においても問題にはなりません。

ただし、カスタマイズ ソリューションをインストールしてない場合はどうなるでしょうか。カスタマイズ機能で生成されたデータは Web フロント エンド サーバーに配置されていないため、読み取れなくなってしまいます。クライアント PC でのイメージとしては、Excel をインストールしていないので、xlsx ファイルが読めなくなってしまったような状況になります。

 

具体的なソリューションの例

もう少し、深く理解したい人のために、具体的な例を挙げます。下記にごく一般的で最少構成の Web パーツ ソリューションの例を記載します。

 

Web パーツをインストールすると、すべての Web フロント エンド サーバーに以下のファイルが配置されます。Web フロント エンド サーバーに配置されたこれらの物理ファイルはバックアップには含まれません。

1) feature.xml, element.xml といった機能の定義ファイル
2) 実装コードがコンパイルされて組み込まれた DLL
3) Web パーツを安全なコントロールと認識させるために web.config への SafeControl 要素追加
4) Web パーツをページに追加できるよう Web パーツ ギャラリーにアップロードするための *.webpart ファイル

 

下記、実際にこの Web パーツを使用した際に注目ください。下記 2 つの情報は、サイト内のデータに直接記載されているので、バックアップ内に含まれます。

1) サイトやサイト コレクションでWeb パーツ機能を有効化すると、サイト内の Web パーツ ギャラリーに *.webpart ファイルが追加されます。
2) ページの編集を実施して Web パーツをページに追加すると、ページ上に Web パーツを追加しているという情報がコンテンツ DB 内 WebParts テーブルに記録されます。

 

つまり、Web パーツ機能を有効化し使用しているというデータがあるにもかかわらず、Web パーツを表示するためのプログラムが Web フロント エンド サーバー上にないため、正常に動作しなくなるという状況が発生します。

 

(補足)
本筋の話とはそれますが、Web パーツ機能を有効化した際に *.webpart ファイルが Web パーツ ギャラリーに保存されます。ただし、逆に Web パーツ機能を無効化しても、*.webpart ファイルは削除されません。

SharePoint の機能は、サイトコンテンツを削除するという動作については慎重となる実装となります。そのため、もう使用していないはずの Web パーツがヘルスアナライザー上でエラーを出しているような状況に遭遇することもあります。

この場合、もう使用していないということがわかった時点で、Web パーツ ギャラリーから *.webpart ファイルを削除していただく形で構いませんし、残しておいても特に警告が通知されるだけで使用上特に害はありません。

 

バックアップの復元方法

上記の通り、カスタム ソリューションを含むファームをバックアップしても、カスタマイズ モジュールやスキーマ定義を使用して生成されたデータのみしかバックアップされません。
そのため、ファームを超えたバックアップ・復元を実施する場合は、これらのカスタマイズを移行先にインストールする作業を併せて実施する必要があります。

 

復元手順概要

1. SharePoint サーバーのインストール
2. バックアップ データの復元 (*)
3. カスタム ソリューションのインストール (*)

 

例えば、ファーム内のカスタマイズがソリューション パッケージのみで構成されている場合は、ソリューション パッケージをインストールしてデータを復元すれば作業は終わりです。

ただし、Technet の記事が複雑になっている理由は、ほとんどの運用シナリオにおいて、このようなカスタマイズ一覧や導入手順が統一管理されていないことと、ソリューション パッケージをインストールするだけにとどまらないことに起因します。
その結果、どんなソリューションがインストールされているかをその場で情報収集して確認し、Technet に記載された情報を確認しながら、膨大な移行計画を立てていく必要が生じてしまいます。

このような状況に備えるため、日頃からファーム上にどのようなカスタマイズを実装しているかについて、カスタマイズ一覧と導入手順を統一管理しておくことで、突然生じる移行シナリオに備えておく必要があります。

(参考情報)

ファームに展開されたソリューション パッケージ (*.wsp) を一括で取得する PowerShell スクリプトを以下に記載します。

$outfolder = "C:\TEMP\"

$farm = Get-SPFarm

$farm.Solutions | foreach { $farm.Solutions.Item($_.Name).SolutionFile.SaveAs($outfolder + $_.Name) }

また、SharePoint Server 2013 からは、ファーム ソリューションをバックアップし、別環境に復元できるようになっています。併せてご参考にしてください。

Backup-SPFarm -backupmethod full -directory C:\TEMP\ -item "farm\solutions"

(* 補足)
復元手順 2. 3. において、バックアップ データの復元とソリューションのインストール作業の順序は、どちらでも問題ありません。前もって計画的にカスタマイズをすべてインストールしてからデータを復元しても構いませんし、一度復元してから足らないカスタマイズをインストールしていっても構いません。

バックアップ データの復元時にカスタマイズがインストールされているか否かはチェックされません。あくまで実行時にチェックがかかり、インストールが不足している機能を使用した際にはエラーとなり、診断ログに記録されます。

 

追加情報
ファームを超えたバックアップ・復元に類似したシナリオとして、ファーム内におけるサーバーの障害復旧やサーバーの増設などがあります。この場合、構成ウィザードを実行してファームに参加した時点で、ソリューション パッケージが自動的にソリューションを展開しますので、再度インストール展開を実施する必要はありません。
ただし、手動でサーバーごとに物理ファイルに対するカスタマイズを実施している場合は、この後手動でカスタマイズを適用していただく必要があります。

 

認識しておきたい点

重要な点として、カスタマイズの内容は、カスタマイズに従事または展開を実施した当事者しか完全にはわからないということを認識しておく必要があります。例えば、カスタマイズに関する技術に精通した人は、大まかな実装と展開方法を推測することはできます。しかし、実際の利用者の特別な要件をカバーした場合や、開発者のスキル レベルなどによっては、通常想定される方法とは異なる実装になっている場合もあります。

このような独自の状況が生じることを想定し、カスタマイズを計画する際には、実現までの開発工数を考慮するだけではなく、保守時に生じる移行などの複雑化や修正プログラムの影響テスト、製品のメジャーバージョン アップグレード時の再テストなどのリスクをあらかじめ想定しておくことが重要です。

 

 

特筆すべきカスタマイズの種類

下記に特筆すべきカスタマイズについて記載します。

ソリューション パッケージ
通常、ソリューション パッケージは、何も特別な考慮は必要とせず、単純に展開するだけです。しかしながら、利用者の特別な要件を満たす場合や、開発者のスキルなどで、ソリューションを適切に展開するよう実装されておらず、一部の展開操作を手動で行う必要があるものも考えられます。こういった場合を考慮して、必ず導入手順書 (単純に展開するだけというメモだけでも OK) は抑えておくようにしてください。

 

サイトコンテンツのカスタマイズ
SharePoint Designer で実施したページのカスタマイズ、表示テンプレートのカスタマイズはコンテンツ DB に格納されるため多くの場合バックアップに含まれます。ただし、特に移行時に URL など条件が変わった場合は、実装内容に合わせて動作確認を実施することをお勧めします。

InfoPath フォーム テンプレート
InfoPath の場合も同様にテストしてください。特に URL が変わった場合は発行先やデータ接続などを新しい URL に変更したうえで再発行してください。
既存のフォーム (*.xml) はフォーム ライブラリの詳細設定画面より [ドキュメントへの再リンク] を実施して、再度関連付け直します。

ワークフロー
SharePoint Designer で作成した 2010 形式ワークフローや実行中のワークフロー インスタンスの情報もバックアップに含まれます。

2013 形式ワークフローは外部のサービスであるワークフロー マネージャのデータベースに格納されるため SharePoint のバックアップには含まれません。ワークフロー マネージャという製品をバックアップする方法もありますがかなりの労力を必要とするため現実的ではありません。既存インスタンスをあきらめて、再利用可能なワークフロー テンプレートをサイトに再適用する方法が現実的と思われます。

タイトル : Understanding SharePoint 2013 Workflow Backup
アドレス : http://technet.microsoft.com/ja-jp/library/jj937239(v=office.15).aspx

 

物理ファイル カスタマイズ (非推奨)
LAYOUTS (_layouts) や ISAPI (_vti_bin) 内のファイル、IIS 仮装ディレクトリ内に手動配置したファイルなど、サーバー上に展開されたファイルを直接更新したり、新規追加するような変更を加えた場合は、バックアップには含まれません。
これらのファイルに対して手動でカスタマイズを再適用してください。

Web.config
web.config を直接編集したカスタマイズについてですが、Technet に記載されている通り上書きでも構いませんが、もし web.config に Machine ID の記載があり、別のサーバーからバックアップを復元している場合は、サーバーの違いを認識できなくなり、不都合が生じます。この値を元の値から変更しないよう注意する必要があります。つまり、ファイルを上書きするよりも、カスタマイズを再適用する方が、多くの場合無難ということになります。
理想は、ソリューション パッケージの FeatureActivated イベントなどで下記 API を使用した設定変更にとどめたいところです。しかし、httpRuntime の executionTimeout 値をページごとに変更するなど、細かい変更点を全てプログラム化しておくことは開発及びテスト工数を考慮しても、難しい側面があります。

タイトル : SPWebConfigModification class
アドレス : http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification(v=office.15).aspx

 

注意事項

ファイル システム バックアップは、カスタマイズ ファイルに限定して使用すること

バックアップ・復元のシナリオがあまりにも複雑なので、Web フロント エンド サーバーの GAC やシステム ファイル等をまるごとバックアップして復元することも考えやすいと思います。

しかし、一度でも SharePoint が構成ウィザードを実行して構成されれば、インストール ファイル以外の様々なファイルが生成され、これらは実行環境によって異なるキャッシュなどのファイルが生成されることになります。そのため、ファイル システム バックアップなどで、異なるサーバーで生成されたファイルなどを全部復元すると、移行時に不可解な現象が大量に発生することが予想されますので絶対にやめてください。

Technet に記載されている通り、SharePoint を一度でも構成した環境でファイルシステム バックアップを使用する場合は手動でカスタマイズした一部の物理ファイルのみにとどめるべきです。

上記情報をご参考にしていただけますと幸いです。今回の投稿は以上になります。

Comments (0)

Skip to main content