---
# System prepended metadata

title: Velero 1.15/1.16 -> OADP-1.5 updates to ensure coverage

---

# Velero 1.15/1.16 -> OADP-1.5 updates to ensure coverage

https://github.com/vmware-tanzu/velero/releases


## Velero 1.15

####  Data mover micro service ( no user facing changes )
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.

#### 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/.
  - POC: Michal Pyrc
  - https://issues.redhat.com/browse/OADP-5780
  - https://issues.redhat.com/browse/OADP-5832

#### 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/.
  - POC: Michal Pyrc
  - https://issues.redhat.com/browse/OADP-5780
  - https://issues.redhat.com/browse/OADP-5832

#### 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/.
  - POC: Michal Pyrc


## Velero 1.16

#### 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 #8334.
  - POC: Scott Seago
  
#### 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 (#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 (#8242).  

  - POC: Scott, Shubham or Tiger

