名称	略称・呼び方	ざっくり言うと
Oracle Zero Data Loss Recovery Appliance	ZDLRA	Oracle Database の保護に特化した専用 Engineered System
Oracle Database Autonomous Recovery Service	RCV	Oracle Database 向けのフルマネージド・バックアップ／リカバリ・サービス
Oracle Database Zero Data Loss Autonomous Recovery Service	ZRCV	RCV でリアルタイム・データ保護を利用する構成
Oracle Database Zero Data Loss Cloud Protect	Cloud Protect	オンプレミスの Oracle Database を Recovery Service で保護するための機能

名前だけを並べると、なかなかの混乱具合です。

特に ZDLRA と ZRCV は別の名前になっていますし、さらに Cloud Protect まで登場しました。

ここからは、この関係を歴史とテクノロジーの両面から整理してみます。

2. まずは全体像を整理してみる

細かい説明に入る前に、今回登場するものの関係をざっくり整理しておきます。

図 1：ZDL の全体像

ものすごく単純化すると、このような関係です。

ZDLRA は、お客様のデータセンターなどに設置する Oracle Database 保護専用の Engineered System。

RCV / ZRCV は、ZDLRA で培われたテクノロジーをベースにしたクラウドサービス。

そして、Cloud Protect は、オンプレミスで稼働する Oracle Database を Recovery Service で保護するための機能です。

つまり、3 種類のまったく異なるバックアップ製品が存在している、と考えるよりも、Oracle Database のデータ保護テクノロジーが利用形態を変えながら広がってきたと捉えると分かりやすくなります。

3. ZDL の元祖、ZDLRA

まずは、Zero Data Loss Recovery Appliance、略して ZDLRA です。

ZDLRA は 2014 年に発表された、Oracle Database のデータ保護を目的とした Engineered System です。

「Recovery Appliance」という名前のとおり、Oracle Database のバックアップとリカバリに特化した専用システムです。

ここでポイントになるのは、単純に「バックアップを保存するための大容量ストレージ」ではない、ということです。

ZDLRA は Oracle Recovery Manager、いわゆる RMAN と密接に統合されており、Oracle Database の仕組みを理解したうえでバックアップ・データを管理します。

代表的な特徴として、次のようなものがあります。

最初の Level 0 バックアップ取得後は Level 1 の増分バックアップを中心に運用する「Incremental Forever」
増分バックアップから必要な時点のフルバックアップを論理的に構成する「Virtual Full Backup」
データベースで発生する REDO を継続的に転送する「Real-Time Redo Transport」
バックアップ・データの継続的な検証
バックアップ／リストア処理の多くをデータベース・サーバーからオフロード

ZDLRA の特徴を理解するうえで重要なのが、バックアップだけでなく REDO も保護するという考え方です。

Oracle Database では、一般的な RMAN バックアップでも ARCHIVELOG モードで Archived Redo Log を適切にバックアップしていれば、データファイルのバックアップ取得時点より後までリカバリできます。

一方、最後に保護された Archived Redo Log より後に発生した REDO が失われれば、その部分についてはデータ損失が発生する可能性があります。

ZDLRA では、Real-Time Redo Transport によってデータベースで発生する REDO を継続的に Recovery Appliance へ転送することで、このデータ損失の可能性を極小化します。

これが「Zero Data Loss」という名前につながる重要なテクノロジーです。

Oracle のドキュメントでは、Real-Time Redo Transport を利用することで、RPO を 1 秒未満に抑えることができると説明されています。

「Zero」という名前ではありますが、単純に「何が起きても必ず 0 秒 RPO」という意味として理解するのではなく、こうした仕組みによってデータ損失の可能性を限りなく小さくするもの、と理解しておくのがよいでしょう。

4. ZDLRA がクラウドへ ― RCV / ZRCV

続いて登場するのが、Oracle Database Autonomous Recovery Service です。

Oracle は 2022 年に Oracle Database Zero Data Loss Autonomous Recovery Service を発表しました。

Oracle の公式説明でも、このサービスは ZDLRA のテクノロジーをベースにしたフルマネージド・クラウドサービスとされています。

つまり、ZDLRA で提供されていた Oracle Database に特化したバックアップ／リカバリの考え方を、専用のアプライアンスを自分で所有することなく、クラウドサービスとして利用できるようにしたものです。

ただし、ここでまた名前が少しややこしくなります。

本記事では、Recovery Service を利用する際にリアルタイム・データ保護を利用するかどうかによって、次のように呼び分けます。

呼び方	リアルタイム・データ保護	概要
RCV	なし	Autonomous Recovery Service
ZRCV	あり	Zero Data Loss Autonomous Recovery Service

RCV でも、増分バックアップ、バックアップの検証、イミュータブルなバックアップなど、Recovery Service のさまざまな機能を利用できます。

そこに Real-Time Protection を利用し、REDO をリアルタイムに保護する構成が Zero Data Loss Autonomous Recovery Service、つまり ZRCV です。

「RCV と ZRCV というまったく別のバックアップ・サービス」と考えるよりも、Recovery Service におけるリアルタイム・データ保護の有無に着目すると分かりやすいでしょう。

5. ちょっと小ネタ ― ZDLARS じゃないの？

ここで、名前について少し寄り道します。

「Zero Data Loss Autonomous Recovery Service」を初めて見たとき、頭文字を取れば「ZDLARS」では？と思いませんか。

少なくとも私はそう思いました。

ところが、Oracle の資料で使われている略称は ZRCV です。

Oracle の資料では、Autonomous Recovery Service を RCV、Zero Data Loss Autonomous Recovery Service を ZRCV と表記しています。

そのため、本記事でも Oracle の表記に合わせて RCV / ZRCV と呼ぶことにします。

一方、Zero Data Loss Recovery Appliance は素直に ZDLRA。

ZDLRA、RCV、ZRCV、Cloud Protect。

やっぱり、最初はちょっとややこしいですね。

6. そして登場した Zero Data Loss Cloud Protect

ZDLRA と RCV / ZRCV の関係が分かったところで、さらに Oracle Database Zero Data Loss Cloud Protect が登場します。

Cloud Protect は 2025 年 10 月に発表された機能で、オンプレミスで稼働している Oracle Database を Recovery Service で保護できるようにするものです。

ここで重要なのは、Cloud Protect という新しいバックアップ・ストレージが登場したわけではないというところです。

Cloud Protect は、新しいバックアップ・ストレージではなく、オンプレミスの Oracle Database を Autonomous Recovery Service で保護するための機能です。

Cloud Protect の登場によって、Oracle Database 自体はオンプレミスに残したまま、バックアップ／リカバリにはクラウドの Recovery Service を利用するという選択肢が加わったことになります。

これは、オンプレミス環境をすぐにはクラウドへ移行できない場合でも、バックアップ基盤からクラウドサービスを利用したいケースでは面白い選択肢です。

ただし、現時点では何でも接続できるわけではありません。

Cloud Protect Fleet Agent の対応プラットフォームや Oracle Database のバージョンなどには要件があります。

そのため、既存のオンプレミス Oracle Database で Cloud Protect を検討する場合には、OS、Oracle Database のバージョン、ネットワーク構成などを含め、最新のサポート要件を Oracle のドキュメントで確認することをおすすめします。

7. ZDLRA と ZRCV に共通するテクノロジー

ここまで名前と製品の関係を中心に見てきました。

では、ZDLRA と ZRCV は、一般的な Oracle Database のバックアップと何が違うのでしょうか。

ここは少し注意が必要です。

Oracle Database の一般的な RMAN バックアップでも、ARCHIVELOG モードで運用し、Archived Redo Log を適切にバックアップしていれば、最後に取得したフルバックアップや増分バックアップの時点までしか戻れない、というわけではありません。

データファイルのバックアップに Archived Redo Log を適用することで、最後に保護された Archived Redo Log の時点までリカバリできます。

そのうえで ZDLRA / ZRCV が特徴的なのは、増分バックアップに加えて、データベースで発生する REDO を継続的に転送して保護するという点です。

図 2 一般的な RMAN の ARCHIVELOG 運用と、ZDLRA / ZRCV による REDO のリアルタイム保護の違い 図 2：ZDLRA / ZRCV の仕組み

図の上段は、一般的な RMAN ＋ ARCHIVELOG 運用のイメージです。

フルバックアップや増分バックアップに加えて Archived Redo Log を取得・バックアップすることで、最後に保護された Archived Redo Log の時点までリカバリできます。

ただし、Archived Redo Log の取得やバックアップには間隔があります。

障害によってオンライン REDO ログなどが失われた場合、最後に保護された Archived Redo Log より後に発生した REDO は失われる可能性があります。

これに対して、図の下段が ZDLRA / ZRCV のイメージです。

まず、ZDLRA では RMAN の Incremental Forever 戦略を利用します。

最初に Level 0 バックアップを取得した後は、Level 1 の増分バックアップを継続して取得します。

Recovery Appliance は受信した増分バックアップを管理し、必要な時点のフルバックアップを論理的に構成します。

これが Virtual Full Backup の考え方です。

毎回フルバックアップを取得する必要がないため、データベース・サーバー側のバックアップ負荷やバックアップ・ウィンドウを抑えることができます。

そして、Zero Data Loss を考えるうえで特に重要なのが REDO のリアルタイム転送です。

ZDLRA では Real-Time Redo Transport、ZRCV では Real-Time Protection によって、データベースで発生する REDO を継続的に保護します。

図 2 では、両者に共通する考え方を分かりやすくするため、これを「REDO のリアルタイム転送」と表現しています。

一般的な ARCHIVELOG 運用が Archived Redo Log を単位として保護していくのに対し、ZDLRA / ZRCV では REDO を継続的に転送することで、Archived Redo Log のバックアップ間隔に存在するデータ損失の可能性をさらに小さくします。

Oracle のドキュメントでは、Real-Time Redo Transport を利用した Recovery Appliance について、一般的にゼロから 1 秒未満のデータ損失が想定されると説明されています。

そのため図 2 では、「データ損失リスクを 1 秒未満に抑制」と表現しています。

つまり、「Zero Data Loss」のポイントは、一般的な RMAN / ARCHIVELOG 運用ではリカバリできないということではありません。

Incremental Forever、Virtual Full Backup、REDO のリアルタイム保護、そして継続的なリカバリ検証を組み合わせることで、Oracle Database のバックアップとリカバリを効率化しながら、データ損失の可能性を極小化する。

これが ZDLRA で実現され、Recovery Service に受け継がれている重要な考え方です。

8. 結局、どれを使えばいいの？

ここまで整理すると、それぞれの立ち位置も見えてきます。

選択肢	主な利用イメージ
ZDLRA	自社環境に大規模な Oracle Database 保護基盤を構築し、専用 Engineered System として運用したい
RCV	Oracle Database のバックアップ／リカバリをフルマネージド・クラウドサービスとして利用したい
ZRCV	RCV に加えて REDO のリアルタイム保護を利用し、データ損失の可能性を極小化したい
Cloud Protect ＋ Recovery Service	オンプレミスの Oracle Database はそのままに、バックアップ／リカバリ基盤として Recovery Service を利用したい

以前であれば、「オンプレミスなら ZDLRA、クラウドなら Recovery Service」と整理することもできました。

しかし Cloud Protect が登場したことで、オンプレミスの Oracle Database から Recovery Service を利用するという選択肢も加わりました。

そのため現在は、「Oracle Database がどこにあるか」だけではなく、バックアップ基盤を自社で持ちたいのか、クラウドサービスとして利用したいのか、そして REDO のリアルタイム保護が必要なのかという観点で考えると分かりやすいでしょう。

9. まとめ

今回は、「ZDL ってなぁに？」ということで、Oracle Database のバックアップ／リカバリ関連で登場する ZDLRA、RCV / ZRCV、Zero Data Loss Cloud Protect について整理しました。

ZDLRA は、Oracle Database のデータ保護に特化した Engineered System。

RCV / ZRCV は、ZDLRA のテクノロジーをベースにしたフルマネージド・クラウドサービス。

その中でも REDO のリアルタイム保護を利用するものが ZRCV です。

そして Zero Data Loss Cloud Protect は、オンプレミスの Oracle Database を Autonomous Recovery Service で保護するための機能です。

また、一般的な RMAN ＋ ARCHIVELOG 運用でも Archived Redo Log を利用してバックアップ取得時点より後までリカバリできますが、ZDLRA / ZRCV では REDO を継続的に保護することで、そのデータ損失の可能性をさらに小さくします。

ZDL という文字だけを追いかけると複雑に見えますが、歴史をたどってみると、ZDLRA で実現してきた Oracle Database 専用のデータ保護テクノロジーを、クラウドへ、さらにハイブリッド環境へと広げてきたという流れが見えてきます。

名前が似ているのには、ちゃんと理由があったわけですね。

今回の記事が、ZDLRA、RCV、ZRCV、Cloud Protect の資料を見たときに「これは何だっけ？」となった際の整理に役立てば幸いです。

今回はここまで。

また次回まで、みなさまごきげんよう。

SB C&S の OCI 相談センター

OCI を取り扱われているパートナー企業様へ様々なご支援メニューを用意しております

著者紹介

先端技術統括部
DXｺﾝｻﾙﾃｨﾝｸﾞ部ﾃﾞｼﾞﾀﾙｲﾉﾍﾞｰｼｮﾝ課
永瀬晋作

みなさま、ごきげんよう。

【OCI】ZDL ってなぁに？

1. そもそも ZDL ってなぁに？