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

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 デプロイを保護します。 次の表と付属の図は、バックアップするデータベースを示し、これらのデータベースをデプロイで物理的に配布する方法の例を示しています。

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

展開トポロジ

デプロイ構成に基づいて、このトポロジ例のように、バックアップが必要なすべてのデータベースが同じ物理サーバー上にある可能性があります。

Note

この例には 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 を使用している場合は、セカンダリ データベースのバックアップを作成できます。 また、バックアップ圧縮を使用したり、複数のファイルにバックアップを分割したりすることもできます。 バックアップ オプションの簡単な説明を次に示します。

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

デプロイを回復するには、データベースの完全バックアップが必要です。 完全バックアップには、完全バックアップを回復できるように、トランザクション ログの一部が含まれています。 完全バックアップは、バックアップ時に存在していたデータベース全体を表すという点で自己完結型です。 詳細については、「 完全なデータベース バックアップ」を参照してください。

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

差分データベース バックアップでは、前回のデータベースの完全バックアップ以降に変更されたデータ (差分ベースと呼ばれます) のみが記録されます。 データベースの差分バックアップは、データベースの完全バックアップよりも小さく、高速です。 このオプションを使用すると、バックアップ時間が短縮され、複雑さが増します。 大規模なデータベースの場合、差分バックアップはデータベース バックアップよりも短い間隔で実行できるため、作業損失の露出が減少します。 詳細については、「 Differential データベース バックアップ」を参照してください。

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

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

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

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

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

次の種類のトランザクション ログ バックアップを実行できます。

• 純粋ログ バックアップには、一括変更なしで、一定の間隔のトランザクション ログ レコードのみが含まれます。
• 一括ログ バックアップには、一括操作によって変更されたログページとデータ ページが含まれます。 特定の時点への復旧は実行できません。
• ログ末尾のバックアップは、まだバックアップされていないログ レコードをキャプチャするために、破損している可能性のあるデータベースから取得されます。 ログ末尾のバックアップは、作業の損失を防ぐために障害が発生した後に作成され、純粋なログ データまたは一括ログ データを含めることができます。

データの同期は 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 インスタンスまたは複数のサーバーに分散される場合があります。

Note

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

データベース	説明
TFS_Configuration	Azure DevOps Server の構成データベースには、デプロイのカタログ、サーバー名、および構成データが含まれています。 このデータベースの名前には、azure DevOps Server をインストールしたユーザーのユーザー名など、 TFS_ と Configuration の間に追加の文字が含まれる場合があります。 たとえば、データベースの名前はTFS_UserNameConfiguration
TFS_Warehouse	ウェアハウス データベースには、Reporting Services で使用されるウェアハウスを構築するためのデータが含まれています。 このデータベースの名前には、azure DevOps Server をインストールしたユーザーのユーザー名など、 TFS_ と Warehouse の間に追加の文字が含まれる場合があります。 たとえば、データベースの名前が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場合があります。 Note: このデータベースをバックアップできますが、復元されたTFS_Warehouse データベースからウェアハウスを再構築する必要があります。
ReportServer	Reporting Services のデータベースには、Azure DevOps Server のデプロイに関するレポートとレポートの設定が含まれています。 Note: Reporting Services が Azure DevOps Server とは別のサーバーにインストールされている場合、このデータベースが Azure DevOps Server のデータ層サーバーに存在しない可能性があります。 その場合は、Azure DevOps Server とは別に構成、バックアップ、復元する必要があります。 同期エラーを回避するには、データベースのメンテナンスを同期する必要があります。
ReportServerTempDB	特定のレポートを実行すると、Reporting Services の一時データベースに情報が一時的に格納されます。 Note: Reporting Services が Azure DevOps Server とは別のサーバーにインストールされている場合、このデータベースが Azure DevOps Server のデータ層サーバーに存在しない可能性があります。 この場合は、Azure DevOps Server とは別に構成、バックアップ、復元する必要があります。 ただし、同期エラーを回避するには、データベースのメンテナンスを同期する必要があります。
VirtualManagerDB	SCVMM の管理データベースには、仮想マシン、仮想マシン ホスト、仮想マシン ライブラリ サーバー、そのプロパティなど、SCVMM 管理者コンソールで表示する情報が含まれています。 Note: SCVMM が Azure DevOps Server とは別のサーバーにインストールされている場合、このデータベースは Azure DevOps Server のデータ層サーバーに存在しない可能性があります。 その場合は、Azure DevOps Server とは別に構成、バックアップ、復元する必要があります。 ただし、同期エラーを回避するには、マークされたトランザクションを使用し、データベースのメンテナンスを同期する必要があります。

関連記事

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