vmware-tanzu
/
velero
mirror of https://github.com/vmware-tanzu/velero.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #4911 from a-mccarthy/fixes-1919 

Add note about restoring when resource scaled to 0
pull/4936/head
qiuming 2022-05-25 10:05:50 +08:00 committed by GitHub
parent a79c1a5877 8f31bff1b5
commit dfca4dba15
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
site/content/docs/main/restic.md
View File

@ -251,7 +251,7 @@ Instructions to back up using this approach are as follows:
### Using opt-in pod volume backup
Velero, by default, uses this approach to discover pod volumes that need to be backed up using Restic, where every pod containing a volume to be backed up using Restic must be annotated with the volume's name.
Velero, by default, uses this approach to discover pod volumes that need to be backed up using Restic. Every pod containing a volume to be backed up using Restic must be annotated with the volume's name using the `backup.velero.io/backup-volumes` annotation.
Instructions to back up using this approach are as follows:
@ -527,6 +527,8 @@ within each restored volume, under `.velero`, whose name is the UID of the Veler
1. Once all such files are found, the init container's process terminates successfully and the pod moves
on to running other init containers/the main containers.
Velero won't restore a resource if a that resource is scaled to 0 and already exists in the cluster. If Velero restored the requested pods in this scenario, the Kubernetes reconciliation loops that manage resources would delete the running pods because its scaled to be 0. Velero will be able to restore once the resources is scaled up, and the pods are created and remain running.
## 3rd party controllers
### Monitor backup annotation