# Storage

As described on our Architecture page, Vault's storage backend is untrusted storage used purely to keep encrypted information.

### Supported storage backends

Many other options for storage are available with community support for Vault - see our Storage Configuration section for more information.

{% hint style="info" %}
**Choosing a storage backend:** Refer to the integrated storage vs. external storage section of the storage configuration page to help make a decision about which storage backend to use.
{% endhint %}

### Backups

Due to the highly flexible nature of Vault's potential storage configurations, providing exact guidance on backing up Vault is challenging.

When backing up Vault, there are two pieces to consider:

1. Vault's encrypted data in the storage backend
2. Configuration files and management scripts for running the Vault server

There's also a big question - what is the error case you're trying to guard against by saving a backup?

#### The big question - why take backups?

It's important to consider the question of "why take a backup" while developing your ongoing backup and disaster recovery strategy.

Taking a backup is recommended prior to upgrades, as downgrading Vault storage is not always possible. Generally, a backup is recommended any time a major change is planned for a cluster.

More specifically, we recommend taking backups **before**, but not during, write operations to the `/sys` API (excluding the `/sys/leases`, `/sys/namespaces`, `/sys/tools`, `/sys/wrapping`, `/sys/policies`, and `/sys/pprof` endpoints). Some examples of workflows that write to the `/sys` API are upgrades and rekeys. In the future, this guidance may change for the Integrated Storage backend.

Backups *can* also help with accidental data deletions or modifications. In this case, the story can get a little tricky. If you simply recover a backup from 5AM with the correct data, but the current time is 10AM, you will lose data written between 5 and 10AM.

We do not recommend backups as protection against the failure of an individual machine. Vault servers can run in clusters, so to protect against server failure, we recommend running Vault in HA mode. With community features, a Vault cluster can extend across multiple availability zones within a region.

When using Vault in HA Mode, a backup can help guard against the failure of a data center.

Ultimately, backups are not a replacement for running in HA, as you develop a plan for recovering from or guarding against failure, you should consider both backups and HA as critical components of that plan.

#### Backing up vault's persisted data

Backups and restores are ideally performed while Vault is offline. If offline backups are not feasible, we recommend using a storage backend that supports atomic snapshots (such as Consul or Integrated Storage).

{% hint style="info" %}
If your storage backend does not support atomic snapshots, we recommend only taking offline backups.
{% endhint %}

#### Configuration

In addition to backing up Vault's encrypted data via the storage backend, you may also wish to save the server configuration files, any scripts for managing the Vault service, and ensure you can reinstall any user-installed plugins. The location of these files will be specific to your installation of Vault.

{% hint style="info" %}
Although a backup or snapshot of Vault's data from the storage backend is encrypted, some of your configuration may be sensitive (a Vault token for Transit Autounseal or a TLS private key in your configuration, for example). The presence of this information in your backups will mean that they may need to be carefully protected.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.enclaive.cloud/vault/documentation/concepts/storage.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.