• HashiCorp Developer

  • HashiCorp Cloud Platform
  • Terraform
  • Packer
  • Consul
  • Vault
  • Boundary
  • Nomad
  • Waypoint
  • Vagrant
Vault
  • Install
  • Tutorials
  • Documentation
  • API
  • Integrations
  • Try Cloud(opens in new tab)
  • Sign up
Vault Home

Documentation

Skip to main content
  • Documentation
  • What is Vault?
  • Use Cases

  • Browser Support
  • Installing Vault

  • Vault Integration Program
  • Vault Interoperability Matrix
  • Troubleshoot






  • Glossary

    • Overview
    • Replication
    • Automated Integrated Storage Snapshots
    • Automated Upgrades
    • Redundancy Zones
    • Lease Count Quotas
    • Entropy Augmentation
    • Seal Wrap
    • Namespaces
    • Performance Standbys
    • Eventual Consistency
    • Control Groups
    • Managed Keys
    • HCP Vault

  • Resources

  • Tutorial Library
  • Certifications
  • Community Forum
    (opens in new tab)
  • Support
    (opens in new tab)
  • GitHub
    (opens in new tab)
  1. Developer
  2. Vault
  3. Documentation
  4. Vault Enterprise
  5. Automated Integrated Storage Snapshots
  • Vault
  • v1.11.x
  • v1.10.x
  • v1.9.x
  • v1.8.x
  • v1.7.x
  • v1.6.x
  • v1.5.x
  • v1.4.x

»Automated Integrated Storage Snapshots

Note: This feature requires Vault Enterprise

Any production system should include a provision for taking regular backups. Vault Enterprise can be configured to take and store snapshots at a specific interval.

»Configuration

There can be multiple named snapshot configurations, each with their own schedule and storage type. Storage type can either be local (meaning the snapshots will be stored in the same filesystem that the Vault servers see) or a cloud object storage service such as AWS S3.

Local is not usually a good production option. Only the active node will be taking snapshots, but you can't predict which node is going to be active at any point in time, so unless you're using a distributed filesystem you'll be stuck checking each node's filesystem to find the snapshot you want. Moreover backups ought to be stored somewhere with redundancy, and ideally not on the same system they're meant to protect.

Cloud storage types can usually be managed in two ways. The mode supported by all is providing explicit credentials during configuration. In addition, AWS and GCP can be used without specifying credentials, by ensuring that the VMs on which Vault is running have been granted permission to access the specified object store.

»vs Snapshot Agents

Nomad and Consul Enterprise offer the same functionality in a slightly different way. They provide a snapshot agent, which is a standalone program that runs "outside" the cluster but otherwise behaves much the same as Vault's built-in automated snapshot mechanism.

There are various trade-offs to this approach. The main reason Vault doesn't do things this way is that the snapshot agents need something to manage HA. One doesn't want a single point of failure for something as important as backups, which means running multiple snapshot agents, but that requires some way to coordinate among them to ensure that only one is actually taking snapshots at any given time. Consul already has an API for distributed locks, which is one way of doing this. Another option is to use an orchestrator like Kubernetes or Nomad to run the snapshot agent as a batch job. It seemed best not to assume that all Vault Enterprise users would be running Consul or an orchestrator.

»See also

Refer to the API docs for the specifics of how to configure automated snapshots and query their status.

Edit this page on GitHub

On this page

  1. Automated Integrated Storage Snapshots
  2. Configuration
  3. vs Snapshot Agents
  4. See also
Give Feedback(opens in new tab)
  • Certifications
  • System Status
  • Terms of Use
  • Security
  • Privacy
  • Trademark Policy
  • Trade Controls
  • Give Feedback(opens in new tab)