Restore to an OpenShift Cluster

Enterprise

Bacula Enterprise Only

This solution is only available for Bacula Enterprise. For subscription inquiries, please reach out to sales@baculasystems.com.

To use this restore method, the where=/ parameter of a Bacula restore command is used. You can select any supported OpenShift Resource to restore, or batch restore the whole namespace or even multiple namespaces. If you select a single resource to restore it will be restored as is without any dependent objects. In most cases, for (Config Maps, Secrets, Services, etc.) this is fine and restore will always succeed. On the other hand, compound objects (Pods, Deployments, etc.) won’t be ready unless all dependencies are resolved during the restore. In this case you should make sure that you select all required resources to restore.

In OpenShift, a successful resource restore doesn’t necessarily result in the service successfully coming online. In some cases further monitoring and investigation will be required. For example:

Container image is unavailable.
Volume Claim cannot provision new volume.
Untrusted Image Repository.
Infrastructure limits exceeded, i.e. a number of Pods or Memory allocations.
etc…

All example cases above must be resolved by the OpenShift administrator. When all issues are resolved, the resource should automatically come online. If not, it may be necessary to repeat a restore to redeploy the Resource configuration.

The OpenShift plugin does not wait for a Resource to come online during restore. It checks the Resource creation or replace operation status and reports any errors in the job log. The only exception to this is PVC Data restore, when the OpenShift plugin will wait for a successful archive data restore. This operation is always executed at the end of the namespace recovery (when pvcdata is restored with other K8S objects) and should wait for proper PVC mount.