Documentation

Repository Maintenance

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.

Settings

Resource Limitation

You can customize the maintenance job resource requests and limit when using the velero install CLI command.

Log

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.

Num of Keeping Latest Maintenance Jobs

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>

Default Repository Maintenance Frequency

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.

Others

Maintenance jobs will inherit the labels, annotations, tolerations, affinity, nodeSelector, service account, image, environment variables, cloud-credentials etc. from Velero deployment.

Getting Started

To help you get started, see the documentation.