Documentation for version v1.14 is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.
From v1.14 on, Velero decouples repository maintenance from the Velero server by launching a k8s job to do maintenance when needed, to mitigate the impact on the Velero server during backups.
Before v1.14.0, Velero performs periodic maintenance on the repository within Velero server pod, this operation may consume significant CPU and memory resources in some cases, leading to Velero server being killed by OOM. Now Velero will launch independent k8s jobs to do the maintenance in Velero installation namespace.
For repository maintenance jobs, there’s no limit on resources by default. You could configure the job resource limitation based on target data to be backed up.
You can customize the maintenance job resource requests and limit when using the velero install CLI command.
Maintenance job inherits the log level and log format settings from the Velero server, so if the Velero server enabled the debug log, the maintenance job will also open the debug level log.
Velero will keep one specific number of the latest maintenance jobs for each repository. By default, we only keep 3 latest maintenance jobs for each repository, and Velero support configures this setting by the below command when Velero installs:
velero install --keep-latest-maintenance-jobs <NUM>
The frequency of running maintenance jobs could be set by the below command when Velero is installed:
velero install --default-repo-maintain-frequency <DURATION>
For Kopia the default maintenance frequency is 1 hour, and Restic is 7 * 24 hours.
Maintenance jobs will inherit the labels, annotations, tolerations, affinity, nodeSelector, service account, image, environment variables, cloud-credentials etc. from Velero deployment.
To help you get started, see the documentation.