Resuming a Restore

Even though a Restore is designed to be robust and contains retries and error handling, a Restore can be interrupted for numerous reasons:

• Kubernetes terminated the Pod due to resource constraints.
• You deleted the associated Pod or Job.
• The process failed for some other reason. In these cases, you may want to resume the Restore from where it left off.

Another situation where resuming a restore is useful is when you have restored data to another environment, perhaps while a Backup was running, and then you want to restore more data at a later time.

In any case, you can restart and resume the Restore from the last successful point.

How to resume a Restore

You can simply resume the Restore by deleting the associated Job.

$ kubectl delete job $(kubectl get restore <restore-name> -o jsonpath='{.metadata.annotations.io\.kannika/restore-job-name}')

The name of the Job is stored in the io.kannika/restore-job-name annotation on the Restore.

Note

If the resource was created by a previous version of Kannika then you may also find a label with that same name. Some labels have been replaced by annotations in version 0.11

If the Restore is enabled, Kannika Armory will automatically regenerate a new Job and restart the Restore process.

How does Kannika Armory track the progress of a Restore?

The status of a Restore is tracked by the Restore Report.

Restarting from scratch

If you want to restart the Restore from scratch, you must:

• first delete the Restore Report associated with the Restore,
• then delete the Job associated with the Restore.

$ kubectl delete pvc $(kubectl get restore <restore-name> -o jsonpath='{.metadata.annotations.io\.kannika/report-pvc-name}')
$ kubectl delete job $(kubectl get restore <restore-name> -o jsonpath='{.metadata.annotations.io\.kannika/restore-job-name}')