Skip to content

chore(deps): update backup test tools (main) - abandoned #52

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
Open
renovate wants to merge 2 commits into
base: main
Choose a base branch
from
Open

chore(deps): update backup test tools (main) - abandoned #52

renovate wants to merge 2 commits into from

Conversation

@renovate
Copy link

@renovate renovate bot commented Jun 6, 2025

This PR contains the following updates:

Package Update Change
minio/mc minor RELEASE.2025-04-16T18-13-26Z -> RELEASE.2025-05-21T01-59-54Z
minio/minio minor RELEASE.2025-04-22T22-12-26Z -> RELEASE.2025-05-24T17-08-30Z
vmware-tanzu/velero minor v1.12.1 -> v1.16.1

Release Notes

vmware-tanzu/velero (vmware-tanzu/velero)

v1.16.1

Compare Source

v1.16.1

Download

https://github.com/vmware-tanzu/velero/releases/tag/v1.16.1

Container Image

velero/velero:v1.16.1

Documentation

https://velero.io/docs/v1.16/

Upgrading

https://velero.io/docs/v1.16/upgrade-to-1.16/

All Changes

v1.16.0

Compare Source

v1.16

Download

https://github.com/vmware-tanzu/velero/releases/tag/v1.16.0

Container Image

velero/velero:v1.16.0

Documentation

https://velero.io/docs/v1.16/

Upgrading

https://velero.io/docs/v1.16/upgrade-to-1.16/

Highlights
Windows cluster support

In v1.16, Velero supports to run in Windows clusters and backup/restore Windows workloads, either stateful or stateless:

  • Hybrid build and all-in-one image: the build process is enhanced to build an all-in-one image for hybrid CPU architecture and hybrid platform. For more information, check the design https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/multiple-arch-build-with-windows.md
  • Deployment in Windows clusters: Velero node-agent, data mover pods and maintenance jobs now support to run in both linux and Windows nodes
  • Data mover backup/restore Windows workloads: Velero built-in data mover supports Windows workloads throughout its full cycle, i.e., discovery, backup, restore, pre/post hook, etc. It automatically identifies Windows workloads and schedules data mover pods to the right group of nodes

Check the epic issue https://github.com/vmware-tanzu/velero/issues/8289 for more information.

Parallel Item Block backup

v1.16 now supports to back up item blocks in parallel. Specifically, during backup, correlated resources are grouped in item blocks and Velero backup engine creates a thread pool to back up the item blocks in parallel. This significantly improves the backup throughput, especially when there are large scale of resources.
Pre/post hooks also belongs to item blocks, so will also run in parallel along with the item blocks.
Users are allowed to configure the parallelism through the --item-block-worker-count Velero server parameter. If not configured, the default parallelism is 1.

For more information, check issue https://github.com/vmware-tanzu/velero/issues/8334.

Data mover restore enhancement in scalability

In previous releases, for each volume of WaitForFirstConsumer mode, data mover restore is only allowed to happen in the node that the volume is attached. This severely degrades the parallelism and the balance of node resource(CPU, memory, network bandwidth) consumption for data mover restore (https://github.com/vmware-tanzu/velero/issues/8044).

In v1.16, users are allowed to configure data mover restores running and spreading evenly across all nodes in the cluster. The configuration is done through a new flag ignoreDelayBinding in node-agent configuration (https://github.com/vmware-tanzu/velero/issues/8242).

Data mover enhancements in observability

In 1.16, some observability enhancements are added:

The outputs are in the same node-agent log and enabled automatically.

CSI snapshot backup/restore enhancement in usability

In previous releases, a unnecessary VolumeSnapshotContent object is retained for each backup and synced to other clusters sharing the same backup storage location. And during restore, the retained VolumeSnapshotContent is also restored unnecessarily.

In 1.16, the retained VolumeSnapshotContent is removed from the backup, so no unnecessary CSI objects are synced or restored.

For more information, check issue https://github.com/vmware-tanzu/velero/issues/8725.

Backup Repository Maintenance enhancement in resiliency and observability

In v1.16, some enhancements of backup repository maintenance are added to improve the observability and resiliency:

Volume Policy enhancement of filtering volumes by PVC labels

In v1.16, Volume Policy is extended to support filtering volumes by PVC labels. (https://github.com/vmware-tanzu/velero/issues/8256).

Resource Status restore per object

In v1.16, users are allowed to define whether to restore resource status per object through an annotation velero.io/restore-status set on the object. (https://github.com/vmware-tanzu/velero/issues/8204).

Velero Restore Helper binary is merged into Velero image

In v1.16, Velero banaries, i.e., velero, velero-helper and velero-restore-helper, are all included into the single Velero image. (https://github.com/vmware-tanzu/velero/issues/8484).

Runtime and dependencies

Golang runtime: 1.23.7
kopia: 0.19.0

Limitations/Known issues
Limitations of Windows support
  • fs-backup is not supported for Windows workloads and so fs-backup runs only in linux nodes for linux workloads
  • Backup/restore of Security Descriptors and NTFS extended attributes are not supported. As a result, backup/restore of workloads running with non-administrative privileges are not supported.
All Changes

v1.15.2

Compare Source

v1.15.2

Download

https://github.com/vmware-tanzu/velero/releases/tag/v1.15.2

Container Image

velero/velero:v1.15.2

Documentation

https://velero.io/docs/v1.15/

Upgrading

https://velero.io/docs/v1.15/upgrade-to-1.15/

All Changes

v1.15.1

Compare Source

v1.15.1

Download

https://github.com/vmware-tanzu/velero/releases/tag/v1.15.1

Container Image

velero/velero:v1.15.1

Documentation

https://velero.io/docs/v1.15/

Upgrading

https://velero.io/docs/v1.15/upgrade-to-1.15/

All Changes

v1.15.0

Compare Source

v1.15

Download

https://github.com/vmware-tanzu/velero/releases/tag/v1.15.0

Container Image

velero/velero:v1.15.0

Documentation

https://velero.io/docs/v1.15/

Upgrading

https://velero.io/docs/v1.15/upgrade-to-1.15/

Highlights
Data mover micro service

Data transfer activities for CSI Snapshot Data Movement are moved from node-agent pods to dedicate backupPods or restorePods. This brings many benefits such as:

  • This avoids to access volume data through host path, while host path access is privileged and may involve security escalations, which are concerned by users.
  • This enables users to to control resource (i.e., cpu, memory) allocations in a granular manner, e.g., control them per backup/restore of a volume.
  • This enhances the resilience, crash of one data movement activity won't affect others.
  • This prevents unnecessary full backup because of host path changes after workload pods restart.
  • For more information, check the design https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/vgdp-micro-service/vgdp-micro-service.md.
Item Block concepts and ItemBlockAction (IBA) plugin

Item Block concepts are introduced for resource backups to help to achieve multiple thread backups. Specifically, correlated resources are categorized in the same item block and item blocks could be processed concurrently in multiple threads.
ItemBlockAction plugin is introduced to help Velero to categorize resources into item blocks. At present, Velero provides built-in IBAs for pods and PVCs and Velero also supports customized IBAs for any resources.
In v1.15, Velero doesn't support multiple thread process of item blocks though item block concepts and IBA plugins are fully supported. The multiple thread support will be delivered in future releases.
For more information, check the design https://github.com/vmware-tanzu/velero/blob/main/design/backup-performance-improvements.md.

Node selection for repository maintenance job

Repository maintenance are resource consuming tasks, Velero now allows you to configure the nodes to run repository maintenance jobs, so that you can run repository maintenance jobs in idle nodes or avoid them to run in nodes hosting critical workloads.
To support the configuration, a new repository maintenance configuration configMap is introduced.
For more information, check the document https://velero.io/docs/v1.15/repository-maintenance/.

Backup PVC read-only configuration

In 1.15, Velero allows you to configure the data mover backupPods to read-only mount the backupPVCs. In this way, the data mover expose process could be significantly accelerated for some storages (i.e., ceph).
To support the configuration, a new backup PVC configuration configMap is introduced.
For more information, check the document https://velero.io/docs/v1.15/data-movement-backup-pvc-configuration/.

Backup PVC storage class configuration

In 1.15, Velero allows you to configure the storageclass used by the data mover backupPods. In this way, the provision of backupPVCs don't need to adhere to the same pattern as workload PVCs, e.g., for a backupPVC, it only needs one replica, whereas, the a workload PVC may have multiple replicas.
To support the configuration, the same backup PVC configuration configMap is used.
For more information, check the document https://velero.io/docs/v1.15/data-movement-backup-pvc-configuration/.

Backup repository data cache configuration

The backup repository may need to cache data on the client side during various repository operations, i.e., read, write, maintenance, etc. The cache consumes the root file system space of the pod where the repository access happens.
In 1.15, Velero allows you to configure the total size of the cache per repository. In this way, if your pod doesn't have enough space in its root file system, the pod won't be evicted due to running out of ephemeral storage.
To support the configuration, a new backup repository configuration configMap is introduced.
For more information, check the document https://velero.io/docs/v1.15/backup-repository-configuration/.

Performance improvements

In 1.15, several performance related issues/enhancements are included, which makes significant performance improvements in specific scenarios:

Runtime and dependencies

Golang runtime: v1.22.8
kopia: v0.17.0

Limitations/Known issues
Read-only backup PVC may not work on SELinux environments

Due to an issue of Kubernetes upstream, if a volume is mounted as read-only in SELinux environments, the read privilege is not granted to any user, as a result, the data mover backup will fail. On the other hand, the backupPVC must be mounted as read-only in order to accelerate the data mover expose process.
Therefore, a user option is added in the same backup PVC configuration configMap, once the option is enabled, the backupPod container will run as a super privileged container and disable SELinux access control. If you have concern in this super privileged container or you have configured pod security admissions and don't allow super privileged containers, you will not be able to use this read-only backupPVC feature and lose the benefit to accelerate the data mover expose process.

Breaking changes
Deprecation of Restic

Restic path for fs-backup is in deprecation process starting from 1.15. According to Velero deprecation policy, for 1.15, if Restic path is used the backup/restore of fs-backup still creates and succeeds, but you will see warnings in below scenarios:

  • When --uploader-type=restic is used in Velero installation
  • When Restic path is used to create backup/restore of fs-backup
node-agent configuration name is configurable

Previously, a fixed name is searched for node-agent configuration configMap. Now in 1.15, Velero allows you to customize the name of the configMap, on the other hand, the name must be specified by node-agent server parameter node-agent-configmap.

Repository maintenance job configurations in Velero server parameter are moved to repository maintenance job configuration configMap

In 1.15, below Velero server parameters for repository maintenance jobs are moved to the repository maintenance job configuration configMap. While for back compatibility reason, the same Velero sever parameters are preserved as is. But the configMap is recommended and the same values in the configMap take preference if they exist in both places:

--keep-latest-maintenance-jobs
--maintenance-job-cpu-request
--maintenance-job-mem-request
--maintenance-job-cpu-limit
--maintenance-job-mem-limit
Changing PVC selected-node feature is deprecated

In 1.15, the Changing PVC selected-node feature enters deprecation process and will be removed in future releases according to Velero deprecation policy. Usage of this feature for any purpose is not recommended.

All Changes

v1.14.1

Compare Source

v1.14.1

Download

https://github.com/vmware-tanzu/velero/releases/tag/v1.14.1

Container Image

velero/velero:v1.14.1

Documentation

https://velero.io/docs/v1.14/

Upgrading

https://velero.io/docs/v1.14/upgrade-to-1.14/

All Changes

v1.14.0

Compare Source

v1.14

Download

https://github.com/vmware-tanzu/velero/releases/tag/v1.14.0

Container Image

velero/velero:v1.14.0

Documentation

https://velero.io/docs/v1.14/

Upgrading

https://velero.io/docs/v1.14/upgrade-to-1.14/

Highlights
The maintenance work for kopia/restic backup repositories is run in jobs

Since velero started using kopia as the approach for filesystem-level backup/restore, we've noticed an issue when velero connects to the kopia backup repositories and performs maintenance, it sometimes consumes excessive memory that can cause the velero pod to get OOM Killed. To mitigate this issue, the maintenance work will be moved out of velero pod to a separate kubernetes job, and the user will be able to specify the resource request in "velero install".

Volume Policies are extended to support more actions to handle volumes

In an earlier release, a flexible volume policy was introduced to skip certain volumes from a backup. In v1.14 we've made enhancement to this policy to allow the user to set how the volumes should be backed up. The user will be able to set "fs-backup" or "snapshot" as value of “action" in the policy and velero will backup the volumes accordingly. This enhancement allows the user to achieve a fine-grained control like "opt-in/out" without having to update the target workload. For more details please refer to https://velero.io/docs/v1.14/resource-filtering/#supported-volumepolicy-actions

Node Selection for Data Movement Backup

In velero the data movement flow relies on datamover pods, and these pods may take s

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Never, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot requested a review from NiccoloFei as a code owner June 6, 2025 15:15
@renovate renovate bot changed the title chore(deps): update backup test tools (main) chore(deps): update backup test tools (main) - abandoned Jul 10, 2025
@renovate
Copy link
Author

renovate bot commented Jul 10, 2025

Autoclosing Skipped

This PR has been flagged for autoclosing. However, it is being skipped due to the branch being already modified. Please close/delete it manually or report a bug if you think this is in error.

@renovate
Copy link
Author

renovate bot commented Jul 20, 2025

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@NiccoloFei NiccoloFei Awaiting requested review from NiccoloFei NiccoloFei is a code owner

Assignees

No one assigned

Labels

automated do not backport no-issue

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@NiccoloFei