docs: adding a storage concepts page#9155
Conversation
It very briefly covers some considerations for taking backups.
mladlow
requested review from
briankassouf,
calvn,
chrishoffman,
kalafut,
ncabatoff and
vishalnayak
Co-authored-by: Calvin Leung Huang <cleung2010@gmail.com> Co-authored-by: Jim Kalafut <jkalafut@hashicorp.com>
devops-rob
left a comment
devops-rob
left a comment
There was a problem hiding this comment.
This looks good to me. I think adding some clarity around the disk back ups for the underlying server is the only thing we need to address but all in all it's useful for practitioners. Good work @mladlow
|
|
||
| **If your storage backend does not support atomic snapshots, we recommend only taking offline backups.** | ||
|
|
||
| We recommend taking backups **before**, but not during, write operations to the `/sys` API |
There was a problem hiding this comment.
Do we want to give any explanation for why we recommend this? e.g. "Even with atomic snapshots, certain Vault operations may consist of multiple writes, and a snapshot taken in the middle of them may result in an inconsistent state and thus a less useful backup."
There was a problem hiding this comment.
I followed up with Nick and will follow up with Mark, but the short answer is no. Feel free to reach out to me for further discussion.
There was a problem hiding this comment.
This section may fit better in the "Why take backups" section.
There was a problem hiding this comment.
I think understanding when to take a backup is more of a "how do I" and less of a "should I" kind of thing - could you elaborate on the connection to the "should I" section?
There was a problem hiding this comment.
I more read it as you "should" take a backup before doing system changing operations. Which i think is more useful than saying don't take a snapshot during these operations.
| ### The Big Question - Why Take Backups? | ||
|
|
||
| It's important to consider the question of "why take a backup" while developing your ongoing | ||
| backup strategy. |
There was a problem hiding this comment.
This section mostly talks about when not to use backups, should we add a bit more around when backups are useful? i.e. before an upgrade or major change to the cluster, to combat accidental data deletions, etc?
There was a problem hiding this comment.
@briankassouf I moved some things around - could you re-read the "Why take Backups" section and see what you think?
Added HashiConf talk link.
vishalnayak
left a comment
vishalnayak
left a comment
There was a problem hiding this comment.
This is good information to go into the docs!
|
|
||
| ## Supported Storage Backends | ||
|
|
||
| For enterprise customers, HashiCorp provides official support for Consul and |
There was a problem hiding this comment.
Do we want to remove "For enterprise customers" here?
There was a problem hiding this comment.
I don't think so? I think you have to be paying us to have support?
There was a problem hiding this comment.
My thought was that if support encompasses fixing bugs reported in the open and reviewing community PRs for Consul and Raft storage, it is free for non-enterprise folks.
| 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 |
There was a problem hiding this comment.
We may want to reword this to keep people from thinking that it is sometimes possible to downgrade storage. Some ideas: "downgrading Vault storage is not recommended", or "not supported"?
Co-authored-by: Vishal Nayak <vishalnayak@users.noreply.github.com>
* Adding a storage concepts page It very briefly covers some considerations for taking backups. * Apply suggestions from code review Co-authored-by: Calvin Leung Huang <cleung2010@gmail.com> Co-authored-by: Jim Kalafut <jkalafut@hashicorp.com> * Updated with some additional comments * Attempt to further clarify sensitivity * Update storage.mdx * More on "Why backup?" Added HashiConf talk link. * Update website/content/docs/concepts/storage.mdx Co-authored-by: Vishal Nayak <vishalnayak@users.noreply.github.com> Co-authored-by: Calvin Leung Huang <cleung2010@gmail.com> Co-authored-by: Jim Kalafut <jkalafut@hashicorp.com> Co-authored-by: Vishal Nayak <vishalnayak@users.noreply.github.com>
Co-authored-by: claire bontempo <68122737+hellobontempo@users.noreply.github.com>
9 participants
This new concepts page very briefly covers some considerations for taking backups.
I have a google doc containing the same content. It's had some review. I'm happy to have a split of conversation here and in the doc, if people would prefer to look at the doc.