Restore to Kubernetes Cluster

To use this restore method, the where=/ parameter of a Bacula restore command is used. You can select any supported Kubernetes Object to restore, or batch restore the whole namespace or even multiple namespaces. If you select a single object 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. When you restore compound objects (Pods, Deployments, Ingress, etc.), they won’t be ready unless all dependencies are resolved. In this case you should make sure that you select all required objects to restore. Furthermore, it is important to note that certain containers such as Postgresql, MySQL, etc., require pvc data. In the event that these containers do not locate data within pvc, they will generate new ones. From Bacula Enterprise version 16.0.14, there is no need for concern as the plugin will handle the restore seamlessly.

In Kubernetes, a successful object 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 Kubernetes administrator. When all issues are resolved, the object should automatically come online. If not, it may be necessary to repeat a restore to redeploy the Object configuration.

The Kubernetes Plugin does not wait for a Object to come online during restore. It checks the Object creation or replace operation status and reports any errors in the job log. The only exception to this is PVC Data restore, when the Kubernetes Plugin will wait for a successful archive data restore. From Bacula Enterprise version 16.0.14, this operation is always executed before create compound components (Pods, Deployments, etc.).