バックアップと復旧のベスト プラクティス (SharePoint Foundation 2010)
適用先: SharePoint Foundation 2010
この記事では、Microsoft SharePoint Foundation 2010 のバックアップと復旧の操作が成功し、環境内でデータと持続性が失われないようにするために使用できるベスト プラクティスについて説明します。記事には、パフォーマンス、品質保証、セキュリティ、卓越した運用のためのベスト プラクティスが含まれています。
この記事の内容
パフォーマンスのベスト プラクティス
品質保証のベスト プラクティス
操作のベスト プラクティス
パフォーマンスのベスト プラクティス
バックアップと復元の操作は、実行中に、サーバー リソースを消費し、サーバーのパフォーマンスを制限する可能性があります。以下のベスト プラクティスに従うことにより、リソースの使用量を削減し、サーバーのパフォーマンス、およびバックアップまたは復元操作のパフォーマンスを向上させることができます。
SQL Server とバックアップ場所の間の遅延を最小限に抑える
一般的に、バックアップには、ネットワーク ドライブではなくデータベース サーバー上のローカル ディスクを使用し、後からデータをネットワーク上の共有フォルダーにコピーすることをお勧めします。ネットワーク ドライブは、データベース サーバーとの間の遅延が 1 ミリ秒以下の場合に、良好なパフォーマンスが得られます。
I/O ボトルネックを回避するには、Microsoft SQL Server 2008 Service Pack 1 (SP1) (累積的な更新プログラム 2 を適用済み) を実行しているディスクとは別のディスクにメインのバックアップを実行します。
仕様では、ほとんどのバックアップ ジョブは、ジョブを終了するために、消費できるだけの I/O リソースを消費します。したがって、ディスクのキュー処理が実行され、I/O 要求の遅延が通常よりも大きくなる可能性があります。これは一般的な動作であり、問題と見なす必要はありません。
処理競合を回避する
ユーザーがシステムへのアクセスを必要とする時間帯にバックアップ ジョブを実行しないでください。すべてのデータベースが同時にバックアップされないように、バックアップをずらして行うことを検討してください。
回復時間を早くするために、データベースのサイズを小さくする
データベース サイズを小さくして、バックアップと回復の両方の速度を上げます。このために、Web アプリケーションでは大きなコンテンツ データベースを 1 つ使用するのではなく、複数のコンテンツ データベースを使用します。
大規模なデータベースで増分バックアップを使用する
DPM 2010 で利用できるような大規模なデータベースには、増分バックアップを使用します。大規模なデータベースの場合、フル バックアップよりも増分バックアップの方がより高速かつ効率的に復元できます。バックアップの種類の詳細については、「バックアップの概要 (SQL Server)」(https://go.microsoft.com/fwlink/?linkid=203863&clcid=0x411) を参照してください。
バックアップ中に圧縮を使用する
状況によっては、圧縮を使用してバックアップ サイズの改善 (30% 増量) と時間の短縮 (25% 短縮) を行うことができます。バックアップの圧縮は、SQL Server 2008 Enterprise で導入されました。バックアップの圧縮が SQL Server のパフォーマンスにどのような影響を与えるかについての詳細は、「バックアップの圧縮 (SQL Server)」(https://go.microsoft.com/fwlink/?linkid=129381&clcid=0x411) を参照してください。
SQL Server のバックアップと復元の最適化に関する推奨事項に従う
SQL Server のバックアップを使用している場合、復旧時間を最小限にするために、(完全復旧モデルまたは一括ログ復旧ログの) 完全バックアップ、差分バックアップ、およびトランザクション ログ バックアップを組み合わせて使用します。差分データベース バックアップは、通常、完全データベース バックアップよりも高速に作成でき、データベースを復旧するために必要なトランザクション ログの量が少なくなります。
完全復旧モデルを使用する場合は、メンテナンスの問題を回避するために、トランザクション ログ ファイルを定期的に切り詰めることをお勧めします。
SQL Server バックアップと復元のパフォーマンスを最適化する方法の詳細な推奨事項については、「SQL Server におけるバックアップと復元のパフォーマンスの最適化」(https://go.microsoft.com/fwlink/?linkid=126630&clcid=0x411) を参照してください。
RAID を使用する場合は RAID 10 を使用する
ディスク バックアップ デバイスで RAID (Redundant Array of Independent Disks) を使用するかどうかを慎重に検討してください。たとえば、RAID 5 は書き込みのパフォーマンスが低く、ディスクが 1 つの場合とほぼ同じ速度です (これは、RAID 5 でパリティ情報を維持する必要があるためです)。バックアップ デバイスに RAID 10 を使用すると、バックアップがより高速になる可能性があります。バックアップで RAID を使用する方法の詳細については、「Configure RAID for maximum SQL Server I/O throughput (英語)」(https://go.microsoft.com/fwlink/?linkid=126632&clcid=0x411) (英語) を参照してください。
バックアップまたは復元のパフォーマンスが良好になるように SharePoint 設定を構成する
サーバーの全体管理と Windows PowerShell の両方で設定を構成して、バックアップまたは復元の効率とパフォーマンスを向上させることができます。
Export-SPWeb Windows PowerShell コマンドレットを使用している場合は、NoFileCompression パラメーターを使用できます。既定では、SharePoint Foundation 2010 は、Web アプリケーション、サイト コレクション、リスト、またはドキュメント ライブラリのエクスポート中にファイルの圧縮を使用します。このパラメーターを使用すると、エクスポートとインポート中のファイル圧縮を抑制できます。ファイルの圧縮で使用できるリソースは最大で 30% 増えますが、エクスポートされたファイルが使用するディスク容量はおよそ 25% 少なくなります。エクスポート中に NoFileCompression パラメーターを使用する場合、同じコンテンツをインポートするときも NoFileCompression パラメーターを使用する必要があります。
NoLogFile パラメーターを使用することもできます。既定では、SharePoint Foundation 2010 は、コンテンツをエクスポートするときに必ずログ ファイルを生成します。このパラメーターを使用すると、ログ ファイルの作成を抑制してリソースを節約できます。しかし、常にログを作成することをお勧めします。ログはトラブルシューティングで使用できます。またログを作成するために、多くのリソースが使用されるわけではありません。
注意
これらの設定は、サーバーの全体管理から使用できます。
Backup-SPFarm コマンドレットを使用する場合、BackupThreads パラメーターを使用して、バックアップ プロセス中に SharePoint Foundation 2010 が使用するスレッドの数を指定できます。指定したスレッドの数が多いと、バックアップ操作で利用するリソースも増えますが、十分なリソースを利用できれば、バックアップ操作の終了もその分早くなります。ただし各スレッドはログ ファイル内で個々に報告されるため、使用するスレッドの数が少なくなるとログ ファイルの解釈も簡単になります。既定では 3 つのスレッドが使用されます。利用できる最大のスレッド数は 10 です。
注意
この設定は、サーバーの全体管理の [バックアップおよび復元の既定の設定] ページにある [バックアップと復元] セクションからも使用できます。
使用するツールを決定するときにサイト コレクションのサイズを考慮する
業務で、ファームレベルまたはデータベース レベルのバックアップの他にサイト コレクションのバックアップも必要になる場合、サイト コレクションのサイズに基づいて使用するツールを選択します。
15 GB 未満: Windows PowerShell コマンドの Backup-SPSite を使用します。詳細については、「サイト コレクションをバックアップする (SharePoint Foundation 2010)」を参照してください。
15 GB から 100 GB: SharePoint 製品とテクノロジのツール、SQL Server ツール、または他のデータベース バックアップ ツールを使用して、サイト コレクションを含むコンテンツ データベースを保護します。詳細については、「サイト コレクションをバックアップする (SharePoint Foundation 2010)」を参照してください。
100 GB より大きい: 組み込みのバックアップと回復ツールではなく、Microsoft SQL Server 2005、DPM 2010 などの差分バックアップ ソリューションを使用します。
品質保証のベスト プラクティス
このベスト プラクティスに従って、ファーム環境のバックアップの品質を保証し、データ損失の可能性を減らすことができます。
十分な記憶域があることを確認する
システムにバックアップを収容するための十分なディスク領域があることを確認します。
バックアップの品質を定期的にテストする
バックアップを定期的にテストし一貫性を検証します。実際の回復操作を実行してバックアップのコンテンツを検証し、環境全体を復元できることを確認します。地理的に分散した環境では、リモート ファームを設定して、障害復旧の準備をします。次に、データベース接続コマンドを使用してデータベースのコピーをリモート ファームにコピーしユーザーをリダイレクトすることにより、環境を復元できます。定期的にデータ回復のテストを実施し、ファイルが適切にバックアップされていることを確認します。データ復元テストでは、ソフトウェア検証では検出できないハードウェア問題が見つかる場合があります。
ULS トレース ログをバックアップする
SharePoint Foundation 2010 ツールは、ULS トレース ログをバックアップしません。ULS トレース ログ内のデータは、パフォーマンス分析、トラブルシューティング、サービスレベル アグリーメントの順守の監視のため、および法律、規則、業務上の理由で利用することができます。したがって、日常的な保守業務の一環として、このデータを保護してください。ULS ログのバックアップの詳細については、「ログをバックアップまたはアーカイブする (SharePoint Foundation 2010)」を参照してください。
バックアップ ファイルのコピーをオフサイトで保管する
火事、地震などの災害発生時にデータが失われることを避けるため、サーバーとは別の場所にバックアップのコピーを保持します。これにより、データ損失から重要なデータを保護できます。バックアップ メディアのコピーは 3 つ作成し、少なくとも 1 つをオフサイトの管理された環境で保管することをお勧めします。コピーには、バックアップと回復に関する資料、ドキュメント、データベースとトランザクション ログのバックアップ、および用途とトレース ログのバックアップがすべて含まれている必要があります。
操作のベスト プラクティス
これらの操作のベスト プラクティスを使用すると、適切なドキュメントと、より簡単かつ確実な方法で、バックアップと復元操作を計画し実行することができます。
FQDN サーバー名を使用する
異なるドメインのサーバーを参照するときは、必ず完全修飾ドメイン名 (FQDN) を使用します。
正確なレコードを保持する
SharePoint Foundation 2010 の展開時に、作成するアカウント、コンピューター名、パスワード、選択したセットアップ オプションを記録します。この情報は安全な場所に保管します。
復旧環境をいつでも使える状態にする
リモート ファームを設定して、復元テストと障害復旧の準備をします。次に、データベース接続コマンドを使用してデータベースのコピーをリモート ファームにコピーしユーザーをリダイレクトすることにより、環境を復元できます。同様に、運用環境と同じバージョンのソフトウェアを実行しているスタンバイ環境を設定して、迅速にデータベースの復元とドキュメントの回復を実行できるようにします。
バックアップ操作のスケジュールを設定する
バックアップのスケジュールを設定するには、Windows タスク スケジューラを使用し、Windows PowerShell スクリプト ファイル (*.ps1) でバックアップを実行します。
BLOB ストレージで SQL FILESTREAM プロバイダーを使用する
SQL FILESTREAM プロバイダーを使用する BLOB ストレージを使用し、リモート BLOB ストア (RBS) が定義されたコンテンツ データベースをバックアップする場合、SharePoint ツールまたは SQL Server ツールを使用すると、RBS とコンテンツ データベースの両方がバックアップおよび復元されます。RBS を他の復元方法で使用することはお勧めしません。