Pre-job and Post-job Hooks

Backup and restore tasks running on an edge can use pre-job and post-job hooks to perform actions immediately before and after the task. Hooks are useful when a workload needs preparation before a backup or restore, or cleanup afterward. For example, a pre-job hook can quiesce a database or mount a snapshot, while a post-job hook can resume the database or remove the snapshot.

Hooks are scripts that are managed on the edge host. The edge only executes scripts from the directory configured with -scripts-dir. The task refers to a script by its file name; it cannot provide an arbitrary path. File names containing path separators, . or .. are rejected. An edge without a configured scripts directory does not accept hooks.

The pre-job hook runs before the backup or restore begins. If it fails, the task is aborted and the backup or restore does not start. The post-job hook runs after the job once a pre-job hook has completed, regardless of whether the backup or restore itself succeeded. It also runs when the job is cancelled. This ensures that cleanup or recovery actions can still take place after a failed or cancelled job.

A failure in the post-job hook causes the task to be reported as failed, even if the backup or restore itself succeeded. The backup is not discarded in this case. For example, if a post-job hook is responsible for resuming a database and that operation fails, the task reports the hook failure so that the resulting state can be investigated.

Hook scripts inherit the environment of the edge process and receive additional variables describing the current task:

• PLAKAR_WORK_ID: identifier of the work item.
• PLAKAR_OP: operation being performed.
• PLAKAR_HOOK: pre_job or post_job.

This allows the same script to be used by multiple tasks and to distinguish between the pre-job and post-job phases.

The output of each hook appears in the job’s output alongside the task’s own. When a hook fails, the end of its output is also included in the error reported to the Control Plane, providing context for diagnosing the failure.

Hooks on Kubernetes

On Kubernetes, hook scripts are provided through a ConfigMap configured with scripts.configMapName. The chart mounts the ConfigMap as a read-only, executable directory at scripts.mountPath and passes that path to the edge using -scripts-dir. See Configure the chart.