データベース、デプロイ トポロジ、バックアップ

Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019

データ損失からデプロイを保護するには、Azure DevOps Server依存するデータベースのバックアップの定期的なスケジュールを作成します。 Azure DevOps Serverデプロイを完全に復元するには、まずAzure DevOps Serverデータベースをすべてバックアップします。

デプロイにSQL Server Reporting Servicesが含まれている場合は、それらのコンポーネント内で Azure DevOps が使用するデータベースもバックアップする必要があります。 同期エラーまたはデータの不一致エラーを防ぐため、すべてのバックアップのタイム スタンプが同じになるようにしてください。 確実に同期するための最も簡単な方法は、マークされたトランザクションを使用する方法です。 すべてのデータベースで関連するトランザクションを定期的にマークすることで、データベースに一連の共通復旧ポイントを確立します。 レポートを使用する単一サーバー展開をバックアップするための詳細なガイダンスについては、「 バックアップ スケジュールと計画を作成する」を参照してください。

データベースのバックアップ

データベース バックアップを作成して、データ損失から Azure DevOps デプロイを保護します。 次の表と付属の図は、バックアップするデータベースを示し、それらのデータベースをデプロイで物理的に分散する方法の例を示しています。

データベースの種類	製品	必須コンポーネント
構成データベース	Azure DevOps Server	はい
ウェアハウス データベース	Azure DevOps Server	はい
プロジェクト コレクション データベース	Azure DevOps Server	はい
レポート データベース	SQL Server Reporting Services	いいえ
分析データベース	SQL Server Analysis Services	いいえ

展開トポロジ

配置の構成によっては、この例のトポロジのように、バックアップが必要なすべてのデータベースが同じ物理サーバー上にある場合があります。

注意

この例には、Reporting Servicesまたは SharePoint 製品は含まれていないため、レポート、分析、または SharePoint 製品に関連付けられているデータベースをバックアップする必要はありません。

または、データベースが多数のサーバーやサーバー ファームに分散されている場合もあります。 このトポロジの例では、6 つのサーバーまたはサーバー ファームにまたがってスケーリングされた次のデータベースをバックアップする必要があります。

• 構成データベース

• ウェアハウス データベース

• SQL Server クラスターにあるプロジェクト コレクション データベース

• を実行しているスタンドアロン サーバー上にあるコレクション データベースSQL Server

• Reporting Services を実行するサーバー上のデータベース

• Analysis Services を実行するサーバー上のデータベース

• 両方の SharePoint Web アプリケーションの SharePoint 製品管理データベースとサイト コレクション データベース

  SharePoint データベースが複数のサーバーにまたがってスケーリングされている場合、スケジュールされたバックアップ機能を使用してバックアップすることはできません。 これらのデータベースのバックアップを手動で構成し、それらのバックアップが Azure DevOps Server データベース バックアップと同期されていることを確認する必要があります。 詳細については、「Azure DevOps Server を手動でバックアップする」をご覧ください。

どちらの例でも、サーバーに接続するクライアントをバックアップする必要はありません。 ただし、復元された展開に再接続する前に、クライアント コンピューター上のAzure DevOps Serverのキャッシュを手動でクリアする必要がある場合があります。

バックアップ対象のデータベース

次の一覧では、デプロイ リソースに応じて、バックアップする必要がある内容に関する追加の詳細を示します。

重要

次の一覧のすべてのデータベースは、SQL Server データベースです。 SQL Server Management Studioを使用して個々のデータベースをいつでもバックアップできますが、可能な限り、このような個々のバックアップは使用しないでください。 Azure DevOps で使用されるデータベースがすべて関連しているため、個々のバックアップから復元すると、予期しない結果が発生する可能性があります。 1 つのデータベースのみをバックアップする場合、そのデータベース内のデータが他のデータベースのデータと同期されない可能性があります。

• Azure DevOps Serverのデータベース - Azure DevOps Serverの論理データ層には、構成データベース、ウェアハウス データベース、配置内の各プロジェクト コレクションのデータベースなど、複数のSQL Server データベースが含まれます。 これらのデータベースはすべて、同じサーバー上にあるか、同じSQL Serverデプロイ内の複数のインスタンスに分散されるか、複数のサーバーに分散されている可能性があります。 どのように物理的に分散していても、すべてのデータベースのバックアップは同じタイム スタンプになるようにし、データが失われることがないようにしてください。 データベースのバックアップは手動で実行することも、特定の時間や特定の間隔で実行するメンテナンス プランを使用して自動的に実行することもできます。

  重要

  Azure DevOps データベースの一覧は静的ではありません。 コレクションを作成するたびに新しいデータベースが作成されます。 コレクションを作成するときは、必ずメンテナンス プランにそのコレクションのデータベースを追加します。

• Reporting Servicesおよび Analysis Services のデータベース - デプロイでSQL Server Reporting ServicesまたはSQL Server Analysis Servicesを使用してAzure DevOps Serverのレポートを生成する場合では、レポートデータベースと分析データベースをバックアップする必要があります。 ただし、この場合でも、復元後に特定のデータベース (ウェアハウスなど) を生成し直す必要があります。
• レポート サーバーの暗号化キー - レポート サーバーには、バックアップする必要がある暗号化キーがあります。 このキーは、レポート サーバーのデータベースに格納されている機密情報を保護するためのものです。 このキーは、Reporting Services 構成ツールまたはコマンド ライン ツールを使用して手動でバックアップできます。

バックアップの事前準備

Azure DevOps をデプロイするときは、作成するアカウントと、指定したコンピューター名、パスワード、セットアップ オプションを記録しておく必要があります。 また、回復資料、ドキュメント、データベース、トランザクション ログのバックアップのすべてのコピーは、必ず安全な場所に保管してください。 火災や地震などの災害に対する保護手段として、サーバー バックアップの複製を、サーバーが設置されている場所とは異なる場所に保管します。 これにより、重要なデータの消失を防止できます。 ベスト プラクティスとしては、バックアップ メディアのコピーを 3 つ作成し、少なくとも 1 つのコピーを管理された別の環境に保管します。

重要

定期的に試験データの復元を実行し、ファイルが正常にバックアップされていることを検証します。 試用版の復元では、ソフトウェアのみの検証では表示されないハードウェアの問題が明らかになる可能性があります。

データベースのバックアップと復元を行うときは、ネットワーク アドレスを持つメディア (たとえば、ネットワーク ドライブとして共有されているテープやディスク) にデータをバックアップする必要があります。 バックアップ計画には、次のようなメディア管理の準備を含める必要があります。

• バックアップ セットの保存とリサイクルに対するトラッキング計画と管理計画。
• バックアップ メディアの上書きに対するスケジュール。
• マルチサーバー環境では、集中バックアップと分散バックアップのいずれを採用するかの決定。
• メディアの耐用年数のトラッキング方法。
• バックアップ セットまたはバックアップ メディア (テープなど) の消失による影響を最小限に抑える手順。
• バックアップ セットを内部と外部のいずれで保管するかの決定、およびその決定が復元時間与える影響の分析。

Azure DevOps データはSQL Server データベースに格納されるため、Azure DevOps のクライアントがインストールされているコンピューターをバックアップする必要はありません。 これらのコンピューターに関連するメディア障害または障害が発生した場合は、クライアント ソフトウェアを再インストールしてサーバーに再接続できます。 クライアント ソフトウェアを再インストールすることで、バックアップからクライアント コンピューターを復元する代わりに、よりクリーンで信頼性の高い方法がユーザーに提供されます。

サーバーをバックアップするには、使用可能なスケジュールされたバックアップ機能を使用するか、SQL Serverでメンテナンス プランを手動で作成して、Azure DevOps デプロイに関連するデータベースをバックアップします。 Azure DevOps データベースは相互に関係して機能し、手動プランを作成する場合は、それらをバックアップして同時に復元する必要があります。 データベースのバックアップ方法の詳細については、「データベースのバックアップと復元」SQL Server参照してください。

バックアップの種類

使用可能なバックアップの種類を理解すると、デプロイをバックアップするための最適なオプションを決定するのに役立ちます。 たとえば、大規模な配置を使用しており、限られたストレージ リソースを効率的に使用してデータ損失から保護する場合は、完全データ バックアップだけでなく差分バックアップを構成できます。 SQL Server Always Onを使用している場合は、セカンダリ データベースのバックアップを作成できます。 バックアップを圧縮したり、複数のファイルにバックアップを分割することもできます。 バックアップ オプションの簡単な説明を次に示します。

データの完全バックアップ (データベース)

デプロイを回復するには、データベースの完全バックアップが必要です。 完全なバックアップには、完全なバックアップを復元できるようにするために、トランザクション ログの部分が含まれます。 完全なバックアップは、バックアップが完了した時点で存在していたデータベース全体に相当するデータを含んでおり、単体で使用できます。 詳細については、「 データベースの完全バックアップ」を参照してください。

差分データ バックアップ (データベース)

データベースの差分バックアップでは、前回のデータベースの完全バックアップ以降に変更されたデータ (差分ベースと呼ばれます) のみが記録されます。 差分データベース バックアップは、完全データベース バックアップよりも、サイズが小さく、高速に実行できます。 このオプションを使用すると、処理は複雑になりますが、バックアップにかかる時間を短縮できます。 サイズの大きいデータベースには、データベース バックアップよりも差分バックアップの実行間隔を短くすることで、作業内容が失われる可能性を削減できます。 詳細については、「 データベースの差分バックアップ」を参照してください。

また、トランザクション ログも定期的にバックアップしてください 完全データベース バックアップ モデルを使用して、データを回復するときに、これらのバックアップが必要です。 トランザクション ログをバックアップする場合は、障害発生時点またはそれより前の時点までデータベースを復旧できます。

トランザクション ログのバックアップ

トランザクション ログは、各変更を実行したトランザクションに加えて、データベースで発生したすべての変更のシリアル レコードです。 トランザクション ログには、各トランザクションの開始およびデータに対する変更が記録されるほか、必要に応じて、各トランザクションの間に行われた変更を元に戻すのに必要な情報も記録されます。 データベースでログに記録する操作が発生するごとに、ログの容量が継続的に増加します。

トランザクション ログをバックアップすることで、データベースを以前の時点の状態に復元できます。 たとえば、不要なデータが入力されたり、エラーが発生したりする前のポイントにデータベースを復元できます。 データベースのバックアップの他に、トランザクション ログのバックアップを復元計画に加える必要があります。 詳細については、「トランザクション ログ バックアップ (SQL Server)」を参照してください。

通常、トランザクション ログのバックアップでは、完全なバックアップより少量のリソースが使用されます。 したがって、トランザクション ログのバックアップを完全なバックアップより頻繁に作成し、データが失われるリスクを軽減できます。 ただし、トランザクション ログのバックアップが完全なバックアップより大きくなる場合があります。 たとえば、トランザクション レートが高いデータベースでは、トランザクション ログが急速に増加します。 この状況では、トランザクション ログのバックアップをより頻繁に作成してください。 詳細については、「完全なトランザクション ログのトラブルシューティング (SQL Server エラー 9002)」を参照してください。

トランザクション ログのバックアップには、次の 3 種類があります。

• ピュア ログ バックアップには、一括変更のない、間隔を置いたトランザクション ログ レコードのみが格納されます。
• 一括ログのバックアップには、一括操作によって変更されたログとデータ ページが格納されます。 特定の時点への復旧は実行できません。
• ログ末尾のバックアップは、損傷を受けた可能性のあるデータベースから取得され、バックアップされていないログ レコードを取り込みます。 ログ末尾のバックアップは、作業の無駄が発生するのを防ぐために、障害が発生した後で取得され、これにはピュア ログ データまたは一括ログのデータを格納できます。

データの同期はAzure DevOps Serverの正常な復元に不可欠であるため、バックアップを手動で構成する場合は、バックアップ戦略の一部としてマークされたトランザクションを使用する必要があります。 詳細については、「バックアップ スケジュールと計画を作成する」および「手動でAzure DevOps Serverをバックアップする」を参照してください。

アプリケーション層サービスのバックアップ

論理アプリケーション層に必要なバックアップは、Reporting Servicesの暗号化キーのみです。 スケジュールされたバックアップ機能を使用して配置をバックアップした場合、このキーはプランの一部としてバックアップされます。 プロジェクト ポータルとして使用される Web サイトをバックアップする必要があると想定する場合があります。

アプリケーション層はデータ層よりも簡単にバックアップできますが、アプリケーション層を復元する手順がいくつかあります。 Azure DevOps Server用に別のアプリケーション層をインストールし、新しいアプリケーション層を使用するようにプロジェクト コレクションをリダイレクトし、プロジェクトのポータル サイトをリダイレクトする必要があります。

既定のデータベース名

データベースの名前をカスタマイズしない場合は、次の表を使用して、Azure DevOps Serverのデプロイで使用されるデータベースを特定できます。 前にも説明しましたが、すべての配置に、これらのデータベースがすべて含まれているわけではありません。 たとえば、Reporting Services でAzure DevOps Serverを構成しなかった場合、ReportServer データベースまたは ReportServerTempDB データベースはありません。 同様に、ラボ管理をサポートするようにAzure DevOps Serverを構成しない限り、System Center Virtual Machine Manager (SCVMM)、VirtualManagerDB 用のデータベースはありません。 さらに、Azure DevOps Serverが使用するデータベースは、SQL Serverの複数のインスタンスまたは複数のサーバーに分散される場合があります。

注意

既定では、プレフィックス TFS_は、Azure DevOps Serverのインストール時または動作中に自動的に作成されるすべてのデータベースの名前に追加されます。

データベース	説明
TFS_Configuration	Azure DevOps Serverの構成データベースには、デプロイのカタログ、サーバー名、および構成データが含まれています。 このデータベースの名前には、Azure DevOps Serverをインストールしたユーザーのユーザー名など、TFS_と構成の間に追加の文字が含まれる場合があります。 たとえば、データベースの名前がTFS_UserNameConfiguration
TFS_Warehouse	ウェアハウス データベースです。Reporting Services が使用するウェアハウスをビルドするためのデータが格納されています。 このデータベースの名前には、TFS_と Warehouse の間に追加の文字 (Azure DevOps Serverをインストールしたユーザーのユーザー名など) が含まれる場合があります。 たとえば、データベースの名前がTFS_UserNameWarehouseされる場合があります。
TFS_CollectionName	プロジェクト コレクションのデータベースには、そのコレクション内のプロジェクトのすべてのデータが含まれています。 このデータには、ソース コード、ビルド構成、およびラボ管理構成が含まれます。 コレクション データベースの数は、コレクションの数と同じになります。 たとえば、デプロイに 3 つのコレクションがある場合は、これら 3 つのコレクション データベースをバックアップする必要があります。 各データベースの名前には、コレクションを作成したユーザーのユーザー名など、 TFS_ と CollectionName の間に追加の文字が含まれる場合があります。 たとえば、コレクション データベースの名前がTFS_UserNameCollectionNameされる場合があります。
TFS_Analysis	SQL Server Analysis Servicesのデータベースには、Azure DevOps Serverのデプロイ用のデータ ソースとキューブが含まれています。 このデータベースの名前には、Analysis Services をインストールしたユーザーのユーザー名など、 TFS_ と Analysis の間に追加の文字が含まれる場合があります。 たとえば、データベースの名前がTFS_UserNameAnalysisされる場合があります。 注: このデータベースはバックアップできますが、復元されたTFS_Warehouse データベースからウェアハウスを再構築する必要があります。
ReportServer	Reporting Servicesのデータベースには、Azure DevOps Serverの展開に関するレポートとレポートの設定が含まれています。 注: Reporting ServicesがAzure DevOps Serverとは別のサーバーにインストールされている場合、このデータベースはAzure DevOps Server用のデータ層サーバーに存在しない可能性があります。 その場合は、Azure DevOps Serverとは別に構成、バックアップ、復元する必要があります。 同期エラーを回避するには、データベースのメンテナンスを同期する必要があります。
ReportServerTempDB	Reporting Services の一時データベースです。特定のレポートを実行するときに情報が一時的に格納されます。 注: Reporting ServicesがAzure DevOps Serverとは別のサーバーにインストールされている場合、このデータベースはAzure DevOps Server用のデータ層サーバーに存在しない可能性があります。 この場合は、Azure DevOps Serverとは別に構成、バックアップ、復元する必要があります。 ただし、同期エラーを防ぐため、データベースを保守する際は、両者に矛盾が生じないように注意する必要があります。
VirtualManagerDB	SCVMM の管理データベースには、仮想マシン、仮想マシンのホスト、仮想マシンのライブラリ サーバー、およびそれらのプロパティなど、SCVMM 管理者コンソールに表示される情報が格納されています。 注: SCVMM がAzure DevOps Serverとは別のサーバーにインストールされている場合、このデータベースはAzure DevOps Server用のデータ層サーバーに存在しない可能性があります。 その場合は、Azure DevOps Serverとは別に構成、バックアップ、復元する必要があります。 ただし、同期エラーを防ぐため、データベースを保守する際は、マークされたトランザクションを使用して両者に矛盾が生じないように注意する必要があります。

関連記事

• Azure DevOps Serverのバックアップと復元
• 配置の新しいハードウェアへの復元