SharePointの災害復旧

Question

Windows Sharepoint Services 3.0の災害復旧計画はどのようなものですか？

現在、SQLバックアップツールを使用してすべてのデータベース（1コンテンツ、管理、検索、構成）をバックアップし、dataprotectorを介してフロントエンドサーバーをバックアップしています。

バックアップをテストするには、別のサーバーファームを使用し、コンテンツデータベースを復元します（ technet ）を選択し、このデータベースを使用する新しいアプリケーションを作成します。新しく作成した共有ポイントアプリケーションにソリューションを再展開するだけです。

ただし、データベースアクセス資格情報（SQLサーバー上）を変更する必要があります。実稼働環境で使用されるユーザーアカウントは、「テスト」で使用されるユーザーアカウントとは異なります。農場。

最後に、コンテンツデータベースを復元し、すべてのサイトにアクセスできます。検索は機能しませんが、調査中です。

この復元シナリオは信頼できますか（Microsoftがサポートしているように）？

Answer 1

設定データベースと検索データベースの両方を実際にバックアップ/復元することはできません：

• 構成データベースの復元は、新しいファームのサーバー名がまったく同じ場合にのみ機能します
• 検索データベースを復元すると、フルテキストインデックスは同期されません。ただし、インデックスを再作成するだけでよいため、これは問題ではありません。

結果として、はい、これはコンテンツにとって信頼できると言えます。ただし、次のことに注意してください。

• 一部の構成（AAM、管理パス...）をやり直す必要がある場合があります。
• これにはカスタマイズは含まれません。ソリューションのバックアップを保持する必要があります

Answer 2

信頼性は見る人の目にあります。この場合、復元プロセスのテストが成功した場合、はい、信頼できます。

Answer 3

多くのクライアントが仮想環境でSharePoint（MOSSとWSSの両方）を実行していますが、SQL Serverも仮想化され、SQLツールとボリュームシャドウコピーの両方でバックアップされています。

仮想環境の利点は、仮想サーバーホストがイメージを起動するのにかかる時間だけダウンタイムが発生することです。

仮想化を使用していない場合は、トランザクションログを定期的にバックアップすることを忘れないでください。これにより、1日の特定のポイントに簡単に復元できるようになります。

Answer 4

ヘルプで説明されているように、「壊滅的なバックアップのために」stsadm -o backupコマンドを使用することを好みます。これはスケジュールできますが、ディスク容量が不足し始め、古いバックアップをアーカイブする必要がある場合、バックアップメタデータXMLファイルのメンテナンスが必要です。 Nicoが言うように、ほとんどの場合、設定データベースの復元は機能しないため、タイマージョブ（通常）およびその他の設定を介して転送するという利点があります。

復元するには、ユーザーインターフェイスを使用できます。このインターフェイスは、他の多くのものをいじる必要はありません。ソリューションも復元できると思いますが、広範囲にテストしていません。