---
title: "DR 2.0の回復ポイント目標および回復時間目標"
slug: "recovery-point-objectives-and-recovery-time-objectives-for-dr-2-0"
abstract: "Managed Cloud PaaS 2.0(DR 2.0とも呼ばれる)のリカバリーポイント目標(RPO)および回復時間目標(RTO)について学びましょう。"
---
# DR 2.0の回復ポイント目標および回復時間目標

本番環境の障害からDR環境での運用復帰までの時間は、フェイルオーバープロセス開始のリクエストを作成するかどうかに依存します。フェイルオーバー前に故障やイベントの調査に費やす時間は、運用復帰のタイミングを遅らせます。このトピックでは、DR 2.0のフェイルオーバープロセスに関わるリカバリーポイント目標(RPO)および復旧時間目標(RTO)について説明します。

## リカバリーポイント目標(RPO)

サービスの種類

リカバリーポイントの目的

Azure SQL フェイルオーバーグループ

~5秒

Azure App Serviceはバックアップと復元を計画します

3時間

Azure Redisキャッシュ(セカンダリージョンで再構築)

該当なし

Sitecoreの設定と自動化

3時間

バックアップとリストアを用いるSolr as a Service(サービスとしてのソリューション)

3時間

## 技術復旧時間目標(RTO)

サービスの種類

技術復旧時間目標

Azure SQLフェイルオーバーグループ

10分

Azure App Service plans backup

10分

Azure Redis Cache \*

30分

Sitecoreの設定と自動化

10分

バックアップとリストアを用いるSolr as a Service(サービスとしてのソリューション)

10分

\* Azure Redisキャッシュのスケーリングアップは約30分かかります。この間、Azure Redis Cacheサービスへのアクセスが断続的に行われる場合があります。 [MicrosoftのAzure Redisスケーリング](https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-how-to-scale?tabs=scale-up-and-down-with-basic-standard-and-premium#how-long-does-scaling-take)に関するドキュメントをご参照ください。

> !注技術RTOの価値は、Sitecoreプラットフォームの復元にかかる時間のみを考慮しています。顧客やパートナーが手動でフェイルオーバーの許可を得る試みやカスタマイズの検証を試みるなど、手作業が必要な場合、実効的なRTOは延長されます。

## プラットフォームおよびウェブサイトの回復時間目標(RTO)

以下に記載するRTO値は、DRフェイルオーバープロセスを開始するために顧客の承認が必要です。

バックアップ技術

責任ある所有者

技術復旧時間目標

Sitecore CMサーバーアクセスとサービスの利用可能性

Sitecore

1時間

Sitecore CDサーバーのアクセスとサービスの利用可能性

Sitecore

1時間

ウェブサイトへのアクセスと入手可能性

顧客/パートナー

顧客依存の活動で、カスタムアプリケーション接続文字列やサードパーティ接続の検証が必要です。

> !注RTOは大規模なコンテンツデータベースにかかる大幅な時間のため、xDBインデックスの再構築はカバーしません。分析インデックスの再構築が行われない場合、これはEXMのようにリストに依存する機能にのみ影響し、ランタイムサイトには影響しないはずです。