mirror of
https://github.com/vmware-tanzu/velero.git
synced 2026-01-07 13:55:20 +00:00
add doc for backup repo config
Signed-off-by: Lyndon-Li <lyonghui@vmware.com>
This commit is contained in:
@@ -642,7 +642,7 @@ Velero node-agent uses [BestEffort as the QoS][14] for node-agent pods (so no CP
|
||||
If you want to constraint the CPU/memory usage, you need to [customize the resource limits][15]. The CPU/memory consumption is always related to the scale of data to be backed up/restored, refer to [Performance Guidance][16] 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, the cache is stored in the node-agent pod's root file system and the cleanup is triggered for the data/metadata that are older than 10 minutes (not configurable at present). So you should prepare enough disk space, otherwise, the node-agent pod may be evicted due to running out of the ephemeral storage.
|
||||
For Kopia repository, the cache is stored in the node-agent pod's root file system. Velero allows you to configure a limit of the cache size so that the node-agent pod won't be evicted due to running out of the ephemeral storage. For more details, check [Backup Repository Configuration][18].
|
||||
|
||||
## Restic Deprecation
|
||||
|
||||
@@ -695,3 +695,4 @@ In the output of `velero backup describe` command for a backup with fs-backup:
|
||||
[15]: customize-installation.md#customize-resource-requests-and-limits
|
||||
[16]: performance-guidance.md
|
||||
[17]: https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md#deprecation-policy
|
||||
[18]: backup-repository-configuration.md
|
||||
|
||||
Reference in New Issue
Block a user