Backing Up Vaults and Keys

This topic describes how to preserve virtual private vaults and encryption keys. At this time, the only type of vaults you can back up are virtual private vaults.

You might create backups to store in a bucket or offline, outside of Oracle Cloud Infrastructure. You might want to back up a vault or encryption key before deleting either if you don't need them now, but think you might need to use the key for decryption later, for example. Deleting a vault and key otherwise means losing the ability to decrypt any resource or data that the key was used to encrypt. Restoring a key lets you resume using a resource that was previously encrypted by the key.

You can restore a backup in any region within the realm, making it possible to access encrypted resources even in disaster recovery scenarios where the region of the backed up resource is no longer available.

Note

By default, a key backup includes metadata about the vault it's associated with. A vault backup might optionally include key metadata, but you cannot back up secrets, whether independently or as part of a vault backup. You can only back up and restore keys and virtual private vaults.

For information about creating and managing the use of keys, see Managing Keys. For information about what you can do with vaults where you store keys and secrets, see Managing Vaults. For information about creating and managing the use of secrets, see Managing Secrets.

How It Works

Keys are always associated with the vault where you created them. This relationship persists even as the key is backed up and restored. As a result, restoring a key always requires you to already have the vault associated with the key. You also need the vault because the vault hosts the management and cryptographic endpoints against which you manage and use the key. This might mean that you need to first restore the vault, and then restore the key, if both were backed up and subsequently deleted.

You back up a vault or key by exporting identifying information about the vault or key and what it contains. (The service encrypts the backups, and only the service can restore them.) Vault backups can optionally include keys, assuming the vault has keys and the keys are in a supported lifecycle state when you perform the backup. You can only back up active, enabled, or disabled keys. Backups exclude keys that are deleted or in a transitional state (for example, "Creating" or "Pending Deletion"). Key backups always include vault metadata, in addition to key metadata. Having vault metadata makes it possible to restore the key at all. You can only back up active vaults.

You can back up only one vault or one key at a time. (The exception is when you backup keys as part of a vault backup.) When you perform a key backup, the file includes all associated key versions in an enabled state. Backups exclude key versions in a deleted or pending deletion state.

Backup operations require you to specify where to download the backup. Downloads can be stored in a new or existing Object Storage bucket or a temporary URL that's created specifically for pre-authenticated requests. For more information about pre-authenticated requests, see Using Pre-Authenticated Requests. Backups must be stored in buckets in the same region, but you can copy the backup to a different region by using Object Storage.

Backup and restore operations generate work requests to help you track their progress.

You restore a vault or key by importing the backup from storage to where you want it, as long as you restore the vault to the same tenancy and compartment where you originally created the backup. The key also can only be restored to its original tenancy and compartment, which might be a different compartment from the vault. You can, however, restore vaults and keys to a different region if your tenancy spans multiple regions.

You can restore a vault or a key individually. If you included keys in a vault backup, then restoring the vault restores all the keys included in the backup. Restoring a key restores all the key versions included in the backup.

You can restore a vault or key even when the vault or key already exists in the region. Also, at any time, you can take a newer backup of a vault or key if you want to capture changes to the vault, such as a new name or tags, or the keys, such as new key versions. Updating an already restored vault or key reflects those changes. Updates from a backup are always additive. This means that updates can only append new information. For example, any new key versions created in a reference vault are added to its restored key when you update the restored key. But, if you delete a key from a reference vault, and then you update a restored vault from a backup of the reference vault, the update does not result in a corresponding key deletion in the restored vault. Similarly, any keys that you create for a restored vault are independent of any keys associated with the reference vault that you created the backup from. You manage them independently, too.

Most other operations are not allowed while a backup or restore operation is in progress. This prevents you from deleting a key while it's being backed up, for example. Prohibited operations include attempts to perform simultaneous backup or restore operations on the same resource.

To make it easier to reuse any policies that you created to allow management and use of vaults and keys, when you restore a vault and key, they maintain the same unique Oracle Cloud Identifier (OCID) if they're restored to the region where they were originally backed up. When you restore a vault or key to a different region, you must review and update policies to correspond to new OCIDs.

When you restore a vault or key, especially a key with a lot of key versions, tenancy service limits do apply.

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be given the required type of access in a policy  written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which compartment  you should work in.

For administrators: for typical policies that give access to vaults, keys, and secrets, see Let security admins manage vaults, keys, and secrets. For more information about permissions or if you need to write more restrictive policies, see Details for the Vault Service.

Depending on where you want to store backups and retrieve them from, you might also need access to an Object Storage bucket. For administrators: for typical policies that gives access to buckets, see Let users write objects to Object Storage buckets and Let users download objects from Object Storage buckets.

If you're new to policies, see Getting Started with Policies and Common Policies.

Using the Console

Note

Only active virtual private vaults and active, enabled, or disabled keys can be exported to a backup.

To back up a vault
To back up a key
To restore a vault
To update a vault from a backup
To restore a key
To update a key from a backup
To view a work request for a backup or restore operation

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use the following operations to back up and restore virtual private vaults and keys: