Restore to Kubernetes Cluster

CommunityEnterprise

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 perform a batch restore of entire whole namespace or even multiple namespaces.

If you select a single object to restore, it is restored as is without any dependent objects. In most cases (Config Maps, Secrets, Services, etc.), this is fine and restore succeeds. When you restore compound objects (Pods, Deployments, Ingress, etc.),the restored objects may not become ready unless all dependencies are also restored. In these cases, ensure you select all required objects.

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 generate new ones. Starting with Bacula Enterprise version 16.0.14, there is no need for concern as the plugin handles the restore seamlessly.

In Kubernetes, a successful object restore does not necessarily mean the service comes online immediately. Additional monitoring and troubleshooting may 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 of the above issues must be resolved by the Kubernetes administrator. Once resolved, the objects should come online automatically. If not, you may need to repeat the restore to redeploy the object configuration.

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