Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add note about non-destrutive restore #4885

Closed
wants to merge 1 commit into from
Closed

Add note about non-destrutive restore #4885

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions site/content/docs/main/how-velero-works.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,8 @@ By default, backup storage locations are created in read-write mode. However, du

You can optionally specify restore hooks to be executed during a restore or after resources are restored. For example, you might need to perform a custom database restore operation before the database application containers start. [More about restore hooks][11].

During a restore, Velero is non-destructive. That means that Velero will never overwrite a pre-existing resource which has the same name as a resource in the backup it is restoring. Similarly, if a persistent volume exists, Velero will not overwrite the data in it. This behavior is by design, so that you don't have to worry about accidentally overwriting your cluster's state when using Velero.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not exactly true for v1.9+

A contributor from redhat recently added an option so that some resources can be overwritten:
#4851 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for bringing this up, I'll close this PR and address this with the changes in PR #4928


## Backup workflow

When you run `velero backup create test-backup`:
Expand Down
4 changes: 2 additions & 2 deletions site/content/docs/main/restore-reference.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,9 +40,9 @@ Available Commands:

**Auto assigned** NodePorts **deleted** by default and Services get new **auto assigned** nodePorts after restore.

**Explicitly specified** NodePorts auto detected using **`last-applied-config`** annotation and **preserved** after restore. NodePorts can be explicitly specified as .spec.ports[*].nodePort field on Service definition.
**Explicitly specified** NodePorts auto detected using **`last-applied-config`** annotation and **preserved** after restore. NodePorts can be explicitly specified as `.spec.ports[*].nodePort` field on Service definition.

#### Always Preserve NodePorts
### Always Preserve NodePorts

It is not always possible to set nodePorts explicitly on some big clusters because of operation complexity. Official Kubernetes documents states that preventing port collisions is responsibility of the user when explicitly specifying nodePorts:

Expand Down