| 階層（提案） | 可用性 | パターン | RPO / RTO |
|---|---|---|---|
| 標準 | 99.7% | マルチゾーン、高可用性データベース、エアギャップバックアップ | ゾーン: RPO ≈ 0。リージョン: 保管庫から復元。 |
| Live DR | 99.9% | ライブ配信中の第2地域 | RPO秒、RTO≦15分 |
| Live DRプレミアム | 99.95% | 両地域における交通は24時間365日優先されます。 | RPO秒、RTO≦5分 |
非稼働率は95%です。稼働率は、合意されたメンテナンス時間（月4時間）を除き、TRANXACTの入口で月ごとに測定されます。
サイジングを行う前に、ティアを確定してください。Live DRはフルサイズのセカンドリージョンであり、ランタイムインフラストラクチャのコストをほぼ2倍にします。そのため、削減されるダウンタイムコストとは別に、独立した行として表示してください。
受動的ではなく、生き生きと。
パッシブスタンバイは待機状態にあり、年に一度（もし検証されるとしても）検証されるだけで、フェイルオーバー時には復元とスケールアップによって実行されます。Live DR、フルサイズのクラスタと継続的にレプリケートされたデータベースを稼働させ、終日、読み取り、レポート作成、ASK （自動サービス要求）、合成投稿に対応します。フェイルオーバーは昇格であり、何も再構築されることなく、その健全性は毎分検証されます。
| テスト | インパクト | どのくらいの頻度で | カテゴリ |
|---|---|---|---|
| 継続的な検証 ― 合成投稿、遅延アラート、地域間台帳チェックサム | なし | 毎分 | 標準 (TO_4.10.01) |
| 計画された切り替え訓練 - 書き込みの一時停止、昇格、シフト、検証、役割の交換 | 書き込みが数秒間停止します | 四半期ごと | 標準 (TO_4.10.03) |
| 追加の切り替え訓練 | 書き込みが数秒間停止します | リクエストに応じて、2週間前までに | 追加情報（TO_4.10.04） |
| 隔離されたドリル - 統合が無効になっているフェンス付きクローン | 生産中はなし | リクエストに応じて、2週間前までに | 追加情報（TO_4.10.05） |
| クリーンルーム復元テスト | 生産中はなし | 年間 | 標準 (TO_4.9.07) |
| 訓練後のビジネス検証 | 顧客の努力 | 各ドリル | 除外済み (TO_4.10.06) |
バックアップ
| 本番環境データベース | 非本番環境データベース | |
|---|---|---|
| 撮影済み | 日次スナップショット＋継続ログ | 日次スナップショット |
| 回復して | 30日以内の任意の時点 | 最後のスナップショットは14日前です。 |
| 保管庫のコピー | 毎日、不変、90日間 | 毎週、変更不可、30日間 |
ドキュメントは継続的にバージョン管理され、毎日本番環境用の保管庫にコピーされます。インフラストラクチャ・アズ・コードと構成情報も保管庫に格納されているため、ランタイムは復元ではなくコードから再構築されます。
なぜ金庫なのか
レプリケーションは障害から保護するものであり、データの破損から保護するものではありません。ランサムウェアや不正なデータは、数秒以内にスタンバイ環境と災害復旧（DR）環境へ複製されます。保管庫は、個別のIDとキーを持つ独立したアカウントであり、本番環境とのネットワークパスはなく、管理者でさえ短縮できない書き込み専用保持期間と、二重承認による削除機能を備えています。保管庫からのリストアは、隔離された環境で行われ、スキャン、調整、そして昇格という手順を経て、決して本番環境に直接適用されることはありません。
保持ロックは一度設定すると短縮できません。監査や法的保留が必要な場合は、事前に保持期間を延長し、長期保存用のコピーのサイズは、現在のデータベースサイズではなく、台帳の増加と文書量に基づいて決定してください。
Calderwood社は、同じ管轄区域内の別のAzureリージョンで、99.9%の稼働率を誇るLive DRを選択しました。準備状況の確認として、本番稼働前に最初の切り替え訓練とクリーンルームでの復旧訓練を実施する予定です。銀行および給与支払いパートナーも切り替え計画に組み込まれており、エンドポイントはトラフィックマネージャーに追従します。
試してみて バッチジョブにより、14時05分にカルダーウッド社の請求書4,000件が破損しました。稼働中の災害Live DRは正常で、遅延は2秒です。DR環境へのフェイルオーバーで解決できるでしょうか？
いいえ。破損は発生後数秒でスタンバイおよびDR領域に複製されるため、フェイルオーバーによって同じ不良データに移行します。解決策は、14:04への特定時点復元（TO_4.9.05、標準）または、履歴自体に疑わしい点がある場合は、保管庫からのクリーンルーム復元（TO_4.9.06）を行い、財務管理者が復元されたデータを承認すること（TO_4.9.11）です。