Merge branch 'main' into support-customized-host-os

2026-09-18 22:14:29 +00:00 · 2026-02-09 18:36:55 +08:00
parent 18c32ed29c e159992f48
commit 5121417457
156 changed files with 12007 additions and 116 deletions
@@ -17,6 +17,7 @@ If you're using Velero and want to add your organization to this list,
 <a href="https://www.replicated.com/" border="0" target="_blank"><img alt="replicated.com" src="site/static/img/adopters/replicated-logo-red.svg" height="50"></a>
 <a href="https://cloudcasa.io/" border="0" target="_blank"><img alt="cloudcasa.io" src="site/static/img/adopters/cloudcasa.svg" height="50"></a>
 <a href="https://azure.microsoft.com/" border="0" target="_blank"><img alt="azure.com" src="site/static/img/adopters/azure.svg" height="50"></a>
+<a href="https://www.broadcom.com/" border="0" target="_blank"><img alt="broadcom.com" src="site/static/img/adopters/broadcom.svg" height="50"></a>
 ## Success Stories

 Below is a list of adopters of Velero in **production environments** that have
@@ -68,6 +69,9 @@ Replicated uses the Velero open source project to enable snapshots in [KOTS][101
 **[Microsoft Azure][105]**<br>
 [Azure Backup for AKS][106] is an Azure native, Kubernetes aware, Enterprise ready backup for containerized applications deployed on Azure Kubernetes Service (AKS). AKS Backup utilizes Velero to perform backup and restore operations to protect stateful applications in AKS clusters.<br>

+**[Broadcom][107]**<br>
+[VMware Cloud Foundation][108] (VCF) offers built-in [vSphere Kubernetes Service][109] (VKS),  a Kubernetes runtime that includes a CNCF certified Kubernetes distribution, to deploy and manage containerized workloads. VCF empowers platform engineers with native [Kubernetes multi-cluster management][110] capability for managing Kubernetes (K8s) infrastructure at scale. VCF utilizes Velero for Kubernetes data protection enabling platform engineers to back up and restore containerized workloads manifests & persistent volumes, helping to increase the resiliency of stateful applications in VKS cluster.
+
 ## Adding your organization to the list of Velero Adopters

 If you are using Velero and would like to be included in the list of `Velero Adopters`, add an SVG version of your logo to the `site/static/img/adopters` directory in this repo and submit a [pull request][3] with your change. Name the image file something that reflects your company (e.g., if your company is called Acme, name the image acme.png). See this for an example [PR][4].
@@ -125,3 +129,8 @@ If you would like to add your logo to a future `Adopters of Velero` section on [

 [105]: https://azure.microsoft.com/
 [106]: https://learn.microsoft.com/azure/backup/backup-overview
+
+[107]: https://www.broadcom.com/
+[108]: https://www.vmware.com/products/cloud-infrastructure/vmware-cloud-foundation
+[109]: https://www.vmware.com/products/cloud-infrastructure/vsphere-kubernetes-service
+[110]: https://blogs.vmware.com/cloud-foundation/2025/09/29/empowering-platform-engineers-with-native-kubernetes-multi-cluster-management-in-vmware-cloud-foundation/
@@ -7,11 +7,11 @@
 | Maintainer          | GitHub ID                                                     | Affiliation                                      |
 |---------------------|---------------------------------------------------------------|--------------------------------------------------|
 | Scott Seago         | [sseago](https://github.com/sseago)                           | [OpenShift](https://github.com/openshift)        |
-| Daniel Jiang        | [reasonerjt](https://github.com/reasonerjt)                   | [VMware](https://www.github.com/vmware/)         |
-| Wenkai Yin          | [ywk253100](https://github.com/ywk253100)                     | [VMware](https://www.github.com/vmware/)         |
-| Xun Jiang           | [blackpiglet](https://github.com/blackpiglet)                 | [VMware](https://www.github.com/vmware/)         |
+| Daniel Jiang        | [reasonerjt](https://github.com/reasonerjt)                   | Broadcom                                         |
+| Wenkai Yin          | [ywk253100](https://github.com/ywk253100)                     | Broadcom                                         |
+| Xun Jiang           | [blackpiglet](https://github.com/blackpiglet)                 | Broadcom                                         |
 | Shubham Pampattiwar | [shubham-pampattiwar](https://github.com/shubham-pampattiwar) | [OpenShift](https://github.com/openshift)        |
-| Yonghui Li          | [Lyndon-Li](https://github.com/Lyndon-Li)                     | [VMware](https://www.github.com/vmware/)         |
+| Yonghui Li          | [Lyndon-Li](https://github.com/Lyndon-Li)                     | Broadcom                                         |
 | Anshul Ahuja        | [anshulahuja98](https://github.com/anshulahuja98)             | [Microsoft Azure](https://www.github.com/azure/) |
 | Tiger Kaovilai      | [kaovilai](https://github.com/kaovilai)                       | [OpenShift](https://github.com/openshift)        |

@@ -27,14 +27,3 @@
 * JenTing Hsiao ([jenting](https://github.com/jenting))
 * Dave Smith-Uchida ([dsu-igeek](https://github.com/dsu-igeek))
 * Ming Qiu ([qiuming-best](https://github.com/qiuming-best))
-
-## Velero Contributors & Stakeholders
-
-| Feature Area           |                                         Lead                                         |
-|------------------------|:------------------------------------------------------------------------------------:|
-| Technical Lead         |               Daniel Jiang [reasonerjt](https://github.com/reasonerjt)               |
-| Kubernetes CSI Liaison |                                                                                      |
-| Deployment             |                                                                                      |
-| Community Management   |            Orlin Vasilev [OrlinVasilev](https://github.com/OrlinVasilev)             |
-| Product Management     | Pradeep Kumar Chaturvedi [pradeepkchaturvedi](https://github.com/pradeepkchaturvedi) |
-
@@ -42,13 +42,11 @@ The following is a list of the supported Kubernetes versions for each Velero ver

 | Velero version | Expected Kubernetes version compatibility | Tested on Kubernetes version        |
 |----------------|-------------------------------------------|-------------------------------------|
-| 1.17           | 1.18-latest                               | 1.31.7, 1.32.3, 1.33.1, and 1.34.0          |
+| 1.18           | 1.18-latest                               | 1.33.7, 1.34.1, and 1.35.0          |
+| 1.17           | 1.18-latest                               | 1.31.7, 1.32.3, 1.33.1, and 1.34.0  |
 | 1.16           | 1.18-latest                               | 1.31.4, 1.32.3, and 1.33.0          |
 | 1.15           | 1.18-latest                               | 1.28.8, 1.29.8, 1.30.4 and 1.31.1   |
 | 1.14           | 1.18-latest                               | 1.27.9, 1.28.9, and 1.29.4          |
-| 1.13           | 1.18-latest                               | 1.26.5, 1.27.3, 1.27.8, and 1.28.3  |
-| 1.12           | 1.18-latest                               | 1.25.7, 1.26.5, 1.26.7, and 1.27.3  |
-| 1.11           | 1.18-latest                               | 1.23.10, 1.24.9, 1.25.5, and 1.26.1 |

 Velero supports IPv4, IPv6, and dual stack environments. Support for this was tested against Velero v1.8.

@@ -0,0 +1,109 @@
+## v1.18
+
+### Download
+https://github.com/vmware-tanzu/velero/releases/tag/v1.18.0
+
+### Container Image
+`velero/velero:v1.18.0`
+
+### Documentation
+https://velero.io/docs/v1.18/
+
+### Upgrading
+https://velero.io/docs/v1.18/upgrade-to-1.18/
+
+### Highlights
+#### Concurrent backup
+In v1.18, Velero is capable to process multiple backups concurrently. This is a significant usability improvement, especially for multiple tenants or multiple users case, backups submitted from different users could run their backups simultaneously without interfering with each other.  
+
+Check design https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/concurrent-backup-processing.md for more details.
+
+#### Cache volume for data movers
+In v1.18, Velero allows users to configure cache volumes for data mover pods during restore for CSI snapshot data movement and fs-backup. This brings below benefits:
+- Solve the problem that data mover pods fail to when pod's ephemeral disk is limited
+- Solve the problem that multiple data mover pods fail to run concurrently in one node when the node's ephemeral disk is limited
+- Working together with backup repository's cache limit configuration, cache volume with appropriate size helps to improve the restore throughput
+
+Check design https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/backup-repo-cache-volume.md for more details.
+
+#### Incremental size for data movers
+In v1.18, Velero allows users to observe the incremental size of data movers backups for CSI snapshot data movement and fs-backup, so that users could visually see the data reduction due to incremental backup.
+
+#### Wildcard support for namespaces
+In v1.18, Velero allows to use Glob regular expressions for namespace filters during backup and restore, so that users could filter namespaces in a batch manner.
+
+#### VolumePolicy for PVC phase
+In v1.18, Velero VolumePolicy supports actions by PVC phase, which help users to do special operations for PVCs with a specific phase, e.g., skip PVCs in Pending/Lost status from the backup.  
+
+#### Scalability and Resiliency improvements
+##### Prevent Velero server OOM Kill for large backup repositories
+In v1.18, some backup repository operations are delay executed out of Velero server, so Velero server won't be OOM Killed.
+
+#### Performance improvement for VolumePolicy
+In v1.18, VolumePolicy is enhanced for large number of pods/PVCs so that the performance is significantly improved.
+
+#### Events for data mover pod diagnostic
+In v1.18, events are recorded into data mover pod diagnostic, which allows user to see more information for troubleshooting when the data mover pod fails.
+
+### Runtime and dependencies
+Golang runtime: 1.25.7  
+kopia: 0.22.3
+
+### Limitations/Known issues
+
+### Breaking changes
+#### Deprecation of PVC selected node feature
+According to [Velero deprecation policy](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md#deprecation-policy), PVC selected node feature is deprecated in v1.18. Velero could appropriately handle PVC's selected-node annotation, so users don't need to do anything particularly.
+
+### All Changes
+* Remove backup from running list when backup fails validation (#9498, @sseago)
+* Maintenance Job only uses the first element of the LoadAffinity array (#9494, @blackpiglet)
+* Fix issue #9478, add diagnose info on expose peek fails (#9481, @Lyndon-Li)
+* Add Role, RoleBinding, ClusterRole, and ClusterRoleBinding in restore sequence. (#9474, @blackpiglet)
+* Add maintenance job and data mover pod's labels and annotations setting. (#9452, @blackpiglet)
+* Fix plugin init container names exceeding DNS-1123 limit (#9445, @mpryc)
+* Add PVC-to-Pod cache to improve volume policy performance (#9441, @shubham-pampattiwar)
+* Remove VolumeSnapshotClass from CSI B/R process. (#9431, @blackpiglet)
+* Use hookIndex for recording multiple restore exec hooks. (#9366, @blackpiglet)
+* Sanitize Azure HTTP responses in BSL status messages (#9321, @shubham-pampattiwar)
+* Remove labels associated with previous backups (#9206, @Joeavaikath)
+* Add VolumePolicy support for PVC Phase conditions to allow skipping Pending PVCs (#9166, @claude)
+* feat: Enhance BackupStorageLocation with Secret-based CA certificate support (#9141, @kaovilai)
+* Add `--apply` flag to `install` command, allowing usage of Kubernetes apply to make changes to existing installs (#9132, @mjnagel)
+* Fix issue #9194, add doc for GOMAXPROCS behavior change (#9420, @Lyndon-Li)
+* Apply volume policies to VolumeGroupSnapshot PVC filtering (#9419, @shubham-pampattiwar)
+* Fix issue #9276, add doc for cache volume support (#9418, @Lyndon-Li)
+* Add Prometheus metrics for maintenance jobs (#9414, @shubham-pampattiwar)
+* Fix issue #9400, connect repo first time after creation so that init params could be written (#9407, @Lyndon-Li)
+* Cache volume for PVR (#9397, @Lyndon-Li)
+* Cache volume support for DataDownload (#9391, @Lyndon-Li)
+* don't copy securitycontext from first container if configmap found (#9389, @sseago)
+* Refactor repo provider interface for static configuration (#9379, @Lyndon-Li)
+* Fix issue #9365, prevent fake completion notification due to multiple update of single PVR (#9375, @Lyndon-Li)
+* Add cache volume configuration (#9370, @Lyndon-Li)
+* Track actual resource names for GenerateName in restore status (#9368, @shubham-pampattiwar)
+* Fix managed fields patch for resources using GenerateName (#9367, @shubham-pampattiwar)
+* Support cache volume for generic restore exposer and pod volume exposer (#9362, @Lyndon-Li)
+* Add incrementalSize to DU/PVB for reporting new/changed size (#9357, @sseago)
+* Add snapshotSize for DataDownload, PodVolumeRestore (#9354, @Lyndon-Li)
+* Add cache dir configuration for udmrepo (#9353, @Lyndon-Li)
+* Fix the Job build error when BackupReposiotry name longer than 63. (#9350, @blackpiglet)
+* Add cache configuration to VGDP (#9342, @Lyndon-Li)
+* Fix issue #9332, add bytesDone for cache files (#9333, @Lyndon-Li)
+* Fix typos in documentation (#9329, @T4iFooN-IX)
+* Concurrent backup processing (#9307, @sseago)
+* VerifyJSONConfigs verify every elements in Data. (#9302, @blackpiglet)
+* Fix issue #9267, add events to data mover prepare diagnostic (#9296, @Lyndon-Li)
+* Add option for privileged fs-backup pod (#9295, @sseago)
+* Fix issue #9193, don't connect repo in repo controller (#9291, @Lyndon-Li)
+* Implement concurrency control for cache of native VolumeSnapshotter plugin. (#9281, @0xLeo258)
+* Fix issue #7904, remove the code and doc for PVC node selection (#9269, @Lyndon-Li)
+* Fix schedule controller to prevent backup queue accumulation during extended blocking scenarios by properly handling empty backup phases (#9264, @shubham-pampattiwar)
+* Fix repository maintenance jobs to inherit allowlisted tolerations from Velero deployment (#9256, @shubham-pampattiwar)
+* Implement wildcard namespace pattern expansion for backup namespace includes/excludes. This change adds support for wildcard patterns (*, ?, [abc], {a,b,c}) in namespace includes and excludes during backup operations (#9255, @Joeavaikath)
+* Protect VolumeSnapshot field from race condition during multi-thread backup (#9248, @0xLeo258)
+* Update AzureAD Microsoft Authentication Library to v1.5.0 (#9244, @priyansh17)
+* Get pod list once per namespace in pvc IBA (#9226, @sseago)
+* Fix issue #7725, add design for backup repo cache configuration (#9148, @Lyndon-Li)
+* Fix issue #9229, don't attach backupPVC to the source node (#9233, @Lyndon-Li)
+* feat: Permit specifying annotations for the BackupPVC (#9173, @clementnuss)
@@ -1 +0,0 @@
-Add `--apply` flag to `install` command, allowing usage of Kubernetes apply to make changes to existing installs
@@ -1 +0,0 @@
-feat: Enhance BackupStorageLocation with Secret-based CA certificate support
@@ -1 +0,0 @@
-Fix issue #7725, add design for backup repo cache configuration
@@ -1 +0,0 @@
-Add VolumePolicy support for PVC Phase conditions to allow skipping Pending PVCs
@@ -1 +0,0 @@
-feat: Permit specifying annotations for the BackupPVC
@@ -1 +0,0 @@
-Remove labels associated with previous backups
@@ -1 +0,0 @@
-Get pod list once per namespace in pvc IBA
@@ -1 +0,0 @@
-Fix issue #9229, don't attach backupPVC to the source node
@@ -1 +0,0 @@
-Update AzureAD Microsoft Authentication Library to v1.5.0
@@ -1 +0,0 @@
-Protect VolumeSnapshot field from race condition during multi-thread backup
@@ -1,10 +0,0 @@
-Implement wildcard namespace pattern expansion for backup namespace includes/excludes.
-
-This change adds support for wildcard patterns (*, ?, [abc], {a,b,c}) in namespace includes and excludes during backup operations. 
-When wildcard patterns are detected, they are expanded against the list of active namespaces in the cluster before the backup proceeds.
-
-Key features:
- Wildcard patterns in namespace includes/excludes are automatically detected and expanded
- Pattern validation ensures unsupported patterns (regex, consecutive asterisks) are rejected
- Empty wildcard results (e.g., "invalid*" matching no namespaces) correctly result in empty backups
- Exact namespace names and "*" continue to work as before (no expansion needed)
@@ -1 +0,0 @@
-Fix repository maintenance jobs to inherit allowlisted tolerations from Velero deployment
@@ -1 +0,0 @@
-Fix schedule controller to prevent backup queue accumulation during extended blocking scenarios by properly handling empty backup phases
@@ -1 +0,0 @@
-Fix issue #7904, remove the code and doc for PVC node selection
@@ -1 +0,0 @@
-Implement concurrency control for cache of native VolumeSnapshotter plugin.
@@ -1 +0,0 @@
-Fix issue #9193, don't connect repo in repo controller
@@ -1 +0,0 @@
-Add option for privileged fs-backup pod
@@ -1 +0,0 @@
-Fix issue #9267, add events to data mover prepare diagnostic
@@ -1 +0,0 @@
-VerifyJSONConfigs verify every elements in Data.
@@ -1 +0,0 @@
-Concurrent backup processing
@@ -1 +0,0 @@
-Sanitize Azure HTTP responses in BSL status messages
@@ -1 +0,0 @@
-Fix typos in documentation
@@ -1 +0,0 @@
-Fix issue #9332, add bytesDone for cache files
@@ -1 +0,0 @@
-Add cache configuration to VGDP
@@ -1 +0,0 @@
-Fix the Job build error when BackupReposiotry name longer than 63.
@@ -1 +0,0 @@
-Add cache dir configuration for udmrepo
@@ -1 +0,0 @@
-Add snapshotSize for DataDownload, PodVolumeRestore
@@ -1 +0,0 @@
-Add incrementalSize to DU/PVB for reporting new/changed size
@@ -1 +0,0 @@
-Support cache volume for generic restore exposer and pod volume exposer
@@ -1 +0,0 @@
-Use hookIndex for recording multiple restore exec hooks.
@@ -1 +0,0 @@
-Fix managed fields patch for resources using GenerateName
@@ -1 +0,0 @@
-Track actual resource names for GenerateName in restore status
@@ -1 +0,0 @@
-Add cache volume configuration
@@ -1 +0,0 @@
-Fix issue #9365, prevent fake completion notification due to multiple update of single PVR
@@ -1 +0,0 @@
-Refactor repo provider interface for static configuration
@@ -1 +0,0 @@
-don't copy securitycontext from first container if configmap found
@@ -1 +0,0 @@
-Cache volume support for DataDownload
@@ -1 +0,0 @@
-Cache volume for PVR
@@ -1 +0,0 @@
-Fix issue #9400, connect repo first time after creation so that init params could be written
@@ -1 +0,0 @@
-Add Prometheus metrics for maintenance jobs
@@ -1 +0,0 @@
-Fix issue #9276, add doc for cache volume support
@@ -1 +0,0 @@
-Apply volume policies to VolumeGroupSnapshot PVC filtering
@@ -1 +0,0 @@
-Fix issue #9194, add doc for GOMAXPROCS behavior change
@@ -1 +0,0 @@
-Remove VolumeSnapshotClass from CSI B/R process.
@@ -1 +0,0 @@
-Add PVC-to-Pod cache to improve volume policy performance
@@ -1 +0,0 @@
-Fix plugin init container names exceeding DNS-1123 limit
@@ -1 +0,0 @@
-Add maintenance job and data mover pod's labels and annotations setting.
@@ -1 +0,0 @@
-Add Role, RoleBinding, ClusterRole, and ClusterRoleBinding in restore sequence.
@@ -1 +0,0 @@
-Fix issue #9478, add diagnose info on expose peek fails
@@ -1 +0,0 @@
-Maintenance Job only uses the first element of the LoadAffinity array
@@ -1,5 +1,5 @@
 diff --git a/go.mod b/go.mod
-index 5f939c481..6ae17f4a1 100644
+index 5f939c481..f6205aa3c 100644
 --- a/go.mod
 +++ b/go.mod
@@ -24,32 +24,31 @@ require (
@@ -14,13 +14,13 @@ index 5f939c481..6ae17f4a1 100644
 -	golang.org/x/term v0.4.0
 -	golang.org/x/text v0.6.0
 -	google.golang.org/api v0.106.0
-+	golang.org/x/crypto v0.36.0
-+	golang.org/x/net v0.38.0
+	golang.org/x/crypto v0.45.0
+	golang.org/x/net v0.47.0
 +	golang.org/x/oauth2 v0.28.0
-+	golang.org/x/sync v0.12.0
-+	golang.org/x/sys v0.31.0
-+	golang.org/x/term v0.30.0
-+	golang.org/x/text v0.23.0
+	golang.org/x/sync v0.18.0
+	golang.org/x/sys v0.38.0
+	golang.org/x/term v0.37.0
+	golang.org/x/text v0.31.0
 +	google.golang.org/api v0.114.0
 )
 
@@ -64,11 +64,11 @@ index 5f939c481..6ae17f4a1 100644
 )
 
 -go 1.18
-+go 1.23.0
+go 1.24.0
 +
-+toolchain go1.23.7
+toolchain go1.24.11
 diff --git a/go.sum b/go.sum
-index 026e1d2fa..805792055 100644
+index 026e1d2fa..4a37e7ac7 100644
 --- a/go.sum
 +++ b/go.sum
@@ -1,23 +1,24 @@
@@ -170,8 +170,8 @@ index 026e1d2fa..805792055 100644
 golang.org/x/crypto v0.0.0-20211215153901-e495a2d5b3d3/go.mod h1:IxCIyHEi3zRg3s0A5j5BB6A9Jmi73HwBIUl50j+osU4=
 -golang.org/x/crypto v0.5.0 h1:U/0M97KRkSFvyD/3FSmdP5W5swImpNgle/EHFhOsQPE=
 -golang.org/x/crypto v0.5.0/go.mod h1:NK/OQwhpMQP3MwtdjgLlYHnH9ebylxKWv3e0fK+mkQU=
-+golang.org/x/crypto v0.36.0 h1:AnAEvhDddvBdpY+uR+MyHmuZzzNqXSe/GvuDeob5L34=
-+golang.org/x/crypto v0.36.0/go.mod h1:Y4J0ReaxCR1IMaabaSMugxJES1EpwhBHhv2bDHklZvc=
+golang.org/x/crypto v0.45.0 h1:jMBrvKuj23MTlT0bQEOBcAE0mjg8mK9RXFhRH6nyF3Q=
+golang.org/x/crypto v0.45.0/go.mod h1:XTGrrkGJve7CYK7J8PEww4aY7gM3qMCElcJQ8n8JdX4=
 golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
 golang.org/x/lint v0.0.0-20181026193005-c67002cb31c3/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE=
 golang.org/x/lint v0.0.0-20190227174305-5b3e6a55c961/go.mod h1:wehouNa3lNwaWXcvxsM5YxQ5yQlVC4a0KAMCusXpPoU=
@@ -181,8 +181,8 @@ index 026e1d2fa..805792055 100644
 golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
 -golang.org/x/net v0.5.0 h1:GyT4nK/YDHSqa1c4753ouYCDajOYKTja9Xb/OHtgvSw=
 -golang.org/x/net v0.5.0/go.mod h1:DivGGAXEgPSlEBzxGzZI+ZLohi+xUj054jfeKui00ws=
-+golang.org/x/net v0.38.0 h1:vRMAPTMaeGqVhG5QyLJHqNDwecKTomGeqbnfZyKlBI8=
-+golang.org/x/net v0.38.0/go.mod h1:ivrbrMbzFq5J41QOQh0siUuly180yBYtLp+CKbEaFx8=
+golang.org/x/net v0.47.0 h1:Mx+4dIFzqraBXUugkia1OOvlD6LemFo1ALMHjrXDOhY=
+golang.org/x/net v0.47.0/go.mod h1:/jNxtkgq5yWUGYkaZGqo27cfGZ1c5Nen03aYrrKpVRU=
 golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U=
 -golang.org/x/oauth2 v0.4.0 h1:NF0gk8LVPg1Ml7SSbGyySuoxdsXitj7TvgvuRxIMc/M=
 -golang.org/x/oauth2 v0.4.0/go.mod h1:RznEsdpjGAINPTOF0UH/t+xJ75L18YO3Ho6Pyn+uRec=
@@ -194,8 +194,8 @@ index 026e1d2fa..805792055 100644
 golang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 -golang.org/x/sync v0.1.0 h1:wsuoTGHzEhffawBOhz5CYhcrV4IdKZbEyZjBMuTp12o=
 -golang.org/x/sync v0.1.0/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
-+golang.org/x/sync v0.12.0 h1:MHc5BpPuC30uJk597Ri8TV3CNZcTLu6B6z4lJy+g6Jw=
-+golang.org/x/sync v0.12.0/go.mod h1:1dzgHSNfp02xaA81J2MS99Qcpr2w7fw1gpm99rleRqA=
+golang.org/x/sync v0.18.0 h1:kr88TuHDroi+UVf+0hZnirlk8o8T+4MrK6mr60WkH/I=
+golang.org/x/sync v0.18.0/go.mod h1:9KTHXmSnoGruLpwFjVSX0lNNA75CykiMECbovNTZqGI=
 golang.org/x/sys v0.0.0-20180830151530-49385e6e1522/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
@@ -205,21 +205,21 @@ index 026e1d2fa..805792055 100644
 golang.org/x/sys v0.0.0-20220715151400-c0bba94af5f8/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 -golang.org/x/sys v0.4.0 h1:Zr2JFtRQNX3BCZ8YtxRE9hNJYC8J6I1MVbMg6owUp18=
 -golang.org/x/sys v0.4.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-+golang.org/x/sys v0.31.0 h1:ioabZlmFYtWhL+TRYpcnNlLwhyxaM9kWTDEmfnprqik=
-+golang.org/x/sys v0.31.0/go.mod h1:BJP2sWEmIv4KK5OTEluFJCKSidICx8ciO85XgH3Ak8k=
+golang.org/x/sys v0.38.0 h1:3yZWxaJjBmCWXqhN1qh02AkOnCQ1poK6oF+a7xWL6Gc=
+golang.org/x/sys v0.38.0/go.mod h1:OgkHotnGiDImocRcuBABYBEXf8A9a87e/uXjp9XT3ks=
 golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
 -golang.org/x/term v0.4.0 h1:O7UWfv5+A2qiuulQk30kVinPoMtoIPeVaKLEgLpVkvg=
 -golang.org/x/term v0.4.0/go.mod h1:9P2UbLfCdcvo3p/nzKvsmas4TnlujnuoV9hGgYzW1lQ=
-+golang.org/x/term v0.30.0 h1:PQ39fJZ+mfadBm0y5WlL4vlM7Sx1Hgf13sMIY2+QS9Y=
-+golang.org/x/term v0.30.0/go.mod h1:NYYFdzHoI5wRh/h5tDMdMqCqPJZEuNqVR5xJLd/n67g=
+golang.org/x/term v0.37.0 h1:8EGAD0qCmHYZg6J17DvsMy9/wJ7/D/4pV/wfnld5lTU=
+golang.org/x/term v0.37.0/go.mod h1:5pB4lxRNYYVZuTLmy8oR2BH8dflOR+IbTYFD8fi3254=
 golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
 golang.org/x/text v0.3.2/go.mod h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk=
 golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
 golang.org/x/text v0.3.6/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
 -golang.org/x/text v0.6.0 h1:3XmdazWV+ubf7QgHSTWeykHOci5oeekaGJBLkrkaw4k=
 -golang.org/x/text v0.6.0/go.mod h1:mrYo+phRRbMaCq/xk9113O4dZlRixOauAjOtrjsXDZ8=
-+golang.org/x/text v0.23.0 h1:D71I7dUrlY+VX0gQShAThNGHFxZ13dGLBHQLVl1mJlY=
-+golang.org/x/text v0.23.0/go.mod h1:/BLNzu4aZCJ1+kcD0DNRotWKage4q2rGVAg4o22unh4=
+golang.org/x/text v0.31.0 h1:aC8ghyu4JhP8VojJ2lEHBnochRno1sgL6nEi9WGFGMM=
+golang.org/x/text v0.31.0/go.mod h1:tKRAlv61yKIjGGHX/4tP1LTbc13YSec1pxVEWXzfoeM=
 golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
 golang.org/x/tools v0.0.0-20190114222345-bf090417da8b/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
 golang.org/x/tools v0.0.0-20190226205152-f727befe758c/go.mod h1:9Yl7xja0Znq3iFh3HoIrodX9oNMXvdceNzlUR8zjMvY=
@@ -340,20 +340,16 @@ func (s *nodeAgentServer) run() {
 		}
 	}

+	var cachePVCConfig *velerotypes.CachePVC
 	if s.dataPathConfigs != nil && s.dataPathConfigs.CachePVCConfig != nil {
 		if err := s.validateCachePVCConfig(*s.dataPathConfigs.CachePVCConfig); err != nil {
 			s.logger.WithError(err).Warnf("Ignore cache config %v", s.dataPathConfigs.CachePVCConfig)
 		} else {
+			cachePVCConfig = s.dataPathConfigs.CachePVCConfig
 			s.logger.Infof("Using cache volume configs %v", s.dataPathConfigs.CachePVCConfig)
 		}
 	}

-	var cachePVCConfig *velerotypes.CachePVC
-	if s.dataPathConfigs != nil && s.dataPathConfigs.CachePVCConfig != nil {
-		cachePVCConfig = s.dataPathConfigs.CachePVCConfig
-		s.logger.Infof("Using customized cachePVC config %v", cachePVCConfig)
-	}
-
 	var podLabels map[string]string
 	if s.dataPathConfigs != nil && len(s.dataPathConfigs.PodLabels) > 0 {
 		podLabels = s.dataPathConfigs.PodLabels
@@ -368,6 +364,8 @@ func (s *nodeAgentServer) run() {

 	if s.backupRepoConfigs != nil {
 		s.logger.Infof("Using backup repo config %v", s.backupRepoConfigs)
+	} else if cachePVCConfig != nil {
+		s.logger.Info("Backup repo config is not provided, using default values for cache volume configs")
 	}

 	pvbReconciler := controller.NewPodVolumeBackupReconciler(
@@ -307,6 +307,16 @@ func (b *backupReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctr

 	backupScheduleName := request.GetLabels()[velerov1api.ScheduleNameLabel]

+	b.backupTracker.Add(request.Namespace, request.Name)
+	defer func() {
+		switch request.Status.Phase {
+		case velerov1api.BackupPhaseCompleted, velerov1api.BackupPhasePartiallyFailed, velerov1api.BackupPhaseFailed, velerov1api.BackupPhaseFailedValidation:
+			b.backupTracker.Delete(request.Namespace, request.Name)
+		case velerov1api.BackupPhaseWaitingForPluginOperations, velerov1api.BackupPhaseWaitingForPluginOperationsPartiallyFailed, velerov1api.BackupPhaseFinalizing, velerov1api.BackupPhaseFinalizingPartiallyFailed:
+			b.backupTracker.AddPostProcessing(request.Namespace, request.Name)
+		}
+	}()
+
 	if request.Status.Phase == velerov1api.BackupPhaseFailedValidation {
 		log.Debug("failed to validate backup status")
 		b.metrics.RegisterBackupValidationFailure(backupScheduleName)
@@ -318,16 +328,6 @@ func (b *backupReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctr
 	// store ref to just-updated item for creating patch
 	original = request.Backup.DeepCopy()

-	b.backupTracker.Add(request.Namespace, request.Name)
-	defer func() {
-		switch request.Status.Phase {
-		case velerov1api.BackupPhaseCompleted, velerov1api.BackupPhasePartiallyFailed, velerov1api.BackupPhaseFailed, velerov1api.BackupPhaseFailedValidation:
-			b.backupTracker.Delete(request.Namespace, request.Name)
-		case velerov1api.BackupPhaseWaitingForPluginOperations, velerov1api.BackupPhaseWaitingForPluginOperationsPartiallyFailed, velerov1api.BackupPhaseFinalizing, velerov1api.BackupPhaseFinalizingPartiallyFailed:
-			b.backupTracker.AddPostProcessing(request.Namespace, request.Name)
-		}
-	}()
-
 	log.Debug("Running backup")

 	b.metrics.RegisterBackupAttempt(backupScheduleName)
@@ -246,6 +246,7 @@ func TestProcessBackupValidationFailures(t *testing.T) {
 				clock:                 &clock.RealClock{},
 				formatFlag:            formatFlag,
 				metrics:               metrics.NewServerMetrics(),
+				backupTracker:         NewBackupTracker(),
 			}

 			require.NotNil(t, test.backup)
@@ -15,6 +15,7 @@ params:
  latest: v1.17
  versions:
    - main
+    - v1.18
    - v1.17
    - v1.16
    - v1.15
@@ -0,0 +1,58 @@
+---
+toc: "false"
+cascade:
+  version: v1.18
+  toc: "true"
+---
+![100]
+
+[![Build Status][1]][2]
+
+## Overview
+
+Velero (formerly Heptio Ark) gives you tools to back up and restore your Kubernetes cluster resources and persistent volumes. You can run Velero with a cloud provider or on-premises. Velero lets you:
+
+* Take backups of your cluster and restore in case of loss.
+* Migrate cluster resources to other clusters.
+* Replicate your production cluster to development and testing clusters.
+
+Velero consists of:
+
+* A server that runs on your cluster
+* A command-line client that runs locally
+
+## Documentation
+
+This site is our documentation home with installation instructions, plus information about customizing Velero for your needs, architecture, extending Velero, contributing to Velero and more.
+
+Please use the version selector at the top of the site to ensure you are using the appropriate documentation for your version of Velero.
+
+## Troubleshooting
+
+If you encounter issues, review the [troubleshooting docs][30], [file an issue][4], or talk to us on the [#velero-users channel][25] on the Kubernetes Slack server.
+
+## Contributing
+
+If you are ready to jump in and test, add code, or help with documentation, follow the instructions on our [Start contributing](https://velero.io/docs/v1.18.0/start-contributing/) documentation for guidance on how to setup Velero for development.
+
+## Changelog
+
+See [the list of releases][6] to find out about feature changes.
+
+[1]: https://github.com/vmware-tanzu/velero/workflows/Main%20CI/badge.svg
+[2]: https://github.com/vmware-tanzu/velero/actions?query=workflow%3A"Main+CI"
+
+[4]: https://github.com/vmware-tanzu/velero/issues
+[6]: https://github.com/vmware-tanzu/velero/releases
+
+[9]: https://kubernetes.io/docs/setup/
+[10]: https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-with-homebrew-on-macos
+[11]: https://kubernetes.io/docs/tasks/tools/install-kubectl/#tabset-1
+[12]: https://github.com/kubernetes/kubernetes/blob/main/cluster/addons/dns/README.md
+[14]: https://github.com/kubernetes/kubernetes
+[24]: https://groups.google.com/forum/#!forum/projectvelero
+[25]: https://kubernetes.slack.com/messages/velero-users
+
+[30]: troubleshooting.md
+
+[100]: img/velero.png
@@ -0,0 +1,21 @@
+---
+title: "Table of Contents"
+layout: docs
+---
+
+## API types
+
+Here we list the API types that have some functionality that you can only configure via json/yaml vs the `velero` cli
+(hooks)
+
+* [Backup][1]
+* [Restore][2]
+* [Schedule][3]
+* [BackupStorageLocation][4]
+* [VolumeSnapshotLocation][5]
+
+[1]: backup.md
+[2]: restore.md
+[3]: schedule.md
+[4]: backupstoragelocation.md
+[5]: volumesnapshotlocation.md
@@ -0,0 +1,19 @@
+---
+layout: docs
+title: API types
+---
+
+Here's a list the API types that have some functionality that you can only configure via json/yaml vs the `velero` cli
+(hooks)
+
+* [Backup][1]
+* [Restore][2]
+* [Schedule][3]
+* [BackupStorageLocation][4]
+* [VolumeSnapshotLocation][5]
+
+[1]: backup.md
+[2]: restore.md
+[3]: schedule.md
+[4]: backupstoragelocation.md
+[5]: volumesnapshotlocation.md
@@ -0,0 +1,211 @@
+---
+title: "Backup API Type"
+layout: docs
+---
+
+## Use
+
+Use the `Backup` API type to request the Velero server to perform a backup. Once created, the
+Velero Server immediately starts the backup process.
+
+## API GroupVersion
+
+Backup belongs to the API group version `velero.io/v1`.
+
+## Definition
+
+Here is a sample `Backup` object with each of the fields documented:
+
+```yaml
+# Standard Kubernetes API Version declaration. Required.
+apiVersion: velero.io/v1
+# Standard Kubernetes Kind declaration. Required.
+kind: Backup
+# Standard Kubernetes metadata. Required.
+metadata:
+  # Backup name. May be any valid Kubernetes object name. Required.
+  name: a
+  # Backup namespace. Must be the namespace of the Velero server. Required.
+  namespace: velero
+# Parameters about the backup. Required.
+spec:
+  # CSISnapshotTimeout specifies the time used to wait for
+  # CSI VolumeSnapshot status turns to ReadyToUse during creation, before
+  # returning error as timeout. The default value is 10 minute.
+  csiSnapshotTimeout: 10m
+  # ItemOperationTimeout specifies the time used to wait for
+  # asynchronous BackupItemAction operations
+  # The default value is 4 hour.
+  itemOperationTimeout: 4h
+  # resourcePolicy specifies the referenced resource policies that backup should follow
+  # optional
+  resourcePolicy:
+    kind: configmap
+    name: resource-policy-configmap
+  # Array of namespaces to include in the backup. If unspecified, all namespaces are included.
+  # Optional.
+  includedNamespaces:
+  - '*'
+  # Array of namespaces to exclude from the backup. Optional.
+  excludedNamespaces:
+  - some-namespace
+  # Array of resources to include in the backup. Resources may be shortcuts (for example 'po' for 'pods')
+  # or fully-qualified. If unspecified, all resources are included. Optional.
+  includedResources:
+  - '*'
+  # Array of resources to exclude from the backup. Resources may be shortcuts (for example 'po' for 'pods')
+  # or fully-qualified. Optional.
+  excludedResources:
+  - storageclasses.storage.k8s.io
+  # Order of the resources to be collected during the backup process.  It's a map with key being the plural resource
+  # name, and the value being a list of object names separated by comma.  Each resource name has format "namespace/objectname".
+  # For cluster resources, simply use "objectname". Optional
+  orderedResources:
+    pods: mysql/mysql-cluster-replica-0,mysql/mysql-cluster-replica-1,mysql/mysql-cluster-source-0
+    persistentvolumes: pvc-87ae0832-18fd-4f40-a2a4-5ed4242680c4,pvc-63be1bb0-90f5-4629-a7db-b8ce61ee29b3
+  # Whether to include cluster-scoped resources. Valid values are true, false, and
+  # null/unset. If true, all cluster-scoped resources are included (subject to included/excluded
+  # resources and the label selector). If false, no cluster-scoped resources are included. If unset,
+  # all cluster-scoped resources are included if and only if all namespaces are included and there are
+  # no excluded namespaces. Otherwise, if there is at least one namespace specified in either
+  # includedNamespaces or excludedNamespaces, then the only cluster-scoped resources that are backed
+  # up are those associated with namespace-scoped resources included in the backup. For example, if a
+  # PersistentVolumeClaim is included in the backup, its associated PersistentVolume (which is
+  # cluster-scoped) would also be backed up.
+  includeClusterResources: null
+  # Array of cluster-scoped resources to exclude from the backup. Resources may be shortcuts 
+  # (for example 'sc' for 'storageclasses'), or fully-qualified. If unspecified, 
+  # no additional cluster-scoped resources are excluded. Optional.
+  # Cannot work with include-resources, exclude-resources and include-cluster-resources.
+  excludedClusterScopedResources: {}
+  # Array of cluster-scoped resources to include from the backup. Resources may be shortcuts 
+  # (for example 'sc' for 'storageclasses'), or fully-qualified. If unspecified, 
+  # no additional cluster-scoped resources are included. Optional.
+  # Cannot work with include-resources, exclude-resources and include-cluster-resources.
+  includedClusterScopedResources: {}
+  # Array of namespace-scoped resources to exclude from the backup. Resources may be shortcuts 
+  # (for example 'cm' for 'configmaps'), or fully-qualified. If unspecified, 
+  # no namespace-scoped resources are excluded. Optional.
+  # Cannot work with include-resources, exclude-resources and include-cluster-resources.
+  excludedNamespaceScopedResources: {}
+  # Array of namespace-scoped resources to include from the backup. Resources may be shortcuts 
+  # (for example 'cm' for 'configmaps'), or fully-qualified. If unspecified, 
+  # all namespace-scoped resources are included. Optional.
+  # Cannot work with include-resources, exclude-resources and include-cluster-resources.
+  includedNamespaceScopedResources: {}
+  # Individual objects must match this label selector to be included in the backup. Optional.
+  labelSelector:
+    matchLabels:
+      app: velero
+      component: server
+  # Individual object when matched with any of the label selector specified in the set are to be included in the backup. Optional.
+  # orLabelSelectors as well as labelSelector cannot co-exist, only one of them can be specified in the backup request
+  orLabelSelectors:
+  - matchLabels:
+      app: velero
+  - matchLabels:
+      app: data-protection
+  # Whether or not to snapshot volumes. Valid values are true, false, and null/unset. If unset, Velero performs snapshots as long as
+  # a persistent volume provider is configured for Velero.
+  snapshotVolumes: null
+  # Where to store the tarball and logs.
+  storageLocation: aws-primary
+  # The list of locations in which to store volume snapshots created for this backup.
+  volumeSnapshotLocations:
+    - aws-primary
+    - gcp-primary
+  # The amount of time before this backup is eligible for garbage collection. If not specified,
+  # a default value of 30 days will be used. The default can be configured on the velero server
+  # by passing the flag --default-backup-ttl.
+  ttl: 24h0m0s
+  # whether pod volume file system backup should be used for all volumes by default.
+  defaultVolumesToFsBackup: true
+  # Whether snapshot data should be moved. If set, data movement is launched after the snapshot is created.
+  snapshotMoveData: true
+  # The data mover to be used by the backup. If the value is "" or "velero", the built-in data mover will be used.
+  datamover: velero
+  # UploaderConfig specifies the configuration for the uploader
+  uploaderConfig:
+      # ParallelFilesUpload is the number of files parallel uploads to perform when using the uploader.
+      parallelFilesUpload: 10
+  # Actions to perform at different times during a backup. The only hook supported is
+  # executing a command in a container in a pod using the pod exec API. Optional.
+  hooks:
+    # Array of hooks that are applicable to specific resources. Optional.
+    resources:
+      -
+        # Name of the hook. Will be displayed in backup log.
+        name: my-hook
+        # Array of namespaces to which this hook applies. If unspecified, the hook applies to all
+        # namespaces. Optional.
+        includedNamespaces:
+        - '*'
+        # Array of namespaces to which this hook does not apply. Optional.
+        excludedNamespaces:
+        - some-namespace
+        # Array of resources to which this hook applies. The only resource supported at this time is
+        # pods.
+        includedResources:
+        - pods
+        # Array of resources to which this hook does not apply. Optional.
+        excludedResources: []
+        # This hook only applies to objects matching this label selector. Optional.
+        labelSelector:
+          matchLabels:
+            app: velero
+            component: server
+        # An array of hooks to run before executing custom actions. Only "exec" hooks are supported.
+        pre:
+          -
+            # The type of hook. This must be "exec".
+            exec:
+              # The name of the container where the command will be executed. If unspecified, the
+              # first container in the pod will be used. Optional.
+              container: my-container
+              # The command to execute, specified as an array. Required.
+              command:
+                - /bin/uname
+                - -a
+              # How to handle an error executing the command. Valid values are Fail and Continue.
+              # Defaults to Fail. Optional.
+              onError: Fail
+              # How long to wait for the command to finish executing. Defaults to 30 seconds. Optional.
+              timeout: 10s
+        # An array of hooks to run after all custom actions and additional items have been
+        # processed. Only "exec" hooks are supported.
+        post:
+          # Same content as pre above.
+# Status about the Backup. Users should not set any data here.
+status:
+  # The version of this Backup. The only version supported is 1.
+  version: 1
+  # The date and time when the Backup is eligible for garbage collection.
+  expiration: null
+  # The current phase.
+  # Valid values are New, FailedValidation, InProgress, WaitingForPluginOperations,
+  # WaitingForPluginOperationsPartiallyFailed, FinalizingafterPluginOperations,
+  # FinalizingPartiallyFailed, Completed, PartiallyFailed, Failed.
+  phase: ""
+  # An array of any validation errors encountered.
+  validationErrors: null
+  # Date/time when the backup started being processed.
+  startTimestamp: 2019-04-29T15:58:43Z
+  # Date/time when the backup finished being processed.
+  completionTimestamp: 2019-04-29T15:58:56Z
+  # Number of volume snapshots that Velero tried to create for this backup.
+  volumeSnapshotsAttempted: 2
+  # Number of volume snapshots that Velero successfully created for this backup.
+  volumeSnapshotsCompleted: 1
+  # Number of attempted BackupItemAction operations for this backup.
+  backupItemOperationsAttempted: 2
+  # Number of BackupItemAction operations that Velero successfully completed for this backup.
+  backupItemOperationsCompleted: 1
+  # Number of BackupItemAction operations that ended in failure for this backup.
+  backupItemOperationsFailed: 0
+  # Number of warnings that were logged by the backup.
+  warnings: 2
+  # Number of errors that were logged by the backup.
+  errors: 0
+  # An error that caused the entire backup to fail.
+  failureReason: ""
+```
@@ -0,0 +1,112 @@
+---
+title: "Velero Backup Storage Locations"
+layout: docs
+---
+
+## Backup Storage Location
+
+Velero can store backups in a number of locations. These are represented in the cluster via the `BackupStorageLocation` CRD.
+
+Velero must have at least one `BackupStorageLocation`. By default, this is expected to be named `default`, however the name can be changed by specifying `--default-backup-storage-location` on `velero server`.  Backups that do not explicitly specify a storage location will be saved to this `BackupStorageLocation`.
+
+A sample YAML `BackupStorageLocation` looks like the following:
+
+```yaml
+apiVersion: velero.io/v1
+kind: BackupStorageLocation
+metadata:
+  name: default
+  namespace: velero
+spec:
+  backupSyncPeriod: 2m0s
+  provider: aws
+  objectStorage:
+    bucket: myBucket
+  credential:
+    name: secret-name
+    key: key-in-secret
+  config:
+    region: us-west-2
+    profile: "default"
+```
+
+### Example with self-signed certificate
+
+When using object storage with self-signed certificates, you can specify the CA certificate:
+
+```yaml
+apiVersion: velero.io/v1
+kind: BackupStorageLocation
+metadata:
+  name: default
+  namespace: velero
+spec:
+  provider: aws
+  objectStorage:
+    bucket: velero-backups
+    # Base64 encoded CA certificate (deprecated - use caCertRef instead)
+    caCert: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR1VENDQXFHZ0F3SUJBZ0lVTWRiWkNaYnBhcE9lYThDR0NMQnhhY3dVa213d0RRWUpLb1pJaHZjTkFRRUwKQlFBd2JERUxNQWtHQTFVRUJoTUNWVk14RXpBUkJnTlZCQWdNQ2tOaGJHbG1iM0p1YVdFeEZqQVVCZ05WQkFjTQpEVk5oYmlCR2NtRnVZMmx6WTI4eEdEQVdCZ05WQkFvTUQwVjRZVzF3YkdVZ1EyOXRjR0Z1ZVRFV01CUUdBMVVFCkF3d05aWGhoYlhCc1pTNXNiMk5oYkRBZUZ3MHlNekEzTVRBeE9UVXlNVGhhRncweU5EQTNNRGt4T1RVeU1UaGEKTUd3eEN6QUpCZ05WQkFZVEFsVlRNUk13RVFZRFZRUUNEQXBEWEJ4cG1iM0p1YVdFeEZqQVVCZ05WQkFjTURWTmgKYmlCR2NtRnVZMmx6WTI4eEdEQVdCZ05WQkFvTUQwVjRZVzF3YkdVZ1EyOXRjR0Z1ZVRFV01CUUdBMVVFQXd3TgpaWGhoYlhCc1pTNXNiMk5oYkRDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBS1dqCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
+  config:
+    region: us-east-1
+    s3Url: https://minio.example.com
+```
+
+#### Using a CA Certificate with Secret Reference (Recommended)
+
+The recommended approach is to use `caCertRef` to reference a Secret containing the CA certificate:
+
+```yaml
+# First, create a Secret containing the CA certificate
+apiVersion: v1
+kind: Secret
+metadata:
+  name: storage-ca-cert
+  namespace: velero
+type: Opaque
+data:
+  ca-bundle.crt: <base64-encoded-certificate>
+
+---
+# Then reference it in the BackupStorageLocation
+apiVersion: velero.io/v1
+kind: BackupStorageLocation
+metadata:
+  name: default
+  namespace: velero
+spec:
+  provider: aws
+  objectStorage:
+    bucket: myBucket
+    caCertRef:
+      name: storage-ca-cert
+      key: ca-bundle.crt
+  # ... other configuration
+```
+
+**Note:** You cannot specify both `caCert` and `caCertRef` in the same BackupStorageLocation. The `caCert` field is deprecated and will be removed in a future version.
+
+### Parameter Reference
+
+The configurable parameters are as follows:
+
+#### Main config parameters
+
+{{< table caption="Main config parameters" >}}
+| Key | Type | Default | Meaning |
+| --- | --- | --- | --- |
+| `provider` | String | Required Field | The name for whichever object storage provider will be used to store the backups. See [your object storage provider's plugin documentation](../supported-providers) for the appropriate value to use. |
+| `objectStorage` | ObjectStorageLocation | Required Field | Specification of the object storage for the given provider. |
+| `objectStorage/bucket` | String | Required Field | The storage bucket where backups are to be uploaded. |
+| `objectStorage/prefix` | String | Optional Field | The directory inside a storage bucket where backups are to be uploaded. |
+| `objectStorage/caCert` | String | Optional Field | **Deprecated**: Use `caCertRef` instead. A base64 encoded CA bundle to be used when verifying TLS connections |
+| `objectStorage/caCertRef` | [corev1.SecretKeySelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#secretkeyselector-v1-core) | Optional Field | Reference to a Secret containing a CA bundle to be used when verifying TLS connections. The Secret must be in the same namespace as the BackupStorageLocation. |
+| `objectStorage/caCertRef/name` | String | Required Field (when using caCertRef) | The name of the Secret containing the CA certificate bundle |
+| `objectStorage/caCertRef/key` | String | Required Field (when using caCertRef) | The key within the Secret that contains the CA certificate bundle |
+| `config` | map[string]string | None (Optional) | Provider-specific configuration keys/values to be passed to the object store plugin. See [your object storage provider's plugin documentation](../supported-providers) for details. |
+| `accessMode` | String | `ReadWrite` | How Velero can access the backup storage location. Valid values are `ReadWrite`, `ReadOnly`. |
+| `backupSyncPeriod` | metav1.Duration | Optional Field | How frequently Velero should synchronize backups in object storage. Default is Velero's server backup sync period. Set this to `0s` to disable sync. |
+| `validationFrequency` | metav1.Duration | Optional Field | How frequently Velero should validate the object storage . Default is Velero's server validation frequency. Set this to `0s` to disable validation. Default 1 minute. |
+| `credential` | [corev1.SecretKeySelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#secretkeyselector-v1-core) | Optional Field | The credential information to be used with this location. |
+| `credential/name` | String | Optional Field | The name of the secret within the Velero namespace which contains the credential information. |
+| `credential/key` | String | Optional Field | The key to use within the secret. |
+{{< /table >}}
@@ -0,0 +1,219 @@
+---
+title: "Restore API Type"
+layout: docs
+---
+
+## Use
+
+The `Restore` API type is used as a request for the Velero server to perform a Restore. Once created, the
+Velero Server immediately starts the Restore process.
+
+## API GroupVersion
+
+Restore belongs to the API group version `velero.io/v1`.
+
+## Definition
+
+Here is a sample `Restore` object with each of the fields documented:
+
+```yaml
+# Standard Kubernetes API Version declaration. Required.
+apiVersion: velero.io/v1
+# Standard Kubernetes Kind declaration. Required.
+kind: Restore
+# Standard Kubernetes metadata. Required.
+metadata:
+  # Restore name. May be any valid Kubernetes object name. Required.
+  name: a-very-special-backup-0000111122223333
+  # Restore namespace. Must be the namespace of the Velero server. Required.
+  namespace: velero
+# Parameters about the restore. Required.
+spec:
+  # The unique name of the Velero backup to restore from.
+  backupName: a-very-special-backup
+  # The unique name of the Velero schedule
+  # to restore from. If specified, and BackupName is empty, Velero will
+  # restore from the most recent successful backup created from this schedule.
+  scheduleName: my-scheduled-backup-name
+  # ItemOperationTimeout specifies the time used to wait for
+  # asynchronous BackupItemAction operations
+  # The default value is 4 hour.
+  itemOperationTimeout: 4h
+  # UploaderConfig specifies the configuration for the restore.
+  uploaderConfig:
+    # WriteSparseFiles is a flag to indicate whether write files sparsely or not
+    writeSparseFiles: true
+    # ParallelFilesDownload is the concurrency number setting for restore
+    parallelFilesDownload: 10
+  # Array of namespaces to include in the restore. If unspecified, all namespaces are included.
+  # Optional.
+  includedNamespaces:
+  - '*'
+  # Array of namespaces to exclude from the restore. Optional.
+  excludedNamespaces:
+  - some-namespace
+  # Array of resources to include in the restore. Resources may be shortcuts (for example 'po' for 'pods')
+  # or fully-qualified. If unspecified, all resources are included. Optional.
+  includedResources:
+  - '*'
+  # Array of resources to exclude from the restore. Resources may be shortcuts (for example 'po' for 'pods')
+  # or fully-qualified. Optional.
+  excludedResources:
+  - storageclasses.storage.k8s.io
+
+  # restoreStatus selects resources to restore not only the specification, but
+  # the status of the manifest. This is specially useful for CRDs that maintain
+  # external references. By default, it excludes all resources.
+  restoreStatus:
+    # Array of resources to include in the restore status. Just like above,
+    # resources may be shortcuts (for example 'po' for 'pods') or fully-qualified.
+    # If unspecified, no resources are included. Optional.
+    includedResources:
+    - workflows
+    # Array of resources to exclude from the restore status. Resources may be
+    # shortcuts (for example 'po' for 'pods') or fully-qualified.
+    # If unspecified, all resources are excluded. Optional.
+    excludedResources: []
+
+  # Whether or not to include cluster-scoped resources. Valid values are true, false, and
+  # null/unset. If true, all cluster-scoped resources are included (subject to included/excluded
+  # resources and the label selector). If false, no cluster-scoped resources are included. If unset,
+  # all cluster-scoped resources are included if and only if all namespaces are included and there are
+  # no excluded namespaces. Otherwise, if there is at least one namespace specified in either
+  # includedNamespaces or excludedNamespaces, then the only cluster-scoped resources that are backed
+  # up are those associated with namespace-scoped resources included in the restore. For example, if a
+  # PersistentVolumeClaim is included in the restore, its associated PersistentVolume (which is
+  # cluster-scoped) would also be backed up.
+  includeClusterResources: null
+  # Individual objects must match this label selector to be included in the restore. Optional.
+  labelSelector:
+    matchLabels:
+      app: velero
+      component: server
+  # Individual object when matched with any of the label selector specified in the set are to be included in the restore. Optional.
+  # orLabelSelectors as well as labelSelector cannot co-exist, only one of them can be specified in the restore request
+  orLabelSelectors:
+  - matchLabels:
+      app: velero
+  - matchLabels:
+      app: data-protection
+  # namespaceMapping is a map of source namespace names to
+  # target namespace names to restore into. Any source namespaces not
+  # included in the map will be restored into namespaces of the same name.
+  namespaceMapping:
+    namespace-backup-from: namespace-to-restore-to
+  # restorePVs specifies whether to restore all included PVs
+  # from snapshot. Optional
+  restorePVs: true
+  # preserveNodePorts specifies whether to restore old nodePorts from backup,
+  # so that the exposed port numbers on the node will remain the same after restore. Optional
+  preserveNodePorts: true
+  # existingResourcePolicy specifies the restore behaviour
+  # for the Kubernetes resource to be restored. Optional
+  existingResourcePolicy: none
+  # ResourceModifier specifies the reference to JSON resource patches
+  # that should be applied to resources before restoration. Optional
+  resourceModifier:
+    kind: ConfigMap
+    name: resource-modifier-configmap
+  # Actions to perform during or post restore. The only hooks currently supported are
+  # adding an init container to a pod before it can be restored and executing a command in a
+  # restored pod's container. Optional.
+  hooks:
+    # Array of hooks that are applicable to specific resources. Optional.
+    resources:
+    # Name is the name of this hook.
+    - name: restore-hook-1
+      # Array of namespaces to which this hook applies. If unspecified, the hook applies to all
+      # namespaces. Optional.
+      includedNamespaces:
+      - ns1
+      # Array of namespaces to which this hook does not apply. Optional.
+      excludedNamespaces:
+      - ns3
+      # Array of resources to which this hook applies. If unspecified, the hook applies to all resources in the backup. Optional.
+      # The only resource supported at this time is pods.
+      includedResources:
+      - pods
+      # Array of resources to which this hook does not apply. Optional.
+      excludedResources: []
+      # This hook only applies to objects matching this label selector. Optional.
+      labelSelector:
+        matchLabels:
+          app: velero
+          component: server
+      # An array of hooks to run during or after restores. Currently only "init" and "exec" hooks
+      # are supported.
+      postHooks:
+      # The type of the hook. This must be "init" or "exec".
+      - init:
+          # An array of container specs to be added as init containers to pods to which this hook applies to.
+          initContainers:
+          - name: restore-hook-init1
+            image: alpine:latest
+            # Mounting volumes from the podSpec to which this hooks applies to.
+            volumeMounts:
+            - mountPath: /restores/pvc1-vm
+              # Volume name from the podSpec
+              name: pvc1-vm
+            command:
+            - /bin/ash
+            - -c
+            - echo -n "FOOBARBAZ" >> /restores/pvc1-vm/foobarbaz
+          - name: restore-hook-init2
+            image: alpine:latest
+            # Mounting volumes from the podSpec to which this hooks applies to.
+            volumeMounts:
+            - mountPath: /restores/pvc2-vm
+              # Volume name from the podSpec
+              name: pvc2-vm
+            command:
+            - /bin/ash
+            - -c
+            - echo -n "DEADFEED" >> /restores/pvc2-vm/deadfeed
+      - exec:
+          # The container name where the hook will be executed. Defaults to the first container.
+          # Optional.
+          container: foo
+          # The command that will be executed in the container. Required.
+          command:
+          - /bin/bash
+          - -c
+          - "psql < /backup/backup.sql"
+          # How long to wait for a container to become ready. This should be long enough for the
+          # container to start plus any preceding hooks in the same container to complete. The wait
+          # timeout begins when the container is restored and may require time for the image to pull
+          # and volumes to mount. If not set the restore will wait indefinitely. Optional.
+          waitTimeout: 5m
+          # How long to wait once execution begins. Defaults to 30 seconds. Optional.
+          execTimeout: 1m
+          # How to handle execution failures. Valid values are `Fail` and `Continue`. Defaults to
+          # `Continue`. With `Continue` mode, execution failures are logged only. With `Fail` mode,
+          # no more restore hooks will be executed in any container in any pod and the status of the
+          # Restore will be `PartiallyFailed`. Optional.
+          onError: Continue
+# RestoreStatus captures the current status of a Velero restore. Users should not set any data here.
+status:
+  # The current phase.
+  # Valid values are New, FailedValidation, InProgress, WaitingForPluginOperations,
+  # WaitingForPluginOperationsPartiallyFailed, Completed, PartiallyFailed, Failed.
+  phase: ""
+  # An array of any validation errors encountered.
+  validationErrors: null
+  # Number of attempted RestoreItemAction operations for this restore.
+  restoreItemOperationsAttempted: 2
+  # Number of RestoreItemAction operations that Velero successfully completed for this restore.
+  restoreItemOperationsCompleted: 1
+  # Number of RestoreItemAction operations that ended in failure for this restore.
+  restoreItemOperationsFailed: 0
+  # Number of warnings that were logged by the restore.
+  warnings: 2
+  # Errors is a count of all error messages that were generated
+  # during execution of the restore. The actual errors are stored in object
+  # storage.
+  errors: 0
+  # FailureReason is an error that caused the entire restore
+  # to fail.
+  failureReason:
+
+```
@@ -0,0 +1,216 @@
+---
+title: "Schedule API Type"
+layout: docs
+---
+
+## Use
+
+The `Schedule` API type is used as a repeatable request for the Velero server to perform a backup for a given cron notation. Once created, the
+Velero Server will start the backup process. It will then wait for the next valid point of the given cron expression and execute the backup
+process on a repeating basis.
+
+### Schedule Control Fields
+
+The Schedule API provides several fields to control backup execution behavior:
+
+- **paused**: When set to `true`, the schedule is paused and no new backups will be created. When set back to `false`, the schedule is unpaused and will resume creating backups according to the cron schedule.
+
+- **skipImmediately**: Controls whether to skip an immediate backup when a schedule is created or unpaused. By default (when `false`), if a backup is due immediately upon creation or unpausing, it will be executed right away. When set to `true`, the controller will:
+  1. Skip the immediate backup
+  2. Record the current time in the `lastSkipped` status field
+  3. Automatically reset `skipImmediately` back to `false` (one-time use)
+  4. Schedule the next backup based on the cron expression, using `lastSkipped` as the reference time
+
+- **lastSkipped**: A status field (not directly settable) that records when a backup was last skipped due to `skipImmediately` being `true`. The controller uses this timestamp, if more recent than `lastBackup`, to calculate the next scheduled backup time.
+
+This "consume and reset" pattern for `skipImmediately` ensures that after skipping one immediate backup, the schedule returns to normal behavior for subsequent runs without requiring user intervention.
+
+## API GroupVersion
+
+Schedule belongs to the API group version `velero.io/v1`.
+
+## Definition
+
+Here is a sample `Schedule` object with each of the fields documented:
+
+```yaml
+# Standard Kubernetes API Version declaration. Required.
+apiVersion: velero.io/v1
+# Standard Kubernetes Kind declaration. Required.
+kind: Schedule
+# Standard Kubernetes metadata. Required.
+metadata:
+  # Schedule name. May be any valid Kubernetes object name. Required.
+  name: a
+  # Schedule namespace. Must be the namespace of the Velero server. Required.
+  namespace: velero
+# Parameters about the scheduled backup. Required.
+spec:
+  # Paused specifies whether the schedule is paused or not
+  paused: false
+  # SkipImmediately specifies whether to skip backup if schedule is due immediately when unpaused or created.
+  # This is a one-time flag that will be automatically reset to false after being consumed.
+  # When true, the controller will skip the immediate backup, set LastSkipped timestamp, and reset this to false.
+  skipImmediately: false
+  # Schedule is a Cron expression defining when to run the Backup
+  schedule: 0 7 * * *
+  # Specifies whether to use OwnerReferences on backups created by this Schedule. 
+  # Notice: if set to true, when schedule is deleted, backups will be deleted too. Optional.
+  useOwnerReferencesInBackup: false
+  # Template is the spec that should be used for each backup triggered by this schedule.
+  template:
+    # CSISnapshotTimeout specifies the time used to wait for
+    # CSI VolumeSnapshot status turns to ReadyToUse during creation, before
+    # returning error as timeout. The default value is 10 minute.
+    csiSnapshotTimeout: 10m
+    # resourcePolicy specifies the referenced resource policies that backup should follow
+    # optional
+    resourcePolicy:
+      kind: configmap
+      name: resource-policy-configmap
+    # Array of namespaces to include in the scheduled backup. If unspecified, all namespaces are included.
+    # Optional.
+    includedNamespaces:
+    - '*'
+    # Array of namespaces to exclude from the scheduled backup. Optional.
+    excludedNamespaces:
+    - some-namespace
+    # Array of resources to include in the scheduled backup. Resources may be shortcuts (for example 'po' for 'pods')
+    # or fully-qualified. If unspecified, all resources are included. Optional.
+    includedResources:
+    - '*'
+    # Array of resources to exclude from the scheduled backup. Resources may be shortcuts (for example 'po' for 'pods')
+    # or fully-qualified. Optional.
+    excludedResources:
+    - storageclasses.storage.k8s.io
+    orderedResources:
+      pods: mysql/mysql-cluster-replica-0,mysql/mysql-cluster-replica-1,mysql/mysql-cluster-source-0
+      persistentvolumes: pvc-87ae0832-18fd-4f40-a2a4-5ed4242680c4,pvc-63be1bb0-90f5-4629-a7db-b8ce61ee29b3
+    # Whether to include cluster-scoped resources. Valid values are true, false, and
+    # null/unset. If true, all cluster-scoped resources are included (subject to included/excluded
+    # resources and the label selector). If false, no cluster-scoped resources are included. If unset,
+    # all cluster-scoped resources are included if and only if all namespaces are included and there are
+    # no excluded namespaces. Otherwise, if there is at least one namespace specified in either
+    # includedNamespaces or excludedNamespaces, then the only cluster-scoped resources that are backed
+    # up are those associated with namespace-scoped resources included in the scheduled backup. For example, if a
+    # PersistentVolumeClaim is included in the backup, its associated PersistentVolume (which is
+    # cluster-scoped) would also be backed up.
+    includeClusterResources: null
+    # Array of cluster-scoped resources to exclude from the backup. Resources may be shortcuts 
+    # (for example 'sc' for 'storageclasses'), or fully-qualified. If unspecified, 
+    # no additional cluster-scoped resources are excluded. Optional.
+    # Cannot work with include-resources, exclude-resources and include-cluster-resources.
+    excludedClusterScopedResources: {}
+    # Array of cluster-scoped resources to include from the backup. Resources may be shortcuts 
+    # (for example 'sc' for 'storageclasses'), or fully-qualified. If unspecified, 
+    # no additional cluster-scoped resources are included. Optional.
+    # Cannot work with include-resources, exclude-resources and include-cluster-resources.
+    includedClusterScopedResources: {}
+    # Array of namespace-scoped resources to exclude from the backup. Resources may be shortcuts 
+    # (for example 'cm' for 'configmaps'), or fully-qualified. If unspecified, 
+    # no namespace-scoped resources are excluded. Optional.
+    # Cannot work with include-resources, exclude-resources and include-cluster-resources.
+    excludedNamespaceScopedResources: {}
+    # Array of namespace-scoped resources to include from the backup. Resources may be shortcuts 
+    # (for example 'cm' for 'configmaps'), or fully-qualified. If unspecified, 
+    # all namespace-scoped resources are included. Optional.
+    # Cannot work with include-resources, exclude-resources and include-cluster-resources.
+    includedNamespaceScopedResources: {}
+    # Individual objects must match this label selector to be included in the scheduled backup. Optional.
+    labelSelector:
+      matchLabels:
+        app: velero
+        component: server
+    # Individual object when matched with any of the label selector specified in the set are to be included in the backup. Optional.
+    # orLabelSelectors as well as labelSelector cannot co-exist, only one of them can be specified in the backup request
+    orLabelSelectors:
+      - matchLabels:
+          app: velero
+      - matchLabels:
+          app: data-protection
+    # Whether to snapshot volumes. Valid values are true, false, and null/unset. If unset, Velero performs snapshots as long as
+    # a persistent volume provider is configured for Velero.
+    snapshotVolumes: null
+    # Where to store the tarball and logs.
+    storageLocation: aws-primary
+    # The list of locations in which to store volume snapshots created for backups under this schedule.
+    volumeSnapshotLocations:
+      - aws-primary
+      - gcp-primary
+    # The amount of time before backups created on this schedule are eligible for garbage collection. If not specified,
+    # a default value of 30 days will be used. The default can be configured on the velero server
+    # by passing the flag --default-backup-ttl.
+    ttl: 24h0m0s
+    # whether pod volume file system backup should be used for all volumes by default.
+    defaultVolumesToFsBackup: true
+    # Whether snapshot data should be moved. If set, data movement is launched after the snapshot is created.
+    snapshotMoveData: true
+    # The data mover to be used by the backup. If the value is "" or "velero", the built-in data mover will be used.
+    datamover: velero
+    # UploaderConfig specifies the configuration for the uploader
+    uploaderConfig:
+        # ParallelFilesUpload is the number of files parallel uploads to perform when using the uploader.
+        parallelFilesUpload: 10
+    # The labels you want on backup objects, created from this schedule (instead of copying the labels you have on schedule object itself).
+    # When this field is set, the labels from the Schedule resource are not copied to the Backup resource.
+    metadata:
+      labels:
+        labelname: somelabelvalue
+    # Actions to perform at different times during a backup. The only hook supported is
+    # executing a command in a container in a pod using the pod exec API. Optional.
+    hooks:
+      # Array of hooks that are applicable to specific resources. Optional.
+      resources:
+        -
+          # Name of the hook. Will be displayed in backup log.
+          name: my-hook
+          # Array of namespaces to which this hook applies. If unspecified, the hook applies to all
+          # namespaces. Optional.
+          includedNamespaces:
+          - '*'
+          # Array of namespaces to which this hook does not apply. Optional.
+          excludedNamespaces:
+          - some-namespace
+          # Array of resources to which this hook applies. The only resource supported at this time is
+          # pods.
+          includedResources:
+          - pods
+          # Array of resources to which this hook does not apply. Optional.
+          excludedResources: []
+          # This hook only applies to objects matching this label selector. Optional.
+          labelSelector:
+            matchLabels:
+              app: velero
+              component: server
+          # An array of hooks to run before executing custom actions. Only "exec" hooks are supported.
+          pre:
+            -
+              # The type of hook. This must be "exec".
+              exec:
+                # The name of the container where the command will be executed. If unspecified, the
+                # first container in the pod will be used. Optional.
+                container: my-container
+                # The command to execute, specified as an array. Required.
+                command:
+                  - /bin/uname
+                  - -a
+                # How to handle an error executing the command. Valid values are Fail and Continue.
+                # Defaults to Fail. Optional.
+                onError: Fail
+                # How long to wait for the command to finish executing. Defaults to 30 seconds. Optional.
+                timeout: 10s
+          # An array of hooks to run after all custom actions and additional items have been
+          # processed. Only "exec" hooks are supported.
+          post:
+            # Same content as pre above.
+status:
+  # The current phase.
+  # Valid values are New, Enabled, FailedValidation.
+  phase: ""
+  # Date/time of the last backup for a given schedule
+  lastBackup:
+  # Date/time when a backup was last skipped due to skipImmediately being true
+  lastSkipped:
+  # An array of any validation errors encountered.
+  validationErrors:
+```
@@ -0,0 +1,46 @@
+---
+title: "Velero Volume Snapshot Location"
+layout: docs
+---
+
+## Volume Snapshot Location
+
+A volume snapshot location is the location in which to store the volume snapshots created for a backup.
+
+Velero can be configured to take snapshots of volumes from multiple providers. Velero also allows you to configure multiple possible `VolumeSnapshotLocation` per provider, although you can only select one location per provider at backup time.
+
+Each VolumeSnapshotLocation describes a provider + location. These are represented in the cluster via the `VolumeSnapshotLocation` CRD. Velero must have at least one `VolumeSnapshotLocation` per cloud provider.
+
+A sample YAML `VolumeSnapshotLocation` looks like the following:
+
+```yaml
+apiVersion: velero.io/v1
+kind: VolumeSnapshotLocation
+metadata:
+  name: aws-default
+  namespace: velero
+spec:
+  provider: aws
+  credential:
+    name: secret-name
+    key: key-in-secret
+  config:
+    region: us-west-2
+    profile: "default"
+```
+
+### Parameter Reference
+
+The configurable parameters are as follows:
+
+#### Main config parameters
+
+{{< table caption="Main config parameters" >}}
+| Key | Type | Default | Meaning |
+| --- | --- | --- | --- |
+| `provider` | String | Required Field | The name for whichever storage provider will be used to create/store the volume snapshots. See [your volume snapshot provider's plugin documentation](../supported-providers) for the appropriate value to use. |
+| `config` | map string string | None (Optional) |  Provider-specific configuration keys/values to be passed to the volume snapshotter plugin. See [your volume snapshot provider's plugin documentation](../supported-providers) for details. |
+| `credential` | [corev1.SecretKeySelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#secretkeyselector-v1-core) | Optional Field | The credential information to be used with this location. |
+| `credential/name` | String | Optional Field | The name of the secret within the Velero namespace which contains the credential information. |
+| `credential/key` | String | Optional Field | The key to use within the secret. |
+{{< /table >}}
@@ -0,0 +1,126 @@
+---
+title: "Backup Hooks"
+layout: docs
+---
+
+Velero supports executing commands in containers in pods during a backup.
+
+## Backup Hooks
+
+When performing a backup, you can specify one or more commands to execute in a container in a pod
+when that pod is being backed up. The commands can be configured to run *before* any custom action
+processing ("pre" hooks), or after all custom actions have been completed and any additional items
+specified by custom action have been backed up ("post" hooks). Note that hooks are _not_ executed within a shell
+on the containers.
+
+As of Velero 1.15, related items that must be backed up together are grouped into ItemBlocks, and pod hooks run before and after the ItemBlock is backed up.
+In particular, this means that if an ItemBlock contains more than one pod (such as in a scenario where an RWX volume is mounted by multiple pods), pre hooks are run for all pods in the ItemBlock, then the items are backed up, then all post hooks are run.
+
+There are two ways to specify hooks: annotations on the pod itself, and in the Backup spec.
+
+### Specifying Hooks As Pod Annotations
+
+You can use the following annotations on a pod to make Velero execute a hook when backing up the pod:
+
+#### Pre hooks
+
+* `pre.hook.backup.velero.io/container`
+  * The container where the command should be executed. Defaults to the first container in the pod. Optional.
+* `pre.hook.backup.velero.io/command`
+  * The command to execute. This command is not executed within a shell by default. If a shell is needed to run your command, include a shell command, like `/bin/sh`, that is supported by the container at the beginning of your command. If you need multiple arguments, specify the command as a JSON array, such as `["/usr/bin/uname", "-a"]`. See [examples of using pre hook commands](#backup-hook-commands-examples). Optional.
+* `pre.hook.backup.velero.io/on-error`
+  * What to do if the command returns a non-zero exit code.  Defaults to `Fail`. Valid values are Fail and Continue. Optional.
+* `pre.hook.backup.velero.io/timeout`
+  * How long to wait for the command to execute. The hook is considered in error if the command exceeds the timeout. Defaults to 30s. Optional.
+
+
+#### Post hooks
+
+* `post.hook.backup.velero.io/container`
+  * The container where the command should be executed. Default is the first container in the pod. Optional.
+* `post.hook.backup.velero.io/command`
+  * The command to execute. This command is not executed within a shell by default. If a shell is needed to run your command, include a shell command, like `/bin/sh`, that is supported by the container at the beginning of your command. If you need multiple arguments, specify the command as a JSON array, such as `["/usr/bin/uname", "-a"]`. See [examples of using pre hook commands](#backup-hook-commands-examples). Optional.
+* `post.hook.backup.velero.io/on-error`
+  * What to do if the command returns a non-zero exit code.  Defaults to `Fail`. Valid values are Fail and Continue. Optional.
+* `post.hook.backup.velero.io/timeout`
+  * How long to wait for the command to execute. The hook is considered in error if the command exceeds the timeout. Defaults to 30s. Optional.
+
+### Specifying Hooks in the Backup Spec
+
+Please see the documentation on the [Backup API Type][1] for how to specify hooks in the Backup
+spec.
+
+## Hook Example with fsfreeze
+
+This examples walks you through using both pre and post hooks for freezing a file system. Freezing the
+file system is useful to ensure that all pending disk I/O operations have completed prior to taking a snapshot.
+
+### Annotations
+
+The Velero [example/nginx-app/with-pv.yaml][2] serves as an example of adding the pre and post hook annotations directly
+to your declarative deployment. Below is an example of what updating an object in place might look like.
+
+```shell
+kubectl annotate pod -n nginx-example -l app=nginx \
+    pre.hook.backup.velero.io/command='["/sbin/fsfreeze", "--freeze", "/var/log/nginx"]' \
+    pre.hook.backup.velero.io/container=fsfreeze \
+    post.hook.backup.velero.io/command='["/sbin/fsfreeze", "--unfreeze", "/var/log/nginx"]' \
+    post.hook.backup.velero.io/container=fsfreeze
+```
+
+Now test the pre and post hooks by creating a backup. You can use the Velero logs to verify that the pre and post
+hooks are running and exiting without error.
+
+```shell
+velero backup create nginx-hook-test
+
+velero backup get nginx-hook-test
+velero backup logs nginx-hook-test | grep hookCommand
+```
+
+## Backup hook commands examples
+
+### Multiple commands
+
+To use multiple commands, wrap your target command in a shell and separate them with `;`, `&&`, or other shell conditional constructs.
+
+```shell
+    pre.hook.backup.velero.io/command='["/bin/bash", "-c", "echo hello > hello.txt && echo goodbye > goodbye.txt"]'
+```
+
+#### Using environment variables
+
+You are able to use environment variables from your pods in your pre and post hook commands by including a shell command before using the environment variable. For example, `MYSQL_ROOT_PASSWORD` is an environment variable defined in pod called `mysql`. To use `MYSQL_ROOT_PASSWORD` in your pre-hook, you'd include a shell, like `/bin/sh`, before calling your environment variable:
+
+```
+pre:
+- exec:
+    container: mysql
+    command:
+      - /bin/sh
+      - -c
+      - mysql --password=$MYSQL_ROOT_PASSWORD -e "FLUSH TABLES WITH READ LOCK"
+    onError: Fail
+```
+
+Note that the container must support the shell command you use. 
+
+## Backup Hook Execution Results
+### Viewing Results
+
+Velero records the execution results of hooks, allowing users to obtain this information by running the following command:
+
+```bash
+$ velero backup describe <backup name>
+```
+
+The displayed results include the number of hooks that were attempted to be executed and the number of hooks that failed execution. Any detailed failure reasons will be present in `Errors` section if applicable. 
+
+```bash
+HooksAttempted:   1
+HooksFailed:      0
+```
+
+
+[1]: api-types/backup.md
+[2]: https://github.com/vmware-tanzu/velero/blob/v1.18.0/examples/nginx-app/with-pv.yaml
@@ -0,0 +1,167 @@
+---
+title: "Backup Reference"
+layout: docs
+---
+
+## Exclude Specific Items from Backup
+
+It is possible to exclude individual items from being backed up, even if they match the resource/namespace/label selectors defined in the backup spec. To do this, label the item as follows:
+
+```bash
+kubectl label -n <ITEM_NAMESPACE> <RESOURCE>/<NAME> velero.io/exclude-from-backup=true
+```
+## Parallel Files Upload
+If using fs-backup with Kopia uploader or CSI snapshot data movements, it's allowed to configure the option for parallel files upload, which could accelerate the backup:
+```bash
+velero backup create <BACKUP_NAME> --include-namespaces <NAMESPACE> --parallel-files-upload <NUM> --wait
+```
+
+## Specify Backup Orders of Resources of Specific Kind
+
+To backup resources of specific Kind in a specific order, use option --ordered-resources to specify a mapping Kinds to an ordered list of specific resources of that Kind.  Resource names are separated by commas and their names are in format 'namespace/resourcename'. For cluster scope resource, simply use resource name. Key-value pairs in the mapping are separated by semi-colon.  Kind name is in plural form.
+
+```bash
+velero backup create backupName --include-cluster-resources=true --ordered-resources 'pods=ns1/pod1,ns1/pod2;persistentvolumes=pv4,pv8' --include-namespaces=ns1
+velero backup create backupName --ordered-resources 'statefulsets=ns1/sts1,ns1/sts0' --include-namespaces=ns1
+```
+## Schedule a Backup
+
+The **schedule** operation allows you to create a backup of your data at a specified time, defined by a [Cron expression](https://en.wikipedia.org/wiki/Cron).
+
+```
+velero schedule create NAME --schedule="* * * * *" [flags]
+```
+
+Cron schedules use the following format.
+
+```
+# ┌───────────── minute (0 - 59)
+# │ ┌───────────── hour (0 - 23)
+# │ │ ┌───────────── day of the month (1 - 31)
+# │ │ │ ┌───────────── month (1 - 12)
+# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
+# │ │ │ │ │                                   7 is also Sunday on some systems)
+# │ │ │ │ │
+# │ │ │ │ │
+# * * * * *
+```
+
+For example, the command below creates a backup that runs every day at 3am.
+
+```
+velero schedule create example-schedule --schedule="0 3 * * *"
+```
+
+This command will create the backup, `example-schedule`, within Velero, but the backup will not be taken until the next scheduled time, 3am. Backups created by a schedule are saved with the name `<SCHEDULE NAME>-<TIMESTAMP>`, where `<TIMESTAMP>` is formatted as *YYYYMMDDhhmmss*. For a full list of available configuration flags use the Velero CLI help command.
+
+```
+velero schedule create --help
+```
+
+Once you create the scheduled backup, you can then trigger it manually using the `velero backup` command.
+
+```
+velero backup create --from-schedule example-schedule
+```
+
+This command will immediately trigger a new backup based on your template for `example-schedule`. This will not affect the backup schedule, and another backup will trigger at the scheduled time.
+
+### Time zone specification
+Time zone can be specified in the schedule cron. The format is `CRON_TZ=<timezone> <cron>`.
+
+Specifying timezones can reduce disputes in the case of daylight saving time changes. For example, if the schedule is set to run at 3am, and daylight saving time changes, the schedule will still run at 3am in the timezone specified.
+
+Be aware that jobs scheduled during daylight-savings leap-ahead transitions will not be run!
+
+For example, the command below creates a backup that runs every day at 3am in the timezone `America/New_York`.
+
+```
+velero schedule create example-schedule --schedule="CRON_TZ=America/New_York 0 3 * * *"
+```
+
+Another example, the command below creates a backup that runs every day at 3am in the timezone `Asia/Shanghai`.
+
+```
+velero schedule create example-schedule --schedule="CRON_TZ=Asia/Shanghai 0 3 * * *"
+```
+
+The supported timezone names are listed in the [IANA Time Zone Database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List) under 'TZ identifier'.
+<!--
+cron's WithLocation functions uses time.Location as parameter, and [time.LoadLocation](https://pkg.go.dev/time#LoadLocation) support names from IANA timezone database in following locations in this order
+- the directory or uncompressed zip file named by the ZONEINFO environment variable
+- on a Unix system, the system standard installation location
+- $GOROOT/lib/time/zoneinfo.zip
+- the time/tzdata package, if it was imported
+ -->
+
+### Limitation
+
+#### Backup's OwnerReference with Schedule
+Backups created from schedule can have owner reference to the schedule. This can be achieved by command:
+
+```
+velero schedule create --use-owner-references-in-backup <backup-name>
+```
+By this way, schedule is the owner of it created backups. This is useful for some GitOps scenarios, or the resource tree of k8s synchronized from other places.
+
+Please do notice there is also side effect that may not be expected. Because schedule is the owner, when the schedule is deleted, the related backups CR (Just backup CR is deleted. Backup data still exists in object store and snapshots) will be deleted by k8s GC controller, too, but Velero controller will sync these backups from object store's metadata into k8s. Then k8s GC controller and Velero controller will fight over whether these backups should exist all through.
+
+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.
+
+Even with versions prior to 1.11, there was no explicit support in Velero to work with object storage that has "immutability" configuration. As a result, you may see some problems even though backups seem to work (e.g. versions objects not being deleted when backup is deleted).
+
+Note that backups may still work in some cases depending on specific providers and configurations.
+
+* For AWS S3 service, backups work because S3's object lock only applies to versioned buckets, and the object data can still be updated as the new version. But when backups are deleted, old versions of the objects will not be deleted.
+* Azure Storage Blob supports both versioned-level immutability and container-level immutability. For the versioned-level scenario, data immutability can still work in Velero, but the container-level cannot.
+* GCP Cloud storage policy only supports bucket-level immutability, so there is no way to make it work in the GCP environment.
+
+The following are the links to cloud providers' documentation in this regard:
+
+* [AWS S3 Using S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html)
+* [Azure Storage Blob Containers - Lock Immutability Policy](https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-version-scope?tabs=azure-portal)
+* [GCP cloud storage Retention policies and retention policy locks](https://cloud.google.com/storage/docs/bucket-lock)
+ 
+## Kubernetes API Pagination
+
+By default, Velero will paginate the LIST API call for each resource type in the Kubernetes API when collecting items into a backup. The `--client-page-size` flag for the Velero server configures the size of each page.
+
+Depending on the cluster's scale, tuning the page size can improve backup performance. You can experiment with higher values, noting their impact on the relevant `apiserver_request_duration_seconds_*` metrics from the Kubernetes apiserver.
+
+Pagination can be entirely disabled by setting `--client-page-size` to `0`. This will request all items in a single unpaginated LIST call.
+
+## Deleting Backups
+
+Use the following commands to delete Velero backups and data:
+
+* `kubectl delete backup <backupName> -n <veleroNamespace>` will delete the backup custom resource only and will not delete any associated data from object/block storage
+* `velero backup delete <backupName>` will delete the backup resource including all data in object/block storage
@@ -0,0 +1,63 @@
+---
+title: "Backup Repository Configuration"
+layout: docs
+---
+
+Velero uses selectable backup repositories for various backup/restore methods, i.e., [file-system backup][1], [CSI snapshot data movement][2], etc. To achieve the best performance, backup repositories may need to be configured according to the running environments.  
+
+Velero uses a BackupRepository CR to represent the instance of the backup repository. Now, a new field `repositoryConfig` is added to support various configurations to the underlying backup repository.  
+
+Velero also allows you to specify configurations before the BackupRepository CR is created through a configMap. The configurations in the configMap will be copied to the BackupRepository CR when it is created at the due time.  
+The configMap should be in the same namespace where Velero is installed. If multiple Velero instances are installed in different namespaces, there should be one configMap in each namespace which applies to Velero instance in that namespace only. The name of the configMap should be specified in the Velero server parameter `--backup-repository-configmap`.  
+
+
+The users can specify the ConfigMap name during velero installation by CLI:
+`velero install --backup-repository-configmap=<ConfigMap-Name>`
+
+Conclusively, you have two ways to add/change/delete configurations of a backup repository:  
+- If the BackupRepository CR for the backup repository is already there, you should modify the `repositoryConfig` field. The new changes will be applied to the backup repository at the due time, it doesn't require Velero server to restart.   
+- Otherwise, you can create the backup repository configMap as a template for the BackupRepository CRs that are going to be created.  
+
+The backup repository configMap is repository type (i.e., kopia, restic) specific, so for one repository type, you only need to create one set of configurations, they will be applied to all BackupRepository CRs of the same type. Whereas, the changes of `repositoryConfig` field apply to the specific BackupRepository CR only, you may need to change every BackupRepository CR of the same type.  
+
+Below is an example of the BackupRepository configMap with the configurations:  
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: <config-name>
+  namespace: velero
+data:
+  <kopia>: |
+    {
+      "cacheLimitMB": 2048,
+      "fullMaintenanceInterval": "fastGC"
+    }
+  <other-repository-type>: |
+    {
+      "cacheLimitMB": 1024   
+    } 
+```
+
+To create the configMap, you need to save something like the above sample to a file and then run below commands:  
+```shell
+kubectl apply -f <yaml-file-name>
+```
+
+When and how the configurations are used is decided by the backup repository itself. Though you can specify any configuration to the configMap or `repositoryConfig`, the configuration may/may not be used by the backup repository, or the configuration may be used at an arbitrary time.  
+
+Below is the supported configurations by Velero and the specific backup repository.  
+***Kopia repository:***  
+`cacheLimitMB`: specifies the size limit(in MB) for the local data cache. The more data is cached locally, the less data may be downloaded from the backup storage, so the better performance may be achieved. Practically, you can specify any size that is smaller than the free space so that the disk space won't run out. This parameter is for repository connection, that is, you could change it before connecting to the repository. E.g., before a backup/restore/maintenance.  
+
+`fullMaintenanceInterval`: The full maintenance interval defaults to kopia defaults of 24 hours. Override options below allows for faster removal of deleted velero backups from kopia repo.
+- normalGC: 24 hours
+- fastGC: 12 hours
+- eagerGC: 6 hours
+
+Per kopia [Maintenance Safety](https://kopia.io/docs/advanced/maintenance/#maintenance-safety), it is expected that velero backup deletion will not result in immediate kopia repository data removal. Reducing full maintenance interval using above options should help reduce time taken to remove blobs not in use.
+
+On the other hand, the not-in-use data will be deleted permanently after the full maintenance, so shorter full maintenance intervals may weaken the data safety if they are used incorrectly.
+
+[1]: file-system-backup.md
+[2]: csi-snapshot-data-movement.md
@@ -0,0 +1,79 @@
+---
+title: "Backup Restore Windows Workloads"
+layout: docs
+---
+
+## Prerequisites
+
+Velero supports to backup and restore Windows workloads, either stateless or stateful.  
+To keep compatibility to the existing Velero plugins, Velero server runs in linux nodes only, so Velero requires at least one linux node in the cluster. And it is not recommended to run Velero server in control plane, so a linux worker node is required. For resource requirement of the linux node for Velero server, see [Customize resource requests and limits][1].  
+
+Velero is built and tested with `windows/amd64/ltsc2022` container only, older Windows versions, i.e., Windows Server 2019, are not supported.  
+
+For volume backups, CSI and CSI snapshot should be supported by the storage.  
+
+## Installation
+
+As mentioned in [Image building][2], a hybrid image is provided for all platforms, so you don't need to set different images for linux and Windows clusters, you can always use the all-in-one image, e.g., `velero/velero:v1.16.0` or `velero/velero:main`.  
+
+In order to backup/restore volumes for stateful workloads, Velero node-agent needs to run in the Windows nodes. Velero provides a dedicated daemonset for Windows nodes, called `node-agent-windows`.  
+Therefore, in a typical cluster with linux and Windows nodes, there are two daemonsets for Velero node-agent, the existing `node-agent` deamonset for linux nodes, and the `node-agent-windows` daemonset for Windows nodes.  
+If you want to install `node-agent` deamonset, specify `--use-node-agent` parameter in `velero install` command; and if you want to install `node-agent-windows` daemonset, specify `--use-node-agent-windows` parameter.  
+
+## Resource backup restore
+
+Resource backup/restore for Windows workloads are done by Velero server as same as linux workloads.  
+
+Since Velero server is running in linux nodes only, all the existing plugins, i.e., BIA, RIA, BackupStore plugins, could be started by Velero in a cluster with Windows nodes. However, whether or how the plugins are functional to Windows workloads are decided by the plugins themselves.  
+It is recommended that plugin providers do a well round test with Velero in Windows cluster environments, and:
+- If they need to support Windows workloads, make the necessary modification to ensure their plugins work well with Windows workloads
+- If they don't want to support Windows workloads, or part of the Windows workloads, they need to ensure the plugins won't cause any failure or crash when they process the undesired Windows workload items
+
+## Volume backup restore
+
+Below are the status of supportive of Windows workload volumes for different backup methods:
+- CSI snapshot data movement: block volumes (i.e., vSphere CNS Block Volume, Azure Disk, AWS EBS, GCP Persistent Disk, etc.) are full supported; file volumes (i.e., vSphere CNS File Volume, Azure File, AWS EFS, GCP Filestore, etc.) are not tested or officially supported. This is the same with linux workloads
+- CSI snapshot backup: block volumes (i.e., vSphere CNS Block Volume, Azure Disk, AWS EBS, GCP Persistent Disk, etc.) are full supported; file volumes (i.e., vSphere CNS File Volume, Azure File, AWS EFS, GCP Filestore, etc.) are not tested or officially supported. This is the same with linux workloads
+- native snapshot backup: supported as same as linux workloads
+- file system backup: at present, NOT supported
+
+For volume backups/restores conducted through Velero plugins, the supportive status is decided by the plugin themselves.  
+
+### CSI snapshot data movement
+
+During backup, Velero automatically identifies the OS type of the workload and schedules data mover pods to the right nodes. Specifically, for a linux workload, linux nodes in the cluster will be used; for a Windows workload, Windows nodes in the cluster will be used.  
+You could view the OS type that a data mover pod is running with from the DataUpload status's `nodeOS` field.   
+
+Velero takes several measures to deduce the OS type for volumes of workloads, from PVCs, VolumeAttach CRs, nodes and storage classes. If Velero fails to deduce the OS type, it fallbacks to linux, then the data mover pods will be scheduled to linux nodes. As a result, the data mover pods may not be able to start and the corresponding DataUploads will be cancelled because of timeout, so the backup will be partially failed.  
+
+Therefore, it is highly recommended you provide a dedicated storage class for Windows workloads volumes, and set `csi.storage.k8s.io/fstype` correctly. E.g., for linux workload volumes, set `csi.storage.k8s.io/fstype=ext4`; for Windows workload volumes set `csi.storage.k8s.io/fstype=ntfs`.  
+Specifically, if you have X number of storage classes for linux workloads, you need to create another X number of storage classes for Windows workloads.  
+This is helpful for Velero to deduce the right OS type successfully all the time, especially when you are backing up below kind of volumes belonging to a Windows workload:
+- The PVC is with Immediate mode
+- There is no pod mounting the PVC at the time of backup
+
+For restore, Velero automatically inherits the OS type from backup, so no deduction process is required.  
+
+For other information, check [CSI Snapshot Data Movement][3].  
+
+
+## Backup Repository Maintenance job
+
+Backup Repository Maintenance jobs and pods are supported to run in Windows nodes, that is, you can take full node resources in a cluster with Windows nodes for Backup Repository Maintenance. For more information, check [Repository Maintenance][4].  
+
+## Backup restore hooks
+
+Pre/post backup/restore hooks are supported for Windows workloads, the commands run in the same Windows nodes hosting the workload pods. For more information, check [Backup Hooks][5] and [Restore Hooks][6].  
+
+## Limitations
+
+NTFS extended attributes/advanced features are not supported, i.e., Security Descriptors, System/Hidden/ReadOnly attributes, Creation Time, NTFS Streams, etc. That is, after backup/restore, these data will be lost.  
+
+
+
+[1]: customize-installation.md#customize-resource-requests-and-limits
+[2]: build-from-source.md#image-building
+[3]: csi-snapshot-data-movement.md
+[4]: repository-maintenance.md
+[5]: backup-hooks.md
+[6]: restore-hooks.md
@@ -0,0 +1,73 @@
+---
+title: "Basic Install"
+layout: docs
+---
+
+Use this doc to get a basic installation of Velero.
+Refer [this document](customize-installation.md) to customize your installation, including setting priority classes for Velero components.
+
+## Prerequisites
+
+- Access to a Kubernetes cluster, v1.16 or later, with DNS and container networking enabled. For more information on supported Kubernetes versions, see the Velero [compatibility matrix](https://github.com/vmware-tanzu/velero#velero-compatibility-matrix).
+- `kubectl` installed locally
+
+Velero uses object storage to store backups and associated artifacts. It also optionally integrates with supported block storage systems to snapshot your persistent volumes. Before beginning the installation process, you should identify the object storage provider and optional block storage provider(s) you'll be using from the list of [compatible providers][0].
+
+Velero supports storage providers for both cloud-provider environments and on-premises environments. For more details on on-premises scenarios, see the [on-premises documentation][2].
+
+### Velero on Windows
+
+Velero supports to backup and restore Windows workloads, either stateless or stateful.
+Velero node-agent and data mover pods could run in Windows nodes. To keep compatibility to the existing Velero plugins, Velero server runs in linux nodes only, so Velero requires at least one linux node in the cluster. Velero provides Windows images for specific Windows versions. For more information see [Backup Restore Windows Workloads][6].  
+
+## Install the CLI
+
+### Option 1: MacOS - Homebrew
+
+On macOS, you can use [Homebrew](https://brew.sh) to install the `velero` client:
+
+```bash
+brew install velero
+```
+
+### Option 2: GitHub release
+
+1. Download the [latest release][1]'s tarball for your client platform.
+1. Extract the tarball:
+
+   ```bash
+   tar -xvf <RELEASE-TARBALL-NAME>.tar.gz
+   ```
+
+1. Move the extracted `velero` binary to somewhere in your `$PATH` (`/usr/local/bin` for most users).
+
+### Option 3: Windows - Chocolatey
+
+On Windows, you can use [Chocolatey](https://chocolatey.org/install) to install the [velero](https://chocolatey.org/packages/velero) client:
+
+```powershell
+choco install velero
+```
+
+## Install and configure the server components
+
+There are two supported methods for installing the Velero server components:
+
+- the `velero install` CLI command
+- the [Helm chart](https://vmware-tanzu.github.io/helm-charts/)
+
+Velero uses storage provider plugins to integrate with a variety of storage systems to support backup and snapshot operations. The steps to install and configure the Velero server components along with the appropriate plugins are specific to your chosen storage provider. To find installation instructions for your chosen storage provider, follow the documentation link for your provider at our [supported storage providers][0] page
+
+_Note: if your object storage provider is different than your volume snapshot provider, follow the installation instructions for your object storage provider first, then return here and follow the instructions to [add your volume snapshot provider][4]._
+
+## Command line Autocompletion
+
+Please refer to [this part of the documentation][5].
+
+[0]: supported-providers.md
+[1]: https://github.com/vmware-tanzu/velero/releases/latest
+[2]: on-premises.md
+[3]: overview-plugins.md
+[4]: customize-installation.md#install-an-additional-volume-snapshot-provider
+[5]: customize-installation.md#optional-velero-cli-configurations
+[6]: backup-restore-windows.md
@@ -0,0 +1,198 @@
+---
+title: "Build from source"
+layout: docs
+---
+
+## Prerequisites
+
+* Access to a Kubernetes cluster, version 1.7 or later.
+* A DNS server on the cluster
+* `kubectl` installed
+* [Go][5] installed (minimum version 1.8)
+
+## Get the source
+
+### Option 1) Get latest (recommended)
+
+```bash
+mkdir $HOME/go
+export GOPATH=$HOME/go
+go get github.com/vmware-tanzu/velero
+```
+
+Where `go` is your [import path][4] for Go.
+
+For Go development, it is recommended to add the Go import path (`$HOME/go` in this example) to your path.
+
+### Option 2) Release archive
+
+Download the archive named `Source code` from the [release page][22] and extract it in your Go import path as `src/github.com/vmware-tanzu/velero`.
+
+Note that the Makefile targets assume building from a git repository. When building from an archive, you will be limited to the `go build` commands described below.
+
+## Build
+
+There are a number of different ways to build `velero` depending on your needs. This section outlines the main possibilities.
+
+When building by using `make`, it will place the binaries under `_output/bin/$GOOS/$GOARCH`. For example, you will find the binary for darwin here: `_output/bin/darwin/amd64/velero`, and the binary for linux here: `_output/bin/linux/amd64/velero`. `make` will also splice version and git commit information in so that `velero version` displays proper output.
+
+Note: `velero install` will also use the version information to determine which tagged image to deploy. If you would like to overwrite what image gets deployed, use the `image` flag (see below for instructions on how to build images).
+
+### Build the binary
+
+To build the `velero` binary on your local machine, compiled for your OS and architecture, run one of these two commands:
+
+```bash
+go build ./cmd/velero
+```
+
+```bash
+make local
+```
+
+### Cross compiling
+
+To build the velero binary targeting linux/amd64 within a build container on your local machine, run:
+
+```bash
+make build
+```
+
+For any specific platform, run `make build-<GOOS>-<GOARCH>`.
+
+For example, to build for the Mac, run `make build-darwin-amd64`.
+
+Velero's `Makefile` has a convenience target, `all-build`, that builds the following platforms:
+
+* linux-amd64
+* linux-arm
+* linux-arm64
+* linux-ppc64le
+* darwin-amd64
+* windows-amd64
+
+## Making images and updating Velero
+
+If after installing Velero you would like to change the image used by its deployment to one that contains your code changes, you may do so by updating the image:
+
+```bash
+kubectl -n velero set image deploy/velero velero=myimagerepo/velero:$VERSION
+```
+
+To build a Velero container image, you need to configure `buildx` first.
+
+### Buildx
+
+Docker Buildx is a CLI plugin that extends the docker command with the full support of the features provided by Moby BuildKit builder toolkit. It provides the same user experience as docker build with many new features like creating scoped builder instances and building against multiple nodes concurrently.
+
+More information in the [docker docs][23] and in the [buildx github][24] repo.
+
+### Image building
+
+#### Build local image
+
+If you want to build an image with the same OS type and CPU architecture with your local machine, you can keep most the build parameters as default.  
+Run below command to build the local image:  
+```bash
+make container
+```
+Optionally, set the `$VERSION` environment variable to change the image tag or `$BIN` to change which binary to build a container image for.  
+Optionally, you can set the `$REGISTRY` environment variable. For example, if you want to build the `gcr.io/my-registry/velero:main` image, set `$REGISTRY` to `gcr.io/my-registry`. If this variable is not set, the default is `velero`.  
+The image is preserved in the local machine, you can run `docker push` to push the image to the specified registry, or if not specified, docker hub by default.  
+
+#### Build hybrid image
+
+You can also build a hybrid image that supports multiple OS types or CPU architectures. A hybrid image contains a manifest list with one or more manifests each of which maps to a single `os type/arch/os version` configuration.  
+Below `os type/arch/os version` configurations are tested and supported:
+* `linux/amd64`
+* `linux/arm64`
+* `windows/amd64/ltsc2022`
+
+The hybrid image must be pushed to a registry as the local system doesn't support all the manifests in the image. So `BUILDX_OUTPUT_TYPE` parameter must be set as `registry`.  
+By default, `$REGISTRY` is set as `velero`, you can change it to your own registry.  
+
+To build a hybrid image, the following one time setup is necessary:
+
+1. If you are building cross platform container images
+    ```bash
+    $ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
+    ```
+2. Create and bootstrap a new docker buildx builder
+    ```bash
+    $ docker buildx create --use --name builder
+      builder
+    $ docker buildx inspect --bootstrap
+      [+] Building 2.6s (1/1) FINISHED
+      => [internal] booting buildkit                                2.6s
+      => => pulling image moby/buildkit:buildx-stable-1             1.9s
+      => => creating container buildx_buildkit_builder0             0.7s
+    Name:   builder
+    Driver: docker-container
+
+    Nodes:
+    Name:      builder0
+    Endpoint:  unix:///var/run/docker.sock
+    Status:    running
+    Platforms: linux/amd64, linux/arm64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
+    ```
+    NOTE: Without the above setup, the output of `docker buildx inspect --bootstrap` will be:
+    ```bash
+    $ docker buildx inspect --bootstrap
+    Name:   default
+    Driver: docker
+
+    Nodes:
+    Name:      default
+    Endpoint:  default
+    Status:    running
+    Platforms: linux/amd64, linux/arm64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
+    ```
+    And the `REGISTRY=myrepo BUILDX_OUTPUT_TYPE=registry make container` will fail with the below error:
+    ```bash
+    $ REGISTRY=ashishamarnath BUILDX_PLATFORMS=linux/arm64 BUILDX_OUTPUT_TYPE=registry make container
+    auto-push is currently not implemented for docker driver
+    make: *** [container] Error 1
+    ```
+
+Having completed the above one time setup, now the output of `docker buildx inspect --bootstrap` should be like
+
+```bash
+$ docker buildx inspect --bootstrap
+Name:   builder
+Driver: docker-container
+
+Nodes:
+Name:      builder0
+Endpoint:  unix:///var/run/docker.sock
+Status:    running
+Platforms: linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v
+```
+
+Now build and push the container image by running the `make container` command with `$BUILDX_OUTPUT_TYPE` set to `registry`.
+
+Blow command builds a hybrid image with single configuration `linux/amd64`:  
+```bash
+$ REGISTRY=myrepo BUILDX_OUTPUT_TYPE=registry make container
+```
+
+Blow command builds a hybrid image with configurations `linux/amd64` and `linux/arm64`:  
+```bash
+$ REGISTRY=myrepo BUILDX_OUTPUT_TYPE=registry BUILD_ARCH=amd64,arm64 make container
+```
+
+Blow command builds a hybrid image with configurations `linux/amd64`, `linux/arm64` and `windows/amd64/ltsc2022`:  
+```bash
+$ REGISTRY=myrepo BUILDX_OUTPUT_TYPE=registry BUILD_OS=linux,windows BUILD_ARCH=amd64,arm64 make container
+```
+
+Note: if you want to update the image but not change its name, you will have to trigger Kubernetes to pick up the new image. One way of doing so is by deleting the Velero deployment pod and node-agent pods:
+
+```bash
+kubectl -n velero delete pods -l deploy=velero
+```
+
+[4]: https://blog.golang.org/organizing-go-code
+[5]: https://golang.org/doc/install
+[22]: https://github.com/vmware-tanzu/velero/releases
+[23]: https://docs.docker.com/buildx/working-with-buildx/
+[24]: https://github.com/docker/buildx
@@ -0,0 +1,171 @@
+---
+title: "Code Standards"
+layout: docs
+toc: "true"
+---
+
+## Opening PRs
+
+When opening a pull request, please fill out the checklist supplied the template. This will help others properly categorize and review your pull request.
+
+### PR title
+
+Make sure that the pull request title summarizes the change made (and not just "fixes issue #xxxx"):
+
+Example PR titles:
+
+ - "Check for nil when validating foo"
+ - "Issue #1234: Check for nil when validating foo"
+
+### Cherry-pick PRs
+
+When a PR to main needs to be cherry-picked to a release branch, please wait until the main PR is merged first before creating the CP PR. If the CP PR is made before the main PR is merged, there is a risk that PR modifications in response to review comments will not make it into the CP PR.
+
+The Cherry-pick PR title should reference the branch it's cherry-picked to and the fact that it's a CP of a commit to main:
+
+ - "[release-1.13 CP] Issue #1234: Check for nil when validating foo"
+
+
+## Adding a changelog
+
+Authors are expected to include a changelog file with their pull requests. The changelog file
+should be a new file created in the `changelogs/unreleased` folder. The file should follow the
+naming convention of `pr-username` and the contents of the file should be your text for the
+changelog.
+
+    velero/changelogs/unreleased   <- folder
+        000-username            <- file
+
+Add that to the PR.
+
+A command to do this is `make new-changelog CHANGELOG_BODY="Changes you have made"`
+
+If a PR does not warrant a changelog, the CI check for a changelog can be skipped by applying a `changelog-not-required` label on the PR. If you are making a PR on a release branch, you should still make a new file in the `changelogs/unreleased` folder on the release branch for your change. 
+
+## Copyright header
+
+Whenever a source code file is being modified, the copyright notice should be updated to our standard copyright notice. That is, it should read “Copyright the Velero contributors.”
+
+For new files, the entire copyright and license header must be added.
+
+Please note that doc files do not need a copyright header.
+
+## Code
+
+- Log messages are capitalized.
+
+- Error messages are kept lower-cased.
+
+- Wrap/add a stack only to errors that are being directly returned from non-velero code, such as an API call to the Kubernetes server.
+
+    ```bash
+    errors.WithStack(err)
+    ```
+
+- Prefer to use the utilities in the Kubernetes package [`sets`](https://godoc.org/github.com/kubernetes/apimachinery/pkg/util/sets).
+
+    ```bash
+    k8s.io/apimachinery/pkg/util/sets
+    ```
+
+## Imports
+
+For imports, we use the following convention:
+
+`<group><version><api | client | informer | ...>`
+
+Example:
+
+    import (
+        corev1api "k8s.io/api/core/v1"
+    	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
+    	corev1client "k8s.io/client-go/kubernetes/typed/core/v1"
+    	corev1listers "k8s.io/client-go/listers/core/v1"
+
+        velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+        velerov1client "github.com/vmware-tanzu/velero/pkg/generated/clientset/versioned/typed/velero/v1"
+    )
+
+## Mocks
+
+We use a package to generate mocks for our interfaces.
+
+Example: if you want to change this mock: https://github.com/vmware-tanzu/velero/blob/v1.18.0/pkg/podvolume/mocks/restorer.go
+
+Run:
+
+```bash
+go get github.com/vektra/mockery/.../
+cd pkg/podvolume
+mockery -name=Restorer
+```
+
+Might need to run `make update` to update the imports.
+
+## Kubernetes Labels
+
+When generating label values, be sure to pass them through the `label.GetValidName()` helper function.
+
+This will help ensure that the values are the proper length and format to be stored and queried.
+
+In general, UIDs are safe to persist as label values.
+
+This function is not relevant to annotation values, which do not have restrictions.
+
+## DCO Sign off
+
+All authors to the project retain copyright to their work. However, to ensure
+that they are only submitting work that they have rights to, we are requiring
+everyone to acknowledge this by signing their work.
+
+Any copyright notices in this repo should specify the authors as "the Velero contributors".
+
+To sign your work, just add a line like this at the end of your commit message:
+
+```
+Signed-off-by: Joe Beda <joe@heptio.com>
+```
+
+This can easily be done with the `--signoff` option to `git commit`.
+
+By doing this you state that you can certify the following (from [https://developercertificate.org/](https://developercertificate.org/)):
+
+```
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+1 Letterman Drive
+Suite D4700
+San Francisco, CA, 94129
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.
+```
@@ -0,0 +1,102 @@
+---
+title: "Use IBM Cloud Object Storage as Velero's storage destination."
+layout: docs
+---
+You can deploy Velero on IBM [Public][5] or [Private][4] clouds, or even on any other Kubernetes cluster, but anyway you can use IBM Cloud Object Store as a destination for Velero's backups.
+
+To set up IBM Cloud Object Storage (COS) as Velero's destination, you:
+
+* Download an official release of Velero
+* Create your COS instance
+* Create an S3 bucket
+* Define a service that can store data in the bucket
+* Configure and start the Velero server
+
+## Download Velero
+
+1. Download the [latest official release's](https://github.com/vmware-tanzu/velero/releases) tarball for your client platform.
+
+    _We strongly recommend that you use an [official release](https://github.com/vmware-tanzu/velero/releases) of
+Velero. The tarballs for each release contain the `velero` command-line client. The code in the main branch
+of the Velero repository is under active development and is not guaranteed to be stable!_
+
+1. Extract the tarball:
+
+    ```bash
+    tar -xvf <RELEASE-TARBALL-NAME>.tar.gz -C /dir/to/extract/to
+    ```
+
+    The directory you extracted is called the "Velero directory" in subsequent steps.
+
+1. Move the `velero` binary from the Velero directory to somewhere in your PATH.
+
+## Create COS instance
+If you don’t have a COS instance, you can create a new one, according to the detailed instructions in [Creating a new resource instance][1].
+
+## Create an S3 bucket
+Velero requires an object storage bucket to store backups in. See instructions in [Create some buckets to store your data][2].
+
+## Define a service that can store data in the bucket.
+The process of creating service credentials is described in [Service credentials][3].
+Several comments:
+
+1. The Velero service will write its backup into the bucket, so it requires the “Writer” access role.
+
+2. Velero uses an AWS S3 compatible API. Which means it authenticates using a signature created from a pair of access and secret keys — a set of HMAC credentials. You can create these HMAC credentials by specifying `{“HMAC”:true}` as an optional inline parameter. See [HMAC credentials][31] guide.
+
+3. After successfully creating a Service credential, you can view the JSON definition of the credential. Under the `cos_hmac_keys` entry there are `access_key_id` and `secret_access_key`. Use them in the next step.
+
+4. Create a Velero-specific credentials file (`credentials-velero`) in your local directory:
+
+    ```
+    [default]
+    aws_access_key_id=<ACCESS_KEY_ID>
+    aws_secret_access_key=<SECRET_ACCESS_KEY>
+    ```
+
+    Where the access key id and secret are the values that you got above.
+
+## Install and start Velero
+
+Install Velero, including all prerequisites, into the cluster and start the deployment. This will create a namespace called `velero`, and place a deployment named `velero` in it.
+
+```bash
+velero install \
+    --provider aws \
+    --bucket <YOUR_BUCKET> \
+    --secret-file ./credentials-velero \
+    --plugins velero/velero-plugin-for-aws:v1.10.0\
+    --use-volume-snapshots=false \
+    --backup-location-config region=<YOUR_REGION>,s3ForcePathStyle="true",s3Url=<YOUR_URL_ACCESS_POINT>,checksumAlgorithm=""
+```
+
+Velero does not have a volume snapshot plugin for IBM Cloud, so creating volume snapshots is disabled.
+
+Additionally, you can specify `--use-node-agent` to enable [File System Backup][16], and `--wait` to wait for the deployment to be ready.
+
+(Optional) Specify [CPU and memory resource requests and limits][15] for the Velero/node-agent pods.
+
+Once the installation is complete, remove the default `VolumeSnapshotLocation` that was created by `velero install`, since it's specific to AWS and won't work for IBM Cloud:
+
+```bash
+kubectl -n velero delete volumesnapshotlocation.velero.io default
+```
+
+For more complex installation needs, use either the Helm chart, or add `--dry-run -o yaml` options for generating the YAML representation for the installation.
+
+## Installing the nginx example (optional)
+
+If you run the nginx example, in file `examples/nginx-app/with-pv.yaml`:
+
+Uncomment `storageClassName: <YOUR_STORAGE_CLASS_NAME>` and replace with your `StorageClass` name.
+
+[0]: ../namespace.md
+[1]: https://cloud.ibm.com/docs/cloud-object-storage/getting-started.html
+[2]: https://cloud.ibm.com/docs/cloud-object-storage/getting-started.html#create-buckets
+[3]: https://cloud.ibm.com/docs/cloud-object-storage/iam?topic=cloud-object-storage-service-credentials
+[31]: https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-uhc-hmac-credentials-main
+[4]: https://www.ibm.com/docs/en/cloud-private
+[5]: https://cloud.ibm.com/docs/containers/container_index.html#container_index
+[14]: http://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
+[15]: ../customize-installation.md#customize-resource-requests-and-limits
+[16]: ../file-system-backup.md
@@ -0,0 +1,301 @@
+---
+title: "Quick start evaluation install with Minio"
+layout: docs
+---
+
+The following example sets up the Velero server and client, then backs up and restores a sample application.
+
+For simplicity, the example uses Minio, an S3-compatible storage service that runs locally on your cluster.
+For additional functionality with this setup, see the section below on how to [expose Minio outside your cluster][1].
+
+**NOTE** The example lets you explore basic Velero functionality. Configuring Minio for production is out of scope.
+
+See [Set up Velero on your platform][3] for how to configure Velero for a production environment.
+
+If you encounter issues with installing or configuring, see [Debugging Installation Issues](debugging-install.md).
+
+## Prerequisites
+
+* Access to a Kubernetes cluster, version 1.7 or later.  **Note:** File System Backup support requires Kubernetes version 1.10 or later, or an earlier version with the mount propagation feature enabled. File System Backup support is not required for this example, but may be of interest later. See [File System Backup][17].
+* A DNS server on the cluster
+* `kubectl` installed
+* Sufficient disk space to store backups in Minio.  You will need sufficient disk space available to handle any
+backups plus at least 1GB additional.  Minio will not operate if less than 1GB of free disk space is available.
+
+## Install the CLI
+
+### Option 1: MacOS - Homebrew
+
+On macOS, you can use [Homebrew](https://brew.sh) to install the `velero` client:
+
+```bash
+brew install velero
+```
+
+### Option 2: GitHub release
+
+1. Download the [latest official release's](https://github.com/vmware-tanzu/velero/releases) tarball for your client platform.
+
+    _We strongly recommend that you use an [official release](https://github.com/vmware-tanzu/velero/releases) of
+Velero. The tarballs for each release contain the `velero` command-line client. The code in the main branch
+of the Velero repository is under active development and is not guaranteed to be stable!_
+
+1. Extract the tarball:
+
+    ```bash
+    tar -xvf <RELEASE-TARBALL-NAME>.tar.gz -C /dir/to/extract/to
+    ```
+
+    The directory you extracted is called the "Velero directory" in subsequent steps.
+
+1. Move the `velero` binary from the Velero directory to somewhere in your PATH.
+
+## Set up server
+
+These instructions start the Velero server and a Minio instance that is accessible from within the cluster only. See [Expose Minio outside your cluster](#expose-minio-outside-your-cluster-with-a-service) for information about configuring your cluster for outside access to Minio. Outside access is required to access logs and run `velero describe` commands.
+
+1. Create a Velero-specific credentials file (`credentials-velero`) in your Velero directory:
+
+    ```
+    [default]
+    aws_access_key_id = minio
+    aws_secret_access_key = minio123
+    ```
+
+1. Start the server and the local storage service. In the Velero directory, run:
+
+    ```
+    kubectl apply -f examples/minio/00-minio-deployment.yaml
+    ```
+    _Note_: The example Minio yaml provided uses "empty dir".  Your node needs to have enough space available to store the
+    data being backed up plus 1GB of free space.  If the node does not have enough space, you can modify the example yaml to
+    use a Persistent Volume instead of "empty dir"
+
+    ```
+    velero install \
+        --provider aws \
+        --plugins velero/velero-plugin-for-aws:v1.2.1 \
+        --bucket velero \
+        --secret-file ./credentials-velero \
+        --use-volume-snapshots=false \
+        --backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio.velero.svc:9000
+    ```
+
+    * This example assumes that it is running within a local cluster without a volume provider capable of snapshots, so no `VolumeSnapshotLocation` is created (`--use-volume-snapshots=false`). You may need to update AWS plugin version to one that is [compatible](https://github.com/vmware-tanzu/velero-plugin-for-aws#compatibility) with the version of Velero you are installing.
+
+    * Additionally, you can specify `--use-node-agent` to enable File System Backup support, and `--wait` to wait for the deployment to be ready.
+
+    * This example also assumes you have named your Minio bucket "velero".
+
+    * Please make sure to set parameter `s3ForcePathStyle=true`. The parameter is used to set the Velero integrated AWS SDK data query address style. There are two types of the address: [virtual-host and path-style](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html). If the `s3ForcePathStyle=true` is not set, the default value is false, then the AWS SDK will query in virtual-host style, but the MinIO server only support path-style address by default. The miss match will mean Velero can upload data to MinIO, but **cannot download from MinIO**. This [link](https://github.com/vmware-tanzu/velero/issues/7268) is an example of this issue.
+    It can be resolved by two ways:
+      * Set `s3ForcePathStyle=true` for parameter `--backup-location-config` when installing Velero. This is the preferred way.
+      * Make MinIO server support virtual-host style address. Add the [MINIO_DOMAIN environment variable](https://min.io/docs/minio/linux/reference/minio-server/settings/core.html#id5) for MinIO server will do the magic.
+
+
+1. Deploy the example nginx application:
+
+    ```bash
+    kubectl apply -f examples/nginx-app/base.yaml
+    ```
+
+1. Check to see that both the Velero and nginx deployments are successfully created:
+
+    ```
+    kubectl get deployments -l component=velero --namespace=velero
+    kubectl get deployments --namespace=nginx-example
+    ```
+
+## Back up
+
+1. Create a backup for any object that matches the `app=nginx` label selector:
+
+    ```
+    velero backup create nginx-backup --selector app=nginx
+    ```
+
+    Alternatively if you want to backup all objects *except* those matching the label `backup=ignore`:
+
+    ```
+    velero backup create nginx-backup --selector 'backup notin (ignore)'
+    ```
+
+1. (Optional) Create regularly scheduled backups based on a cron expression using the `app=nginx` label selector:
+
+    ```
+    velero schedule create nginx-daily --schedule="0 1 * * *" --selector app=nginx
+    ```
+
+    Alternatively, you can use some non-standard shorthand cron expressions:
+
+    ```
+    velero schedule create nginx-daily --schedule="@daily" --selector app=nginx
+    ```
+
+    See the [cron package's documentation][30] for more usage examples.
+
+1. Simulate a disaster:
+
+    ```
+    kubectl delete namespace nginx-example
+    ```
+
+1. To check that the nginx deployment and service are gone, run:
+
+    ```
+    kubectl get deployments --namespace=nginx-example
+    kubectl get services --namespace=nginx-example
+    kubectl get namespace/nginx-example
+    ```
+
+    You should get no results.
+
+    NOTE: You might need to wait for a few minutes for the namespace to be fully cleaned up.
+
+## Restore
+
+1. Run:
+
+    ```
+    velero restore create --from-backup nginx-backup
+    ```
+
+1. Run:
+
+    ```
+    velero restore get
+    ```
+
+    After the restore finishes, the output looks like the following:
+
+    ```
+    NAME                          BACKUP         STATUS      WARNINGS   ERRORS    CREATED                         SELECTOR
+    nginx-backup-20170727200524   nginx-backup   Completed   0          0         2017-07-27 20:05:24 +0000 UTC   <none>
+    ```
+
+NOTE: The restore can take a few moments to finish. During this time, the `STATUS` column reads `InProgress`.
+
+After a successful restore, the `STATUS` column is `Completed`, and `WARNINGS` and `ERRORS` are 0. All objects in the `nginx-example` namespace should be just as they were before you deleted them.
+
+If there are errors or warnings, you can look at them in detail:
+
+```
+velero restore describe <RESTORE_NAME>
+```
+
+For more information, see [the debugging information][18].
+
+## Clean up
+
+If you want to delete any backups you created, including data in object storage and persistent
+volume snapshots, you can run:
+
+```
+velero backup delete BACKUP_NAME
+```
+
+This asks the Velero server to delete all backup data associated with `BACKUP_NAME`.  You need to do
+this for each backup you want to permanently delete. A future version of Velero will allow you to
+delete multiple backups by name or label selector.
+
+Once fully removed, the backup is no longer visible when you run:
+
+```
+velero backup get BACKUP_NAME
+```
+
+To completely uninstall Velero, minio, and the nginx example app from your Kubernetes cluster:
+
+```
+kubectl delete namespace/velero clusterrolebinding/velero
+kubectl delete crds -l component=velero
+kubectl delete -f examples/nginx-app/base.yaml
+```
+
+## Expose Minio outside your cluster with a Service
+
+When you run commands to get logs or describe a backup, the Velero server generates a pre-signed URL to download the requested items. To access these URLs from outside the cluster -- that is, from your Velero client -- you need to make Minio available outside the cluster. You can:
+
+- Change the Minio Service type from `ClusterIP` to `NodePort`.
+- Set up Ingress for your cluster, keeping Minio Service type `ClusterIP`.
+
+You can also specify a `publicUrl` config field for the pre-signed URL in your backup storage location config.
+
+### Expose Minio with Service of type NodePort
+
+The Minio deployment by default specifies a Service of type `ClusterIP`. You can change this to `NodePort` to easily expose a cluster service externally if you can reach the node from your Velero client.
+
+You must also get the Minio URL, which you can then specify as the value of the `publicUrl` field in your backup storage location config.
+
+1.  In `examples/minio/00-minio-deployment.yaml`, change the value of Service `spec.type` from `ClusterIP` to `NodePort`.
+
+1.  Get the Minio URL:
+
+  - if you're running Minikube:
+
+      ```shell
+      minikube service minio --namespace=velero --url
+      ```
+
+  - in any other environment:
+    1.  Get the value of an external IP address or DNS name of any node in your cluster. You must be able to reach this address from the Velero client.
+    1.  Append the value of the NodePort to get a complete URL. You can get this value by running:
+
+        ```shell
+        kubectl -n velero get svc/minio -o jsonpath='{.spec.ports[0].nodePort}'
+        ```
+
+1.  Edit your `BackupStorageLocation` YAML, adding `publicUrl: <URL_FROM_PREVIOUS_STEP>` as a field under `spec.config`. You must include the `http://` or `https://` prefix.
+
+## Accessing logs with an HTTPS endpoint
+
+If you're using Minio with HTTPS, you may see unintelligible text in the output of `velero describe`, or `velero logs` commands.
+
+To fix this, you can add a public URL to the `BackupStorageLocation`.
+
+In a terminal, run the following:
+
+```shell
+kubectl patch -n velero backupstoragelocation default --type merge -p '{"spec":{"config":{"publicUrl":"https://<a public IP for your Minio instance>:9000"}}}'
+```
+
+If your certificate is self-signed, see the [documentation on self-signed certificates][32].
+
+## Expose Minio outside your cluster with Kubernetes in Docker (KinD):
+
+Kubernetes in Docker does not have support for NodePort services (see [this issue](https://github.com/kubernetes-sigs/kind/issues/99)). In this case, you can use a port forward to access the Minio bucket.
+
+In a terminal, run the following:
+
+```shell
+MINIO_POD=$(kubectl get pods -n velero -l component=minio -o jsonpath='{.items[0].metadata.name}')
+
+kubectl port-forward $MINIO_POD -n velero 9000:9000
+```
+
+Then, in another terminal:
+
+```shell
+kubectl edit backupstoragelocation default -n velero
+```
+
+Add `publicUrl: http://localhost:9000` under the `spec.config` section.
+
+
+### Work with Ingress
+
+Configuring Ingress for your cluster is out of scope for the Velero documentation. If you have already set up Ingress, however, it makes sense to continue with it while you run the example Velero configuration with Minio.
+
+In this case:
+
+1.  Keep the Service type as `ClusterIP`.
+
+1.  Edit your `BackupStorageLocation` YAML, adding `publicUrl: <URL_AND_PORT_OF_INGRESS>` as a field under `spec.config`.
+
+[1]: #expose-minio-with-service-of-type-nodeport
+[3]: ../customize-installation.md
+[17]: ../file-system-backup.md
+[18]: ../debugging-restores.md
+[26]: https://github.com/vmware-tanzu/velero/releases
+[30]: https://godoc.org/github.com/robfig/cron
+[32]: ../self-signed-certificates.md
@@ -0,0 +1,248 @@
+---
+title: "Use Oracle Cloud as a Backup Storage Provider for Velero"
+layout: docs
+---
+
+## Introduction
+
+[Velero](https://velero.io/) is a tool used to backup and migrate Kubernetes applications. Here are the steps to use [Oracle Cloud Object Storage](https://docs.cloud.oracle.com/iaas/Content/Object/Concepts/objectstorageoverview.htm) as a destination for Velero backups.
+
+1. [Download Velero](#download-velero)
+2. [Create A Customer Secret Key](#create-a-customer-secret-key)
+3. [Create An Oracle Object Storage Bucket](#create-an-oracle-object-storage-bucket)
+4. [Install Velero](#install-velero)
+5. [Clean Up](#clean-up)
+6. [Examples](#examples)
+7. [Additional Reading](#additional-reading)
+
+## Download Velero
+
+1. Download the [latest release](https://github.com/vmware-tanzu/velero/releases/) of Velero to your development environment. This includes the `velero` CLI utility and example Kubernetes manifest files. For example:
+
+    ```
+    wget https://github.com/vmware-tanzu/velero/releases/download/v1.0.0/velero-v1.0.0-linux-amd64.tar.gz
+    ```
+
+    **NOTE:** Its strongly recommend that you use an official release of Velero. The tarballs for each release contain the velero command-line client. The code in the main branch of the Velero repository is under active development and is not guaranteed to be stable!
+
+2. Untar the release in your `/usr/bin` directory:  `tar -xzvf <RELEASE-TARBALL-NAME>.tar.gz`
+
+   You may choose to rename the directory `velero` for the sake of simplicity: `mv velero-v1.0.0-linux-amd64 velero`
+
+3. Add it to your PATH: `export PATH=/usr/local/bin/velero:$PATH`
+
+4. Run `velero` to confirm the CLI has been installed correctly. You should see an output like this:
+
+```
+$ velero
+Velero is a tool for managing disaster recovery, specifically for Kubernetes
+cluster resources. It provides a simple, configurable, and operationally robust
+way to back up your application state and associated data.
+
+If you're familiar with kubectl, Velero supports a similar model, allowing you to
+execute commands such as 'velero get backup' and 'velero create schedule'. The same
+operations can also be performed as 'velero backup get' and 'velero schedule create'.
+
+Usage:
+  velero [command]
+```
+
+
+
+## Create A Customer Secret Key
+
+1. Oracle Object Storage provides an API to enable interoperability with Amazon S3. To use this Amazon S3 Compatibility API, you need to generate the signing key required to authenticate with Amazon S3. This special signing key is an Access Key/Secret Key pair. Follow these steps to [create a Customer Secret Key](https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingcredentials.htm#To4). Refer to this link for more information about [Working with Customer Secret Keys](https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingcredentials.htm#s3).
+
+2. Create a Velero credentials file with your Customer Secret Key:
+
+   ```
+   $ vi credentials-velero
+
+   [default]
+   aws_access_key_id=bae031188893d1eb83719648790ac850b76c9441
+   aws_secret_access_key=MmY9heKrWiNVCSZQ2Mf5XTJ6Ys93Bw2d2D6NMSTXZlk=
+   ```
+
+
+
+## Create An Oracle Object Storage Bucket
+
+Create an Oracle Cloud Object Storage bucket called `velero` in the root compartment of your Oracle Cloud tenancy. Refer to this page for [more information about creating a bucket with Object Storage](https://docs.cloud.oracle.com/iaas/Content/Object/Tasks/managingbuckets.htm#usingconsole).
+
+
+
+## Install Velero
+
+You will need the following information to install Velero into your Kubernetes cluster with Oracle Object Storage as the Backup Storage provider:
+
+```
+velero install \
+    --provider [provider name] \
+    --bucket [bucket name] \
+    --prefix [tenancy name] \
+    --use-volume-snapshots=false \
+    --secret-file [secret file location] \
+    --backup-location-config region=[region],s3ForcePathStyle="true",s3Url=[storage API endpoint]
+```
+
+- `--provider` This example uses the S3-compatible API, so use `aws` as the provider.
+- `--bucket` The name of the bucket created in Oracle Object Storage - in our case this is named `velero`.
+- ` --prefix` The name of your Oracle Cloud tenancy - in our case this is named `oracle-cloudnative`.
+- `--use-volume-snapshots=false` Velero does not have a volume snapshot plugin for Oracle Cloud, so creating volume snapshots is disabled.
+- `--secret-file` The path to your `credentials-velero` file.
+- `--backup-location-config` The path to your Oracle Object Storage bucket. This consists of your `region` which corresponds to your Oracle Cloud region name ([List of Oracle Cloud Regions](https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm?Highlight=regions)) and the `s3Url`, the S3-compatible API endpoint for Oracle Object Storage based on your region: `https://oracle-cloudnative.compat.objectstorage.[region name].oraclecloud.com`
+
+For example:
+
+```
+velero install \
+    --provider aws \
+    --bucket velero \
+    --prefix oracle-cloudnative \
+    --use-volume-snapshots=false \
+    --secret-file /Users/mboxell/bin/velero/credentials-velero \
+    --backup-location-config region=us-phoenix-1,s3ForcePathStyle="true",s3Url=https://oracle-cloudnative.compat.objectstorage.us-phoenix-1.oraclecloud.com
+```
+
+This will create a `velero` namespace in your cluster along with a number of CRDs, a ClusterRoleBinding, ServiceAccount, Secret, and Deployment for Velero. If your pod fails to successfully provision, you can troubleshoot your installation by running: `kubectl logs [velero pod name]`.
+
+
+
+## Clean Up
+
+To remove Velero from your environment, delete the namespace, ClusterRoleBinding, ServiceAccount, Secret, and Deployment and delete the CRDs, run:
+
+```
+kubectl delete namespace/velero clusterrolebinding/velero
+kubectl delete crds -l component=velero
+```
+
+This will remove all resources created by `velero install`.
+
+
+
+## Examples
+
+After creating the Velero server in your cluster, try this example:
+
+### Basic example (without PersistentVolumes)
+
+1. Start the sample nginx app: `kubectl apply -f examples/nginx-app/base.yaml`
+
+   This will create an `nginx-example` namespace with a `nginx-deployment` deployment, and `my-nginx` service.
+
+   ```
+   $ kubectl apply -f examples/nginx-app/base.yaml
+   namespace/nginx-example created
+   deployment.apps/nginx-deployment created
+   service/my-nginx created
+   ```
+
+   You can see the created resources by running `kubectl get all`
+
+   ```
+   $ kubectl get all
+   NAME                                    READY   STATUS    RESTARTS   AGE
+   pod/nginx-deployment-67594d6bf6-4296p   1/1     Running   0          20s
+   pod/nginx-deployment-67594d6bf6-f9r5s   1/1     Running   0          20s
+
+   NAME               TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
+   service/my-nginx   LoadBalancer   10.96.69.166   <pending>     80:31859/TCP   21s
+
+   NAME                               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+   deployment.apps/nginx-deployment   2         2         2            2           21s
+
+   NAME                                          DESIRED   CURRENT   READY   AGE
+   replicaset.apps/nginx-deployment-67594d6bf6   2         2         2       21s
+   ```
+
+2. Create a backup: `velero backup create nginx-backup --include-namespaces nginx-example`
+
+   ```
+   $ velero backup create nginx-backup --include-namespaces nginx-example
+   Backup request "nginx-backup" submitted successfully.
+   Run `velero backup describe nginx-backup` or `velero backup logs nginx-backup` for more details.
+   ```
+
+   At this point you can navigate to appropriate bucket, called `velero`, in the Oracle Cloud Object Storage console to see the resources backed up using Velero.
+
+3. Simulate a disaster by deleting the `nginx-example` namespace: `kubectl delete namespaces nginx-example`
+
+   ```
+   $ kubectl delete namespaces nginx-example
+   namespace "nginx-example" deleted
+   ```
+
+   Wait for the namespace to be deleted. To check that the nginx deployment, service, and namespace are gone, run:
+
+   ```
+   kubectl get deployments --namespace=nginx-example
+   kubectl get services --namespace=nginx-example
+   kubectl get namespace/nginx-example
+   ```
+
+   This should return: `No resources found.`
+
+4. Restore your lost resources: `velero restore create --from-backup nginx-backup`
+
+   ```
+   $ velero restore create --from-backup nginx-backup
+   Restore request "nginx-backup-20190604102710" submitted successfully.
+   Run `velero restore describe nginx-backup-20190604102710` or `velero restore logs nginx-backup-20190604102710` for more details.
+   ```
+
+   Running `kubectl get namespaces` will show that the `nginx-example` namespace has been restored along with its contents.
+
+5. Run: `velero restore get` to view the list of restored resources. After the restore finishes, the output looks like the following:
+
+   ```
+   $ velero restore get
+   NAME                          BACKUP         STATUS      WARNINGS   ERRORS   CREATED                         SELECTOR
+   nginx-backup-20190604104249   nginx-backup   Completed   0          0        2019-06-04 10:42:39 -0700 PDT   <none>
+   ```
+
+   NOTE: The restore can take a few moments to finish. During this time, the `STATUS` column reads `InProgress`.
+
+   After a successful restore, the `STATUS` column shows `Completed`, and `WARNINGS` and `ERRORS` will show `0`. All objects in the `nginx-example` namespace should be just as they were before you deleted them.
+
+   If there are errors or warnings, for instance if the `STATUS` column displays `FAILED` instead of `InProgress`, you can look at them in detail with `velero restore describe <RESTORE_NAME>`
+
+
+6. Clean up the environment with `kubectl delete -f examples/nginx-app/base.yaml`
+
+   ```
+   $ kubectl delete -f examples/nginx-app/base.yaml
+   namespace "nginx-example" deleted
+   deployment.apps "nginx-deployment" deleted
+   service "my-nginx" deleted
+   ```
+
+   If you want to delete any backups you created, including data in object storage, you can run: `velero backup delete BACKUP_NAME`
+
+   ```
+   $ velero backup delete nginx-backup
+   Are you sure you want to continue (Y/N)? Y
+   Request to delete backup "nginx-backup" submitted successfully.
+   The backup will be fully deleted after all associated data (disk snapshots, backup files, restores) are removed.
+   ```
+
+   This asks the Velero server to delete all backup data associated with `BACKUP_NAME`. You need to do this for each backup you want to permanently delete. A future version of Velero will allow you to delete multiple backups by name or label selector.
+
+   Once fully removed, the backup is no longer visible when you run: `velero backup get BACKUP_NAME` or more generally `velero backup get`:
+
+   ```
+   $ velero backup get nginx-backup
+   An error occurred: backups.velero.io "nginx-backup" not found
+   ```
+
+   ```
+   $ velero backup get
+   NAME     STATUS      CREATED     EXPIRES     STORAGE     LOCATION        SELECTOR
+   ```
+
+
+
+## Additional Reading
+
+* [Official Velero Documentation](https://velero.io/docs/v1.18.0/)
+* [Oracle Cloud Infrastructure Documentation](https://docs.cloud.oracle.com/)
@@ -0,0 +1,168 @@
+---
+title: "Use Tencent Cloud Object Storage as Velero's storage destination."
+layout: docs
+---
+
+
+You can deploy Velero on Tencent [TKE](https://cloud.tencent.com/document/product/457), or an other Kubernetes cluster, and use Tencent Cloud Object Store as a destination for Velero’s backups.
+
+
+## Prerequisites
+
+- Registered [Tencent Cloud Account](https://cloud.tencent.com/register).
+-  [Tencent Cloud COS](https://console.cloud.tencent.com/cos) service, referred to as COS, has been launched
+- A Kubernetes cluster has been created, cluster version v1.16 or later, and the cluster can use DNS and Internet services normally. If you need to create a TKE cluster, refer to the Tencent [create a cluster](https://cloud.tencent.com/document/product/457/32189) documentation.
+
+## Create a Tencent Cloud COS bucket
+
+Create an object bucket for Velero to store backups in the Tencent Cloud COS console. For how to create, please refer to Tencent Cloud COS [Create a bucket](https://cloud.tencent.com/document/product/436/13309) usage instructions.
+
+Set access to the bucket through the object storage console, the bucket needs to be **read** and **written**, so the account is granted data reading, data writing permissions. For how to configure, see the [permission access settings](https://cloud.tencent.com/document/product/436/13315) Tencent user instructions.
+
+## Get bucket access credentials
+
+Velero uses an AWS S3-compatible API to access Tencent Cloud COS storage, which requires authentication using a pair of access key IDs and key-created signatures.
+
+In the S3 API parameter, the "access_key_id" field is the access key ID and the "secret_access_key" field is the key.
+
+In the [Tencent Cloud Access Management Console](https://console.cloud.tencent.com/cam/capi), Create and acquire  Tencent Cloud Keys "SecretId" and "SecretKey" for  COS authorized account. **Where the "SecretId" value corresponds to the value of S3 API parameter "access_key_id" field, the "SecretKey" value corresponds to the value of S3 API parameter "secret_access_key" field**.
+
+Create the credential profile "credentials-velero" required by Velero in the local directory based on the above correspondence:
+
+```bash
+[default]
+aws_access_key_id=<SecretId>
+aws_secret_access_key=<SecretKey>
+```
+
+## Install Velero Resources
+
+You need to install the Velero CLI first, see [Install the CLI](https://velero.io/docs/v1.5/basic-install/#install-the-cli)  for how to install.
+
+Follow the Velero installation command below to create velero and node-agent workloads and other necessary resource objects.
+
+```bash
+velero install  --provider aws --plugins velero/velero-plugin-for-aws:v1.1.0 --bucket  <BucketName> \
+--secret-file ./credentials-velero \
+--use-node-agent \
+--default-volumes-to-fs-backup \
+--backup-location-config \
+region=ap-guangzhou,s3ForcePathStyle="true",s3Url=https://cos.ap-guangzhou.myqcloud.com
+```
+
+Description of the parameters:
+
+- `--provider`: Declares the type of plugin provided by "aws".
+
+- `--plugins`: Use the AWS S3 compatible API plugin "velero-plugin-for-aws".
+
+- `--bucket`: The bucket name created at Tencent Cloud COS.
+
+- `--secret-file`: Access tencent cloud COS access credential file for the "credentials-velero" credential file created above.
+
+- `--use-node-agent`: Enable Velero node-agent daemonset. At present, Velero File System Backup requires this daemonset, so if you are using File System Backup, it needs to be turned on. For the usage and limitation of File System Backup, See [File System Backup](../file-system-backup.md).
+
+- `--default-volumes-to-fs-backup`: Enable the use of File System Backup to back up all Pod volumes, provided that the `--use-node-agent`parameter needs to be turned on.
+
+- `--backup-location-config`: Back up the bucket access-related configuration:
+
+  `region`: Tencent cloud COS bucket area, for example, if the created region is Guangzhou, the Region parameter value is "ap-guangzhou".
+
+  `s3ForcePathStyle`: Use the S3 file path format.
+
+  `s3Url`: Tencent Cloud COS-compatible S3 API access address,Note that instead of creating a COS bucket for public network access domain name, you must use a format of "https://cos.`region`.myqcloud.com" URL, for example, if the region is Guangzhou, the parameter value is "https://cos.ap-guangzhou.myqcloud.com.".
+
+There are other installation parameters that can be viewed using `velero install --help`, such as setting `--use-volume-snapshots-false`  to close the storage volume data snapshot backup if you do not want to back up the storage volume data.
+
+After executing the installation commands above, the installation process looks like this:
+
+{{< figure src="/docs/main/contributions/img-for-tencent/9015313121ed7987558c88081b052574.png" width="100%">}}
+
+After the installation command is complete, wait for the velero and node-agent workloads to be ready to see if the configured storage location is available.
+
+Executing the 'velero backup-location get' command to view the storage location status and display "Available" indicates that access to Tencent Cloud COS is OK, as shown in the following image:
+
+{{< figure src="/docs/main/contributions/img-for-tencent/69194157ccd5e377d1e7d914fd8c0336.png" width="100%">}}
+
+At this point, The installation using Tencent Cloud COS as Velero storage location is complete, If you need more installation information about Velero, You can see the official website [Velero documentation](https://velero.io/docs/) .
+
+## Velero backup and restore example
+
+In the cluster, use the helm tool to create a minio test service with a persistent volume, and the minio installation method can be found in the [minio installation](https://github.com/minio/charts), in which case can bound a load balancer for the minio service to access the management page using a public address in the browser.
+
+{{< figure src="/docs/main/contributions/img-for-tencent/f0fff5228527edc72d6e71a50d5dc966.png" width="100%">}}
+
+Sign in to the minio web management page and upload some image data for the test, as shown below:
+
+{{< figure src="/docs/main/contributions/img-for-tencent/e932223585c0b19891cc085ad7f438e1.png" width="100%">}}
+
+With Velero Backup, you can back up all objects in the cluster directly, or filter objects by type, namespace, and/or label. This example uses the following command to back up all resources under the 'default' namespace.
+
+```
+velero backup create default-backup --include-namespaces <Namespace>
+```
+
+Use the `velero backup get` command to see if the backup task is complete, and when the backup task status is "Completed," the backup task is completed without any errors, as shown in the following below:
+
+{{< figure src="/docs/main/contributions/img-for-tencent/eb2bbabae48b188748f5278bedf177f1.png" width="100%">}}
+
+At this point delete all of MinIO's resources, including its PVC persistence volume, as shown below::
+
+{{< figure src="/docs/main/contributions/img-for-tencent/15ccaacf00640a04ae29ceed4c86195b.png" width="100%">}}
+
+After deleting the MinIO resource, use your backup to restore the deleted MinIO resource, and temporarily update the backup storage location to read-only mode (this prevents the backup object from being created or deleted in the backup storage location during the restore process)::
+
+```bash
+kubectl patch backupstoragelocation default --namespace velero \
+    --type merge \
+    --patch '{"spec":{"accessMode":"ReadOnly"}}'
+
+```
+
+Modifying access to Velero's storage location is "ReadOnly," as shown in the following image:
+
+{{< figure src="/docs/main/contributions/img-for-tencent/e8c2ab4e5e31d1370c62fad25059a8a8.png" width="100%">}}
+
+Now use the backup "default-backup" that Velero just created to create the restore task:
+
+```bash
+velero restore create --from-backup <BackupObject>
+```
+
+You can also use `velero restore get` to see the status of the restore task, and if the restore status is "Completed," the restore task is complete, as shown in the following image:
+
+{{< figure src="/docs/main/contributions/img-for-tencent/effe8a0a7ce3aa8e422db00bfdddc375.png" width="100%">}}
+
+When the restore is complete, you can see that the previously deleted minio-related resources have been restored successfully, as shown in the following image:
+
+{{< figure src="/docs/main/contributions/img-for-tencent/1d53b0115644d43657c2a5ece805c9b4.png" width="100%">}}
+
+Log in to minio's management page on your browser and you can see that the previously uploaded picture data is still there, indicating that the persistent volume's data was successfully restored, as shown below:
+
+{{< figure src="/docs/main/contributions/img-for-tencent/ceaca9ce6bc92bdce987c63d2fe71561.png" width="100%">}}
+
+When the restore is complete, don't forget to restore the backup storage location to read and write mode so that the next backup task can be used successfully:
+
+```bash
+kubectl patch backupstoragelocation default --namespace velero \
+   --type merge \
+   --patch '{"spec":{"accessMode":"ReadWrite"}}'
+```
+
+
+
+## Uninstall Velero Resources
+
+To uninstall velero resources in a cluster, you can do so using the following command:
+
+```bash
+kubectl delete namespace/velero clusterrolebinding/velero
+kubectl delete crds -l component=velero
+```
+
+
+
+## Additional Reading
+
+- [Official Velero Documentation](https://velero.io/docs/)
+- [Tencent Cloud Documentation](https://cloud.tencent.com/document/product)
@@ -0,0 +1,431 @@
+---
+title: "CSI Snapshot Data Movement"
+layout: docs
+---
+
+CSI Snapshot Data Movement is built according to the [Volume Snapshot Data Movement design][1] and is specifically designed to move CSI snapshot data to a backup storage location.  
+CSI Snapshot Data Movement takes CSI snapshots through the CSI plugin in nearly the same way as [CSI snapshot backup][2]. However, it doesn't stop after a snapshot is taken. Instead, it tries to access the snapshot data through various data movers and back up the data to a backup storage connected to the data movers.  
+Consequently, the volume data is backed up to a pre-defined backup storage in a consistent manner.  
+After the backup completes, the CSI snapshot will be removed by Velero and the snapshot data space will be released on the storage side.  
+
+CSI Snapshot Data Movement is useful in below scenarios:
+- For on-premises users, the storage usually doesn't support durable snapshots, so it is impossible/less efficient/cost ineffective to keep volume snapshots by the storage, as required by the [CSI snapshot backup][2]. This feature helps to move the snapshot data to a storage with lower cost and larger scale for long time preservation.    
+- For public cloud users, this feature helps users to fulfil the multiple cloud strategy. It allows users to back up volume snapshots from one cloud provider and preserve or restore the data to another cloud provider. Then users will be free to flow their business data across cloud providers based on Velero backup and restore.  
+
+Besides, Velero [File System Backup][3] which could also back up the volume data to a pre-defined backup storage. CSI Snapshot Data Movement works together with [File System Backup][3] to satisfy different requirements for the above scenarios. And whenever available, CSI Snapshot Data Movement should be used in preference since the [File System Backup][3] reads data from the live PV, in which way the data is not captured at the same point in time, so is less consistent.  
+Moreover, CSI Snapshot Data Movement brings more possible ways of data access, i.e., accessing the data from the block level, either fully or incrementally.  
+On the other hand, there are quite some cases that CSI snapshot is not available (i.e., you need a volume snapshot plugin for your storage platform, or you're using EFS, NFS, emptyDir, local, or any other volume type that doesn't have a native snapshot), then [File System Backup][3] will be the only option.  
+
+CSI Snapshot Data Movement supports both built-in data mover and customized data movers. For the details of how Velero works with customized data movers, check the [Volume Snapshot Data Movement design][1]. Velero provides a built-in data mover which uses Velero built-in uploaders (at present the available uploader is Kopia uploader) to read the snapshot data and write to the Unified Repository (by default implemented by Kopia repository).    
+
+Velero built-in data mover restores both volume data and metadata, so the data mover pods need to run as root user.
+
+### Priority Class Configuration
+
+For Velero built-in data mover, data mover pods launched during CSI snapshot data movement will use the priority class name configured in the node-agent configmap. The node-agent daemonset itself gets its priority class from the `--node-agent-priority-class-name` flag during Velero installation. This can help ensure proper scheduling behavior in resource-constrained environments. For more details on configuring data mover pod resources, see [Data Movement Pod Resource Configuration][11].
+
+## Setup CSI Snapshot Data Movement
+
+## Prerequisites
+
+ 1. The source cluster is Kubernetes version 1.20 or greater.
+ 2. The source cluster is running a CSI driver capable of support volume snapshots at the [v1 API level][4].
+ 3. CSI Snapshot Data Movement requires the Kubernetes [MountPropagation feature][5].
+
+
+### Install Velero Node Agent
+
+Velero Node Agent is a Kubernetes daemonset that hosts Velero data movement controllers and launches data mover pods. 
+If you are using Velero built-in data mover, Node Agent must be installed. To install Node Agent, use the `--use-node-agent` flag.  
+Velero built-in data mover doesn't require the host path for pod volumes into Node Agent pods. The installation by default creates it in order to support fs-backup. If you don't use fs-backup and want to remove it from Node Agent, you can specify the `--node-agent-disable-host-path` flag.  
+
+```
+velero install --use-node-agent --node-agent-disable-host-path
+```
+
+### Configure A Backup Storage Location
+
+At present, Velero backup repository supports object storage as the backup storage. Velero gets the parameters from the 
+[BackupStorageLocation][8] to compose the URL to the backup storage.  
+Velero's known object storage providers are included here [supported providers][9], for which, Velero pre-defines the endpoints. If you want to use a different backup storage, make sure it is S3 compatible and you provide the correct bucket name and endpoint in BackupStorageLocation. Velero handles the creation of the backup repo prefix in the backup storage, so make sure it is specified in BackupStorageLocation correctly.  
+
+Velero creates one backup repository per namespace. For example, if backing up 2 namespaces, namespace1 and namespace2, using kopia repository on AWS S3, the full backup repo path for namespace1 would be `https://s3-us-west-2.amazonaws.com/bucket/kopia/ns1` and for namespace2 would be `https://s3-us-west-2.amazonaws.com/bucket/kopia/ns2`.  
+
+There may be additional installation steps depending on the cloud provider plugin you are using. You should refer to the [plugin specific documentation][9] for the must up to date information.  
+
+**Note:** Currently, Velero creates a secret named `velero-repo-credentials` in the velero install namespace, containing a default backup repository password.
+You can update the secret with your own password encoded as base64 prior to the first backup (i.e., [File System Backup][3], snapshot data movements) targeting to the backup repository. The value of the key to update is  
+```
+data:
+  repository-password: <custom-password>
+```
+Backup repository is created during the first execution of backup targeting to it after installing Velero with node agent. If you update the secret password after the first backup which created the backup repository, then Velero will not be able to connect with the older backups.  
+
+## Install Velero with CSI support on source cluster
+
+On source cluster, Velero needs to manipulate CSI snapshots through the CSI volume snapshot APIs, so you must enable the `EnableCSI` feature flag on the Velero server.  
+
+To integrate Velero with the CSI volume snapshot APIs, you must enable the `EnableCSI` feature flag.
+
+From release-1.14, the `github.com/vmware-tanzu/velero-plugin-for-csi` repository, which is the Velero CSI plugin, is merged into the `github.com/vmware-tanzu/velero` repository.
+The reasons to merge the CSI plugin are:
+* The VolumeSnapshot data mover depends on the CSI plugin, it's reasonabe to integrate them.
+* This change reduces the Velero deploying complexity.
+* This makes performance tuning easier in the future.
+
+As a result, no need to install Velero CSI plugin anymore.
+
+```bash
+velero install \
+--features=EnableCSI \
+--plugins=<object storage plugin> \
+...
+```
+
+### Configure storage class on target cluster
+
+For Velero built-in data movement, CSI facilities are not required necessarily in the target cluster. On the other hand, Velero built-in data movement creates a PVC with the same specification as it is in the source cluster and expects the volume to be provisioned similarly. For example, the same storage class should be working in the target cluster.  
+By default, Velero won't restore storage class resources from the backup since they are cluster scope resources. However, if you specify the `--include-cluster-resources` restore flag, they will be restored. For a cross provider scenario, the storage class from the source cluster is probably not usable in the target cluster.  
+In either of the above cases, the best practice is to create a working storage class in the target cluster with the same name as it in the source cluster. In this way, even though `--include-cluster-resources` is specified, Velero restore will skip restoring the storage class since it finds an existing one.  
+Otherwise, if the storage class name in the target cluster is different, you can change the PVC's storage class name during restore by the [changing PV/PVC storage class][10] method. You can also configure to skip restoring the storage class resources from the backup since they are not usable.  
+
+### Customized Data Movers
+
+If you are using a customized data mover, follow the data mover's instructions for any further prerequisites.  
+For Velero side configurations mentioned above, the installation and configuration of node-agent may not be required.  
+
+
+## To back up
+
+Velero uses a new custom resource `DataUpload` to drive the data movement. The selected data mover will watch and reconcile the CRs.  
+Velero allows users to decide whether the CSI snapshot data should be moved per backup.  
+Velero also allows users to select the data mover to move the CSI snapshot data per backup.  
+The both selections are simply done by a parameter when running the backup.  
+
+To take a backup with Velero's built-in data mover:
+
+```bash
+velero backup create NAME --snapshot-move-data OPTIONS...
+```
+
+Or if you want to use a customized data mover:
+```bash
+velero backup create NAME --snapshot-move-data --data-mover DATA-MOVER-NAME OPTIONS...
+```
+
+When the backup starts, you will see the `VolumeSnapshot` and `VolumeSnapshotContent` objects created, but after the backup finishes, the objects will disappear.  
+After snapshots are created, you will see one or more `DataUpload` CRs created.  
+You may also see some intermediate objects (i.e., pods, PVCs, PVs) created in Velero namespace or the cluster scope, they are to help data movers to move data. And they will be removed after the backup completes.  
+The phase of a `DataUpload` CR changes several times during the backup process and finally goes to one of the terminal status, `Completed`, `Failed` or `Cancelled`. You can see the phase changes as well as the data upload progress by watching the `DataUpload` CRs. While the `DataUpload` is being processed, progress is shown with `BYTES DONE` representing the amount of volume data that has been processed so far and `TOTAL BYTES` representing the estimated total volume data. Upon completion, these two numbers will be the same. In addition, once the `DataUpload` is done, `INCREMENTAL BYTES` will be filled in with the amount of data which is new or changed since the last backup of this volume. Note that the actual uploaded content may be smaller than `INCREMENTAL BYTES` due to kopia deduplication, compression, etc.  
+
+```bash
+kubectl -n velero get datauploads -l velero.io/backup-name=YOUR_BACKUP_NAME -w
+```
+
+By default, `INCREMENTAL BYTES` is not displayed in the `kubectl get` output. To see this extended field, the `-o wide` arg is needed:
+```bash
+kubectl -n velero get datauploads -o wide -l velero.io/backup-name=YOUR_BACKUP_NAME -w
+```
+
+When the backup completes, you can view information about the backups:
+
+```bash
+velero backup describe YOUR_BACKUP_NAME
+```
+```bash
+kubectl -n velero get datauploads -l velero.io/backup-name=YOUR_BACKUP_NAME -o yaml
+```  
+
+## To restore
+
+You don't need to set any additional information when creating a data mover restore. The configurations are automatically retrieved from the backup, i.e., whether data movement should be involved and which data mover conducts the data movement.    
+
+To restore from your Velero backup:
+
+```bash
+velero restore create --from-backup BACKUP_NAME OPTIONS...
+```
+
+When the restore starts, you will see one or more `DataDownload` CRs created.  
+You may also see some intermediate objects (i.e., pods, PVCs, PVs) created in Velero namespace or the cluster scope, they are to help data movers to move data. And they will be removed after the restore completes.  
+The phase of a `DataDownload` CR changes several times during the restore process and finally goes to one of the terminal status, `Completed`, `Failed` or `Cancelled`. You can see the phase changes as well as the data download progress by watching the DataDownload CRs:  
+
+```bash
+kubectl -n velero get datadownloads -l velero.io/restore-name=YOUR_RESTORE_NAME -w
+```
+
+When the restore completes, view information about your restores:
+
+```bash
+velero restore describe YOUR_RESTORE_NAME
+```
+```bash
+kubectl -n velero get datadownloads -l velero.io/restore-name=YOUR_RESTORE_NAME -o yaml
+```
+
+## Limitations
+
+- CSI and CSI snapshot support both file system volume mode and block volume mode. At present, block mode is only supported for non-Windows platforms, because the block mode code invokes some system calls that are not present in the Windows platform.  
+- [Velero built-in data mover] At present, Velero uses a static, common encryption key for all backup repositories it creates. **This means 
+that anyone who has access to your backup storage can decrypt your backup data**. Make sure that you limit access 
+to the backup storage appropriately. 
+- [Velero built-in data mover] Even though the backup data could be incrementally preserved, for a single file data, Velero built-in data mover leverages on deduplication to find the difference to be saved. This means that large files (such as ones storing a database) will take a long time to scan for data  deduplication, even if the actual difference is small.  
+
+## Troubleshooting
+
+Run the following checks:
+
+Are your Velero server and daemonset pods running?
+
+```bash
+kubectl get pods -n velero
+```
+
+Does your backup repository exist, and is it ready?
+
+```bash
+velero repo get
+
+velero repo get REPO_NAME -o yaml
+```
+
+Are there any errors in your Velero backup/restore?
+
+```bash
+velero backup describe BACKUP_NAME
+velero backup logs BACKUP_NAME
+
+velero restore describe RESTORE_NAME
+velero restore logs RESTORE_NAME
+```
+
+What is the status of your `DataUpload` and `DataDownload`?
+
+```bash
+kubectl -n velero get datauploads -l velero.io/backup-name=BACKUP_NAME -o yaml
+
+kubectl -n velero get datadownloads -l velero.io/restore-name=RESTORE_NAME -o yaml
+```
+
+Is there any useful information in the Velero server or daemonset pod logs?
+
+```bash
+kubectl -n velero logs deploy/velero
+kubectl -n velero logs DAEMON_POD_NAME
+```
+
+**NOTE**: You can increase the verbosity of the pod logs by adding `--log-level=debug` as an argument to the container command in the deployment/daemonset pod template spec.  
+
+If you are using a customized data mover, follow the data mover's instruction for additional troubleshooting methods.  
+
+
+## How backup and restore work
+
+CSI snapshot data movement is a combination of CSI snapshot and data movement, which is jointly executed by Velero server, CSI plugin and the data mover. 
+This section lists some general concept of how CSI snapshot data movement backup and restore work. For the detailed mechanisms and workflows, you can check the [Volume Snapshot Data Movement design][1] and [VGDP Micro Service For Volume Snapshot Data Movement design][18].  
+
+### Custom resource and controllers
+
+Velero has three custom resource definitions and associated controllers:
+
+- `DataUpload` - represents a data upload of a volume snapshot. The CSI plugin creates one `DataUpload` per CSI snapshot. Data movers need to handle these CRs to finish the data upload process.  
+Velero built-in data mover runs a controller for this resource on each node (in node-agent daemonset). Controllers from different nodes may handle one CR in different phases, but finally the data transfer is done by a data mover pod in one node.  
+
+- `DataDownload` - represents a data download of a volume snapshot.  The CSI plugin creates one `DataDownload` per volume to be restored. Data movers need to handle these CRs to finish the data upload process.  
+Velero built-in data mover runs a controller for this resource on each node (in node-agent daemonset). Controllers from different nodes may handle one CR in different phases, but finally the data transfer is done by a data mover pod in one node. 
+
+- `BackupRepository` - represents/manages the lifecycle of Velero's backup repositories. Velero creates a backup repository per namespace when the first CSI snapshot backup/restore for a namespace is requested. You can see information about your Velero's backup repositories by running `velero repo get`.  
+This CR is used by Velero built-in data movers, customized data movers may or may not use it.  
+
+For other resources or controllers involved by customized data movers, check the data mover's instructions.  
+
+### Backup
+
+Velero backs up resources for CSI snapshot data movement backup in the same way as other backup types. When it encounters a PVC, particular logics will be conducted:  
+
+- When it finds a PVC object, Velero calls CSI plugin through a Backup Item Action.  
+- CSI plugin first takes a CSI snapshot to the PVC by creating the `VolumeSnapshot` and  `VolumeSnapshotContent`.  
+- CSI plugin checks if a data movement is required, if so it creates a `DataUpload` CR and then returns to Velero backup.  
+- Velero now is able to back up other resources, including other PVC objects.  
+- Velero backup controller periodically queries the data movement status from CSI plugin, the period is configurable through the Velero server parameter `--item-operation-sync-frequency`, by default it is 10s. On the call, CSI plugin turns to check the phase of the `DataUpload` CRs.  
+- When all the `DataUpload` CRs come to a terminal state (i.e., `Completed`, `Failed` or `Cancelled`), Velero backup persists all the necessary information and finish the backup.  
+
+- CSI plugin expects a data mover to handle the `DataUpload` CR. If no data mover is configured for the backup, Velero built-in data mover will handle it.  
+- If the `DataUpload` CR does not reach to the terminal state with in the given time, the `DataUpload` CR will be cancelled. You can set the timeout value per backup through the `--item-operation-timeout` parameter, the default value is `4 hours`.  
+
+- Velero built-in data mover creates a volume from the CSI snapshot and transfer the data to the backup storage according to the backup storage location defined by users.  
+- After the volume is created from the CSI snapshot, Velero built-in data mover waits for Kubernetes to provision the volume, this may take some time varying from storage providers, but if the provision cannot be finished in a given time, Velero built-in data mover will cancel this `DataUpload` CR. The timeout is configurable through a node-agent's parameter `data-mover-prepare-timeout`, the default value is 30 minutes.  
+- Velero built-in data mover launches a data mover pod to transfer the data from the provisioned volume to the backup storage.  
+- When the data transfer completes or any error happens, Velero built-in data mover sets the `DataUpload` CR to the terminal state, either `Completed` or `Failed`.  
+- Velero built-in data mover also monitors the cancellation request to the `DataUpload` CR, once that happens, it cancels its ongoing activities, cleans up the intermediate resources and set the `DataUpload` CR to `Cancelled`.  
+- Throughout the data transfer, Velero built-in data mover monitors the status of the data mover pod and deletes it after `DataUpload` CR is set to the terminal state.    
+
+### Restore
+
+Velero restores resources for CSI snapshot data movement restore in the same way as other restore types. When it encounters a PVC, particular logics will be conducted: 
+
+- When it finds a PVC object, Velero calls CSI plugin through a Restore Item Action.  
+- CSI plugin checks the backup information, if a data movement was involved, it creates a `DataDownload` CR and then returns to Velero restore.  
+- Velero is now able to restore other resources, including other PVC objects.  
+- Velero restore controller periodically queries the data movement status from CSI plugin, the period is configurable through the Velero server parameter `--item-operation-sync-frequency`, by default it is 10s. On the call, CSI plugin turns to check the phase of the `DataDownload` CRs.  
+- When all `DataDownload` CRs come to a terminal state (i.e., `Completed`, `Failed` or `Cancelled`), Velero restore will finish.  
+
+- CSI plugin expects the same data mover for the backup to handle the `DataDownload` CR. If no data mover was configured for the backup, Velero built-in data mover will handle it.  
+- If the `DataDownload` CR does not reach to the terminal state with in the given time, the `DataDownload` CR will be cancelled. You can set the timeout value per backup through the same `--item-operation-timeout` parameter.  
+
+- Velero built-in data mover creates a volume with the same specification of the source volume.  
+- Velero built-in data mover waits for Kubernetes to provision the volume, this may take some time varying from storage providers, but if the provision cannot be finished in a given time, Velero built-in data mover will cancel this `DataDownload` CR. The timeout is configurable through the same node-agent's parameter `data-mover-prepare-timeout`.  
+- After the volume is provisioned, Velero built-in data mover starts a data mover pod to transfer the data from the backup storage according to the backup storage location defined by users.  
+- When the data transfer completes or any error happens, Velero built-in data mover sets the `DataDownload` CR to the terminal state, either `Completed` or `Failed`.  
+- Velero built-in data mover also monitors the cancellation request to the `DataDownload` CR, once that happens, it cancels its ongoing activities, cleans up the intermediate resources and set the `DataDownload` CR to `Cancelled`.  
+- Throughout the data transfer, Velero built-in data mover monitors the status of the data mover pod and deletes it after `DataDownload` CR is set to the terminal state.  
+
+### Backup Deletion
+When a backup is created, a snapshot is saved into the repository for the volume data. The snapshot is a reference to the volume data saved in the repository.  
+When deleting a backup, Velero calls the repository to delete the repository snapshot. So the repository snapshot disappears immediately after the backup is deleted. Then the volume data backed up in the repository turns to orphan, but it is not deleted by this time. The repository relies on the maintenance functionalitiy to delete the orphan data.  
+As a result, after you delete a backup, you don't see the backup storage size reduces until some full maintenance jobs completes successfully. And for the same reason, you should check and make sure that the periodical repository maintenance job runs and completes successfully.  
+
+Even after deleting all the backups and their backup data (by repository maintenance), the backup storage is still not empty, some repository metadata are there to keep the instance of the backup repository.  
+Furthermore, Velero never deletes these repository metadata, if you are sure you'll never usage the backup repository, you can empty the backup storage manually.  
+
+For Velero built-in data mover, Kopia uploader may keep some internal snapshots which is not managed by Velero. In normal cases, the internal snapshots are deleted along with running of backups.  
+However, if you run a backup which aborts halfway(some internal snapshots are thereby generated) and never run new backups again, some internal snapshots may be left there. In this case, since you stop using the backup repository, you can delete the entire repository metadata from the backup storage manually.  
+
+
+### Parallelism
+
+Velero calls the CSI plugin concurrently for the volume, so `DataUpload`/`DataDownload` CRs are created concurrently by the CSI plugin. For more details about the call between Velero and CSI plugin, check the [Volume Snapshot Data Movement design][1].  
+In which manner the `DataUpload`/`DataDownload` CRs are processed is totally decided by the data mover you select for the backup/restore.  
+
+For Velero built-in data mover, it uses Kubernetes' scheduler to mount a snapshot volume/restore volume associated to a `DataUpload`/`DataDownload` CR into a specific node, and then the `DataUpload`/`DataDownload` controller (in node-agent daemonset) in that node will handle the `DataUpload`/`DataDownload`.  
+By default, a `DataUpload`/`DataDownload` controller in one node handles one request at a time. You can configure more parallelism per node by [node-agent Concurrency Configuration][14].  
+That is to say, the snapshot volumes/restore volumes may spread in different nodes, then their associated `DataUpload`/`DataDownload` CRs will be processed in parallel; while for the snapshot volumes/restore volumes in the same node, by default, their associated `DataUpload`/`DataDownload` CRs are processed sequentially and can be processed concurrently according to your [node-agent Concurrency Configuration][14].  
+
+The prepare process of mounting the snapshot volume/restore volume may generate multiple intermediate objects, to make a control of the intermediate objects, you can configure the [node-agent Prepare Queue Length][20].  
+
+You can check in which node the `DataUpload`/`DataDownload` CRs are processed and their parallelism by watching the `DataUpload`/`DataDownload` CRs:
+
+```bash
+kubectl -n velero get datauploads -l velero.io/backup-name=YOUR_BACKUP_NAME -w
+```
+
+```bash
+kubectl -n velero get datadownloads -l velero.io/restore-name=YOUR_RESTORE_NAME -w
+```
+
+For each volume, the parallelism is like below:  
+- If it is a file system mode volume, files in the volume are processed in parallel. You can use `--parallel-files-upload` backup flag or `--parallel-files-download` restore flag to control how many files are processed in parallel. Otherwise, if they are not set, Velero by default refers to the number of CPU cores in the node (where the backup/restore is running) for the parallelism. That is to say, the parallelism is not affected by the CPU request/limit set to the data mover pods.  
+- If it is a block mode volume, there is no parallelism, the block data is processed sequentially.  
+
+Notice that Golang 1.25 and later respects the CPU limit set to the pods to decide the physical threads provisioned to the pod processes (see [Container-aware GOMAXPROCS][22] for more details), so for Velero 1.18 (which consumes Golang 1.25) and later, if you set a CPU limit to the data mover pods, you may not get the expected performance (e.g., backup/restore throughput) with the default parallelism. The outcome may or may not be obvious varying on your volume data. If it is required, you could customize `--parallel-files-upload` or `--parallel-files-download` according to the CPU limit set to the data mover pods.  
+
+### Restart and resume
+When Velero server is restarted, if the resource backup/restore has completed, so the backup/restore has excceded `InProgress` status and is waiting for the completion of the data movements, Velero will recapture the status of the running data movements and resume the execution.  
+When node-agent is restarted, Velero tries to recapture the status of the running data movements and resume the execution; if the resume fails, the data movements are canceled.  
+
+### Cancellation
+
+At present, Velero backup and restore doesn't support end to end cancellation that is launched by users.  
+However, Velero cancels the `DataUpload`/`DataDownload` in below scenarios automatically:
+- When Velero server is restarted and the backup/restore is in `InProgress` status
+- When node-agent is restarted and the resume of an existing `DataUpload`/`DataDownload` fails  
+- When an ongoing backup/restore is deleted
+- When a backup/restore does not finish before the item operation timeout (default value is `4 hours`)
+
+Customized data movers that support cancellation could cancel their ongoing tasks and clean up any intermediate resources. If you are using Velero built-in data mover, the cancellation is supported.  
+
+### Support ReadOnlyRootFilesystem setting
+When the Velero server pod's SecurityContext sets the `ReadOnlyRootFileSystem` parameter to true, the Velero server pod's filesystem is running in read-only mode. Then the backup deletion may fail, because the repository needs to write some cache and configuration data into the pod's root filesystem.
+
+```
+Errors: /error to connect repo with storage: error to connect to repository: unable to write config file: unable to create config directory: mkdir /home/cnb/udmrepo: read-only file system
+```
+
+The workaround is making those directories as ephemeral k8s volumes, then those directories are not counted as pod's root filesystem.
+The `user-name` is the Velero pod's running user name. The default value is `cnb`.
+
+``` yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: velero
+  namespace: velero
+spec:
+  template:
+    spec:
+      containers:
+      - name: velero
+        ......
+        volumeMounts:
+          ......
+          - mountPath: /home/<user-name>/udmrepo
+            name: udmrepo
+          - mountPath: /home/<user-name>/.cache
+            name: cache
+          ......
+      volumes:
+        ......
+        - emptyDir: {}
+          name: udmrepo
+        - emptyDir: {}
+          name: cache
+        ......
+```
+
+At present, Velero doesn't allow to set `ReadOnlyRootFileSystem` parameter to data mover pods, so the root filesystem for the data mover pods are always writable.  
+
+### Resource Consumption
+
+Both the uploader and repository consume remarkable CPU/memory during the backup/restore, especially for massive small files or large backup size cases.  
+
+For Velero built-in data mover, Velero uses [BestEffort as the QoS][13] for data mover pods (so no CPU/memory request/limit is set), so that backups/restores wouldn't fail due to resource throttling in any cases.  
+If you want to constraint the CPU/memory usage, you need to [Customize Data Mover Pod Resource Limits][11]. The CPU/memory consumption is always related to the scale of data to be backed up/restored, refer to [Performance Guidance][12] for more details, so it is highly recommended that you perform your own testing to find the best resource limits for your data.  
+
+During the restore, the repository may also cache data/metadata so as to reduce the network footprint and speed up the restore. The repository uses its own policy to store and clean up the cache.  
+For Kopia repository, by default, the cache is stored in the data mover pod's root file system. If your root file system space is limited, the data mover pods may be evicted due to running out of the ephemeral storage, which causes the restore fails. To cope with this problem, Velero allows you:
+- configure a limit of the cache size per backup repository, for more details, check [Backup Repository Configuration][17].  
+- configure a dedicated volume for cache data, for more details, check [Data Movement Cache Volume][21].  
+
+
+### Node Selection
+
+The node where a data movement backup/restore runs is decided by the data mover.  
+
+For Velero built-in data mover, it uses Kubernetes' scheduler to mount a snapshot volume/restore volume associated to a `DataUpload`/`DataDownload` CR into a specific node, and then the data movement backup/restore will happen in that node.  
+For the backup, you can intervene this scheduling process through [Data Movement Backup Node Selection][15], so that you can decide which node(s) should/should not run the data movement backup for various purposes.  
+For the restore, this is not supported because sometimes the data movement restore must run in the same node where the restored workload pod is scheduled.  
+
+### BackupPVC Configuration
+
+The `BackupPVC` serves as an intermediate Persistent Volume Claim (PVC) utilized during data movement backup operations, providing efficient access to data.
+In complex storage environments, optimizing `BackupPVC` configurations can significantly enhance the performance of backup operations. [This document][16] outlines advanced configuration options for `BackupPVC`, allowing users to fine-tune access modes and storage class settings based on their storage provider's capabilities.  
+
+### RestorePVC Configuration
+
+The `RestorePVC` serves as an intermediate Persistent Volume Claim (PVC) utilized during data movement restore operations, providing efficient access to data.  
+Sometimes, `RestorePVC` needs to be configured to increase the performance of restore operations. [This document][19] outlines advanced configuration options for `RestorePVC`, allowing users to fine-tune access modes and storage class settings based on their storage provider's capabilities.  
+
+
+[1]: https://github.com/vmware-tanzu/velero/pull/5968
+[2]: csi.md
+[3]: file-system-backup.md
+[4]: https://kubernetes.io/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/
+[5]: https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation
+[7]: https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv
+[8]: api-types/backupstoragelocation.md
+[9]: supported-providers.md
+[10]: restore-reference.md#changing-pv/pvc-Storage-Classes
+[11]: data-movement-pod-resource-configuration.md
+[12]: performance-guidance.md
+[13]: https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/
+[14]: node-agent-concurrency.md
+[15]: data-movement-node-selection.md
+[16]: data-movement-backup-pvc-configuration.md
+[17]: backup-repository-configuration.md
+[18]: https://github.com/vmware-tanzu/velero/pull/7576
+[19]: data-movement-restore-pvc-configuration.md
+[20]: node-agent-prepare-queue-length.md
+[21]: data-movement-cache-volume.md
+[22]: https://tip.golang.org/doc/go1.25#container-aware-gomaxprocs:~:text=Runtime%C2%B6-,Container%2Daware%20GOMAXPROCS,-%C2%B6
+
+
@@ -0,0 +1,136 @@
+---
+title: "Container Storage Interface Snapshot Support in Velero"
+layout: docs
+---
+
+Integrating Container Storage Interface (CSI) snapshot support into Velero enables Velero to backup and restore CSI-backed volumes using the [Kubernetes CSI Snapshot APIs](https://kubernetes.io/docs/concepts/storage/volume-snapshots/).
+
+By supporting CSI snapshot APIs, Velero can support any volume provider that has a CSI driver, without requiring a Velero-specific plugin to be available. This page gives an overview of how to add support for CSI snapshots to Velero.
+
+## Notice
+From release-1.14, the `github.com/vmware-tanzu/velero-plugin-for-csi` repository, which is the Velero CSI plugin, is merged into the `github.com/vmware-tanzu/velero` repository.
+The reasons to merge the CSI plugin are:
+* The VolumeSnapshot data mover depends on the CSI plugin, it's reasonabe to integrate them.
+* This change reduces the Velero deploying complexity.
+* This makes performance tuning easier in the future.
+
+As a result, no need to install Velero CSI plugin anymore.
+
+## Prerequisites
+
+ 1. Your cluster is Kubernetes version 1.20 or greater.
+ 1. Your cluster is running a CSI driver capable of support volume snapshots at the [v1 API level](https://kubernetes.io/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/).
+ 1. When restoring CSI VolumeSnapshots across clusters, the name of the CSI driver in the destination cluster is the same as that on the source cluster to ensure cross cluster portability of CSI VolumeSnapshots
+
+**NOTE:** Not all cloud provider's CSI drivers guarantee snapshot durability, meaning that the VolumeSnapshot and VolumeSnapshotContent objects may be stored in the same object storage system location as the original PersistentVolume and may be vulnerable to data loss. You should refer to your cloud provider's documentation for more information on configuring snapshot durability.  Since v0.3.0 the velero team will provide official support for CSI plugin when they are used with AWS and Azure drivers.
+
+## Installing Velero with CSI support
+
+To integrate Velero with the CSI volume snapshot APIs, you must enable the `EnableCSI` feature flag.
+
+```bash
+velero install \
+--features=EnableCSI \
+--plugins=<object storage plugin> \
+...
+```
+
+To include the status of CSI objects associated with a Velero backup in `velero backup describe` output, run `velero client config set features=EnableCSI`.
+See [Enabling Features][1] for more information about managing client-side feature flags.
+
+## Implementation Choices
+
+This section documents some of the choices made during implementing the CSI snapshot.
+
+ 1. VolumeSnapshots created by the Velero CSI plugins are retained only for the lifetime of the backup even if the `DeletionPolicy` on the VolumeSnapshotClass is set to `Retain`. To accomplish this, during deletion of the backup the prior to deleting the VolumeSnapshot, VolumeSnapshotContent object is patched to set its `DeletionPolicy` to `Delete`. Deleting the VolumeSnapshot object will result in cascade delete of the VolumeSnapshotContent and the snapshot in the storage provider.
+ 2. VolumeSnapshotContent objects created during a `velero backup` that are dangling, unbound to a VolumeSnapshot object, will be discovered, using labels, and deleted on backup deletion.
+ 3. The Velero CSI plugins, to backup CSI backed PVCs, will choose the VolumeSnapshotClass in the cluster based on the following logic:
+    1. **Default Behavior Based On Annotation:**
+    You can specify a default VolumeSnapshotClass for VolumeSnapshots that don't request any particular class to bind to by adding the snapshot.storage.kubernetes.io/is-default-class: "true" annotation.
+    For example, if you want to create a VolumeSnapshotClass for the CSI driver `disk.csi.cloud.com` for taking snapshots of disks created with `disk.csi.cloud.com` based storage classes, you can create a VolumeSnapshotClass like this:
+        ```yaml
+        apiVersion: snapshot.storage.k8s.io/v1
+        kind: VolumeSnapshotClass
+        metadata:
+          name: test-snapclass-by-annotation
+          annotations:
+            snapshot.storage.kubernetes.io/is-default-class: "true"
+        driver: disk.csi.cloud.com
+       ```    
+       Note: If multiple CSI drivers exist, a default VolumeSnapshotClass can be specified for each of them.
+    2. **Default Behavior Based On Label:**
+    You can simply create a VolumeSnapshotClass for a particular driver and put a label on it to indicate that it is the default VolumeSnapshotClass for that driver.  For example, if you want to create a VolumeSnapshotClass for the CSI driver `disk.csi.cloud.com` for taking snapshots of disks created with `disk.csi.cloud.com` based storage classes, you can create a VolumeSnapshotClass like this:
+        ```yaml
+        apiVersion: snapshot.storage.k8s.io/v1
+        kind: VolumeSnapshotClass
+        metadata:
+          name: test-snapclass-by-label
+          labels:
+            velero.io/csi-volumesnapshot-class: "true"
+        driver: disk.csi.cloud.com
+        ```
+        Note: For each driver type, there should only be 1 VolumeSnapshotClass with the label `velero.io/csi-volumesnapshot-class: "true"`.
+
+    2. **Choose VolumeSnapshotClass for a particular Backup Or Schedule:**
+    If you want to use a particular VolumeSnapshotClass for a particular backup or schedule, you can add a annotation to the backup or schedule to indicate which VolumeSnapshotClass to use.  For example, if you want to use the VolumeSnapshotClass `test-snapclass` for a particular backup for snapshotting PVCs of `disk.csi.cloud.com`, you can create a backup like this:
+        ```yaml
+        apiVersion: velero.io/v1
+        kind: Backup
+        metadata:
+          name: test-backup
+          annotations:
+            velero.io/csi-volumesnapshot-class_disk.csi.cloud.com: "test-snapclass"
+        spec:
+            includedNamespaces:
+            - default
+        ```
+        Note: Please ensure all your annotations are in lowercase. And follow the following format: `velero.io/csi-volumesnapshot-class_<driver name> = <VolumeSnapshotClass Name>`
+
+    3. **Choosing VolumeSnapshotClass for a particular PVC:**
+    If you want to use a particular VolumeSnapshotClass for a particular PVC, you can add a annotation to the PVC to indicate which VolumeSnapshotClass to use. This overrides any annotation added to backup or schedule. For example, if you want to use the VolumeSnapshotClass `test-snapclass` for a particular PVC, you can create a PVC like this:
+        ```yaml
+        apiVersion: v1
+        kind: PersistentVolumeClaim
+        metadata:
+          name: test-pvc
+          annotations:
+            velero.io/csi-volumesnapshot-class: "test-snapclass"
+        spec:
+            accessModes:
+            - ReadWriteOnce
+            resources:
+                requests:
+                storage: 1Gi
+            storageClassName: disk.csi.cloud.com
+        ```
+ 4. The VolumeSnapshot objects will be removed from the cluster after the backup is uploaded to the object storage, so that the namespace that is backed up can be deleted without removing the snapshot in the storage provider if the `DeletionPolicy` is `Delete`.  
+
+## How it Works - Overview
+
+Velero's CSI support does not rely on the Velero VolumeSnapshotter plugin interface.
+
+Instead, Velero uses a collection of BackupItemAction plugins that act first against PersistentVolumeClaims.
+
+When this BackupItemAction sees PersistentVolumeClaims pointing to a PersistentVolume backed by a CSI driver, it will choose the VolumeSnapshotClass with the same driver name that has the `velero.io/csi-volumesnapshot-class` label to create a CSI VolumeSnapshot object with the PersistentVolumeClaim as a source.
+This VolumeSnapshot object resides in the same namespace as the PersistentVolumeClaim that was used as a source.
+
+From there, the CSI external-snapshotter controller will see the VolumeSnapshot and create a VolumeSnapshotContent object, a cluster-scoped resource that will point to the actual, disk-based snapshot in the storage system.
+The external-snapshotter plugin will call the CSI driver's snapshot method, and the driver will call the storage system's APIs to generate the snapshot.
+Once an ID is generated and the storage system marks the snapshot as usable for restore, the VolumeSnapshotContent object will be updated with a `status.snapshotHandle` and the `status.readyToUse` field will be set.
+
+Velero will include the generated VolumeSnapshot and VolumeSnapshotContent objects in the backup tarball, as well as
+upload all VolumeSnapshots and VolumeSnapshotContents objects in a JSON file to the object storage system. **Note that
+only Kubernetes objects are uploaded to the object storage, not the data in snapshots.**
+
+From v1.16, when Velero synchronizes backups into a new cluster, the VolumeSnapshotClass that is chosen to take
+snapshot will be synced into the cluster, so that Velero can manage backup expiration appropriately.
+
+
+The `DeletionPolicy` on the VolumeSnapshotContent will be the same as the `DeletionPolicy` on the VolumeSnapshotClass that was used to create the VolumeSnapshot. Setting a `DeletionPolicy` of `Retain` on the VolumeSnapshotClass will preserve the volume snapshot in the storage system for the lifetime of the Velero backup and will prevent the deletion of the volume snapshot, in the storage system, in the event of a disaster where the namespace with the VolumeSnapshot object may be lost.
+
+When the Velero backup expires, the VolumeSnapshot objects will be deleted and the VolumeSnapshotContent objects will be updated to have a `DeletionPolicy` of `Delete`, to free space on the storage system.
+
+**Note:** The AWS, Microsoft Azure, and Google Cloud Platform (GCP) Velero plugins version 1.4 and later are able to snapshot and restore persistent volumes provisioned by a CSI driver via the APIs of the cloud provider, without having to install Velero CSI plugins. See the [AWS](https://github.com/vmware-tanzu/velero-plugin-for-aws), [Microsoft Azure](https://github.com/vmware-tanzu/velero-plugin-for-microsoft-azure), and [Google Cloud Platform (GCP)](https://github.com/vmware-tanzu/velero-plugin-for-gcp) Velero plugin repo for more information on supported CSI drivers.
+From v1.14, no need to install the CSI plugin, because it is integrated into the Velero code base.
+
+[1]: customize-installation.md#enable-server-side-features
@@ -0,0 +1,121 @@
+---
+title: "Plugins"
+layout: docs
+---
+
+Velero has a plugin architecture that allows users to add their own custom functionality to Velero backups & restores without having to modify/recompile the core Velero binary. To add custom functionality, users simply create their own binary containing implementations of Velero's plugin kinds (described below), plus a small amount of boilerplate code to expose the plugin implementations to Velero. This binary is added to a container image that serves as an init container for the Velero server pod and copies the binary into a shared emptyDir volume for the Velero server to access.
+
+Multiple plugins, of any type,  can be implemented in this binary.
+
+A fully-functional [sample plugin repository][1] is provided to serve as a convenient starting point for plugin authors.
+
+## Plugin Naming
+
+A plugin is identified by a prefix + name. 
+
+**Note: Please don't use `velero.io` as the prefix for a plugin not supported by the Velero team.** The prefix should help users identify the entity developing the plugin, so please use a prefix that identify yourself. 
+
+Whenever you define a Backup Storage Location or Volume Snapshot Location, this full name will be the value for the `provider` specification.
+
+For example: `oracle.io/oracle`.
+
+```
+apiVersion: velero.io/v1
+kind: BackupStorageLocation
+spec:
+  provider: oracle.io/oracle
+```
+
+```
+apiVersion: velero.io/v1
+kind: VolumeSnapshotLocation
+spec:
+  provider: oracle.io/oracle
+```
+
+When naming your plugin, keep in mind that the full name needs to conform to these rules:
+- have two parts, prefix + name, separated by '/'
+- none of the above parts can be empty
+- the prefix is a valid DNS subdomain name
+- a plugin with the same prefix + name cannot already exist
+
+### Some examples:
+
+```
+- example.io/azure
+- 1.2.3.4/5678
+- example-with-dash.io/azure
+```
+
+You will need to give your plugin(s) the full name when registering them by calling the appropriate `RegisterX` function: <https://github.com/vmware-tanzu/velero/blob/0e0f357cef7cf15d4c1d291d3caafff2eeb69c1e/pkg/plugin/framework/server.go#L42-L60>
+
+## Plugin Kinds
+
+Velero supports the following kinds of plugins:
+
+- **Object Store** - persists and retrieves backups, backup logs and restore logs
+- **Volume Snapshotter** - creates volume snapshots (during backup) and restores volumes from snapshots (during restore)
+- **Backup Item Action** - executes arbitrary logic for individual items prior to storing them in a backup file
+- **Restore Item Action** - executes arbitrary logic for individual items prior to restoring them into a cluster
+- **Delete Item Action** - executes arbitrary logic based on individual items within a backup prior to deleting the backup
+- **Item Block Action** - executes arbitrary logic for individual items to determine which items should be backed up together
+
+Plugin binaries are discovered by recursively reading a directory in no particular order. Hence no guarantee is provided for the
+order in which item action plugins are invoked. However, if a single binary implements multiple item action plugins,
+they may be invoked in the order in which they are registered but it is best to not depend on this
+implementation. This is not guaranteed officially and the implementation can change at any time.
+
+## Plugin Logging
+
+Velero provides a [logger][2] that can be used by plugins to log structured information to the main Velero server log or
+per-backup/restore logs. It also passes a `--log-level` flag to each plugin binary, whose value is the value of the same
+flag from the main Velero process. This means that if you turn on debug logging for the Velero server via `--log-level=debug`,
+plugins will also emit debug-level logs. See the [sample repository][1] for an example of how to use the logger within your plugin.
+
+## Plugin Configuration
+
+Velero uses a ConfigMap-based convention for providing configuration to plugins. If your plugin needs to be configured at runtime,
+define a ConfigMap like the following:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  # any name can be used; Velero uses the labels (below)
+  # to identify it rather than the name
+  name: my-plugin-config
+
+  # must be in the namespace where the velero deployment
+  # is running
+  namespace: velero
+
+  labels:
+    # this value-less label identifies the ConfigMap as
+    # config for a plugin (the built-in change storageclass
+    # restore item action plugin)
+    velero.io/plugin-config: ""
+
+    # add a label whose key corresponds to the fully-qualified
+    # plugin name (for example mydomain.io/my-plugin-name), and whose
+    # value is the plugin type (BackupItemAction, RestoreItemAction,
+    # ObjectStore, or VolumeSnapshotter)
+    <fully-qualified-plugin-name>: <plugin-type>
+
+data:
+  # add your configuration data here as key-value pairs
+```
+
+Then, in your plugin's implementation, you can read this ConfigMap to fetch the necessary configuration. 
+
+## Feature Flags
+
+Velero will pass any known features flags as a comma-separated list of strings to the `--features` argument.
+
+Once parsed into a `[]string`, the features can then be registered using the `NewFeatureFlagSet` function and queried with `features.Enabled(<featureName>)`.
+
+## Environment Variables
+
+Velero adds the `LD_LIBRARY_PATH` into the list of environment variables to provide the convenience for plugins that requires C libraries/extensions in the runtime.
+
+[1]: https://github.com/vmware-tanzu/velero-plugin-example
+[2]: https://github.com/vmware-tanzu/velero/blob/v1.18.0/pkg/plugin/logger.go
@@ -0,0 +1,535 @@
+---
+title: "Customize Velero Install"
+layout: docs
+---
+
+## Plugins
+
+During install, Velero requires that at least one plugin is added (with the `--plugins` flag). Please see the documentation under [Plugins](overview-plugins.md)
+
+## Install in any namespace
+
+Velero is installed in the `velero` namespace by default. However, you can install Velero in any namespace. See [run in custom namespace][2] for details.
+
+## Use non-file-based identity mechanisms
+
+By default, `velero install` expects a credentials file for your `velero` IAM account to be provided via the `--secret-file` flag.
+
+If you are using an alternate identity mechanism, such as kube2iam/kiam on AWS, Workload Identity on GKE, etc., that does not require a credentials file, you can specify the `--no-secret` flag instead of `--secret-file`.
+
+## Enable file system backup
+
+By default, `velero install` does not install Velero's [File System Backup][3]. To enable it, specify the `--use-node-agent` flag.
+
+If you've already run `velero install` without the `--use-node-agent` flag, you can run the same command again, including the `--use-node-agent` flag, to add the file system backup to your existing install.
+
+Note that for some use cases (including installation on OpenShift clusters) the fs-backup pods must run in a Privileged security context. This is configured through the node-agent configmap (see below) by setting `privilegedFsBackup` to `true` in the configmap.
+
+## CSI Snapshot Data Movement
+
+Velero node-agent is required by [CSI Snapshot Data Movement][12] when Velero built-in data mover is used. By default, `velero install` does not install Velero's node-agent. To enable it, specify the `--use-node-agent` flag.
+
+For some use cases, Velero node-agent requires to run under privileged mode. For example, when backing up block volumes, it is required to allow the node-agent to access the block device. To enable it set velero install flags `--privileged-node-agent`.
+
+If you've already run `velero install` without the `--use-node-agent` or `--privileged-node-agent` flag, you can run the same command again, including the `--use-node-agent` or `--privileged-node-agent` flag, to add CSI snapshot data movement to your existing install.
+
+## Customize the kubelet root path of the node-agent
+When installing with the `--use-node-agent` flag, the node-agent will mount the default kubelet paths `/var/lib/kubelet/pods` and `/var/lib/kubelet/plugins` (hostPath). To customize these kubelet mount paths, use the `--kubelet-root-dir` flag.
+
+## Default Pod Volume backup to file system backup
+
+By default, `velero install` does not enable the use of File System Backup (FSB) to take backups of all pod volumes. You must apply an [annotation](file-system-backup.md/#using-opt-in-pod-volume-backup) to every pod which contains volumes for Velero to use FSB for the backup.
+
+If you are planning to only use FSB for volume backups, you can run the `velero install` command with the `--default-volumes-to-fs-backup` flag. This will default all pod volumes backups to use FSB without having to apply annotations to pods. Note that when this flag is set during install, Velero will always try to use FSB to perform the backup, even want an individual backup to use volume snapshots, by setting the `--snapshot-volumes` flag in the `backup create` command. Alternatively, you can set the  `--default-volumes-to-fs-backup` on an individual backup to to make sure Velero uses FSB for each volume being backed up.
+
+## Update an existing installation
+
+By default, the `velero install` command creates new resources in your cluster. If you're updating an existing Velero installation, you can use the `--apply` flag to apply changes to existing resources instead of attempting to create new ones:
+
+```bash
+velero install --apply
+```
+
+When the `--apply` flag is specified, Velero uses server-side apply to update existing resources. This is particularly useful when updating Velero to a new version or when modifying your installation configuration. While this can be used as part of an upgrade process, please note that for version upgrades, additional steps may be required depending on the specific changes between versions. Also ensure when using this flag that you are setting any additional flags previously used for your existing configuration so that you don't introduce unexpected changes.
+
+## Enable features
+
+New features in Velero will be released as beta features behind feature flags which are not enabled by default. A full listing of Velero feature flags can be found [here][11].
+
+### Enable server side features
+
+Features on the Velero server can be enabled using the `--features` flag to the `velero install` command. This flag takes as value a comma separated list of feature flags to enable. As an example [CSI snapshotting of PVCs][10] can be enabled using `EnableCSI` feature flag in the `velero install` command as shown below:
+
+```bash
+velero install --features=EnableCSI
+```
+
+Another example is enabling the support of multiple API group versions, as documented at [- -features=EnableAPIGroupVersions](enable-api-group-versions-feature.md).
+
+Feature flags, passed to `velero install` will be passed to the Velero deployment and also to the `node-agent` daemon set, if `--use-node-agent` flag is used.
+
+Similarly, features may be disabled by removing the corresponding feature flags from the `--features` flag.
+
+Enabling and disabling feature flags will require modifying the Velero deployment and also the node-agent daemonset. This may be done from the CLI by uninstalling and re-installing Velero, or by editing the `deploy/velero` and `daemonset/node-agent` resources in-cluster.
+
+```bash
+$ kubectl -n velero edit deploy/velero
+$ kubectl -n velero edit daemonset/node-agent
+```
+
+### Enable client side features
+
+For some features it may be necessary to use the `--features` flag to the Velero client. This may be done by passing the `--features` on every command run using the Velero CLI or the by setting the features in the velero client config file using the `velero client config set` command as shown below:
+
+```bash
+velero client config set features=feature1,feature2...
+```
+
+This stores the config in a file at `$HOME/.config/velero/config.json`.
+
+All client side feature flags may be disabled using the below command
+
+```bash
+velero client config set features=
+```
+
+### Colored CLI output
+
+Velero CLI uses colored output for some commands, such as `velero describe`. If
+the environment in which Velero is run doesn't support colored output, the
+colored output will be automatically disabled. However, you can manually disable
+colors with config file:
+
+```bash
+velero client config set colorized=false
+```
+
+Note that if you specify `--colorized=true` as a CLI option it will override
+the config file setting.
+
+
+## Set priority class names for Velero components
+
+You can set priority class names for different Velero components during installation. This allows you to influence the scheduling and eviction behavior of Velero pods, which can be useful in clusters where resource contention is high.
+
+### Priority class configuration options:
+
+1. **Velero server deployment**: Use the `--server-priority-class-name` flag
+2. **Node agent daemonset**: Use the `--node-agent-priority-class-name` flag
+3. **Data mover pods**: Configure through the node-agent configmap (see below)
+4. **Maintenance jobs**: Configure through the repository maintenance job configmap (see below)
+
+```bash
+velero install \
+    --server-priority-class-name=<SERVER_PRIORITY_CLASS> \
+    --node-agent-priority-class-name=<NODE_AGENT_PRIORITY_CLASS>
+```
+
+### Configuring priority classes for data mover pods and maintenance jobs
+
+For data mover pods and maintenance jobs, priority classes are configured through ConfigMaps that must be created before installation:
+
+**Data mover pods** (via node-agent configmap):
+```bash
+kubectl create configmap node-agent-config -n velero --from-file=config.json=/dev/stdin <<EOF
+{
+    "priorityClassName": "low-priority"
+}
+EOF
+
+velero install --node-agent-configmap node-agent-config # ... other flags
+```
+
+**Maintenance jobs** (via repository maintenance job configmap):
+```bash
+kubectl create configmap repo-maintenance-job-config -n velero --from-file=config.json=/dev/stdin <<EOF
+{
+    "global": {
+        "priorityClassName": "low-priority"
+    }
+}
+EOF
+
+velero install --repo-maintenance-job-configmap repo-maintenance-job-config # ... other flags
+```
+
+Note that you need to create the priority classes before installing Velero. For more information on priority classes, see the [Kubernetes documentation on Pod Priority and Preemption](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/).
+
+## Customize resource requests and limits
+
+At installation, You could set resource requests and limits for the Velero pod, the node-agent pod and the [repository maintenance job][14], if you are using the [File System Backup][3] or [CSI Snapshot Data Movement][12].  
+
+{{< table caption="Velero Customize resource requests and limits defaults" >}}
+|Setting|Velero pod defaults|node-agent pod defaults|
+|--- |--- |--- |
+|CPU request|500m|N/A|
+|Memory requests|128Mi|N/A|
+|CPU limit|1000m (1 CPU)|N/A|
+|Memory limit|512Mi|N/A|
+{{< /table >}}
+  
+For Velero pod, through testing, the Velero maintainers have found these defaults work well when backing up and restoring 1000 or less resources. If you are enabling concurrent backups and your backups tend to be large, you may need to increase these limits.
+For node-agent pod, by default it doesn't have CPU/memory request/limit, so that the backups/restores won't break due to resource throttling. The Velero maintainers have also done some [Performance Tests][13] to show the relationship of CPU/memory usage and the scale of data being backed up/restored.
+
+For repository maintenance job, it's no limit on resources by default. You could configure the job resource limitation based on target data to be backed up, some further settings please refer to [repository maintenance job][14].
+
+You don't have to change the defaults all the time, but if you need, it's recommended that you perform your own testing to find the best resource limits for your clusters and resources.   
+
+### Install with custom resource requests and limits
+
+You can customize these resource requests and limit when you first install using the [velero install][6] CLI command.
+
+```
+velero install \
+  --velero-pod-cpu-request <CPU_REQUEST> \
+  --velero-pod-mem-request <MEMORY_REQUEST> \
+  --velero-pod-cpu-limit <CPU_LIMIT> \
+  --velero-pod-mem-limit <MEMORY_LIMIT> \
+  [--use-node-agent] \
+  [--default-volumes-to-fs-backup] \
+  [--node-agent-pod-cpu-request <CPU_REQUEST>] \
+  [--node-agent-pod-mem-request <MEMORY_REQUEST>] \
+  [--node-agent-pod-cpu-limit <CPU_LIMIT>] \
+  [--node-agent-pod-mem-limit <MEMORY_LIMIT>] \
+  [--maintenance-job-cpu-request <CPU_REQUEST>] \
+  [--maintenance-job-mem-request <MEMORY_REQUEST>] \
+  [--maintenance-job-cpu-limit <CPU_LIMIT>] \
+  [--maintenance-job-mem-limit <MEMORY_LIMIT>]
+```
+
+### Update resource requests and limits after install
+
+After installation you can adjust the resource requests and limits in the Velero Deployment spec or node-agent DaemonSet spec, if you are using the File System Backup.
+
+**Velero pod**
+
+Update the `spec.template.spec.containers.resources.limits` and `spec.template.spec.containers.resources.requests` values in the Velero deployment.
+
+```bash
+kubectl patch deployment velero -n velero --patch \
+'{"spec":{"template":{"spec":{"containers":[{"name": "velero", "resources": {"limits":{"cpu": "1", "memory": "512Mi"}, "requests": {"cpu": "1", "memory": "128Mi"}}}]}}}}'
+```
+
+**node-agent pod**
+
+Update the `spec.template.spec.containers.resources.limits` and `spec.template.spec.containers.resources.requests` values in the node-agent DaemonSet spec.
+
+```bash
+kubectl patch daemonset node-agent -n velero --patch \
+'{"spec":{"template":{"spec":{"containers":[{"name": "node-agent", "resources": {"limits":{"cpu": "1", "memory": "1024Mi"}, "requests": {"cpu": "1", "memory": "512Mi"}}}]}}}}'
+```
+
+Additionally, you may want to update the the default File System Backup operation timeout (default 240 minutes) to allow larger backups more time to complete. You can adjust this timeout by adding the `- --fs-backup-timeout` argument to the Velero Deployment spec.
+
+**NOTE:** Changes made to this timeout value will revert back to the default value if you re-run the Velero install command.
+
+1. Open the Velero Deployment spec.
+
+    ```
+    kubectl edit deploy velero -n velero
+    ```
+
+1. Add `- --fs-backup-timeout` to `spec.template.spec.containers`.
+
+    ```yaml
+    spec:
+      template:
+        spec:
+          containers:
+          - args:
+            - --fs-backup-timeout=240m
+    ```
+
+### Ephemeral-storage Requests and Limits
+
+Velero does not set ephemeral-storage limits during installation. Limits and requests can be edited after install for clusters that monitor and restrict ephemeral-storage usage. 
+
+Plugins will use ephemeral-storage. There needs to be a sufficient requests and limit set to account for plugins and the additional ephemeral-storage used to maintain credentials and cache space for datamovers. Object storage plugins will fit comfortably into an allocation of 100MB of ephemeral-storage.
+
+## Configure more than one storage location for backups or volume snapshots
+
+Velero supports any number of backup storage locations and volume snapshot locations. For more details, see [about locations](locations.md).
+
+However, `velero install` only supports configuring at most one backup storage location and one volume snapshot location.
+
+To configure additional locations after running `velero install`, use the `velero backup-location create` and/or `velero snapshot-location create` commands along with provider-specific configuration. Use the `--help` flag on each of these commands for more details.
+
+### Set default backup storage location or volume snapshot locations
+
+When performing backups, Velero needs to know where to backup your data. This means that if you configure multiple locations, you must specify the location Velero should use each time you run `velero backup create`, or you can set a default backup storage location or default volume snapshot locations. If you only have one backup storage location or volume snapshot location set for a provider, Velero will automatically use that location as the default.
+
+#### Set default backup storage location
+currently, Velero could set the default backup storage location as below:
+- First way: Set a default backup storage location by passing a `--default` flag when running `velero backup-location create`.
+
+  ```
+  velero backup-location create backups-primary \
+    --provider aws \
+    --bucket velero-backups \
+    --config region=us-east-1 \
+    --default
+  ```
+- Second way: Set a default backup storage location by passing a  `--default` flag when running `velero backup-location set`.
+  ```bash
+  velero backup-location set backups-primary --default
+  ```
+  We also could remove the default backup storage location by this command, below is one example
+  ```bash
+  velero backup-location set backups-primary --default=false
+  ```
+- Third way: Set a default backup storage location by passing `--default-backup-storage-location` flag on the `velero server` command.
+   ```bash
+  velero server --default-backup-storage-location backups-primary
+   ```
+Note: Only could have one default backup storage location, which means it's not allowed to set two default backup storage locations at the same time, the priorities among these three are as follows:
+- if velero server side has specified one default backup storage location, suppose it's `A`
+  - if `A` backup storage location exists, it's not allowed to set a new default backup storage location
+  - if `A` does not exist
+    - if using `velero backup-location set` or `velero backup-location create --default` command
+      - it could be successful if no default backup storage location exists.
+      - it would fail if already exist one default backup storage location. (So it need to remove other default backup storage location at first)
+- if velero server side has not specified one default backup storage location
+  - if using `velero backup-location set` or `velero backup-location create --default` command
+    - it could be successful if no default backup storage location exists.
+    - it would fail if already exist one default backup storage location. (So it need to remove other default backup storage location at first)
+#### Set default volume snapshot location
+You can set a default volume snapshot location for each of your volume snapshot providers using the `--default-volume-snapshot-locations` flag on the `velero server` command.
+
+```
+velero server --default-volume-snapshot-locations="<PROVIDER-NAME>:<LOCATION-NAME>,<PROVIDER2-NAME>:<LOCATION2-NAME>"
+```
+
+## Do not configure a backup storage location during install
+
+If you need to install Velero without a default backup storage location (without specifying `--bucket` or `--provider`), the `--no-default-backup-location` flag is required for confirmation.
+
+## Install an additional volume snapshot provider
+
+Velero supports using different providers for volume snapshots than for object storage -- for example, you can use AWS S3 for object storage, and Portworx for block volume snapshots.
+
+However, `velero install` only supports configuring a single matching provider for both object storage and volume snapshots.
+
+To use a different volume snapshot provider:
+
+1. Install the Velero server components by following the instructions for your **object storage** provider
+
+1. Add your volume snapshot provider's plugin to Velero (look in [your provider][0]'s documentation for the image name):
+
+    ```bash
+    velero plugin add <registry/image:version>
+    ```
+
+1. Add a volume snapshot location for your provider, following [your provider][0]'s documentation for configuration:
+
+    ```bash
+    velero snapshot-location create <NAME> \
+        --provider <PROVIDER-NAME> \
+        [--config <PROVIDER-CONFIG>]
+    ```
+
+## Generate YAML only
+
+By default, `velero install` generates and applies a customized set of Kubernetes configuration (YAML) to your cluster.
+
+To generate the YAML without applying it to your cluster, use the `--dry-run -o yaml` flags.
+
+This is useful for applying bespoke customizations, integrating with a GitOps workflow, etc.
+
+If you are installing Velero in Kubernetes 1.14.x or earlier, you need to use `kubectl apply`'s `--validate=false` option when applying the generated configuration to your cluster. See [issue 2077][7] and [issue 2311][8] for more context.
+
+## Use a storage provider secured by a self-signed certificate
+
+If you intend to use Velero with a storage provider that is secured by a self-signed certificate,
+you may need to instruct Velero to trust that certificate. See [use Velero with a storage provider secured by a self-signed certificate][9] for details.
+
+## Additional options
+
+Run `velero install --help` or see the [Helm chart documentation](https://vmware-tanzu.github.io/helm-charts/) for the full set of installation options.
+
+## Optional Velero CLI configurations
+
+### Enabling shell autocompletion
+
+**Velero CLI** provides autocompletion support for `Bash` and `Zsh`, which can save you a lot of typing.
+
+Below are the procedures to set up autocompletion for `Bash` (including the difference between `Linux` and `macOS`) and `Zsh`.
+
+#### Bash on Linux
+
+The **Velero CLI** completion script for `Bash` can be generated with the command `velero completion bash`. Sourcing the completion script in your shell enables velero autocompletion.
+
+However, the completion script depends on [**bash-completion**](https://github.com/scop/bash-completion), which means that you have to install this software first (you can test if you have bash-completion already installed by running `type _init_completion`).
+
+##### Install bash-completion
+
+`bash-completion` is provided by many package managers (see [here](https://github.com/scop/bash-completion#installation)). You can install it with `apt-get install bash-completion` or `yum install bash-completion`, etc.
+
+The above commands create `/usr/share/bash-completion/bash_completion`, which is the main script of bash-completion. Depending on your package manager, you have to manually source this file in your `~/.bashrc` file.
+
+To find out, reload your shell and run `type _init_completion`. If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file:
+
+```shell
+source /usr/share/bash-completion/bash_completion
+```
+
+Reload your shell and verify that bash-completion is correctly installed by typing `type _init_completion`.
+
+##### Enable Velero CLI autocompletion for Bash on Linux
+
+You now need to ensure that the **Velero CLI** completion script gets sourced in all your shell sessions. There are two ways in which you can do this:
+
+- Source the completion script in your `~/.bashrc` file:
+
+    ```shell
+    echo 'source <(velero completion bash)' >>~/.bashrc
+    ```
+
+- Add the completion script to the `/etc/bash_completion.d` directory:
+
+    ```shell
+    velero completion bash >/etc/bash_completion.d/velero
+    ```
+
+- If you have an alias for velero, you can extend shell completion to work with that alias:
+
+    ```shell
+    echo 'alias v=velero' >>~/.bashrc
+    echo 'complete -F __start_velero v' >>~/.bashrc
+    ```
+
+> `bash-completion` sources all completion scripts in `/etc/bash_completion.d`.
+
+Both approaches are equivalent. After reloading your shell, velero autocompletion should be working.
+
+#### Bash on macOS
+
+The **Velero CLI** completion script for Bash can be generated with `velero completion bash`. Sourcing this script in your shell enables velero completion.
+
+However, the velero completion script depends on [**bash-completion**](https://github.com/scop/bash-completion) which you thus have to previously install.
+
+
+> There are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2 (which is the default on macOS), and v2 is for Bash 4.1+. The velero completion script **doesn't work** correctly with bash-completion v1 and Bash 3.2. It requires **bash-completion v2** and **Bash 4.1+**. Thus, to be able to correctly use velero completion on macOS, you have to install and use Bash 4.1+ ([*instructions*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). The following instructions assume that you use Bash 4.1+ (that is, any Bash version of 4.1 or newer).
+
+
+##### Install bash-completion
+
+> As mentioned, these instructions assume you use Bash 4.1+, which means you will install bash-completion v2 (in contrast to Bash 3.2 and bash-completion v1, in which case kubectl completion won't work).
+
+You can test if you have bash-completion v2 already installed with `type _init_completion`. If not, you can install it with Homebrew:
+
+  ```shell
+  brew install bash-completion@2
+  ```
+
+As stated in the output of this command, add the following to your `~/.bashrc` file:
+
+  ```shell
+  export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
+  [[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
+  ```
+
+Reload your shell and verify that bash-completion v2 is correctly installed with `type _init_completion`.
+
+##### Enable Velero CLI autocompletion for Bash on macOS
+
+You now have to ensure that the velero completion script gets sourced in all your shell sessions. There are multiple ways to achieve this:
+
+- Source the completion script in your `~/.bashrc` file:
+
+    ```shell
+    echo 'source <(velero completion bash)' >>~/.bashrc
+
+    ```
+
+- Add the completion script to the `/usr/local/etc/bash_completion.d` directory:
+
+    ```shell
+    velero completion bash >/usr/local/etc/bash_completion.d/velero
+    ```
+
+- If you have an alias for velero, you can extend shell completion to work with that alias:
+
+    ```shell
+    echo 'alias v=velero' >>~/.bashrc
+    echo 'complete -F __start_velero v' >>~/.bashrc
+    ```
+
+- If you installed velero with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the velero completion script should already be in `/usr/local/etc/bash_completion.d/velero`. In that case, you don't need to do anything.
+
+> The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work.
+
+In any case, after reloading your shell, velero completion should be working.
+
+#### Autocompletion on Zsh
+
+The velero completion script for Zsh can be generated with the command `velero completion zsh`. Sourcing the completion script in your shell enables velero autocompletion.
+
+To do so in all your shell sessions, add the following to your `~/.zshrc` file:
+
+  ```shell
+  source <(velero completion zsh)
+  ```
+
+If you have an alias for kubectl, you can extend shell completion to work with that alias:
+
+  ```shell
+  echo 'alias v=velero' >>~/.zshrc
+  echo 'complete -F __start_velero v' >>~/.zshrc
+  ```
+
+After reloading your shell, kubectl autocompletion should be working.
+
+If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
+
+  ```shell
+  autoload -Uz compinit
+  compinit
+  ```
+
+## Advanced configuration through external ConfigMaps
+
+Velero supports to configure its some advanced behaviors by external ConfigMaps.
+Velero itself isn't responsible for creating and maintaining these ConfigMaps, instead the users should do that.
+
+By far, `velero install` supports the following parameters to specify the external ConfigMap names:
+* --backup-repository-configmap: [backup repository configuration document][15]
+* --node-agent-configmap: [node-agent concurrency configuration document][16], and there are some other documents specify other parts of node-agent-config.
+* --repo-maintenance-job-configmap: [repository maintenance configuration document][17]
+
+From v1.17, Velero adds verification for the ConfigMaps in CLI and server side, which means `velero install` CLI will fail and velero server and node-agent pod will exit if the specified ConfigMaps don't exist or are invalid.
+
+The change's aim is validating the ConfigMaps and fail early instead of finding the ConfigMaps are not valid during running data mover pod or repository maintenance job.
+
+However, there means the user cannot just running `velero install` CLI then get a working environment, when the external ConfigMaps are involved.
+
+The new workflow is:
+* Create the needed namespace: `kubectl create ns velero`
+* Add PSA labels to the namespace: `kubectl label ns velero pod-security.velero.io/enforce=privileged`
+* Create the needed ConfigMaps.
+* Run the `velero install` CLI:
+  ``` bash
+  velero install \
+    --provider aws \
+    ......
+    --backup-repository-configmap=... \
+    --node-agent-configmap=... \
+    --repo-maintenance-job-configmap=...
+  ```
+
+
+[1]: https://github.com/vmware-tanzu/velero/releases/latest
+[2]: namespace.md
+[3]: file-system-backup.md
+[4]: on-premises.md
+[6]: velero-install.md#usage
+[7]: https://github.com/vmware-tanzu/velero/issues/2077
+[8]: https://github.com/vmware-tanzu/velero/issues/2311
+[9]: self-signed-certificates.md
+[10]: csi.md
+[11]: https://github.com/vmware-tanzu/velero/blob/v1.18.0/pkg/apis/velero/v1/constants.go
+[12]: csi-snapshot-data-movement.md
+[13]: performance-guidance.md
+[14]: repository-maintenance.md
+[15]: backup-repository-configuration.md
+[16]: node-agent-concurrency.md
+[17]: repository-maintenance.md
@@ -0,0 +1,87 @@
+---
+title: "BackupPVC Configuration for Data Movement Backup"
+layout: docs
+---
+
+`BackupPVC`  is an intermediate PVC to access data from during the data movement backup operation.
+
+In some scenarios users may need to configure some advanced options of the backupPVC so that the data movement backup
+operation could perform better. Specifically:
+- For some storage providers, when creating a read-only volume from a snapshot, it is very fast; whereas, if a writable volume
+  is created from the snapshot, they need to clone the entire disk data, which is time consuming. If the `backupPVC`'s `accessModes` is
+  set as `ReadOnlyMany`, the volume driver is able to tell the storage to create a read-only volume, which may dramatically shorten the
+  snapshot expose time. On the other hand,  `ReadOnlyMany` is not supported by all volumes. Therefore, users should be allowed to configure
+  the `accessModes` for the `backupPVC`.
+- Some storage providers create one or more replicas when creating a volume, the number of replicas is defined in the storage class.
+  However, it doesn't make any sense to keep replicas when an intermediate volume used by the backup. Therefore, users should be allowed
+  to configure another storage class specifically used by the `backupPVC`.
+- In SELinux-enabled clusters, such as OpenShift, when using the above-mentioned readOnly access mode setting, SELinux relabeling of the
+  volume is not possible. Therefore for these clusters, when setting `readOnly` for a storage class, users must also disable relabeling.
+  Note that this option is not consistent with the Restricted pod security policy, so if Velero pods must run with a restricted policy,
+  disabling relabeling (and therefore readOnly volume mounting) is not possible.
+
+Velero introduces a new section in the node agent configuration ConfigMap (the name of this ConfigMap is passed using `--node-agent-configmap` velero server argument)
+called `backupPVC`, through which you can specify the following
+configurations:
+
+- `storageClass`: This specifies the storage class to be used for the backupPVC. If this value does not exist or is empty then by 
+default the source PVC's storage class will be used.
+
+- `readOnly`: This is a boolean value. If set to `true` then `ReadOnlyMany` will be the only value set to the backupPVC's access modes. Otherwise 
+`ReadWriteOnce` value will be used.
+
+- `spcNoRelabeling`: This is a boolean value. If set to `true`, then `pod.Spec.SecurityContext.SELinuxOptions.Type` will be set to `spc_t`. From
+  the SELinux point of view, this will be considered a "Super Privileged Container" which means that selinux enforcement will be disabled and
+  volume relabeling will not occur. This field is ignored if `readOnly` is `false`.
+
+The users can specify the ConfigMap name during velero installation by CLI:
+`velero install --node-agent-configmap=<ConfigMap-Name>`
+
+- `annotations`: permits to set annotations on the backupPVC itself. typically useful for some CSI provider which cannot mount
+  a VolumeSnapshot without a custom annotation.
+
+A sample of `backupPVC` config as part of the ConfigMap would look like:
+```json
+{
+    "backupPVC": {
+        "storage-class-1": {
+            "storageClass": "backupPVC-storage-class",
+            "readOnly": true
+        },
+        "storage-class-2": {
+            "storageClass": "backupPVC-storage-class"
+        },
+        "storage-class-3": {
+            "readOnly": true,
+            "annotations": {
+              "some-csi.provider.io/readOnlyClone": true
+            }
+        },
+        "storage-class-4": {
+            "readOnly": true,
+            "spcNoRelabeling": true
+        }
+    }
+}
+```
+
+**Note:** 
+- Users should make sure that the storage class specified in `backupPVC` config should exist in the cluster and can be used by the
+`backupPVC`, otherwise the corresponding DataUpload CR will stay in `Accepted` phase until timeout (data movement prepare timeout value is 30m by default).
+- If the users are setting `readOnly` value as `true` in the `backupPVC` config then they must also make sure that the storage class that is being used for
+`backupPVC` should support creation of `ReadOnlyMany` PVC from a snapshot, otherwise the corresponding DataUpload CR will stay in `Accepted` phase until
+timeout (data movement prepare timeout value is 30m by default).
+- In an SELinux-enabled cluster, any time users set `readOnly=true` they must also set `spcNoRelabeling=true`. There is no need to set `spcNoRelabeling=true`
+if the volume is not readOnly.
+- If any of the above problems occur, then the DataUpload CR is `canceled` after timeout, and the backupPod and backupPVC will be deleted, and the backup
+will be marked as `PartiallyFailed`.
+
+## Related Documentation
+
+- [Node-agent Configuration](supported-configmaps/node-agent-configmap.md) - Complete reference for all configuration options
+- [Node-agent Concurrency](node-agent-concurrency.md) - Configure concurrent operations per node
+- [Node Selection for Data Movement](data-movement-node-selection.md) - Configure which nodes run data movement
+- [Data Movement Pod Resource Configuration](data-movement-pod-resource-configuration.md) - Configure pod resources
+- [BackupPVC Configuration](data-movement-backup-pvc-configuration.md) - Configure backup storage
+- [RestorePVC Configuration](data-movement-restore-pvc-configuration.md) - Configure restore storage
+- [Cache PVC Configuration](data-movement-cache-volume.md) - Configure restore data mover storage
@@ -0,0 +1,55 @@
+---
+title: "Cache PVC Configuration for Data Movement Restore"
+layout: docs
+---
+
+Velero data movement restore (i.e., for CSI snapshot data movement and fs-backup) may request the backup repository to cache data locally so as to reduce the data request from the remote backup storage.  
+The cache behavior is decided by the specific backup repository, and Velero allows you to configure a cache limit for the backup repositories who support it (i.e., kopia repository). For more details, see [Backup Repository Configuration][1].  
+The size of cache may significantly impact on the performance. Specifically, if the cache size is too small, the restore throughput will be severely reduced and much more data would be downloaded from the backup storage.  
+By default, the cache data location is in the data mover pods' root disk. In some environments, the pods' root disk size is very limited, so a large cache size would cause the data mover pods evicted because of running out of ephemeral disk.  
+
+To cope with the problems and guarantee the data mover pods always run with a fine tuned local cache, Velero supports dedicated cache PVCs for data movement restore, for CSI snapshot data movement and fs-backup.  
+
+By default, Velero data mover pods run without cache PVCs. To enable cache PVC, you need to fill the cache PVC configurations in the node-agent configMap.  
+
+A sample of cache PVC configuration as part of the ConfigMap would look like:
+```json
+{
+    "cachePVC": {
+        "residentThresholdInMB": 1024,
+        "storageClass": "sc-wffc"
+    }
+}
+```
+
+To create the configMap, save something like the above sample to a file and then run below commands:  
+```shell
+kubectl create cm node-agent-config -n velero --from-file=<json file name>
+```
+
+A must-have field in the configuration is `storageClass` which tells Velero which storage class is used to provision the cache PVC. Velero relies on Kubernetes dynamic provision process to provision the PVC, static provision is not supported.  
+
+The cache PVC behavior could be further fine tuned through `residentThresholdInMB`. Its value is compared to the size of the backup, if the size is smaller than this value, no cache PVC would be created when restoring from the backup. This ensures that cache PVCs are not created in vain when the backup size is too small and can be accommodated in the data mover pods' root disk.  
+
+This configuration decides whether and how to provision cache PVCs, but it doesn't decide their size. Instead, the size is decided by the specific backup repository. Specifically, Velero asks a cache limit from the backup repository and uses this limit to calculate the cache PVC size.  
+The cache limit is decided by the backup repository itself, for Kopia repository, if `cacheLimitMB` is specified in the backup repository configuration, its value will be used; otherwise, a default limit (5 GB) is used.  
+Then Velero inflates the limit by 20% by considering the non-payload overheads and delay cache cleanup behavior varying on backup repositories.    
+
+Take Kopia repository and the above cache PVC configuration for example:  
+- When `cacheLimitMB` is not available for the repository, a 6GB cache PVC is created for the backup that is larger than 1GB; otherwise, no cache volume is created
+- When `cacheLimitMB` is specified as `10240` for the repository, a 12GB cache PVC is created for the backup that is larger than 1GB; otherwise, no cache volume is created  
+
+To enable both the node-agent configMap and backup repository configMap, specify the flags in velero installation by CLI:
+`velero install --node-agent-configmap=<ConfigMap-Name> --backup-repository-configmap=<ConfigMap-Name>`
+
+## Related Documentation
+
+- [Node-agent Configuration](supported-configmaps/node-agent-configmap.md) - Complete reference for all configuration options
+- [Node-agent Concurrency](node-agent-concurrency.md) - Configure concurrent operations per node
+- [Node Selection for Data Movement](data-movement-node-selection.md) - Configure which nodes run data movement
+- [Data Movement Pod Resource Configuration](data-movement-pod-resource-configuration.md) - Configure pod resources
+- [BackupPVC Configuration](data-movement-backup-pvc-configuration.md) - Configure backup storage
+- [RestorePVC Configuration](data-movement-restore-pvc-configuration.md) - Configure restore storage
+- [Cache PVC Configuration](data-movement-cache-volume.md) - Configure restore data mover storage
+
+[1]: backup-repository-configuration.md
@@ -0,0 +1,270 @@
+---
+title: "Node Selection for Data Movement"
+layout: docs
+---
+
+Velero node-agent is a DaemonSet hosting the data movement modules to complete the concrete work of backups/restores.
+Varying from the data size, data complexity, resource availability, the data movement may take a long time and remarkable resources (CPU, memory, network bandwidth, etc.) during the backup and restore.
+
+Velero data movement backup and restore support to constrain the nodes where it runs. This is helpful in below scenarios:
+- Prevent the data movement from running in specific nodes because users have more critical workloads in the nodes
+- Constrain the data movement to run in specific nodes because these nodes have more resources than others
+- Constrain the data movement to run in specific nodes because the storage allows volume/snapshot provisions in these nodes only
+
+Velero introduces a new section in the node-agent ConfigMap, called ```loadAffinity```, through which users can specify the nodes to/not to run data movement, in the affinity and anti-affinity flavors.
+
+**Important**: Currently, only the first element in the `loadAffinity` array is used. Any additional elements after the first one will be ignored. If you need to specify multiple conditions, combine them within a single `loadAffinity` element using both `matchLabels` and `matchExpressions`.
+
+### Example of Incorrect Usage (Multiple Array Elements)
+
+The following configuration will NOT work as intended:
+
+```json
+{
+    "loadAffinity": [
+        {
+            "nodeSelector": {
+                "matchLabels": {
+                    "environment": "production"
+                }
+            }
+        },
+        {
+            "nodeSelector": {
+                "matchLabels": {
+                    "disk-type": "ssd"
+                }
+            }
+        }
+    ]
+}
+```
+
+In this example, you might expect data movement to run only on nodes that are BOTH in production AND have SSD disks. However, **only the first condition (environment=production) will be applied**. The second array element will be completely ignored.
+
+### Correct Usage (Combined Conditions)
+
+To achieve the intended behavior, combine all conditions into a single array element:
+
+```json
+{
+    "loadAffinity": [
+        {
+            "nodeSelector": {
+                "matchLabels": {
+                    "environment": "production",
+                    "disk-type": "ssd"
+                }
+            }
+        }
+    ]
+}
+```
+
+If it is not there, a ConfigMap should be created manually. The ConfigMap should be in the same namespace where Velero is installed. If multiple Velero instances are installed in different namespaces, there should be one ConfigMap in each namespace which applies to node-agent in that namespace only. The name of the ConfigMap should be specified in the node-agent server parameter ```--node-agent-configmap```.
+The node-agent server checks these configurations at startup time. Therefore, users could edit this ConfigMap any time, but in order to make the changes effective, node-agent server needs to be restarted.
+
+The users can specify the ConfigMap name during velero installation by CLI:
+`velero install --node-agent-configmap=<ConfigMap-Name>`
+
+## Node Selection manner
+
+### Affinity
+Affinity configuration means allowing the data movement to run in the nodes specified. There are two ways to define it:
+-  It could be defined by `MatchLabels`. The labels defined in `MatchLabels` means a `LabelSelectorOpIn` operation by default, so in the current context, they will be treated as affinity rules. In the above sample, it defines to run data movement in nodes with label `beta.kubernetes.io/instance-type` of value `Standard_B4ms` (Run data movement in `Standard_B4ms` nodes only).
+- It could be defined by `MatchExpressions`. The labels are defined in `Key` and `Values` of `MatchExpressions` and the `Operator` should be defined as `LabelSelectorOpIn` or `LabelSelectorOpExists`. In the above sample, it defines to run data movement in nodes with label `kubernetes.io/hostname` of values `node-1`, `node-2` and `node-3` (Run data movement in `node-1`, `node-2` and `node-3` only).
+
+### Anti-affinity
+Anti-affinity configuration means preventing the data movement from running in the nodes specified. Below is the way to define it:
+- It could be defined by `MatchExpressions`. The labels are defined in `Key` and `Values` of `MatchExpressions` and the `Operator` should be defined as `LabelSelectorOpNotIn` or `LabelSelectorOpDoesNotExist`. In the above sample, it disallows data movement to run in nodes with label `xxx/critial-workload`.
+
+## How to create the LoadAffinity ConfigMap and apply to the NodeAgent
+
+To create the ConfigMap, save something like the above sample to a json file and then run below command:
+```
+kubectl create cm <ConfigMap name> -n velero --from-file=<json file name>
+```
+
+To provide the ConfigMap to node-agent, edit the node-agent DaemonSet and add the ```- --node-agent-configmap``` argument to the spec:
+1. Open the node-agent daemonset spec
+```
+kubectl edit ds node-agent -n velero
+```
+2. Add ```- --node-agent-configmap``` to ```spec.template.spec.containers```
+```
+spec:
+  template:
+    spec:
+      containers:
+      - args:
+        - --node-agent-configmap=<ConfigMap name>
+```
+
+## Examples
+
+### LoadAffinity
+Here is a sample of the ConfigMap with ```loadAffinity```:
+```json
+{
+    "loadAffinity": [
+        {
+            "nodeSelector": {
+                "matchLabels": {
+                    "beta.kubernetes.io/instance-type": "Standard_B4ms"
+                },
+                "matchExpressions": [
+                    {
+                        "key": "kubernetes.io/hostname",
+                        "values": [
+                            "node-1",
+                            "node-2",
+                            "node-3"
+                        ],
+                        "operator": "In"
+                    },
+                    {
+                        "key": "xxx/critial-workload",
+                        "operator": "DoesNotExist"
+                    }
+                ]          
+            }
+        }
+    ]
+}
+```
+
+This example demonstrates how to use both `matchLabels` and `matchExpressions` in the same single LoadAffinity element.
+
+### LoadAffinity with StorageClass (Note: Only First Element Used)
+
+``` json
+{
+    "loadAffinity": [
+        {
+            "nodeSelector": {
+                "matchLabels": {
+                    "beta.kubernetes.io/instance-type": "Standard_B4ms"
+                }
+            }
+        },
+        {
+            "nodeSelector": {
+                "matchExpressions": [
+                    {
+                        "key": "kubernetes.io/os",
+                        "values": [
+                            "linux"
+                        ],
+                        "operator": "In"
+                    }
+                ]
+            },
+            "storageClass": "kibishii-storage-class"
+        }
+    ]
+}
+```
+
+This sample demonstrates how the `loadAffinity` elements with `StorageClass` field and without `StorageClass` field setting work together. If the VGDP mounting volume is created from StorageClass `kibishii-storage-class`, its pod will run Linux nodes.
+
+The other VGDP instances will run on nodes, which instance type is `Standard_B4ms`.
+
+### LoadAffinity interacts with BackupPVC
+
+``` json
+{
+    "loadAffinity": [
+        {
+            "nodeSelector": {
+                "matchLabels": {
+                    "beta.kubernetes.io/instance-type": "Standard_B4ms"
+                }
+            },
+            "storageClass": "kibishii-storage-class"
+        },
+        {
+            "nodeSelector": {
+                "matchLabels": {
+                    "beta.kubernetes.io/instance-type": "Standard_B2ms"
+                }
+            },
+            "storageClass": "worker-storagepolicy"
+        }
+    ],
+    "backupPVC": {
+        "kibishii-storage-class": {
+            "storageClass": "worker-storagepolicy"
+        }
+    }
+}
+```
+
+Velero data mover supports to use different StorageClass to create backupPVC by [design](https://github.com/vmware-tanzu/velero/pull/7982).
+
+In this example, if the backup target PVC's StorageClass is `kibishii-storage-class`, its backupPVC should use StorageClass `worker-storagepolicy`. Because the final StorageClass is `worker-storagepolicy`, the backupPod uses the loadAffinity specified by `loadAffinity`'s elements with `StorageClass` field set to `worker-storagepolicy`. backupPod will be assigned to nodes, which instance type is `Standard_B2ms`.
+
+### LoadAffinity interacts with RestorePVC
+
+``` json
+{
+    "loadAffinity": [
+        {
+            "nodeSelector": {
+                "matchLabels": {
+                    "beta.kubernetes.io/instance-type": "Standard_B4ms"
+                }
+            },
+            "storageClass": "kibishii-storage-class"
+        }
+    ],
+    "restorePVC": {
+        "ignoreDelayBinding": false
+    }
+}
+```
+
+#### StorageClass's bind mode is WaitForFirstConsumer
+
+``` yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: kibishii-storage-class
+parameters:
+  svStorageClass: worker-storagepolicy
+provisioner: csi.vsphere.vmware.com
+reclaimPolicy: Delete
+volumeBindingMode: WaitForFirstConsumer
+```
+
+If restorePVC should be created from StorageClass `kibishii-storage-class`, and it's volumeBindingMode is `WaitForFirstConsumer`.
+Although `loadAffinityPerStorageClass` has a section matches the StorageClass, the `ignoreDelayBinding` is set `false`, the Velero exposer will wait until the target Pod scheduled to a node, and returns the node as SelectedNode for the restorePVC.
+As a result, the `loadAffinityPerStorageClass` will not take affect.
+
+#### StorageClass's bind mode is Immediate
+
+``` yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: kibishii-storage-class
+parameters:
+  svStorageClass: worker-storagepolicy
+provisioner: csi.vsphere.vmware.com
+reclaimPolicy: Delete
+volumeBindingMode: Immediate
+```
+
+Because the StorageClass volumeBindingMode is `Immediate`, although `ignoreDelayBinding` is set to `false`, restorePVC will not be created according to the target Pod.
+
+The restorePod will be assigned to nodes, which instance type is `Standard_B4ms`.
+
+## Related Documentation
+
+- [Node-agent Configuration](supported-configmaps/node-agent-configmap.md) - Complete reference for all configuration options
+- [Node-agent Concurrency](node-agent-concurrency.md) - Configure concurrent operations per node
+- [Node Selection for Data Movement](data-movement-node-selection.md) - Configure which nodes run data movement
+- [Data Movement Pod Resource Configuration](data-movement-pod-resource-configuration.md) - Configure pod resources
+- [BackupPVC Configuration](data-movement-backup-pvc-configuration.md) - Configure backup storage
+- [RestorePVC Configuration](data-movement-restore-pvc-configuration.md) - Configure restore storage
+- [Cache PVC Configuration](data-movement-cache-volume.md) - Configure restore data mover storage
@@ -0,0 +1,173 @@
+---
+title: "Data Movement Pod Resource Configuration"
+layout: docs
+---
+
+During [CSI Snapshot Data Movement][1], Velero built-in data mover launches data mover pods to run the data transfer.  
+During [fs-backup][2], Velero also launches data mover pods to run the data transfer.  
+The data transfer is a time and resource consuming activity.  
+
+Velero by default uses the [BestEffort QoS][2] for the data mover pods, which guarantees the best performance of the data movement activities. On the other hand, it may take lots of cluster resource, i.e., CPU, memory, and how many resources are taken is decided by the concurrency and the scale of data to be moved.  
+
+If the cluster nodes don't have sufficient resource, Velero also allows you to customize the resources for the data mover pods.    
+Note: If less resources are assigned to data mover pods, the data movement activities may take longer time; or the data mover pods may be OOM killed if the assigned memory resource doesn't meet the requirements. Consequently, the dataUpload/dataDownload may run longer or fail.  
+
+Refer to [Performance Guidance][3] for a guidance of performance vs. resource usage, and it is highly recommended that you perform your own testing to find the best resource limits for your data.  
+
+Velero introduces a new section in the node-agent configMap, called ```podResources```, through which you can set customized resources configurations for data mover pods.  
+If it is not there, a configMap should be created manually. The configMap should be in the same namespace where Velero is installed. If multiple Velero instances are installed in different namespaces, there should be one configMap in each namespace which applies to node-agent in that namespace only. The name of the configMap should be specified in the node-agent server parameter ```--node-agent-configmap```.  
+Node-agent server checks these configurations at startup time. Therefore, you could edit this configMap any time, but in order to make the changes effective, node-agent server needs to be restarted.  
+
+### Pod Resources
+Here is a sample of the configMap with ```podResources```:  
+```json
+{
+    "podResources": {
+        "cpuRequest": "1000m",
+        "cpuLimit": "1000m",
+        "memoryRequest": "512Mi",
+        "memoryLimit": "1Gi"        
+    }
+}
+```
+
+The string values in ```podResources``` must match Kubernetes Quantity expressions; for each resource, the "request" value must not be larger than the "limit" value. Otherwise, if any one of the values fail, the entire ```podResources``` configuration will be ignored (so the default policy will be used).  
+
+To create the configMap, save something like the above sample to a json file and then run below command:
+```
+kubectl create cm node-agent-config -n velero --from-file=<json file name>
+```
+
+To provide the configMap to node-agent, edit the node-agent daemonset and add the ```- --node-agent-configmap``` argument to the spec:
+1. Open the node-agent daemonset spec  
+```
+kubectl edit ds node-agent -n velero
+```
+2. Add ```- --node-agent-configmap``` to ```spec.template.spec.containers```  
+```
+spec:
+  template:
+    spec:
+      containers:
+      - args:
+        - --node-agent-configmap=<configMap name>
+```
+
+### Priority Class
+
+Data mover pods will use the priorityClassName configured in the node-agent configmap. The priorityClassName for data mover pods is configured through the node-agent configmap (specified via the `--node-agent-configmap` flag), while the node-agent daemonset itself uses the priority class set by the `--node-agent-priority-class-name` flag during Velero installation.
+
+#### When to Use Priority Classes
+
+**Higher Priority Classes** (e.g., `system-cluster-critical`, `system-node-critical`, or custom high-priority):
+- When you have dedicated nodes for backup operations
+- When backup/restore operations are time-critical
+- When you want to ensure data mover pods are scheduled even during high cluster utilization
+- For disaster recovery scenarios where restore speed is critical
+
+**Lower Priority Classes** (e.g., `low-priority` or negative values):
+- When you want to protect production workload performance
+- When backup operations can be delayed during peak hours
+- When cluster resources are limited and production workloads take precedence
+- For non-critical backup operations that can tolerate delays
+
+#### Consequences of Priority Class Settings
+
+**High Priority**:
+- ✅ Data mover pods are more likely to be scheduled quickly
+- ✅ Less likely to be preempted by other workloads
+- ❌ May cause resource pressure on production workloads
+- ❌ Could lead to production pod evictions in extreme cases
+
+**Low Priority**:
+- ✅ Production workloads are protected from resource competition
+- ✅ Cluster stability is maintained during backup operations
+- ❌ Backup/restore operations may take longer to start
+- ❌ Data mover pods may be preempted, causing backup failures
+- ❌ In resource-constrained clusters, backups might not run at all
+
+#### Example Configuration
+
+To configure priority class for data mover pods, include it in your node-agent configmap:
+
+```json
+{
+    "priorityClassName": "backup-priority"
+}
+```
+
+First, create the priority class in your cluster:
+
+```yaml
+apiVersion: scheduling.k8s.io/v1
+kind: PriorityClass
+metadata:
+  name: backup-priority
+value: 1000
+globalDefault: false
+description: "Priority class for Velero data mover pods"
+```
+
+Then create or update the node-agent configmap:
+
+```bash
+kubectl create cm node-agent-config -n velero --from-file=node-agent-config.json
+```
+
+**Note**: If the specified priority class doesn't exist in the cluster when data mover pods are created, the pods will fail to schedule. Velero validates the priority class at startup and logs a warning if it doesn't exist, but the pods will still attempt to use it.
+
+### Pod Labels
+Add customized labels for data mover pods to support third-party integrations and environment-specific requirements.
+
+If `podLabels` is configured, it supersedes Velero's [in-tree third-party labels](https://github.com/vmware-tanzu/velero/blob/94f64639cee09c5caaa65b65ab5f42175f41c101/pkg/util/third_party.go#L19-L21).
+If `podLabels` is not configured, Velero uses the in-tree third-party labels for compatibility with common cloud providers and networking solutions.
+
+The configurations work for DataUpload, DataDownload, PodVolumeBackup, and PodVolumeRestore pods.
+
+#### Configuration Example
+```json
+{
+  "podLabels": {
+    "spectrocloud.com/connection": "proxy",
+    "gnp/k8s-api-access": "",
+    "gnp/monitoring-client": "",
+    "np/s3-backup-backend": "",
+    "cp/inject-truststore": "extended"
+  }
+}
+```
+
+### Pod Annotations
+Add customized annotations for data mover pods to support third-party integrations and pod-level configuration.
+
+If `podAnnotations` is configured, it supersedes Velero's [in-tree third-party annotations](https://github.com/vmware-tanzu/velero/blob/94f64639cee09c5caaa65b65ab5f42175f41c101/pkg/util/third_party.go#L23-L25).
+If `podAnnotations` is not configured, Velero uses the in-tree third-party annotations for compatibility with common cloud providers and networking solutions.
+
+The configurations work for DataUpload, DataDownload, PodVolumeBackup, and PodVolumeRestore pods.
+
+#### Configuration Example
+```json
+{
+  "podAnnotations": {
+    "iam.amazonaws.com/role": "velero-backup-role",
+    "vault.hashicorp.com/agent-inject": "true",
+    "prometheus.io/scrape": "true",
+    "custom.company.com/environment": "production"
+  }
+}
+```
+
+## Related Documentation
+
+- [Node-agent Configuration](supported-configmaps/node-agent-configmap.md) - Complete reference for all configuration options
+- [Node-agent Concurrency](node-agent-concurrency.md) - Configure concurrent operations per node
+- [Node Selection for Data Movement](data-movement-node-selection.md) - Configure which nodes run data movement
+- [Data Movement Pod Resource Configuration](data-movement-pod-resource-configuration.md) - Configure pod resources
+- [BackupPVC Configuration](data-movement-backup-pvc-configuration.md) - Configure backup storage
+- [RestorePVC Configuration](data-movement-restore-pvc-configuration.md) - Configure restore storage
+- [Cache PVC Configuration](data-movement-cache-volume.md) - Configure restore data mover storage
+
+[1]: csi-snapshot-data-movement.md
+[2]: file-system-backup.md
+[3]: https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/
+[4]: performance-guidance.md
--- a/Show More
+++ b/Show More
				`@@ -1 +0,0 @@`
				Add `--apply` flag to `install` command, allowing usage of Kubernetes apply to make changes to existing installs
				`@@ -1 +0,0 @@`
				`feat: Enhance BackupStorageLocation with Secret-based CA certificate support`
				`@@ -1 +0,0 @@`
				`Fix issue #7725, add design for backup repo cache configuration`
				`@@ -1 +0,0 @@`
				`Add VolumePolicy support for PVC Phase conditions to allow skipping Pending PVCs`
				`@@ -1 +0,0 @@`
				`feat: Permit specifying annotations for the BackupPVC`
				`@@ -1 +0,0 @@`
				`Remove labels associated with previous backups`
				`@@ -1 +0,0 @@`
				`Fix issue #9229, don't attach backupPVC to the source node`
				`@@ -1 +0,0 @@`
				`Update AzureAD Microsoft Authentication Library to v1.5.0`
				`@@ -1 +0,0 @@`
				`Protect VolumeSnapshot field from race condition during multi-thread backup`
				`@@ -1 +0,0 @@`
				`Fix repository maintenance jobs to inherit allowlisted tolerations from Velero deployment`