mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-22 15:11:07 +02:00
0660ea6fac
* Update README Let contributors know that docs will now be located in UDR * Add comments to each mdx doc Comment has been added to all mdx docs that are not partials * chore: added changelog changelog check failure * wip: removed changelog * Fix content errors * Doc spacing * Update website/content/docs/deploy/kubernetes/vso/helm.mdx Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com> --------- Co-authored-by: jonathanfrappier <92055993+jonathanfrappier@users.noreply.github.com> Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
112 lines
4.9 KiB
Plaintext
112 lines
4.9 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Upgrade replicated Vault deployments
|
|
description: >-
|
|
Upgrade instructions for replicated Vault deployments
|
|
---
|
|
|
|
> [!IMPORTANT]
|
|
> **Documentation Update:** Product documentation, which were located in this repository under `/website`, are now located in [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs), colocated with all other product documentation. Contributions to this content should be done in the `web-unified-docs` repo, and not this one. Changes made to `/website` content in this repo will not be reflected on the developer.hashicorp.com website.
|
|
|
|
# Upgrade replicated Vault deployments
|
|
|
|
Upgrade your replicated Vault deployment.
|
|
|
|
## HA installations
|
|
|
|
The recommended upgrade procedure depends on the version of Vault you're currently on and the storage backend of Vault. If you're currently running on Vault 1.11 or later with Integrated Storage and you have Autopilot enabled, you should let Autopilot do the upgrade for you, as that's easier and
|
|
less prone to human error. Please refer to our [automated
|
|
upgrades](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrades) documentation for information on this feature and our
|
|
[Automate Upgrades with Vault
|
|
Enterprise](/vault/tutorials/raft/raft-upgrade-automation)
|
|
tutorial for more details.
|
|
|
|
<Note>
|
|
|
|
If you:
|
|
|
|
- run Vault v1.10.x or earlier
|
|
- opt-out of the Autopilot automated upgrade features when running Vault v1.11.x or later with integrated storage
|
|
- run Vault with external backend storage
|
|
|
|
Refer to our HA upgrade guide for
|
|
[Pre-1.11 Vault deployments or deployments without autopilot upgrade automation](/vault/docs/v1.13.x/upgrading/vault-ha-upgrade).
|
|
The pre-1.11 upgrade procedure also applies when upgrading Vault from pre 1.11 to post 1.11.
|
|
|
|
</Note>
|
|
|
|
## Enterprise replication installations
|
|
|
|
<Note>
|
|
|
|
Prior to any upgrade, be sure to also read and follow any instructions in the
|
|
version-specific upgrade notes which are found in the navigation menu for this
|
|
documentation.
|
|
|
|
</Note>
|
|
|
|
Upgrading Vault Enterprise clusters which participate in [Enterprise
|
|
Replication](/vault/docs/enterprise/replication) requires the following basic
|
|
order of operations:
|
|
|
|
- **Upgrade the replication secondary instances first** using appropriate
|
|
guidance from the previous sections
|
|
- Verify functionality of each secondary instance after upgrading
|
|
- When satisfied with functionality of upgraded secondary instances, upgrade
|
|
the primary instance
|
|
|
|
<Note>
|
|
|
|
It is not safe to replicate from a newer version of Vault to an older version.
|
|
When upgrading replicated clusters, ensure that upstream clusters are always on
|
|
older versions of Vault than downstream clusters.
|
|
|
|
</Note>
|
|
|
|
Here is an example of upgrading four Vault replicated Vault clusters:
|
|
|
|
|
|
|
|
In the above scenario, the ideal upgrade procedure would be as follows,
|
|
verifying functionality after each cluster upgrade.
|
|
|
|
1. Upgrade Clusters B and D. These clusters have no downstream clusters, so they
|
|
should be upgraded first, but the ordering of B vs D does not matter.
|
|
2. Upgrade Cluster C, which now has an upgraded downstream cluster (Cluster D).
|
|
Because Cluster C is a cluster, it should also use the HA upgrade process.
|
|
3. Finally, upgrade Cluster A. All clusters downstream of A will already be
|
|
upgraded. It should be upgraded last, as it is a Performance Primary and a DR
|
|
Primary.
|
|
|
|
|
|
## Other stuff
|
|
|
|
!> **Important:** Always back up your data before upgrading! Vault does not
|
|
make backward-compatibility guarantees for its data store. Simply replacing the
|
|
newly-installed Vault binary with the previous version will not cleanly
|
|
downgrade Vault, as upgrades may perform changes to the underlying data
|
|
structure that make the data incompatible with a downgrade. If you need to roll
|
|
back to a previous version of Vault, you should roll back your data store as
|
|
well.
|
|
|
|
Vault upgrades are designed such that large jumps (ie 1.3.10 -> 1.7.x) are
|
|
supported. The upgrade notes for each intervening version must be reviewed. The
|
|
upgrade notes may describe additional steps or configuration to update before,
|
|
during, or after the upgrade.
|
|
|
|
We also recommend you consult the
|
|
[deprecation notices](/vault/docs/updates/deprecation). The notice page includes
|
|
a comprehensive list of deprecated features and the Vault versions where
|
|
the feature was removed or is scheduled to be removed.
|
|
|
|
|
|
## Testing the upgrade
|
|
|
|
It's always a good idea to try to ensure that the upgrade will be successful in
|
|
your environment. The ideal way to do this is to take a snapshot of your data
|
|
and load it into a test cluster. However, if you are issuing secrets to third
|
|
party resources (cloud credentials, database credentials, etc.) ensure that you
|
|
do not allow external network connectivity during testing, in case credentials
|
|
expire. This prevents the test cluster from trying to revoke these resources
|
|
along with the non-test cluster.
|