Backup and restore operations

Backup standard procedure

Note

On HCP Vault, snapshot functionality is managed by the HCP control plane. On starter tier and above clusters HashiCorp performs automated daily snapshots, with the option for a customer-initiated on-demand snapshot. See HCP Vault Operations Tasks.

The objective of this section is to provide a set of standard operating procedures (SOP) for backing up a Vault cluster. It protects your Vault cluster against data corruption or sabotage of which disaster recovery replication might not be able to protect against.

Prerequisites

The following prerequisite steps and knowledge are required in order to backup a Vault cluster. All of the following are required to understand or carry out before attempting to take a backup or restore of Vault.

Working knowledge of Vault: Some working knowledge of Vault is required in order to follow these SOPs.
Vault cluster configuration as defined in our Vault with Integrated Storage Reference Architecture(opens in new tab).
Vault is initialized: This SOP assumes you have already initialized Vault, keyholders are available with access to the unseal keys for each, that you have access to tokens with sufficient privileges for both clusters and encrypted data is stored in the storage backend.

Automated backup procedure for Vault with disaster recovery replication enabled

Enable automated snapshots on the primary cluster with the following command, following the instructions on the Raft Integrated Storage Documentation(opens in new tab) and using the options specified on the API Documentation(opens in new tab).

vault write sys/storage/raft/snapshot-auto/config/[:name] [options]

Restoring a Vault Enterprise cluster

The objective of this section is to provide a set of standard operating procedures for restoring a Vault cluster from a snapshot.

Note

These procedures specifically apply to Vault clusters that use the integrated storage backend.

While typically you would rely on your DR secondary cluster to protect against data loss, there are cases that disaster recovery replication cannot safeguard against, such as data corruption or malicious data manipulation. In these cases, snapshots are the only source of data you will be able to trust when attempting to restore service.

Restore procedure for Vault with disaster recovery replication enabled

Prepare and initialize the new restored Vault cluster. Initialize the cluster, then log in with the new root token that was generated during initialization. Note that these keys and tokens are only temporary; the original unseal keys will be needed following restore.
Copy the snapshot file onto the new cluster. Begin the snapshot restore with the following command.
```
# Replace <backup.snap> with the filename of your snapshot file
vault operator raft snapshot restore -force <backup.snap>
```
Because the snapshot you are restoring is from a different cluster, the unseal keys of the new cluster will not be consistent with the snapshot data. In cases like this, you must specify the -force flag for the snapshot restore to succeed.
Caution: you can safely use -force when restoring a snapshot from a system using Shamir seal. After the restore, the original storage entry for the root key will be available, allowing the original cluster's unseal keys to decrypt it. However, with autounseal, it is crucial to use the same seal configuration for the new cluster as the one used for the cluster being restored. If not, data decryption will not be possible after the restore, and using -force will disable a valuable safeguard.
Once the snapshot restore is complete, unseal the Vault cluster again using the following command.
```
vault operator unseal <unseal_key>
```