SharePoint Server のバックアップと復元のベスト プラクティスBackup and restore best practices in SharePoint Server

に適用されます:はい2013はい2016はい2019なしSharePoint OnlineAPPLIES TO: yes2013 yes2016 yes2019 noSharePoint Online

バックアップと復元のベスト プラクティスによって、SharePoint Server のバックアップ操作と復元操作を成功させることができます。また、この環境はデータ損失や非継続性から保護されます。Best practices for backup and restore help make sure that backup and restore operations in SharePoint Server are successful and that the environment is protected against data loss or continuity gaps.

SharePoint のバックアップ操作と復元操作のベスト プラクティスのパフォーマンスPerformance best practices for SharePoint backup and restore operations

バックアップ操作と復元操作では、操作の実行中にサーバー リソースを使って、サーバーのパフォーマンスを制限します。以下の推奨事項に従って、リソースの使用率を軽減し、サーバーのパフォーマンスとバックアップ タスクや復元タスクのパフォーマンスを向上させます。Backup and restore operations consume server resources and limit server performance while the operations are running. Follow these recommended practices to help reduce resource usage and increase the performance of servers and the backup or restore task.

SQL Server とバックアップ場所の間の遅延を最小限に抑えるMinimize latency between SQL Server and the backup location

一般に、ネットワーク ドライブではなくデータベース サーバーのローカル ディスクにバックアップするのが効率的です。後でネットワーク上の共有フォルダーにデータをコピーできます。ネットワーク ドライブやデータベース サーバーとの間の待機時間が 1 ミリ秒以下のネットワーク ドライブは正常に動作します。In general, it is efficient to back up to a local disk on the database server instead of a network drive. You can then copy the data later to a shared folder on the network. Network drives with 1 millisecond or less latency between them and the database server perform well.


ローカル ドライブにバックアップできない場合、待機時間が同じようなネットワーク ドライブを使用します。ネットワーク バックアップはネットワーク エラーの可能性があるため、完了後にバックアップの操作を検証します。詳細については、「バックアップ デバイス (SQL Server)」の「ネットワーク共有のファイルへのバックアップ」を参照してください。If you cannot back up to local drives, use network drives with similar latency. Because network backups are subject to network errors, verify the backup action after it finishes. For more information, see "Backing Up to a File on a Network Share" in Backup Devices (SQL Server).

I/O のボトルネックを避けるためには、SQL サーバー 2017 RTM、2016、2014、2012 年 5、または 2008 R2 Service Pack 1 (SP1) を実行しているディスクから別のディスクにメインのバックアップを実行します。詳細については、ディスク ファイル (SQL Server) の論理バックアップ デバイスを定義するを参照してください。To avoid I/O bottlenecks, perform the main backup to a separate disk from the disk running SQL Servers 2017 RTM, 2016, 2014, 2012, or 2008 R2 with Service Pack 1 (SP1). For more information, see Define a Logical Backup Device for a Disk File (SQL Server).

設計上は、大半のバックアップ ジョブは使用可能なすべての I/O リソースを使用して、ジョブを実行します。したがって、通常の I/O 要求に対する待機時間より長くなるディスク キューがある場合があります。これは一般的な動作であり、問題と見なす必要はありません。詳細については、「ディスクの使用率の監視」を参照してください。By design, most backup jobs consume all available I/O resources to complete the job. Therefore, you might see disk queuing, which can result in greater than usual latency for I/O requests. This is typical and should not be considered a problem. For more information, see Monitor Disk Usage.

処理競合を回避するAvoid processing conflicts

ユーザーがシステムにアクセスする必要のあるときに、バックアップ ジョブを実行しないでください。通常、システムは 24 時間 365 日実行されています。ベスト プラクティスではサーバー エラーから保護するために、常に増分バックアップが実行されます。すべてのバックアップが同時にバックアップされないように、バックアップをずらして行うことを検討してください。Do not run backup jobs during times when users need access to the system. Typically, systems run 24 hours a day, seven days a week. A best practice is to always run incremental backups to safeguard against server failure. Consider staggering backups so that all databases are not backed up at the same time.

復旧時間を短縮するためにデータベースを小さく保つKeep databases small for faster recovery times

バックアップと復元の両方を高速化するためにデータベースを小さく保ちます。たとえば、1 つの大きなコンテンツ データベースの代わりに Web アプリケーション用に複数のコンテンツ データベースを使用します。詳細については、「データベースの種類と説明 (SharePoint Server)」を参照してください。Keep databases small to speed both backup and restore. For example, use multiple content databases for a web application instead of one large content database. For more information, see Database types and descriptions in SharePoint Server.

SharePoint Server 2016 をサポートするデータベースの概要をグラフィック表示するには、クイック リファレンス ガイド: SharePoint Server 2016 データベースをご覧ください。For a graphical overview of the databases that support SharePoint Server 2016, see Quick reference guide: SharePoint Server 2016 databases.

大型データベースに増分バックアップを使用するUse incremental backups for large databases

データベースをすばやく作成して環境のパフォーマンスを管理することができるため、大型のデータベースには増分バックアップを使います。完全バックアップは増分バックアップよりも早く復元できますが、継続的に増分バックアップを行うことで、データ損失を最小限に抑えることができます。バックアップの種類について詳しくは、「バックアップの概要 (SQL Server)」をご覧ください。Use incremental backups for large databases because you can make them quickly and maintain performance of the environment. Although you can restore full backups faster than incremental backups, continuous incremental backups minimize data loss. For more information about types of backups, see Backup Overview (SQL Server).

バックアップ中に圧縮を使用するUse compression during backup

場合によっては、圧縮を使用するとバックアップのサイズおよび各バックアップを完了する時間が抑えられます。バックアップの圧縮は SQL Server 2008 Enterprise で導入されました。バックアップの圧縮は CPU 使用率を上げ、SQL Server の並行操作に影響を及ぼす可能性があります。In some circumstances, you can use compression to decrease the size of backups and the time to complete each backup. Backup compression was introduced in SQL Server 2008 Enterprise. Backup compression increases CPU usage and this can affect SQL Server concurrent operations.


SharePoint Server では、SQL Server バックアップの圧縮をサポートしています。SharePoint Server データベースでは、SQL Server データの圧縮はサポートされていません。SharePoint Server supports SQL Server backup compression. SQL Server data compression is not supported for SharePoint Server databases.

バックアップ圧縮がどれほど SQL Server のパフォーマンスに影響を与えるかの詳細については、「バックアップ圧縮 (SQL Server)」を参照してください。For more information about how backup compression affects performance in SQL Server, see Backup Compression (SQL Server).

SQL Server のバックアップと復元の最適化に関する推奨事項に従うFollow SQL Server backup and restore optimization recommendations

SQL Server バックアップでは、復旧時間を最小限に抑えるために、完全バックアップ、差分バックアップ、およびトランザクション ログ バックアップ (完全または一括ログ復旧モデル) を組み合わせて使用します。差分データベース バックアップは、通常、完全データベース バックアップよりも高速に作成でき、データベースを復旧するために必要なトランザクション ログ数が少なくなります。SQL Server backups use a combination of full, differential, and transaction log backups (for the full or bulk-logged recovery model) to minimize recovery time. Differential database backups are usually faster to create than full database backups and reduce the number of transaction logs required to recover the database.

完全復旧モデルを使用する場合は、メンテナンスの問題を回避するために、トランザクション ログ ファイルを定期的に切り捨てることをお勧めします。If you are using the full recovery model, we recommend that you periodically truncate the transaction log files to avoid maintenance issues.

SQL Server のバックアップと復元のパフォーマンスを最適化する方法の詳細な推奨事項については、「SQL Server におけるバックアップと復元のパフォーマンスの最適化」を参照してください。For detailed recommendations about how to optimize SQL Server backup and restore performance, see Optimizing Backup and Restore Performance in SQL Server.

RAID を使用する場合は RAID 10 を使用するUse RAID 10 if you use RAID

データをバックアップするデバイスで RAID (Redundant Array of Independent Disks) を使用するかどうかを慎重に検討してください。たとえば、RAID 5 は書き込みのパフォーマンスが低く、ディスクが 1 つの場合とほぼ同じ速度です。これは RAID 5 がパリティ情報を保持するためです。RAID 10 ではパリティを管理する必要がないため、より高速にバックアップを行えます。そのため、データをより高速に読み取りおよび書き込みできます。バックアップで RAID を使用する方法については、「最大の SQL Server I/O スループットのために RAID を構成する」、「RAID レベルと SQL Server」 を参照してください。Carefully consider whether to use redundant array of independent disks (RAID) on the device to which you back up data. For example, RAID 5 has slow write performance, approximately the same speed as for a single disk. This is because RAID 5 has to maintain parity information. RAID 10 can provide faster backups because it doesn't need to manage parity. Therefore, it reads and writes data faster. For more information about how to use RAID with backups, see Configure RAID for maximum SQL Server I/O throughput and RAID Levels and SQL Server.

バックアップまたは復元のパフォーマンスを向上させるために SharePoint 設定を構成するConfigure SharePoint settings to improve backup or restore performance

PowerShell ではファイル圧縮およびログ ファイル設定のみ構成できます。SharePoint サーバーの全体管理 Web サイト および PowerShell の両方にスレッドのバックアップと復元を構成し、バックアップまたは復元の効率性とパフォーマンスを向上させることができます。You can only configure file compression and log file settings in PowerShell. You can configure backup and restore threads in both the SharePoint Central Administration website and PowerShell to increase backup or restore efficiency and performance.

Export-SPWeb PowerShell コマンドレットを使用する場合、 NoFileCompression パラメーターを使用できます。既定では、SharePoint Server では Web アプリケーション、サイト コレクション、リストまたはドキュメント ライブラリのエクスポート時にファイル圧縮を使用します。このパラメーターを使用し、エクスポートおよびインポート時のファイル圧縮を抑制できます。ファイル圧縮は最大 30% 多くリソースを使用する場合があります。ただし、エクスポートされたファイルが使用するディスク領域は約 25% 以下です。エクスポート時に NoFileCompression パラメーターを使用する場合、同じコンテンツをインポートする際にもこのパラメーターを使用する必要があります。If you use the Export-SPWeb PowerShell cmdlet, you can use the NoFileCompression parameter. By default, SharePoint Server uses file compression while exporting web applications, site collection, lists, or document libraries. You can use this parameter to suppress file compression while exporting and importing. File compression can use up to 30% more resources. However, the exported file uses approximately 25% less disk space. If you use the NoFileCompression parameter when you export, you have to also use it when you import the same content.

また、 NoLogFile パラメーターも使用できます。既定では、SharePoint Server では、コンテンツのエクスポート時に常にログ ファイルを作成します。このパラメーターを使用し、ログ ファイル作成を抑制してリソースを節約できますが、常にログを作成することをお勧めします。ログはトラブルシューティングに重要で、ログ作成には CPU やメモリなどのリソースをあまり使用しません。You can also use the NoLogFile parameter. By default, SharePoint Server always creates a log file when you export content. Although you can use this parameter to suppress log file creation to save resources, we recommend that you always create logs. Logs are important for troubleshooting and log creation does not use many resources such as CPU or memory.

Backup-SPFarm コマンドレットを使用する場合、 BackupThreads パラメーターを使用し、SharePoint Server がバックアップ処理中に使用するスレッド数を指定することもできます。多数のスレッドを使用すればするほど、バックアップ中のリソースをより多く消費します。その一方で、バックアップを作成する全体的な時間は短縮されます。スレッドごとにログ ファイルに記録されるため、スレッド数はログ ファイルの解釈に影響します。既定では、3 つのスレッドが使用されます。使用できるスレッドの最大数は 10 です。When you use the Backup-SPFarm cmdlet, you can also use the BackupThreads parameter to specify how many threads SharePoint Server will use during the backup process. A higher number of threads will consume more resources during backup. But the overall time to make the backup is decreased. Because each thread is recorded in the log files, the number of threads does affect log file interpretation. By default, three threads are used. The maximum number of available threads is 10.


バックアップ スレッド設定は、[ バックアップと復元] セクションの [ バックアップおよび復元の既定の設定] ページの サーバーの全体管理 から使用することもできます。The backup threads setting is also available through Central Administration on the Default Backup and Restore Settings page in the Backup and Restore section.

使用するツールの決定時にサイト コレクションのサイズを検討するConsider site collection size when you determine the tools to use

ビジネスでファーム レベルまたはデータベース レベルのバックアップに加えてサイト コレクションのバックアップが必要な場合、サイト コレクションのサイズに基づいてバックアップ ツールを選択します。If the business requires site collection backups in addition to farm-level or database-level backups, choose a backup tool that is based on the size of the site collection.

  • 15-100 GB: Backup-SPSite、SharePoint Server ツール、SQL Server ツール、または他のデータベースのバックアップ ツールを使用し、サイト コレクションを含むコンテンツ データベースを保護します。詳細については、「SharePoint Server でサイト コレクションをバックアップする」を参照してください。15-100 GB: Usethe Backup-SPSite, a SharePoint Server tool, a SQL Server tool, or other database backup tool to protect the content database that contains the site collection. For more information, see Back up site collections in SharePoint Server.

  • 100 GB より大きい: 組み込みのバックアップと復元ツールの代わりに、SQL Server や System Center Data Protection Manager R2 などの差分バックアップ ソリューションを使います。Larger than 100 GB: Use a differential backup solution, such as SQL Server or System Center Data Protection Manager R2, instead of the built-in backup and recovery tools.

SharePoint ファームをバックアップする品質保証のベスト プラクティスQuality assurance best practices to back up a SharePoint farm

以下のベスト プラクティスに従って、ファーム環境のバックアップの品質を保証し、データ損失の可能性を軽減します。Follow these best practices to help ensure the quality of the backups of the farm environment and reduce the chances of data loss.

十分にストレージ領域を持つようにするEnsure you have enough storage space

バックアップに合わせてシステムに十分なディスク領域が確保されるようにします。サーバーの全体管理 でバックアップ ジョブを構成し、必要なディスク領域を確認します。Be certain that the system has enough disk space to accommodate the backup. Configure a backup job in Central Administration to verify the required disk space.

定期的にバックアップの品質をテストするRoutinely test backup quality

定期的にバックアップをテストし、整合性を検証します。練習の復旧操作を実行し、バックアップのコンテンツを検証して完全な環境を復元できるか確認します。地理的に分散した環境の障害復旧の準備をするために、リモート ファームを設定します。次に、データベースのコピーをリモート ファームにアップロードし、ユーザーがリダイレクトされるデータベース接続メソッドを使用することによって、環境を復元できます。プロセスが正常にファイルをバックアップすることを確認するために、試用版のデータ復元アクションを定期的に実行します。試用版の復元では、ソフトウェアの検証を伴わないハードウェアの問題を表示でき、目標復旧時間 (RTO) を満たすようにすることもできます。Routinely test backups and validate their consistency. Run practice recovery operations to validate the contents of the backup and to make sure that you can restore the complete environment. To prepare for disaster recovery of geographically dispersed environments, set up a remote farm. Then you can restore the environment by using the database-attach method to upload a copy of the database to the remote farm and redirect users. Periodically perform a trial data recovery action to verify that the process correctly backs up files. A trial restoration can expose hardware problems that do not come up with software verifications and can also to make sure that the recovery time objectives (RTO) are met.

ULS トレース ログのバックアップBack up ULS trace logs

SharePoint Server のバックアップ処理では、統合ログ サービス (ULS) トレース ログをバックアップしません。ULS トレース ログのデータは、サービス レベル契約に準拠したパフォーマンス分析、トラブルシューティング、および監視に役立てることができます。したがって、定期的なメンテナンスの一部としてこのデータを保護します。The SharePoint Server backup process doesn't back up the Unified Logging Service (ULS) trace logs. Data in ULS trace logs can be useful for performance analysis, troubleshooting, and monitoring compliance with service level agreements. Therefore, protect this data as part of the routine maintenance.

既定では、SharePoint のログ ファイルは、C:\Program files\Common Files\Microsoft Shared\Web Server Extensions\<16 または 15>\Logs にあります。ファイルにはサーバー名の後に日付とタイム スタンプを付けた名前が付けられます。SharePoint のトレース ログは、設定されている間隔と IISRESET コマンドを使ったときに作成されます。By default, SharePoint log files are at C:\Program files\Common Files\Microsoft Shared\Web Server Extensions\<16 or 15>\Logs. The files are named with the server name followed by the date and time stamp. The SharePoint trace logs are created at set intervals and when you use the IISRESET command.

バックアップ ファイルのコピーをオフサイトに格納するStore a copy of backup files off-site

プライマリ データ センターが破壊される自然災害でのデータ損失を防ぐために、サーバーとは別の場所でバックアップの重複コピーを管理します。重複コピーによって、重要なデータ損失を回避することができます。ベスト プラクティスとしては、バックアップ メディアのコピーを 3 つ保持し、制御された環境のオフサイトに少なくとも 1 つのコピーを保持することをお勧めします。これにはすべてのバックアップと復旧資材、文書、データベースとトランザクション ログのバックアップ、および利用状況とトレース ログのバックアップを含める必要があります。To safeguard against loss from a natural disaster that destroys the primary data center, maintain duplicate copies of backups in separate locations from the servers. Duplicate copies can help prevent the loss of critical data. As a best practice, keep three copies of the backup media, and keep at least one copy offsite in a controlled environment. This should include all backup and recovery materials, documents, database and transaction log backups, and usage and trace log backups.

SharePoint Server をバックアップまた復元するベスト プラクティスの手順Procedural best practices to back up and restore SharePoint Server

以下のベスト プラクティスの手順を使用し、バックアップ操作と復元操作を計画および実行します。Use the following procedural best practices to plan and perform backup and restore operations.

FQDN サーバー名を使用するUse FQDN server names

別のドメインにあるサーバーを参照する場合、常に完全修飾ドメイン名 (FQDN) を使用します。When you refer to servers in a different domain, always use fully qualified domain names (FQDN).

正確なレコードを保持するKeep accurate records

SharePoint Server を展開する場合、作成するアカウント、コンピューター名、パスワード、および設定オプションを記録します。この情報を安全な場所に保持します。できる限り、この情報が常に使用できるように複数のレコードを保持します。When you deploy SharePoint Server, record the accounts that you create, the computer names, passwords, and setup options. Keep this information in a safe and secure location. Possibly, keep multiple records to make sure this information is always available.

復旧環境を準備するHave a recovery environment ready

第 2 の格納場所にあるファームを使用し、障害復旧戦略の一部として復元操作の成功を検証します。詳しくは、「SharePoint Server 用の障害回復戦略を選ぶ」をご覧ください。データベースのコピーをリモート ファームにアップロードし、ユーザーをリダイレクトするためにデータベース接続メソッドを使用することにより、障害復旧で環境を復元することができます。詳しくは、「ファームを復元する (SharePoint Server)」の手順を確認して実行してください。また、高可用性のソリューションのために、すぐにデータベースを復元し文書を復旧できるように、運用環境と同じバージョンのソフトウェアを実行するスタンバイ環境をセットアップすることができます。詳しくは、「高可用性とは」をご覧ください。Use a farm in a secondary location to validate the success of restore operations as part of your disaster recovery strategy. For more information, see Choose a disaster recovery strategy for SharePoint Server. In a disaster recovery situation, you can then restore the environment by using the database-attach method to upload a copy of the database to the remote farm and redirect users. For more information, review and follow the steps in Restore farms in SharePoint Server. Also for a high availability solution, you can set up a standby environment that runs the same version of software as the production environment so that you can restore the databases and recover documents quickly. For more information, see Describing high availability.

バックアップ操作をスケジュールするSchedule backup operations

PowerShell バックアップと復元のコマンドレットを使用し、スクリプト ファイル (*.ps1) を作成して Windows タスク サービスを で実行するスケジュールを設定します。これにより、すべてのバックアップ操作はシステムの使用率が最も低く、ユーザーがアクセスしていない最適な時間に実行されるようになります。詳細については、以下を参照してください。Use PowerShell backup and recovery cmdlets to create a script file (*.ps1) and then schedule it to run with Windows Task Scheduler. This makes sure that all backup operations are run at the best time when the system is least busy and users are not accessing it. For more information, see the following:

BLOB ストレージで SQL FILESTREAM プロバイダーを使用するUse the SQL FILESTREAM provider with BLOB storage

リモート BLOB ストレージ (RBS) は SharePoint Server ファームでサポートされています。SharePoint Server での RBS の使用には利点と欠点の両方があります。SharePoint ファームに関する RBS の制限事項の 1 つは、System Center Data Protection Manager が RBS をバックアップするか復元するために FILESTREAM プロバイダーを使うことができないということです。SharePoint Server ではバックアップ操作と復元操作用に FILESTREAM プロバイダーをサポートしています。SharePoint ファームでの RBS の利点は、SharePoint ツールまたは SQL Server ツールのいずれかを使って、定義されたリモート BLOB ストア (RBS) でコンテンツ データベースのバックアップと復元を行えることです。ここでは、RBS およびコンテンツ データベースの両方をバックアップと復元を行います。別の復元メソッドで RBS を使うことはお勧めしません。RBS を使う利点と制約について詳しくは、「SharePoint Server で RBS の使用を決める」をご覧ください。RBS を含む Microsoft SQL Server 2014 Feature Pack をダウンロードしてください。Remote BLOB Storage (RBS) is supported in a SharePoint Server farm. There are both pros and cons associated with using RBS in SharePoint Server. One related limitation of RBS with a SharePoint farm is that System Center Data Protection Manager cannot use the FILESTREAM provider to back up or restore RBS. SharePoint Server supports the FILESTREAM provider for backup and restore operations. A benefit of RBS with a SharePoint farm is that you can use either SharePoint tools or SQL Server tools to back up and restore the content database with the Remote BLOB Store (RBS) defined. This backs up and restores both the RBS and the content database. We do not recommend that you use RBS with other restore methods. For more information about the benefits and limitations of using RBS, see Deciding to use RBS in SharePoint Server. Download Microsoft SQL Server 2014 Feature Packthat includes RBS.


SharePoint サーバー 2019年 2017 の SQL Server に含まれている FILESTREAM プロバイダーをサポートします。SharePoint サーバー 2016年には、2014 の SQL Server に含まれている FILESTREAM プロバイダーがサポートしています。詳細については、有効化および構成ファイルのストリームを参照してください。SharePoint Server 2019 supports the FILESTREAM provider that is included with SQL Server 2017. SharePoint Server 2016 supports the FILESTREAM provider that is included with SQL Server 2014. For more information, see Enable and Configure FILESTREAM.


SharePoint Server 2013 では、Microsoft® SQL Server® 2008 R2 用 Feature Pack に含まれる FILESTREAM プロバイダーをサポートしています。SQL Server 2012 と SQL Server 2014 のインストール メディアには、オプションのアドオン コンポーネントとして RBS が含まれます。SharePoint Server 2013 supports the FILESTREAM provider that is included in the Microsoft® SQL Server® 2008 R2 Feature Pack. The SQL Server 2012 and SQL Server 2014 installation media includes RBS as an optional add-on component.

関連項目See also


SharePoint Server のバックアップと回復の概要Overview of backup and recovery in SharePoint Server

SharePoint Server でのバックアップと回復を計画するPlan for backup and recovery in SharePoint Server

ファームのバックアップと復元を準備する (SharePoint Server)Prepare to back up and restore farms in SharePoint Server

その他のリソースOther Resources

データベース バックアップの暗号化Database Backup Encryption