This is the documentation for the latest development version of Velero. Both code and docs may be unstable, and these docs are not guaranteed to be up to date or correct. See the latest version.

Edit this page


These tips can help you troubleshoot known issues. If they don’t help, you can file an issue, or talk to us on the #velero channel on the Kubernetes Slack server.

See also:

General troubleshooting information

You can use the velero bug command to open a Github issue by launching a browser window with some prepopulated values. Values included are OS, CPU architecture, kubectl client and server versions (if available) and the velero client version. This information isn’t submitted to Github until you click the Submit new issue button in the Github UI, so feel free to add, remove or update whatever information you like.

Some general commands for troubleshooting that may be helpful:

Getting velero debug logs

You can increase the verbosity of the Velero server by editing your Velero deployment to look like this:

kubectl edit deployment/velero -n velero
     - name: velero
         - /velero
         - server
         - --log-level # Add this line
         - debug       # Add this line

Known issue with restoring LoadBalancer Service

Because of how Kubernetes handles Service objects of type=LoadBalancer, when you restore these objects you might encounter an issue with changed values for Service UIDs. Kubernetes automatically generates the name of the cloud resource based on the Service UID, which is different when restored, resulting in a different name for the cloud load balancer. If the DNS CNAME for your application points to the DNS name of your cloud load balancer, you’ll need to update the CNAME pointer when you perform a Velero restore.

Alternatively, you might be able to use the Service’s spec.loadBalancerIP field to keep connections valid, if your cloud provider supports this value. See the Kubernetes documentation about Services of Type LoadBalancer.

Miscellaneous issues

Velero reports custom resource not found errors when starting up.

Velero’s server will not start if the required Custom Resource Definitions are not found in Kubernetes. Run velero install again to install any missing custom resource definitions.

velero backup logs returns a SignatureDoesNotMatch error

Downloading artifacts from object storage utilizes temporary, signed URLs. In the case of S3-compatible providers, such as Ceph, there may be differences between their implementation and the official S3 API that cause errors.

Here are some things to verify if you receive SignatureDoesNotMatch errors:

Velero (or a pod it was backing up) restarted during a backup and the backup is stuck InProgress

Velero cannot currently resume backups that were interrupted. Backups stuck in the InProgress phase can be deleted with kubectl delete backup <name> -n <velero-namespace>. Backups in the InProgress phase have not uploaded any files to object storage.