From dbc3ad7453bbcd9ab86de8a3f980fafb838cd128 Mon Sep 17 00:00:00 2001 From: Xun Jiang Date: Tue, 10 Oct 2023 20:29:29 +0800 Subject: [PATCH 1/2] Update the Velero chocolatey package release procedure. Signed-off-by: Xun Jiang --- site/content/docs/main/release-instructions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/content/docs/main/release-instructions.md b/site/content/docs/main/release-instructions.md index 014653979..5ed47e3c4 100644 --- a/site/content/docs/main/release-instructions.md +++ b/site/content/docs/main/release-instructions.md @@ -131,7 +131,7 @@ These are the steps to update the Velero Homebrew version. - If you don't already have one, create a [GitHub access token for Homebrew](https://github.com/settings/tokens/new?scopes=gist,public_repo&description=Homebrew) - Run `export HOMEBREW_GITHUB_API_TOKEN=your_token_here` on your command line to make sure that `brew` can work on GitHub on your behalf. - Run `hack/release-tools/brew-update.sh`. This script will download the necessary files, do the checks, and invoke the brew helper to submit the PR, which will open in your browser. -- Update Windows Chocolatey version. From a Windows computer, follow the step-by-step instructions to [create the Windows Chocolatey package for Velero CLI](https://github.com/adamrushuk/velero-choco/blob/main/README.md) +- Update Windows Chocolatey version. From a Windows computer, follow the step-by-step instructions to [create the Windows Chocolatey package for Velero CLI](https://github.com/adamrushuk/velero-choco/blob/main/README.md). Please update the `tools\chocolateyinstall.ps1` file content according to [the existing Velero chocolatey package install script file](https://community.chocolatey.org/packages/velero#files). The current Velero chocolatey package maintainer is [Adam Rush](https://github.com/adamrushuk). It's possible others don't have permission to upload the new version. If so, please contact [Adam Rush](https://github.com/adamrushuk) for help. ## Plugins From 79e176086cf3683273982eef57270dabffa65cd7 Mon Sep 17 00:00:00 2001 From: Xun Jiang Date: Tue, 10 Oct 2023 21:04:46 +0800 Subject: [PATCH 2/2] Add some configurations to avoid ArgoCD pruning backups generated from schedule. Signed-off-by: Xun Jiang --- site/content/docs/main/backup-reference.md | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/site/content/docs/main/backup-reference.md b/site/content/docs/main/backup-reference.md index 3d54cfb57..53837b085 100644 --- a/site/content/docs/main/backup-reference.md +++ b/site/content/docs/main/backup-reference.md @@ -76,6 +76,32 @@ Please do notice there is also side effect that may not be expected. Because sch If there is possibility the schedule will be disable to not create backup anymore, and the created backups are still useful. Please do not enable this option. For detail, please reference to [Backups created by a schedule with useOwnerReferenceInBackup set do not get synced properly](https://github.com/vmware-tanzu/velero/issues/4093). +Some GitOps tools have configurations to avoid pruning the day 2 backups generated from the schedule. +For example, the ArgoCD has two ways to do that: +* Add annotations to schedule. This method makes ArgoCD ignore the schedule from syncing, so the generated backups are ignored too, but it has a side effect. When deleting the schedule from the GitOps manifest, the schedule can not be deleted. User needs to do it manually. +``` yaml + annotations: + argocd.argoproj.io/compare-options: IgnoreExtraneous + argocd.argoproj.io/sync-options: Delete=false,Prune=false +``` +* If ArgoCD is deployed by ArgoCD-Operator, there is another option: [resourceExclusions](https://argocd-operator.readthedocs.io/en/latest/reference/argocd/#resource-exclusions-example). This is an example, which means ArgoCD operator should ignore `Backup` and `Restore` in `velero.io` group in the `velero` namespace for all managed k8s cluster. +``` yaml +apiVersion: argoproj.io/v1alpha1 +kind: ArgoCD +metadata: + name: velero-argocd + namespace: velero +spec: + resourceExclusions: | + - apiGroups: + - velero.io + kinds: + - Backup + - Restore + clusters: + - "*" +``` + #### Cannot support backup data immutability Starting from 1.11, Velero's backups may not work as expected when the target object storage has some kind of an "immutability" option configured. These options are known by different names (see links below for some examples). The main reason is that Velero first saves the state of a backup as Finalizing and then checks whether there are any async operations in progress. If there are, it needs to wait for all of them to be finished before moving the backup state to Complete. If there are no async operations, the state is moved to Complete right away. In either case, Velero needs to modify the metadata in object storage and that will not be possible if some kind of immutability is configured on the object storage.