Zero Data Loss Autonomous Recovery Service

この画像では、ワンクリックで有効化できるリアルタイムデータ保護の仕組みを説明しています。ワンクリックでRecovery Serviceを保護対象データベースの代替ログ出力先として設定でき、データベースのメモリ内で生成されたREDO変更が自動的にRecovery Serviceに送信され、受信時に検証されます。データベースのログ切り替えが行われると、Recovery Serviceは圧縮済みアーカイブ・ログ・バックアップを自動的に作成し、リカバリ・カタログに登録します。

Recovery Serviceは、たとえ通常のログスイッチ発生間に保護対象データベースとの接続が中断されても、最後にコミットされたトランザクションまでリカバリ可能な状態を維持します。もしREDOストリームが予期せず終了した場合も、Recovery Serviceは受信中のREDOストリームを閉じ、部分的なアーカイブREDOログ・ファイル・バックアップを作成します。その後、REDOストリームの再開を検知すると、欠落しているすべてのアーカイブREDOログ・ファイルを保護対象データベースから自動的に取得し、リカバリウィンドウを維持します。

バックアップ・ライフサイクル全体にわたるリカバリ検証

バックアップの整合性を確認するだけでなく、必要なときにデータベースを確実にリカバリできるよう、より踏み込んだ検証を行うことで、システム全体のレジリエンスを強化します。

「Continuous Database-Aware Anomaly Detection and Recovery Validation（データベース対応の継続的な異常検出とリカバリ検証）」と題されたこの画像は、Oracle Database Zero Data Loss Autonomous Recovery Serviceが独自のリカバリ準備態勢をどのように提供するかを示しています。

1. 受信REDOとRMANバックアップ・ストリームは、ディスクに保存される前に検証されます。RMANで読み取りできない破損したデータは受け入れられません。
2. バックアップが保管されている間も定期的に検証され、RMANによるPoint-in-Timeリカバリに必要なすべてのデータベース・トランザクション（SCN）が揃っていることを確認します。
3. リストア、バックアップコピー、複製バックアップをネットワーク経由で送信する際にも、事前に検証が行われます。

Autonomous Recovery Serviceは、マルチファクターかつデータベースリカバリ対応の検証をあらゆるタッチポイントで自動的に実施し、本番データベースサーバーに負荷をかけることなく、格納されているバックアップの定期的なリカバリ検証を含む、独自のリカバリ準備能力を提供します。

ポリシーベースのアクセス制御とバックアップのイミュータビリティ

バックアップの安全性を多層的に守るために、本番環境とデータ保護インフラの分離、職務分掌（ロールベースの権限分離）、そしてバックアップの改ざんができない保持ロック（Retention Lock）ポリシーなど、さまざまな仕組みが採用されています。

「Multi-layered Guardrails Protect Backup Integrity and Access（多層的防御によるバックアップの整合性・アクセス保護）」と題されたこの画像では、Recovery Serviceに組み込まれている主なセキュリティ・ベストプラクティスが紹介されています。

• Recovery Serviceは、保護対象となる本番データベースから障害が分離されるよう設計されています。オラクルが管理するテナンシ内で稼働し、プライベート・エンドポイントを介してお客様のテナンシと接続しています。
• すべてのバックアップは暗号化が必須であり、保持ロック付きの保護ポリシーを有効化することで、バックアップはイミュータブルとなります。削除や保持期間の短縮は許可されません。
• データベース管理者（DBA）とRecovery Service管理者の間で、役割ごとにアクセス権限が分離されています。

Recovery Serviceが管理するバックアップは、いかなる管理者やユーザーでも任意に変更・削除することができません。そのため、意図的または誤操作による消去から保護されます。またDBAはRecovery Manager（RMAN）を通してのみRecovery Serviceにアクセス可能で、バックアップ・リストア操作もRMANが一元管理します。お客様のテナンシから論理的・物理的に分離されているため、仮にDBAやシステム管理者の認証情報が不正に利用された場合でも、Recovery Service上のバックアップが攻撃されるリスクは低くなります。

さらに、事前に設定された保持期間やユーザー定義のポリシーにより、サービスレベル契約（SLA）やコンプライアンス要件に応じたバックアップの保持が容易になります。最低14日間のリカバリウィンドウによって、誤操作や悪意ある行為からデータを守ることができます。また、保護対象のデータベースが終了（削除）された場合でも、Recovery Serviceはバックアップを最低72時間自動的に保持することで、万一の場合に備えています。

すべての保護対象データベースには、バックアップのライフサイクル管理（複製、保持期間: point-in-timeリカバリ・ウィンドウ、保持ロック設定など）を定義する保護ポリシーが適用されます。これにより、バックアップのイミュータビリティが担保されます。