Skip to content
Kannika

    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.

    Terminal window
    $ kubectl delete job <restore-job-name>

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

    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?

    Kannika Armory tracks the status of a Restore by continuously writing it to a Restore Report.

    The report is a file that contains the status of the restore process. It is continuously updated as the restore process progresses, and tracks any errors that occur during the restore process.

    Restore report persistence

    The restore reports are written to a persistent volume. The process writes the reports to the /kannika/reports/<report-name> directory, which is persisted across runs. The operator mounts a persistent volume onto the Restore to persist the /kannika/reports directory between runs, using a PersistentVolumeClaim.

    The PersistentVolumeClaim is tracked by the io.kannika/report-pvc-name label on the Restore. It has the following format: <restore-name>-report-<random-id> This label is used to ensure that the Restore has a unique PersistentVolumeClaim for its reports.

    The PersistentVolumeClaim is created when the Restore is created, and is automatically deleted when the Restore is deleted.

    Restarting from scratch

    If you want to restart the Restore from scratch, you have two options:

    1. You can simply delete the Restore and create a new one.

    2. You can delete the PersistentVolumeClaim associated with the Restore. This will delete the Restore Report and allow you to start the Restore from scratch. Note that Kubernetes adds the finalizer kubernetes.io/pvc-protection to the PersistentVolumeClaim, preventing it from being deleted it if it is still in use.

      Terminal window
      $ kubectl delete pvc <restore-name>-report-<random-id>