Autonomous Recovery Service - Listing backups

Autonomous Recovery Service - Listing backups

One of the unique features of the Autonomous Recovery Service (RCV) is the ability to create Long Term Backups by using existing backups that are currently stored in RCV.

NOTE: Long term backups, also known as "Keep" backups are self contained backups that provide the ability to restore to a small predetermined point-in-time window. These long term backups are often stored for months, or even years and are typically used for auditing purposes.

These backups are created dynamically outside of the database itself and the DB host is not used.

Because the DB host is bypassed, the normal backup listings on the DB host using the DBAASCLI tool do not see long term backups.

Viewing backups with OCI

All of the backups can be viewed in both the OCI Console and by using the OCI CLI tool.

In this blog, I will describe how you can use the OCI Cli tool to view all of the backups.

The command I am utilizing to display backups is

oci db backup list

Unfortunately, the output from this command is JSON objects which can be difficult to read if you want to produce a report.  

In this blog, I show examples leveraging JMESPath queries via the --query flag.

---

The Foundation: Listing Database Backups

The baseline command to list backups for a specific database requires the --database-id (OCID). By default, we want to output this as a table, grab all records across pages using the --all flag, and project key fields like Shape and Type:

oci db backup list \
  --database-id {DB OCID} \
  --output table \
  --query "data[?\"lifecycle-state\" == 'ACTIVE'] | sort_by(@, &\"time-started\")[].{Backup_Name: \"display-name\", Time_Started: \"time-started\", Status: \"lifecycle-state\", Version: \"version\", OCID: \"id\", Database_size_GBs: \"database-size-in-gbs\",Shape: \"shape\",Type: \"type\"}"

Running this execution in your environment outputs a perfectly structured text report directly in your shell stream:

+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+-------------+-------------+
| Backup_Name      | Database_size_GBs | OCID                                                                                | Shape       | Status | Time_Started                     | Type        | Version     |
+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+-------------+-------------+
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iafzxovfcfwpr3pcact3e3vu2exz..........         | Exadata.X8M | ACTIVE | 2026-03-30T12:04:06.553000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iat6czxrwvfnhrgl4voypnunsf2qmfc......          | Exadata.X8M | ACTIVE | 2026-03-31T12:05:41.932000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iapdhn7ekp7ax2y74pbbk32yi4c5zr.......          | Exadata.X8M | ACTIVE | 2026-04-01T12:05:13.350000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iakasw46kzqpk74g335esjwehihmkfzuj............. | Exadata.X8M | ACTIVE | 2026-04-02T12:04:54.891000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iagzx75s2s6zravvpjoem2rkvtm7ue54d............. | Exadata.X8M | ACTIVE | 2026-04-03T12:05:40.559000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267ia2j7s7r464swgvrfc34dqh7b635hupho............. | Exadata.X8M | ACTIVE | 2026-04-04T12:03:59.219000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iawkwrmemheourosyriczq3v7lecgmrcj............. | Exadata.X8M | ACTIVE | 2026-04-05T07:24:00.238000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267ia2j25fk53uf5fmfkivkoa6ijcbn3fdg7c............ | Exadata.X8M | ACTIVE | 2026-04-06T12:04:22.389000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iass2o5w5bryallijsjjpk2nso2654jr2............. | Exadata.X8M | ACTIVE | 2026-04-07T12:03:56.898000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv62

Finding the most recent backup

In this example, I am limiting the command to extract only daily backups (no long term backups), sort by the execution time, and return only the first record.

This command can be also be used in any scripting to ensure you are cloning from the most recent backup.

oci db backup list \
  --database-id {DB OCID} \
  --output table \
  --query "data[?\"retention-period-in-days\" == \`null\` && \"retention-period-in-years\" == \`null\` && \"lifecycle-state\" == 'ACTIVE'] | sort_by(@, &\"time-started\")[-1].{Backup_Name: \"display-name\", Time_Started: \"time-started\", Status: \"lifecycle-state\", Version: \"version\", OCID: \"id\", Database_size_GBs: \"database-size-in-gbs\",Shape: \"shape\",Type: \"type\"}"

Executing this slice pattern evaluates down to a single, isolated record representing your absolute most recent backup:

+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+-------------+-------------+
| Backup_Name      | Database_size_GBs | OCID                                                                                | Shape       | Status | Time_Started                     | Type        | Version     |
+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+-------------+-------------+
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iaufuy74ggl2bvf66czd75x3v4366qrwc............. | Exadata.X8M | ACTIVE | 2026-05-19T12:04:12.917000+00:00 | INCREMENTAL | 19.26.0.0.0 |
+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+-------------+-------------+

Finding all of the long term backups

This command will display only backups that were creating with a future expiration date. This can be used to view all of the long term backups that were created for this database.

 oci db backup list \
>   --database-id {Database OCID} \
>   --output table \
>   --query "data[?\"time-expiry-scheduled\" != \`null\` && \"lifecycle-state\" == 'ACTIVE'] | sort_by(@, &\"time-started\")[].{Backup_Name: \"display-name\", Time_Bacdkup_Started: \"time-started\", Status: \"lifecycle-state\", Version: \"version\", Time_Backup_Expires: \"time-expiry-scheduled\", OCID: \"id\", Database_size_GBs: \"database-size-in-gbs\",Shape: \"shape\"}"

+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+----------------------------------+-------------+
| Backup_Name      | Database_size_GBs | OCID                                                                                | Shape       | Status | Time_Bacdkup_Started             | Time_Backup_Expires              | Version     |
+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+----------------------------------+-------------+
| Long_term_backup | 21.0              | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iaskl3otjhgovkhvefzcjzckdg3v5sfwfybglhrl2mqz7a | Exadata.X8M | ACTIVE | 2026-05-14T14:39:17.539000+00:00 | 2027-05-14T14:39:18.871000+00:00 | 19.26.0.0.0 |
+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+----------------------------------+-------------+

Automating cloning of your Exadata Database Service on Dedicated Infrastructure database

One of the questions I often get from customers is 

"How do I automate the cloning of a production database backup to a non-prod copy?  This is something we do often."

There are three different OCI commands  to do what seems like the exact same thing. Specifically, when it comes to restoring a database from a backup, the OCI CLI gives us three primary paths.

The "secret sauce" to choosing the right command is understanding where the database is going and ensuring you have the right OCIDs for your target infrastructure. Let's break down the full parameter sets you need to keep your automation from failing.

These are all "oci db database " commands

---

The Restore Matrix: Choosing Your Command

Command	Infrastructure Target	Required Target ID	Primary Use Case
create-database-from-backup	Exadata / C@C	--db-home-id	Restoring into an existing Exadata Home.
create-from-backup	Base DB (VM/BM)	--db-system-id	Adding a DB to an existing DB System.
create --source DB_BACKUP	Base DB (VM/BM)	--compartment-id	Building a NEW DB System from a backup.

---

1. The Exadata Full Set: create-database-from-backup

This command uses a JSON object for the --database flag. This is where you define the identity of the clone within the Exadata rack along with the backup you want to use to create the new database.

{
  "adminPassword": "YourPassword123#",
  "backupId": "ocid1.dbbackup.oc1...",
  "backupTDEPassword": "SourceWalletPassword",
  "dbName": "EXACLON",
  "dbUniqueName": "EXACLON_PRD",
  "sidPrefix": "EXACL",
  "pluggableDatabases": ["PDB1", "PDB2"],
  "dbHomeId": "ocid1.dbhome.oc1...",
  "storageSizeDetails": {
    "dataStorageSizeInGBs": 256,
    "recoStorageSizeInGBs": 512
  },
  "sourceEncryptionKeyLocationDetails": {
    "providerType": "AWS|AZURE|GCP|EXTERNAL",
    "awsEncryptionKeyId": "string",
    "hsmPassword": "string"
  }
}

---

2. The VM/BM In-Place Clone: create-from-backup

`

This is for standard Virtual Machine shapes. You must provide the dbSystemId (the OCID of the VM) to tell OCI exactly where to deploy the restored data.

{
  "adminPassword": "NewAdminPassword123#",
  "backupId": "ocid1.dbbackup.oc1...",
  "backupTdePassword": "SourceWalletPassword",
  "dbSystemId": "ocid1.dbsystem.oc1.iad.example_vm_ocid",
  "dbName": "VMCLON",
  "dbUniqueName": "VMCLON_DEV",
  "sidPrefix": "VMCL",
  "kmsKeyId": "ocid1.key.oc1...",
  "dataStorageSizeInGbs": 256,
  "recoStorageSizeInGbs": 512,
  "databaseSoftwareImageId": "ocid1.dbsoftwareimage.oc1...",
  "isUnifiedAuditingEnabled": true,
  "waitForState": ["AVAILABLE"],
  "maxWaitSeconds": 3600
}

---

3. Provisioning New Infra: create with --source

This is the "All-In-One" command. It creates the VM Cluster or DB System infrastructure from scratch. Because of this, it requires networking IDs (VCN/Subnet) and hardware shapes.

{
  "source": "DB_BACKUP",
  "backupId": "ocid1.dbbackup.oc1...",
  "tdeWalletPassword": "SourceWalletPassword",
  "compartmentId": "ocid1.compartment.oc1...",
  "subnetId": "ocid1.subnet.oc1...",
  "vmClusterId": "ocid1.vmcluster.oc1...",
  "dbSystemId": "ocid1.dbsystem.oc1...",
  "dbHomeId": "ocid1.dbhome.oc1...",
  "dbName": "NEWDB",
  "dbUniqueName": "NEWDB_U",
  "shape": "VM.Standard.E4.Flex",
  "vaultId": "ocid1.vault.oc1...",
  "kmsKeyId": "ocid1.key.oc1...",
  "dbWorkload": "OLTP",
  "autoBackupEnabled": true,
  "waitForState": ["AVAILABLE"]
}

---

Key Identification Checklist:

• Exadata: You must have the --db-home-id of an existing home on the rack.
• VM In-Place: You need the --db-system-id of the running VM instance.
• Identity: Every command requires a dbName (8 chars max) and dbUniqueName. For automation, use the sidPrefix to prevent instance ID collisions.

---

---

Example from my tenancy

This example shows the command I am using in my tenancy to clone a database

{
  oci db database create \
  --config-file          /home/opc/clone/config \		#--> My OCI authentication config file
  --profile              DEFAULT \				#--> Entry in the config file to use credentials for		
  --region               us-phoenix-1 \				#--> Region I am connecting to execute (source region)
  --source               DB_BACKUP \				#--> Source for the new database is a DB_BACKUP
  --db-home-id           ocid1.dbhome.{...} \			#--> Target home OCID to create new DB
  --vm-cluster-id        ocid1.cloudvmcluster.{...} \		#--> Target VM OCID to create the new DB in
  --admin-password       "$_ADMIN_PW" \				#--> Target DB admin password when creating
  --from-json            file:///{file location}/xx.json	#--> JSON input file 


}

Example from my tenancy (cont)

This is the contents of the .json input file

{
  "source": "DB_BACKUP",				#--> Source is a DB_BACKUP
  "dbHomeId": "ocid1.dbhome.{...}",			#--> Target DB Home OCID
  "database": {
    "backupId": "ocid1.dbbackup.{...}",		        #--> Backup OCID to create database from
    "dbName": "BGRENNC",				#--> New DB name
    "dbUniqueName": "bgrennc_clone",		        #--> New DB Unique name
    "adminPassword": "dd",				#--> New DB Admin password (new TDE password will be the same)
    "backupTDEPassword": "dd",				#--> Original TDE wallet password
    "dbBackupConfig": {
      "autoBackupEnabled": true,			#--> Configure automatic backups
      "recoveryWindowInDays": 30			#--> Set recovery window for new backups
    },
    "definedTags": {
      "Oracle-Tags": {
        "CostType": "Shared"
      }
    }
  }
}

---

Mastering TDE & Key Management

One of the biggest hurdles in database cloning is handling the Transparent Data Encryption (TDE) layer. If your source backup was encrypted using a key from a different cloud provider or a local HSM, you must tell OCI how to decrypt it during the restore process.

1. Cross-Cloud & External Key Providers

When using the create-database-from-backup command (Exadata), you use the sourceEncryptionKeyLocationDetails parameter. This is a JSON object where you must specify the providerType and the corresponding Key OCID or ID from the source provider.

Provider Type	Parameter Required	Description
AWS	awsEncryptionKeyId	The ARN of the AWS KMS key used on the source.
AZURE	azureEncryptionKeyId	The Azure Key Vault key URI.
GCP	googleCloudProviderEncryptionKeyId	The fully qualified resource name of the GCP KMS key.
EXTERNAL	hsmPassword	Used for backups protected by an on-premises Hardware Security Module.

2. Native OCI Vault Integration

For native OCI restores, you have two choices: use the standard Oracle-managed keys (default) or use your own keys via OCI Vault (KMS). If you want to use your own keys, you must provide the kmsKeyId and, in some cases, the vaultId.

• kmsKeyId: The OCID of the Master Encryption Key in the OCI Vault.
• kmsKeyVersionId: (Optional) Use this if you need to pin the restore to a specific version of your key.
• vaultId: Required by the create command to identify which Vault the key resides in.

Important Security Note: If you are restoring a database into a different compartment or tenancy than the source, your Dynamic Group for the target DB System must have READ and USE permissions for the Vault and Key. Without these IAM policies, the restore will fail immediately with a "Not Authorized" error.

By correctly mapping these key parameters, you ensure that your data remains encrypted and compliant throughout its entire lifecycle, even as it moves across cloud boundaries.

Automating with Infrastructure as Code (Terraform)

While the CLI is great for one-off tasks, most of my customers eventually want to bake these clones into their CI/CD pipelines. In Terraform, we use the oci_database_database resource. The "magic" happens in the source attribute and the database_details block.

resource "oci_database_database" "cloned_db" {
    # This maps to the --source flag in the CLI
    source = "DB_BACKUP"

    database {
        admin_password      = var.database_admin_password
        db_name             = "CLONEDB"
        db_unique_name      = "CLONEDB_IAD"
        character_set       = "AL32UTF8"
        ncharacter_set      = "AL16UTF16"
        db_workload         = "OLTP"
        
        # TDE Management
        tde_wallet_password = var.source_tde_password
        kms_key_id          = var.target_vault_key_ocid
    }

    # Target Infrastructure IDs
    db_home_id   = var.target_db_home_ocid
    database_id  = var.source_database_backup_ocid

    # Best Practice: Ignore password changes after initial provision
    lifecycle {
        ignore_changes = [database[0].admin_password]
    }
}

Terraform Pro-Tip: Always use the ignore_changes lifecycle hook for the admin_password. Once the database is restored, security policies often require a password rotation. Without this hook, Terraform will try to revert the password to the plain-text value in your .tfvars every time you run an update!

Autonomous Recovery Service Live Lab available

One of the latest additions to Oracle's Live Labs is the Autonomous Recovery Service. This lab  allow you to understand how to utilize the Autonomous Recovery Service Service for backing up your Oracle database in the cloud, even in a multicloud environment.

If you haven't used it,  Live Labs is Oracle's free, hands-on platform which allows you to go though a workshop or lab to learn more about Oracle's products.

Start Here <-------- Link to this lab

The nice thing about this lab is that you can utilize Oracle's sandbox to learn about the Autonomous Recovery Service (RCV) without the requirement of accessing your OCI/Multicloud tenancy.

Also, the features that are demonstrated in this lab are the same regardless of using the Autonomous Recovery Service in OCI, or in a multcloud environment.

NOTE:

Keep in mind that it does take time to configure your lab for you to use since the provisioning process performs an initial backup.  In my case it took about 60 minutes. You can view the status of building your lab environment on the "My Reservations" page to follow the progress.  Once completed, this makes the environment immediately available once the lab environment is configured.

Setup:

Once your tenancy is configured for the lab you need to log in using the supplied credentials, and change the log in. Be sure to follow the directions and screenshots in the setup portion of the lab before beginning.

Also be sure to note the region and compartment that you will be using, and change the region after logging into the tenancy to the correct region.

Lab 1: Onboarding a database

One you log into the tenancy and region, you can now go through the steps to configure a database to use the recovery service.

NOTE: The lab uses the "Base DB service" for the demo but the steps would be the same regardless of the Oracle Database server utilized or the location (OCI, AWS, GCP, Azure, etc.).

In this section you will 

Create a protection policy - There are default protection policies policies you can use, but most customers chose to create their own for the following reason.

• You can chose the exact retention period between 14 and 95 days. Since the service is incremental forever, backup usage is not dependent on a weekly full backup.
• You can chose the backup location if using multicloud. The default is OCI, and you need to create a protection policy if you want to change the location from the default.
• You can configure a retention lock. Setting a retention lock is only available when creating your own protection policy.

Configure backups for the existing database - In this section you will view the backup configuration for the database.  When the lab environment was provisioned backups were configured, and in this step you will change the protection policy and enable real-time data protection.

Once the configuration changes are saved, you will monitor the update progress.

Lastly you will view the backup information for this database.

Lab 2: Perform point-in-time restores

The next section of the lab will walk through a point-in-time restore.

You will be guided through connecting to the Database directly through "Cloud Shell" and in cloud shell you will

• Create new table and insert data into it.
• Determine the current SCN at this point (with the new table).
• Delete the table
• Abort the database (demonstrating real-time data protection)
• Delete the database files
• Restore the database to the SCN in the second step

This does take a bit and you are encouraged to continue to lab 3 while this occurs.

Lab 3: Create an on-demand backup

This lab walks you through the process to dynamically create an on-demand.

On-demand backups can be either

1. Kept for the current retention period. This is useful when upgrading, or rolling out a new release and you want to create a known restore point. This type of backup is stored in the recovery service and will age out with the retention period.
2. Long-Term backup retention period. This type of backup goes to Oracle managed infrequent object storage, and you specify how long the backups are kept for. 

Lab 4: Monitor & Create Alarms

This section of lab walks you through two additional features that are available with the Autonomous Recovery Service.

Observability - In this section of the lab you explore the metrics that available to view.  The lab demonstrates viewing the data loss exposure in either a chart or table

Alarms - This section shows you how to create an alarm that will sent out an alert on data loss exposure (for example).

Summary:

This lab is a great way to learn more about the Autonomous Recovery Service by going through the features in Oracle's tenancy.